20 января 2022 г., 17:43, "Eugene Grosbein" <eu...@grosbein.net> написал:
> 20.01.2022 22:11, sp...@itl.ua пишет: > >> 3 января 2022 г., 4:44, "Eugene Grosbein" <eu...@grosbein.net> написал: >> >>> Это всё надо писать в PR комментарием. >> >> Раскопки привели к тому, что креш происходит внутри bd_edd_io(), в котором >> нечему крешиться кроме v86int(), в котором вроде бы нечему крешиться кроме >> int $INT_V86 >> >> Выходит, крешится биосовский interrupt handler? > > Это ничему не противоречит. Если loader от 11.2 вызывает BIOS так, что BIOS > отрабатывает чисто, > а более свежий loader вызывает BIOS так, что внутри BIOS всё ломается, > то нужно заточить наш loader, чтобы он был совместим с такими BIOS-ами. Разумеется, workarounds никто не отменял. Но хотечется понимать, на чьей стороне проблема. По идее должен же interrupt handler быть устойчивым к любому набору аргументов (значениям регистров, стека/etc) и возвращаться хотя бы с ошибкой? Или нет? С другой стороны, я проверила все, до чего дотянулась, и не увидела разницы в значениях аргументов перед успешными вызовами bd_edd_io() и перед тем, который валится. Зато обнаружила, что на успешность загрузки влияет значение переменной dest (это переменная bbuf в bd_realstrategy()). Если она установлена в переменную bio_buffer (это так изначально), расположенную в BSS, bd_edd_io() падает. Если она установлена в PTOV(V86_IO_BUFFER) (V86_IO_BUFFER=0x8000) (это мое изменение), bd_edd_io() не падает. При прочих равных условиях. (Ну, только с уменьшенным размером read size, чтобы поместилось в отведенные для V86_IO_BUFFER 4 килобайта). (Само же уменьшение размера read size, если bbuf=bio_buffer, не предотвращает креш.) Т.е. есть два вызова int 0x31, один падает (в AHCI), другой нет. Отличаются только значением некой области памяти, интерпретируемой как адрес. Причем при IDE mode обработчику прерывания нравятся оба варианта адреса, а при AHCI - только один из них. И - вишенка на торте - креш происходит в рандомное (не первое и не энное) обращение к bd_edd_io(), если считать с момента начала опроса флешки. _______________________________________________ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
