[SeaBIOS] [Qemu-devel] problems with freeBSD
kevin at koconnor.net
Fri Mar 8 04:35:07 CET 2013
On Thu, Mar 07, 2013 at 09:43:04AM +0100, Aurelien Jarno wrote:
> On Wed, Mar 06, 2013 at 07:53:51PM -0500, Kevin O'Connor wrote:
> > That change is definitely just build related - I don't see how it
> > could impact the final SeaBIOS binary. How did you conclude that this
> > commit is what fixes the issue?
> I did a git bisect to find the commit fixing the issue. Then, as I was
> not believing the result, I tried the following sequence a dozen of
> times (for some unknown reasons the FreeBSD install CD doesn't exhibit
> the issue, so I used the Debian GNU/kFreeBSD installer):
Thanks for the detailed bug report. Here's what I see going on:
- the SeaBIOS 4219149a commit does change the resulting binary ever so
slightly - the src/virtio_ring.c code has a reference to __FILE__
(the only code in SeaBIOS that does that), and due to slightly
different build rules in this commit it evaluates to a slightly
- the freebsd crash has nothing to do with 4219149a or
src/virtio_ring.c - instead, random changes in the seabios binary
layout can cause (or avoid) the crash. You can see this in action
by modifying seabios to have higher debug levels, commenting out
code, adding dprintf statements, etc.
- the crash happens when freebsd attempts to emulate the bios code (!)
in order to determine the keyboard typematic rate (!). (See
sys/dev/atkbdc/atkbd.c.) Since SeaBIOS doesn't support the typematic
callback rate (int 0x16 ax=0x0306) this doesn't actually achieve
anything in practice were the call to not crash. However, a crash
does (sometimes) result.
- the freebsd x86bios_get_pages() code is buggy (See
sys/compat/x86bios/x86bios.c). It attempts to check that its x86
emulater (!) doesn't access a page it hasn't mapped. However, it
does not check for the case where a two byte access spans two pages.
If the first page is mapped, but the second is not - splat. The
crash I've seen in QEMU had a two byte access to 0xffffff8000015fff
with the fault at 0xffffff8000016000.
- I have not been able to determine why an attempt was made to access
a non-mapped page. My best guess is that the x86emu code (!) goes
off the deep-end in all cases - just some cases lead it to the bug
above and other cases lead it to a more friendly termination.
(Recall that SeaBIOS doesn't support the typematic call anyway.) It
should be possible to track this down by adding debug statements to
the freebsd code if anyone is familiar with the freebsd kernel
More information about the SeaBIOS