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