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

Fri Jun 21, 2013 7:12 pm

В r. 3689 после вылета downloader-а процессы перестают завершаться.
Это было в VirtualBox. Запустил htmlv, нажал на "домик".

Spoiler:

: 1.PNG (39.28 KiB)
Viewed 5058 times

Mon Jun 24, 2013 10:54 am

Mario_r4 wrote:Расследование показало, что проблемы с /bd дисками начались после ревизии 3534, когда был введен новый планировщик задач в ядро. Вернее я проверял начиная с 3536. В ней копирование с /bd1/2 на /hd0/3 (разные разделы одного жесткого диска bd - NTFS, hd - FAT32), файла размером в 2 Мб возвращает код 8. Это сопровождается зависанием мыши, да и вообще всей системы. В ревизии 3525 такой проблемы нет, в ядро между этими ревизиями не менялось. При каждой сбойном результате я перезагружался в Виндовс и запускал скандиск для обоих разделов, так что ошибка файловой системы здесь исключена. А места на /hd0/3 в десятки раз больше, чем нужно для записи.

З.Ы. Проблема наблюдается в том числе и на ядре 3681. Причем если скопировать с /hd0/2 на /hd0/3 то операция проходит без проблем, если же копировать с /bd1/2 (который соответствует /hd0/2) на /hd0/3, то железное подвисание системы.

Чушь, новый планировщик ни при чём, в r3525 наверняка тестирование было в щадящем режиме, при полном отсутствии прочей нагрузки на систему. Я исправила ошибки в коде V86 - не свои, между прочим, хватит гнать на планировщик - в r3696.

ЗЫ: ошибка была в коде перенаправления IRQ на обработку BIOS; надо полагать, в VirtualBox BIOS работает через поллинг жёсткого диска, и там всё работало и так, а в qemu BIOS ждёт прерывания. Впрочем, я этого не проверяла.

Mon Jun 24, 2013 2:34 pm

CleverMouse wrote:Чушь, новый планировщик ни при чём, в r3525 наверняка тестирование было в щадящем режиме, при полном отсутствии прочей нагрузки на систему. Я исправила ошибки в коде V86 - не свои, между прочим, хватит гнать на планировщик - в r3696.

ЗЫ: ошибка была в коде перенаправления IRQ на обработку BIOS; надо полагать, в VirtualBox BIOS работает через поллинг жёсткого диска, и там всё работало и так, а в qemu BIOS ждёт прерывания. Впрочем, я этого не проверяла.

1) Никакая не чушь - условия поверки были идентичными. Никакой прочей нагрузки во всех случаях не было. Я за свои слова отвечаю.
2) Я не гнал собственно на планировщик - просто его внедрение могло стать катализатором проявления багов, которые ранее не проявлялись. Некоторые из них были исправлены, но по всей видимости не все.

З.Ы. Ревизия 3696 исправила проблему в Qemu и на RoverBook U800 копирование теперь работает без проблем.

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

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

Who is online