"Ночные" сборки KolibriOS

Mon Jun 24, 2013 11:45 pm

Спасибо за исправление, теперь не падает.

Wed Jun 26, 2013 8:53 pm

IgorA wrote:обнаружил что после ревизии 3508 на нетбуке (Acer Aspire One 533) смазанный экран

Для отчётности: после некоторого числа различных тестов через ЛС вариантов драйверов, которые IgorA любезно проводил, я исправила проблему с vidintel в r3708.

Thu Jun 27, 2013 7:25 pm

SVN r.3713 в приложении @PANEL горячая комбинация "PrintScreen" изменена на "Ctrl+PrintScreen", поскольку происходит ложное срабатывание запуска при нажатии "*" (звездочка) на блоке дополнительных цифровых клавиш клавиатуры (справа).

Случается это потому, что в функция ядра (ф. 66.4) занимающаяся горячими клавишами не предусматривает передачу кода Ext (224). Собственно "PrintScreen" от "*", только наличием кода Ext (224) и отличается. Соответсвенно самым простым и логичным выводом было поменять горячую комбинацию.

Если кто-нибудь не согласен с моим решением и имеет сильное желание доработать системную ф. 66.4, с обязательным сохранением обратной совместимости, то я никоим образом не возражаю.

Fri Jun 28, 2013 6:22 am

SVN r. 3723 в образ ISO ночной сборки (для всех языковых сборок) добавлен просмотрщик картинок zSea. Все ассоциации из файловых менеджеров по прежнему оставлены на просмотрщике картинок KIV.

Fri Jun 28, 2013 8:50 pm

SVN r. 3729 - видеоплеер Fplay в ночной сборке заменен на ftp://ftp.kolibrios.org/users/Serge/new ... ll-i586mmx - это позволяет запускать видел на большем количестве компьютеров. Спасибо Serge за пересборку под MMX вместо SSE.

Sun Jun 30, 2013 10:34 am

Вот запустил в VirtualBox svn3734-img. Теперь у меня ещё указатель мыши стал иногда мерцать, а двигается рывками.
Но теперь стал лучше проявляться такой баг:
запускаем docpack,
нажимаем в нём на кнопку с надписью "SYSFUNCS.TXT"(этот файл больше — проще повторить),
и тут же начинаем быстро-быстро водить мышью.
В CPU заметно, что TINYPAD запустился, но он тут же вырубается.

Если закрыть нормально запущенный TINYPAD, нажав на "крестик", то на доске отладки пишется: "destroy app object". А тут ничего не пишется, просто вырубается.

В Bochs тоже так бывает, но повторить сложнее, наверное, мышь эмулируется по-другому.

Sun Jun 30, 2013 10:43 am

0CodErr
А на вкладке лога относящейся к ядру что-нибудь пишется? PageFault к примеру? Вообще хороши походом было бы выложить лог вместе с сообщением об ошибке.

Sun Jun 30, 2013 11:22 am

Mario_r4
Никаких сообщений об ошибке не пишется, почти как если бы отсутствовала какая-то необходимая библиотека. TINYPAD появляется в CPU и тут же исчезает.
Пробовал запускать TINYPAD с параметром из RUN — бага не было, только очень медленная отрисовка.

Sun Jun 30, 2013 3:55 pm

0CodErr wrote:Mario_r4
Никаких сообщений об ошибке не пишется, почти как если бы отсутствовала какая-то необходимая библиотека. TINYPAD появляется в CPU и тут же исчезает.
Пробовал запускать TINYPAD с параметром из RUN — бага не было, только очень медленная отрисовка.

Библиотеки тут явно не причем. Имхается мне проблема с IPC. Потому что для передачи в Tinypad из Docpack используется именно IPC, реализация ф. 60 могла быть затронута при внедрении нового планировщика. Еще раз оговорюсь, что это всего лишь гипотеза, относительно планировщика, чтобы автор кода не выражал в очередной раз возмущенное раздражение. Для проверки нужно взять ревизии 3533 и 3534 и проверить каждую описанным способом.

Есть два варианта решения - либо разбираться что случилось с IPC, либо переписать все на использование именованной памяти (ф.68.22, 68.23) и при старте Tynipad передавать указатель на нее. Второе решение явно ускорит процесс передачи информации, но сожрет дополнительную память во время открытия, если передавать весь кусок за один раз.

Mon Jul 01, 2013 8:15 am

Наверное, не в планировщике дело.
В прошлый раз я проверил ещё на 3534 и 3503.
В Bochs баг был в обеих сборках. А в VirtualBox я не успеваю подвигать мышкой до отрисовки TINYPAD(эти сборки быстрее работают).
Тогда, получается, на реальной системе этот баг тем более не должен проявляться?

Mon Jul 01, 2013 8:33 am

0CodErr wrote:Тогда, получается, на реальной системе этот баг тем более не должен проявляться?

Я не знаю, баг выявил ты и у тебя есть повторяемость. Я такого бага не наблюдал.

Tue Jul 02, 2013 7:04 pm

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 - но кому какое дело, как ведёт себя система под нагрузкой, правильно?

Tue Jul 02, 2013 8:20 pm

0CodErr wrote:Вот запустил в VirtualBox svn3734-img. Теперь у меня ещё указатель мыши стал иногда мерцать, а двигается рывками.

Конфигурацию VirtualBox в студию - файлы .vbox и все ассоциированные диски. Чтобы инициализация процесса с рамдиска без нагрузки длилась > 200 мс - это надо очень постараться.

Tue Jul 02, 2013 9:48 pm

CleverMouse wrote: Проблема не с IPC. Проблема в DOCPACK. Вот фрагмент кода DOCPACK

Как я уже заранее оговорился - это была гипотеза. Хорошо, что найдена настоящая причина.

Wed Jul 03, 2013 6:51 pm

CleverMouse wrote:Чтобы инициализация процесса с рамдиска без нагрузки длилась > 200 мс - это надо очень постараться.

Это происходит, вероятно, из-за движения мыши. Если мышью не водить во время запуска, то запустится гораздо быстрее.
Как ты выше и написала:

CleverMouse wrote:указатель мыши отрисовывается с наивысшим приоритетом

Я предположил, что дело может быть в способе эмуляции, потому что, например, в Qemu таких тормозов нет. Ну, то есть, все сборки там "тормозят" более менее одинаково.
Я пробовал отключать в VirtualBox все диски кроме floppy с образом — лучше не стало.

Вот результаты MGB для 3503, 3535, 3734 при разрешении экрана 1024x768 на VirtualBox, указатель мыши находился вне области окна:

Spoiler:

: 3734_vs_3535.PNG (11.72 KiB)
Viewed 4273 times

: 3503_vs_3535.PNG (11.41 KiB)
Viewed 4273 times

А в 2696, наверное, алгоритм тестирования был другим, потому что там уж очень сильные отличия.

Может быть, стоит проводить такие тесты для каждой ночной сборки на реальной системе?

"Ночные" сборки KolibriOS

Who is online