20 января 2022 г., 20:25, "Eugene Grosbein" <eu...@grosbein.net> написал:
> 21.01.2022 0:04, sp...@itl.ua wrote: > >> Выходит, крешится биосовский interrupt handler? >>> Это ничему не противоречит. Если loader от 11.2 вызывает BIOS так, что BIOS >>> отрабатывает чисто, >>> а более свежий loader вызывает BIOS так, что внутри BIOS всё ломается, >>> то нужно заточить наш loader, чтобы он был совместим с такими BIOS-ами. >> >> Разумеется, workarounds никто не отменял. Но хотечется понимать, на чьей >> стороне проблема. >> По идее должен же interrupt handler быть устойчивым к любому набору >> аргументов >> (значениям регистров, стека/etc) и возвращаться хотя бы с ошибкой? Или нет? > > Не совсем. Некоторые вызовы BIOS работают только в real mode, некоторые > только в protected mode, > некоторые в обоих. У нас loader переключает процессор в protected mode, > то есть когда память адресуется как виртуальная и мапится в физическую. > Из-за мапинга тоже вполне может быть креш. Адрес буфера одинаковый во время чтения с hdd и с флешки, он больше значения переменной edata (конец сегмента данных) и меньше значения переменной end (конец BSS), как и положено. Мапинг - просто добавление 0xA000 к виртуальному адресу для получения физического, вроде никаких подводных камней. Если бы дело было таки в мапинге, он бы крушил и обращение к диску тоже, и крушил бы флешку независимо от IDE/AHCI режима. Еще эксперимент: В том месте, где вызывается bd_edd_io(), я поставила цикл из 100 этих вызовов подряд. Креш происходит в середине этого цикла, т.е. один и тот же вызов с одним и тем же набором входных данных срабатывает N раз, а на N+1 падает. Ну, вроде достаточно оснований присмотреться к вызову прерывания. Из bd_edd_io() вызывается v86int(), который вызывает btx-ный int 31h, который вызывает биосовский int 13h (работа с диском). Выходит, фейлится или int 31h или int 13h. _______________________________________________ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
