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