[SeaBIOS] Real mode kexec failure with non-IDE disk

Kevin O'Connor kevin at koconnor.net
Tue May 7 08:17:38 PDT 2019

Hi David,

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
  longer valid.

- 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 mailing list