* Real mode kexec failure with non-IDE disk
@ 2019-04-28 21:05 David Woodhouse
2019-05-01 2:56 ` [SeaBIOS] " Kevin O'Connor
0 siblings, 1 reply; 4+ messages in thread
From: David Woodhouse @ 2019-04-28 21:05 UTC (permalink / raw)
To: seabios; +Cc: kexec
[-- Attachment #1.1: Type: text/plain, Size: 792 bytes --]
When I kexec either Xen or Linux in real mode, from either Xen or
Linux, it fails.
The last thing I see looks like SeaBIOS trying to use SMM for call32:
----------------
IN:
0x00000000000f70ec: mov %eax,%esi
0x00000000000f70ef: mov $0xb5,%eax
0x00000000000f70f5: mov $0x1234,%ecx
0x00000000000f70fb: mov $0xef3dc,%ebx
0x00000000000f7101: out %al,$0xb2
0x00000000000f7103: pause
----------------
IN:
0x00000000000ef3db: hlt
This happens when the real mode boot code calls INT 13h to read from
the disk. It seems to happen with virtio and SATA disks.
This is with the Ubuntu-packaged 1.10.2-1ubuntu1 SeaBIOS. Switching to
an IDE disk, or booting with 'edd=skipmbr', makes Xen work and Linux
get a little further before it dies anyway.
[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]
[-- Attachment #2: Type: text/plain, Size: 143 bytes --]
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [SeaBIOS] Real mode kexec failure with non-IDE disk
2019-04-28 21:05 Real mode kexec failure with non-IDE disk David Woodhouse
@ 2019-05-01 2:56 ` Kevin O'Connor
2019-05-01 20:16 ` David Woodhouse
0 siblings, 1 reply; 4+ messages in thread
From: Kevin O'Connor @ 2019-05-01 2:56 UTC (permalink / raw)
To: David Woodhouse; +Cc: seabios, kexec
On Mon, Apr 29, 2019 at 12:05:33AM +0300, David Woodhouse wrote:
> When I kexec either Xen or Linux in real mode, from either Xen or
> Linux, it fails.
>
> The last thing I see looks like SeaBIOS trying to use SMM for call32:
>
> ----------------
> IN:
> 0x00000000000f70ec: mov %eax,%esi
> 0x00000000000f70ef: mov $0xb5,%eax
> 0x00000000000f70f5: mov $0x1234,%ecx
> 0x00000000000f70fb: mov $0xef3dc,%ebx
> 0x00000000000f7101: out %al,$0xb2
> 0x00000000000f7103: pause
>
> ----------------
> IN:
> 0x00000000000ef3db: hlt
>
> This happens when the real mode boot code calls INT 13h to read from
> the disk. It seems to happen with virtio and SATA disks.
>
> This is with the Ubuntu-packaged 1.10.2-1ubuntu1 SeaBIOS. Switching to
> an IDE disk, or booting with 'edd=skipmbr', makes Xen work and Linux
> get a little further before it dies anyway.
Hi David,
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
).
-Kevin
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [SeaBIOS] Real mode kexec failure with non-IDE disk
2019-05-01 2:56 ` [SeaBIOS] " Kevin O'Connor
@ 2019-05-01 20:16 ` David Woodhouse
2019-05-07 15:17 ` Kevin O'Connor
0 siblings, 1 reply; 4+ messages in thread
From: David Woodhouse @ 2019-05-01 20:16 UTC (permalink / raw)
To: Kevin O'Connor; +Cc: seabios, kexec
[-- Attachment #1.1: Type: text/plain, Size: 6108 bytes --]
On Tue, 2019-04-30 at 22:56 -0400, Kevin O'Connor wrote:
> Hi David,
>
> 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...
This SeaBIOS git master (f4c6e4c1) with an IDE disk, from the moment of
kexec:
unimplemented handle_15XX:330:
a=0000ec00 b=00000002 c=00000000 d=00000000 ds=8f00 es=8f00 ss=d980
si=00000000 di=00000000 bp=00000000 sp=0000fe8e cs=8f00 ip=0060 f=0246
enter handle_12:
a=534d3c00 b=0000befe c=00003c00 d=002ffb80 ds=8f00 es=8f00 ss=d980
si=00000000 di=00000af1 bp=00000000 sp=0000fe8e cs=8f00 ip=0143 f=0202
invalid handle_legacy_disk:729:
a=534d4139 b=000055aa c=0000fe03 d=002ffb81 ds=8f00 es=8f00 ss=d980
si=00001539 di=00000000 bp=00000000 sp=0000fe8e cs=8f00 ip=015b f=0293
invalid handle_legacy_disk:729:
a=534d0201 b=00000000 c=889f0001 d=002f0081 ds=8f00 es=8ee0 ss=d980
si=0000aa55 di=00000000 bp=00000000 sp=0000fe8e cs=8f00 ip=0202 f=0247
Xen 4.11.2-pre
(XEN) Xen version 4.11.2-pre (dwmw@ant.amazon.com) (gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0) debug=n Wed May 1 22:08:39 IDT 2019
(XEN) Latest ChangeSet: Wed May 1 13:37:09 2019 +0300 git:7c281700a8
(XEN) Bootloader: kexec 2.0.19.git
(XEN) Command line: console=vga,com1
(XEN) Xen image load base address: 0
(XEN) Video information:
(XEN) VGA is text mode 80x25, font 8x16
(XEN) Disc information:
(XEN) Found 1 MBR signatures
(XEN) Found 1 EDD information structures
And this is all I see when the disk is virtio:
unimplemented handle_15XX:330:
a=0000ec00 b=00000002 c=00000000 d=00000000 ds=8f00 es=8f00 ss=d980
si=00000000 di=00000000 bp=00000000 sp=0000fe8e cs=8f00 ip=0060 f=0246
enter handle_12:
a=534d3c00 b=0000befd c=00003c00 d=002ffb40 ds=8f00 es=8f00 ss=d980
si=00000000 di=00000af1 bp=00000000 sp=0000fe8e cs=8f00 ip=0143 f=0202
invalid handle_legacy_disk:729:
a=534d4139 b=000055aa c=0000fe03 d=002ffb81 ds=8f00 es=8f00 ss=d980
si=00001539 di=00000000 bp=00000000 sp=0000fe8e cs=8f00 ip=015b f=0293
Increasing debug to 9, I see:
enter handle_15:
a=0000ec00 b=00000002 c=00000000 d=00000000 ds=8f00 es=8f00 ss=d980
si=00000000 di=00000000 bp=00000000 sp=0000f96e cs=8f00 ip=0060 f=0246
unimplemented handle_15XX:330:
a=0000ec00 b=00000002 c=00000000 d=00000000 ds=8f00 es=8f00 ss=d980
si=00000000 di=00000000 bp=00000000 sp=0000f96e cs=8f00 ip=0060 f=0246
enter handle_15:
a=0000e820 b=00000000 c=00000014 d=534d4150 ds=8f00 es=8f00 ss=d980
si=00000000 di=00000a51 bp=00000000 sp=0000f96e cs=8f00 ip=00ec f=0246
enter handle_15:
a=0000e820 b=00000001 c=00000014 d=534d4150 ds=8f00 es=8f00 ss=d980
si=00000000 di=00000a65 bp=00000000 sp=0000f96e cs=8f00 ip=00ec f=0202
enter handle_15:
a=0000e820 b=00000002 c=00000014 d=534d4150 ds=8f00 es=8f00 ss=d980
si=00000000 di=00000a79 bp=00000000 sp=0000f96e cs=8f00 ip=00ec f=0202
enter handle_15:
a=0000e820 b=00000003 c=00000014 d=534d4150 ds=8f00 es=8f00 ss=d980
si=00000000 di=00000a8d bp=00000000 sp=0000f96e cs=8f00 ip=00ec f=0206
enter handle_15:
a=0000e820 b=00000004 c=00000014 d=534d4150 ds=8f00 es=8f00 ss=d980
si=00000000 di=00000aa1 bp=00000000 sp=0000f96e cs=8f00 ip=00ec f=0202
enter handle_15:
a=0000e820 b=00000005 c=00000014 d=534d4150 ds=8f00 es=8f00 ss=d980
si=00000000 di=00000ab5 bp=00000000 sp=0000f96e cs=8f00 ip=00ec f=0206
enter handle_15:
a=0000e820 b=00000006 c=00000014 d=534d4150 ds=8f00 es=8f00 ss=d980
si=00000000 di=00000ac9 bp=00000000 sp=0000f96e cs=8f00 ip=00ec f=0206
enter handle_15:
a=0000e820 b=00000007 c=00000014 d=534d4150 ds=8f00 es=8f00 ss=d980
si=00000000 di=00000add bp=00000000 sp=0000f96e cs=8f00 ip=00ec f=0202
enter handle_15:
a=534d88f1 b=00000000 c=00000014 d=534d4150 ds=8f00 es=8f00 ss=d980
si=00000000 di=00000af1 bp=00000000 sp=0000f96e cs=8f00 ip=0112 f=0246
enter handle_15:
a=534de801 b=00000000 c=00000000 d=534d0000 ds=8f00 es=8f00 ss=d980
si=00000000 di=00000af1 bp=00000000 sp=0000f96e cs=8f00 ip=011f f=0246
enter handle_12:
a=534d3c00 b=0000befd c=00003c00 d=002ffb40 ds=8f00 es=8f00 ss=d980
si=00000000 di=00000af1 bp=00000000 sp=0000f96e cs=8f00 ip=0143 f=0202
invalid handle_legacy_disk:729:
a=534d4139 b=000055aa c=0000fe03 d=002ffb81 ds=8f00 es=8f00 ss=d980
si=00001539 di=00000000 bp=00000000 sp=0000f96e cs=8f00 ip=015b f=0293
call32_smm 0x000ed91a e9120
handle_smi cmd=b5 smbase=0x000a0000
vp notify fe003000 (2) -- 0x0
call16_smm 0x00007a79 0 0
handle_smi cmd=b5 smbase=0x000a0000
handle_smi cmd=b5 smbase=0x000a0000
call16_smm 0x00007a79 0 0
handle_smi cmd=b5 smbase=0x000a0000
handle_smi cmd=b5 smbase=0x000a0000
call16_smm 0x00007a79 0 0
handle_smi cmd=b5 smbase=0x000a0000
handle_smi cmd=b5 smbase=0x000a0000
call16_smm 0x00007a79 0 0
handle_smi cmd=b5 smbase=0x000a0000
handle_smi cmd=b5 smbase=0x000a0000
call16_smm 0x00007a79 0 0
handle_smi cmd=b5 smbase=0x000a0000
handle_smi cmd=b5 smbase=0x000a0000
call16_smm 0x00007a79 0 0
handle_smi cmd=b5 smbase=0x000a0000
handle_smi cmd=b5 smbase=0x000a0000
call16_smm 0x00007a79 0 0
handle_smi cmd=b5 smbase=0x000a0000
handle_smi cmd=b5 smbase=0x000a0000
call16_smm 0x00007a79 0 0
handle_smi cmd=b5 smbase=0x000a0000
handle_smi cmd=b5 smbase=0x000a0000
call16_smm 0x00007a79 0 0
handle_smi cmd=b5 smbase=0x000a0000
handle_smi cmd=b5 smbase=0x000a0000
call16_smm 0x00007a79 0 0
handle_smi cmd=b5 smbase=0x000a0000
handle_smi cmd=b5 smbase=0x000a0000
call16_smm 0x00007a79 0 0
handle_smi cmd=b5 smbase=0x000a0000
handle_smi cmd=b5 smbase=0x000a0000
call16_smm 0x00007a79 0 0
...
That just goes on for ever. The full log from boot (including the boot
of the first kernel) is at http://david.woodhou.se/smi-wtf.txt
[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]
[-- Attachment #2: Type: text/plain, Size: 143 bytes --]
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [SeaBIOS] Real mode kexec failure with non-IDE disk
2019-05-01 20:16 ` David Woodhouse
@ 2019-05-07 15:17 ` Kevin O'Connor
0 siblings, 0 replies; 4+ messages in thread
From: Kevin O'Connor @ 2019-05-07 15:17 UTC (permalink / raw)
To: David Woodhouse; +Cc: seabios, kexec
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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-05-07 15:17 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-04-28 21:05 Real mode kexec failure with non-IDE disk David Woodhouse
2019-05-01 2:56 ` [SeaBIOS] " Kevin O'Connor
2019-05-01 20:16 ` David Woodhouse
2019-05-07 15:17 ` Kevin O'Connor
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.