[freebsd] 13.0 memstick не грузится

[spell at itl.ua]

20 января 2022 г., 20:25, "Eugene Grosbein" <eugen at grosbein.net> написал:

> 21.01.2022 0:04, spell at 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.