Расследование показало, что проблемы с /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, то железное подвисание системы.

Mario_r4
Удивительно, что оно вообще работает. Два разных программных кода обращаются к одному физическому устройству. Причём ядро наивно полагает свой доступ монопольным.

Serge wrote:Mario_r4
Удивительно, что оно вообще работает. Два разных программных кода обращаются к одному физическому устройству. Причём ядро наивно полагает свой доступ монопольным.

До внедрения нового планировщика как-то работало же и с приемлемой скоростью.

Mario_r4
Карусель потоков поменялась, поменялись и паузы между обращениями к контроллеру.
А это не баг с записью на /hd ? Если скопировать на /tmp, а потом записать на /hd, не виснет ?

Такое ощущение, что Колибри становится всё медленней.
Например, 3663 работает быстрее, чем 3682. А 3535 была ещё быстрее.
Особенно заметно в приложениях, использующих скроллбар.
И раньше казалось, что программа запустилась ещё до клика по иконке или в ФМ, но теперь возникает заметная задержка.
Или, например, в TopPanel при быстром движении мыши в старых версиях Колибри успевало отрисоваться больше подменю.
Даже если убить один из потоков OS, то ситуация не меняется, указатель мыши иногда как бы рывками движется.
Запускал в VirtualBox.

0CodErr
Запускаю в Qemu 0.12.2 - визуально скорость не менялась, хотя там реально медленная конфигурация эмулируется. Может в самом VirtualBox дело? Надо на реальном железе проверять. Вот я только так и обнаружил проблему с /bd дисками.

Serge wrote:Mario_r4
Карусель потоков поменялась, поменялись и паузы между обращениями к контроллеру.
А это не баг с записью на /hd ? Если скопировать на /tmp, а потом записать на /hd, не виснет ?

Оказывается баг замечательно повторяем на Qemu 0.12.2 - симпотомы те же, которые были на Roverbook U800.
Дополнительно проверил твою идею - файл скопировался с /bd на /tmp, а потом система опять таки сразу замерзла.

Копировал на /tmp файлы в VBOX, всё работает.

Serge wrote:Копировал на /tmp файлы в VBOX, всё работает.

Я же не зря делал оговорку - на некоторых конфигурациях. Видимо в в твоей проблема не наблюдается, а вот в Qemu определенно присутствует.

Значит нужно подробное описание что и как, чтобы воспроизвести ошибку.
А то начинается "у меня не загружаецца".

Serge wrote:Значит нужно подробное описание что и как, чтобы воспроизвести ошибку.
А то начинается "у меня не загружаецца".

Куда уж подробней то? Я описал как воспроизвести. А Qemu с месяц лежит ftp://ftp.kolibrios.org/users/Mario/Qemu/

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

Spoiler:

1.PNG (39.28 KiB)

Viewed 4835 times

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 ждёт прерывания. Впрочем, я этого не проверяла.

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

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

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

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