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 _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
