Page 60 of 91
Re: "Ночные" сборки KolibriOS
Posted: Mon Jun 24, 2013 11:45 pm
by DmitrySokolowsky
Спасибо за исправление, теперь не падает.
Re: "Ночные" сборки KolibriOS
Posted: Wed Jun 26, 2013 8:53 pm
by CleverMouse
IgorA wrote:обнаружил что после ревизии 3508 на нетбуке (Acer Aspire One 533) смазанный экран
Для отчётности: после некоторого числа различных тестов через ЛС вариантов драйверов, которые
IgorA любезно проводил, я исправила проблему с vidintel в r3708.
Re: "Ночные" сборки KolibriOS
Posted: Thu Jun 27, 2013 7:25 pm
by Mario_r4
SVN r.3713 в приложении
@PANEL горячая комбинация "PrintScreen" изменена на "Ctrl+PrintScreen", поскольку происходит ложное срабатывание запуска при нажатии "*" (звездочка) на блоке дополнительных цифровых клавиш клавиатуры (справа).
Случается это потому, что в функция ядра (ф. 66.4) занимающаяся горячими клавишами не предусматривает передачу кода Ext (224). Собственно "PrintScreen" от "*", только наличием кода Ext (224) и отличается. Соответсвенно самым простым и логичным выводом было поменять горячую комбинацию.
Если кто-нибудь не согласен с моим решением и имеет сильное желание доработать системную ф. 66.4, с обязательным сохранением обратной совместимости, то я никоим образом не возражаю.
Re: "Ночные" сборки KolibriOS
Posted: Fri Jun 28, 2013 6:22 am
by Mario_r4
SVN r. 3723 в образ ISO ночной сборки (для всех языковых сборок) добавлен просмотрщик картинок
zSea. Все ассоциации из файловых менеджеров по прежнему оставлены на просмотрщике картинок KIV.
Re: "Ночные" сборки KolibriOS
Posted: Fri Jun 28, 2013 8:50 pm
by Mario_r4
SVN r. 3729 - видеоплеер Fplay в ночной сборке заменен на
ftp://ftp.kolibrios.org/users/Serge/new ... ll-i586mmx - это позволяет запускать видел на большем количестве компьютеров. Спасибо Serge за пересборку под MMX вместо SSE.
Re: "Ночные" сборки KolibriOS
Posted: Sun Jun 30, 2013 10:34 am
by 0CodErr
Вот запустил в VirtualBox svn3734-img. Теперь у меня ещё указатель мыши стал иногда мерцать, а двигается рывками.
Но теперь стал лучше проявляться такой баг:
запускаем docpack,
нажимаем в нём на кнопку с надписью "SYSFUNCS.TXT"(этот файл больше — проще повторить),
и тут же начинаем быстро-быстро водить мышью.
В CPU заметно, что TINYPAD запустился, но он тут же вырубается.
Если закрыть нормально запущенный TINYPAD, нажав на "крестик", то на доске отладки пишется: "destroy app object". А тут ничего не пишется, просто вырубается.
В Bochs тоже так бывает, но повторить сложнее, наверное, мышь эмулируется по-другому.
Re: "Ночные" сборки KolibriOS
Posted: Sun Jun 30, 2013 10:43 am
by Mario_r4
0CodErr
А на вкладке лога относящейся к ядру что-нибудь пишется? PageFault к примеру? Вообще хороши походом было бы выложить лог вместе с сообщением об ошибке.
Re: "Ночные" сборки KolibriOS
Posted: Sun Jun 30, 2013 11:22 am
by 0CodErr
Mario_r4
Никаких сообщений об ошибке не пишется, почти как если бы отсутствовала какая-то необходимая библиотека. TINYPAD появляется в CPU и тут же исчезает.
Пробовал запускать TINYPAD с параметром из RUN — бага не было, только очень медленная отрисовка.
Re: "Ночные" сборки KolibriOS
Posted: Sun Jun 30, 2013 3:55 pm
by Mario_r4
0CodErr wrote:Mario_r4
Никаких сообщений об ошибке не пишется, почти как если бы отсутствовала какая-то необходимая библиотека. TINYPAD появляется в CPU и тут же исчезает.
Пробовал запускать TINYPAD с параметром из RUN — бага не было, только очень медленная отрисовка.
Библиотеки тут явно не причем. Имхается мне проблема с IPC. Потому что для передачи в Tinypad из Docpack используется именно IPC, реализация ф. 60 могла быть затронута при внедрении нового планировщика. Еще раз оговорюсь, что это всего лишь гипотеза, относительно планировщика, чтобы автор кода не выражал в очередной раз возмущенное раздражение. Для проверки нужно взять ревизии 3533 и 3534 и проверить каждую описанным способом.
Есть два варианта решения - либо разбираться что случилось с IPC, либо переписать все на использование именованной памяти (ф.68.22, 68.23) и при старте Tynipad передавать указатель на нее. Второе решение явно ускорит процесс передачи информации, но сожрет дополнительную память во время открытия, если передавать весь кусок за один раз.
Re: "Ночные" сборки KolibriOS
Posted: Mon Jul 01, 2013 8:15 am
by 0CodErr
Наверное, не в планировщике дело.
В прошлый раз я проверил ещё на 3534 и 3503.
В Bochs баг был в обеих сборках. А в VirtualBox я не успеваю подвигать мышкой до отрисовки TINYPAD(эти сборки быстрее работают).
Тогда, получается, на реальной системе этот баг тем более не должен проявляться?
Re: "Ночные" сборки KolibriOS
Posted: Mon Jul 01, 2013 8:33 am
by Mario_r4
0CodErr wrote:Тогда, получается, на реальной системе этот баг тем более не должен проявляться?
Я не знаю, баг выявил ты и у тебя есть повторяемость. Я такого бага не наблюдал.
Re: "Ночные" сборки KolibriOS
Posted: Tue Jul 02, 2013 7:04 pm
by CleverMouse
Mario_r4 wrote:0CodErr wrote:Mario_r4
Никаких сообщений об ошибке не пишется, почти как если бы отсутствовала какая-то необходимая библиотека. TINYPAD появляется в CPU и тут же исчезает.
Пробовал запускать TINYPAD с параметром из RUN — бага не было, только очень медленная отрисовка.
Библиотеки тут явно не причем. Имхается мне проблема с IPC. Потому что для передачи в Tinypad из Docpack используется именно IPC, реализация ф. 60 могла быть затронута при внедрении нового планировщика. Еще раз оговорюсь, что это всего лишь гипотеза, относительно планировщика, чтобы автор кода не выражал в очередной раз возмущенное раздражение. Для проверки нужно взять ревизии 3533 и 3534 и проверить каждую описанным способом.
Есть два варианта решения - либо разбираться что случилось с IPC, либо переписать все на использование именованной памяти (ф.68.22, 68.23) и при старте Tynipad передавать указатель на нее. Второе решение явно ускорит процесс передачи информации, но сожрет дополнительную память во время открытия, если передавать весь кусок за один раз.
Проблема не с IPC. Проблема в DOCPACK. Вот фрагмент кода DOCPACK:
Code: Select all
mcall 70,fileinfo
mov ecx,eax
mcall 5,20
pop edx
mcall 60,2
DOCPACK запускает tinypad, ждёт 20 тиков, посылает IPC. Если за это время tinypad не успел инициализироваться и определить память для IPC - сообщение уходит в никуда. Если tinypad успел инициализироваться за один тик - остальные 19 тиков он будет тупо ждать.
Планировщик просто подчёркивает некорректный код: указатель мыши отрисовывается с наивысшим приоритетом, если в VirtualBox отрисовка по каким-то причинам тормозит - менее приоритетным процессам придётся подождать.
Аналогичный эффект был бы, если со старым планировщиком запустить пару десятков демок типа trantest - но кому какое дело, как ведёт себя система под нагрузкой, правильно?
Re: "Ночные" сборки KolibriOS
Posted: Tue Jul 02, 2013 8:20 pm
by CleverMouse
0CodErr wrote:Вот запустил в VirtualBox svn3734-img. Теперь у меня ещё указатель мыши стал иногда мерцать, а двигается рывками.
Конфигурацию VirtualBox в студию - файлы .vbox и все ассоциированные диски. Чтобы инициализация процесса с рамдиска без нагрузки длилась > 200 мс - это надо очень постараться.
Re: "Ночные" сборки KolibriOS
Posted: Tue Jul 02, 2013 9:48 pm
by Mario_r4
CleverMouse wrote:
Проблема не с IPC. Проблема в DOCPACK. Вот фрагмент кода DOCPACK
Как я уже заранее оговорился - это была гипотеза. Хорошо, что найдена настоящая причина.
Re: "Ночные" сборки KolibriOS
Posted: Wed Jul 03, 2013 6:51 pm
by 0CodErr
CleverMouse wrote:Чтобы инициализация процесса с рамдиска без нагрузки длилась > 200 мс - это надо очень постараться.
Это происходит, вероятно, из-за движения мыши. Если мышью не водить во время запуска, то запустится гораздо быстрее.
Как ты выше и написала:
CleverMouse wrote:указатель мыши отрисовывается с наивысшим приоритетом
Я предположил, что дело может быть в способе эмуляции, потому что, например, в Qemu таких тормозов нет. Ну, то есть, все сборки там "тормозят" более менее одинаково.
Я пробовал отключать в VirtualBox все диски кроме floppy с образом — лучше не стало.
Вот результаты MGB для 3503, 3535, 3734 при разрешении экрана 1024x768 на VirtualBox, указатель мыши находился вне области окна:
Spoiler:
-
3734_vs_3535.PNG (11.72 KiB)
Viewed 4298 times
-
3503_vs_3535.PNG (11.41 KiB)
Viewed 4298 times
А в 2696, наверное, алгоритм тестирования был другим, потому что там уж очень сильные отличия.
Может быть, стоит проводить такие тесты для каждой ночной сборки на реальной системе?