On Thu, Apr 16, 2015 at 06:37:29PM +0200, Roger Pau Monné wrote:
El 16/04/15 a les 17.52, Kevin O'Connor ha escrit:
Seems like the same problem. You wont be able to set a gdb breakpoint for the freebsd call because freebsd isn't calling the bios - it's attempting to interpret the bios code.
Does the seabios patch below fix the problem for you?
Seems to kind of fix it, but it's hard to tell.
Most of the time the original SeaBIOS binary works without problems. There's sometimes were the int 0x15 call with ah=0xc0 returns what seem to be valid values in ah and flg, but the values in es and bx are corrupted so when freebsd tries to access this region (es << 4 + bx) it gets a page fault.
This is what I see now with the patch applied:
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0 atkbd0: <AT Keyboard> irq 1 on atkbdc0 Calling INT 0x15 (ax=0xc000 bx=0x0000 cx=0x0000 dx=0x0000 es=0x0000 di=0x0000) Exiting INT 0x15 (ax=0xf9c0 bx=0xf9c0 cx=0xf99e dx=0xdf80 es=0x0000 di=0x0000) kbd0 at atkbd0 atkbd0: [GIANT-LOCKED]
Ah, looks like the freebsd code isn't even checking if x86emu exited abnormally.
To summarize, this looks to be the same problem that I investigated two years ago:
http://lists.nongnu.org/archive/html/qemu-devel/2013-03/msg01311.html
Basically, freebsd is attempting to interpret the x86 bios code, but it is using an incomplete interpreter that misinterprets some x86 instructions. That broken interpreter could cause page faults, loop forever, or return bogus values.
Ironically, all this is done to find out the BIOS "keyboard repeat rate" - I don't know why anyone would even care what the BIOS set the keyboard rate to.
I think this needs to be fixed in the freebsd kernel. Until it is fixed, minor changes to the seabios code layout could lead to random crashes in the freebsd kernel.
-Kevin