[SeaBIOS] Real mode kexec failure with non-IDE disk
kevin at koconnor.net
Tue May 7 08:17:38 PDT 2019
On Wed, May 01, 2019 at 11:16:03PM +0300, David Woodhouse wrote:
> On Tue, 2019-04-30 at 22:56 -0400, Kevin O'Connor wrote:
> > That call trace certainly looks odd. The SeaBIOS debugging info would
> > help - try compiling SeaBIOS with debug level 8 and grab the log (as
> > described at: https://www.seabios.org/Debugging#Diagnostic_information
> > ).
> Choosing Xen because it actually succeeds, while Linux real-mode boot
> then dies a bit later even if I use IDE disks...
>The full log from boot (including the boot
> of the first kernel) is at http://david.woodhou.se/smi-wtf.txt
>From that log, it doesn't look like SeaBIOS itself is reset during the
kexec. I could be wrong, but here's my understanding of that log:
- SeaBIOS starts normally and initializes the virtio-blk device
- SeaBIOS hands control to the bootloader. The bootloader makes
various BIOS calls that read blocks from the virtio-blk device.
- At some point the bootloader loads Linux. Linux reinitializes the
virtio-blk device to its liking.
- At some point, a kexec occurs and then SeaBIOS gets a request to
read data from the virtio-blk device. However, the virtio-blk
device was reset by Linux, so the SeaBIOS' device structures are no
- SeaBIOS waits indefinitely for a virtio notify event that it wont
ever receive (because it is waiting on a control structure that the
virtio-blk device is no longer configured to use).
If SeaBIOS doesn't get a signal to reinitialize itself, I'm not sure
there's much it can do in that situation. (Though, as above, it's
possible I've misread the log.)
More information about the kexec