[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.)

Cheers,
-Kevin



More information about the kexec mailing list