On Wed, Dec 23, 2015 at 09:14:44PM +0100, Tobias Diedrich wrote:
> Final diff attached (without the src/stacks.c change, with %d->%u change
> for sector counts).
> Bootlog with debug_level 1 attached.
Great! Patches sent - if no further comments I'll commit in a few
days.
-Kevin
Final diff attached (without the src/stacks.c change, with %d->%u change
for sector counts).
Bootlog with debug_level 1 attached.
On Wed, Dec 23, 2015 at 8:56 PM, Tobias Diedrich <tobiasdiedrich(a)gmail.com>
wrote:
> I replaced the printf(...) with dprintf(1, ...) (since a dprintf earlier
> in the function was working fine).
>
> This appears to have fixed the issue (though PCHS seems to be wrong, maybe
> because sector count is negative when parsed as a signed int). Full log
> attached.
>
> |dfc02000| USB MSC vendor='WD' product='Elements 10B8' rev='1012' type=0
> removable=0
> \dfc04000/ End thread
> |dfbfd000| USB MSC vendor='Multiple' product='Card Reader' rev='1.00'
> type=0 removable=1
> |dfbfd000| Device reports MEDIUM NOT PRESENT
> |dfbfd000| scsi_is_ready returned -1
> |dfbfd000| Unable to configure USB MSC drive.
> |dfbfd000| Unable to configure USB MSC device.
> \dfbfd000/ End thread
> |dfc02000| Waiting for device to detect medium... \dfc03000/ End thread
> |dfc02000| USB MSC blksize=512 sectors=-388003840
> |dfc02000| Registering bootable: USB MSC Drive WD Elements 10B8 1012
> (type:2 prio:103 data:f6110)
> \dfc02000/ End thread
> \dfc08000/ End thread
> All threads complete.
> Scan for option roms
>
> Press ESC for boot menu.
>
>
> On Wed, Dec 23, 2015 at 7:58 PM, Kevin O'Connor <kevin(a)koconnor.net>
> wrote:
>
>> On Wed, Dec 23, 2015 at 07:39:56PM +0100, Tobias Diedrich wrote:
>> > On Wed, Dec 23, 2015 at 7:10 PM, Kevin O'Connor <kevin(a)koconnor.net>
>> wrote:
>> >
>> > > On Wed, Dec 23, 2015 at 07:02:37PM +0100, Tobias Diedrich wrote:
>> > > > Wcall16 with invalid stack: eax=dfbf3e62 edx=0 func=0x000f9563
>> > > esp=dfbf3e50
>> > > >
>> > > > .text._farcall16 0x9563 : { *(.text._farcall16) }
>> > > >
>> > >
>> > > Can you include the full log? It looks like the code tried to call a
>> > > 16bit function while in a "thread", and I need to figure out which
>> > > thread did that.
>> >
>> >
>> > From the esp address it looks like it'sin the USB probe for the MSC
>> device
>> > (full log attached):
>> > /dfc02000\ Start thread func=dfc135f1
>> > |dfc02000| set_address 0xdfc0a200
>> > |dfc02000| config_usb: 0xdfc0a0d0
>> > |dfc02000| device rev=0210 cls=00 sub=00 proto=00 size=64
>> > |dfc02000| Searching bootorder for: /pci@i0cf8/usb@12,2/storage@5
>> /*@0/*@0,0
>> > |dfc02000| Searching bootorder for: /pci@i0cf8/usb@12,2/usb-*@5
>> > |dfc02000| USB MSC vendor='WD' product='Elements 10B8' rev='1012' type=0
>> > removable=0
>> > Wcall16 with invalid stack: eax=dfc02e66 edx=0 func=0x000f91f0
>> esp=dfc02e54
>> > ret=0x000f0604
>>
>> What happens if you apply the patch below? (If it looks like it is
>> hanging, give it at least a minute before stopping it.)
>>
>> -Kevin
>>
>>
>> --- a/src/hw/blockcmd.c
>> +++ b/src/hw/blockcmd.c
>> @@ -168,7 +168,7 @@ scsi_is_ready(struct disk_op_s *op)
>>
>> if (sense.asc == 0x04 && sense.ascq == 0x01 && !in_progress) {
>> /* IN PROGRESS OF BECOMING READY */
>> - printf("Waiting for device to detect medium... ");
>> + //printf("Waiting for device to detect medium... ");
>> /* Allow 30 seconds more */
>> end = timer_calc(30000);
>> in_progress = 1;
>>
>
>
On Wed, Dec 23, 2015 at 07:39:56PM +0100, Tobias Diedrich wrote:
> On Wed, Dec 23, 2015 at 7:10 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote:
>
> > On Wed, Dec 23, 2015 at 07:02:37PM +0100, Tobias Diedrich wrote:
> > > Wcall16 with invalid stack: eax=dfbf3e62 edx=0 func=0x000f9563
> > esp=dfbf3e50
> > >
> > > .text._farcall16 0x9563 : { *(.text._farcall16) }
> > >
> >
> > Can you include the full log? It looks like the code tried to call a
> > 16bit function while in a "thread", and I need to figure out which
> > thread did that.
>
>
> From the esp address it looks like it'sin the USB probe for the MSC device
> (full log attached):
> /dfc02000\ Start thread func=dfc135f1
> |dfc02000| set_address 0xdfc0a200
> |dfc02000| config_usb: 0xdfc0a0d0
> |dfc02000| device rev=0210 cls=00 sub=00 proto=00 size=64
> |dfc02000| Searching bootorder for: /pci@i0cf8/usb@12,2/storage@5/*@0/*@0,0
> |dfc02000| Searching bootorder for: /pci@i0cf8/usb@12,2/usb-*@5
> |dfc02000| USB MSC vendor='WD' product='Elements 10B8' rev='1012' type=0
> removable=0
> Wcall16 with invalid stack: eax=dfc02e66 edx=0 func=0x000f91f0 esp=dfc02e54
> ret=0x000f0604
What happens if you apply the patch below? (If it looks like it is
hanging, give it at least a minute before stopping it.)
-Kevin
--- a/src/hw/blockcmd.c
+++ b/src/hw/blockcmd.c
@@ -168,7 +168,7 @@ scsi_is_ready(struct disk_op_s *op)
if (sense.asc == 0x04 && sense.ascq == 0x01 && !in_progress) {
/* IN PROGRESS OF BECOMING READY */
- printf("Waiting for device to detect medium... ");
+ //printf("Waiting for device to detect medium... ");
/* Allow 30 seconds more */
end = timer_calc(30000);
in_progress = 1;
On Wed, Dec 23, 2015 at 07:02:37PM +0100, Tobias Diedrich wrote:
> Wcall16 with invalid stack: eax=dfbf3e62 edx=0 func=0x000f9563 esp=dfbf3e50
>
> .text._farcall16 0x9563 : { *(.text._farcall16) }
>
Can you include the full log? It looks like the code tried to call a
16bit function while in a "thread", and I need to figure out which
thread did that.
-Kevin
On Wed, Dec 23, 2015 at 07:13:27PM +0100, Tobias Diedrich wrote:
> Wcall16 with invalid stack: eax=dfbf3e62 edx=0 func=0x000f9563 esp=dfbf3e50
> ret=0x000f2304
>
> │.text:000F22C8 sub_F22C8 proc near ; CODE XREF:
> sub_F2309+2Cvp
> ▒
> │.text:000F22C8 ; sub_F2309+35vj
>
FYI, to line up "ret" with the code, one can look in
out/romlayout32flat.lds . I prefer to run the following though:
objdump -m i386 -M suffix -d out/rom.o | less
and then look for the function containing the desired address.
The thread associated with esp=dfbf3e50 is key though, which is why
the full log is useful.
-Kevin
And with verbose logging (level 8).
[...]
|dfbf9000| USB MSC vendor='WD' product='Elements 10B8' rev='1012' type=0
removable=0
|dfbf9000| scsi_is_ready (drive=0x000f5c40)
|dfbf9000| ehci_send_pipe qh=0x0009ed80 dir=0 data=0xdfbf9e45 size=31
|dfbfe000| ehci_send_pipe qh=0x0009ef00 dir=128 data=0xdfbfeed2 size=18
|dfbf9000| ehci_send_pipe qh=0x0009ee00 dir=128 data=0xdfbf9e38 size=13
|dfbfe000| ehci_send_pipe qh=0x0009ef00 dir=128 data=0xdfbfee38 size=13
|dfbf9000| ehci_send_pipe qh=0x0009ed80 dir=0 data=0xdfbf9e45 size=31
|dfbfe000| Device reports MEDIUM NOT PRESENT
|dfbfe000| scsi_is_ready returned -1
|dfbfe000| Unable to configure USB MSC drive.
|dfbfe000| phys_free f5c70 (detail=0xdfc08fe0)
|dfbfe000| Unable to configure USB MSC device.
|dfbfe000| phys_free dfc090f0 (detail=0xdfc090c0)
|dfbfe000| phys_free dfc05400 (detail=0xdfc04e40)
\dfbfe000/ End thread
phys_free dfbfe000 (detail=0xdfc04e10)
|dfbf9000| ehci_send_pipe qh=0x0009ee00 dir=128 data=0xdfbf9ed2 size=18
|dfc02000| ehci_free_pipes 0xdfc057b0
|dfbf9000| ehci_send_pipe qh=0x0009ee00 dir=128 data=0xdfbf9e38 size=13
|dfc02000| phys_free dfc08f00 (detail=0xdfc08f70)
|dfc02000| phys_free 9ee80 (detail=0xdfc09060)
|dfc02000| phys_free 9ef00 (detail=0xdfc09090)
Wcall16 with invalid stack
[hangs here]
On Wed, Dec 23, 2015 at 4:05 PM, Tobias Diedrich <tobiasdiedrich(a)gmail.com>
wrote:
> Hi,
>
> I've attached a WD Elements 2TB drive to my pcengines APU1 as external
> storage and just found that with the disk attached SeaBIOS crashes on boot.
> :/
> The controller is USB2, not USB3.
>
> Both the stock rom "Build 4/5/2014 (current production)" and a
> self-compiled coreboot rom with SeaBIOS master from git
> (rel-1.9.0-43-g76327b9) exhibit the same issue.
>
> I'm not sure if
> http://www.seabios.org/pipermail/seabios/2015-November/009910.html is the
> same issue since it doesn't have log messages and doesn't seem to complain
> about it not booting at all.
>
> Cheers,
> Tobias
>
Hi,
I've attached a WD Elements 2TB drive to my pcengines APU1 as external
storage and just found that with the disk attached SeaBIOS crashes on boot.
:/
The controller is USB2, not USB3.
Both the stock rom "Build 4/5/2014 (current production)" and a
self-compiled coreboot rom with SeaBIOS master from git
(rel-1.9.0-43-g76327b9) exhibit the same issue.
I'm not sure if
http://www.seabios.org/pipermail/seabios/2015-November/009910.html is the
same issue since it doesn't have log messages and doesn't seem to complain
about it not booting at all.
Cheers,
Tobias
Hello Kevin,
Understood.
Thanks.
Best Regards,
Wim Vervoorn
Eltan B.V.
Ambachtstraat 23
5481 SM Schijndel
The Netherlands
T : +31-(0)73-594 46 64
E : wvervoorn(a)eltan.com
W : http://www.eltan.com
"THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR, PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664 OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES."
From: Stefan Berger [mailto:stefanb@us.ibm.com]
Sent: Tuesday, December 22, 2015 3:30 PM
To: Wim Vervoorn <wvervoorn(a)eltan.com>
Cc: Kevin O'Connor <kevin(a)koconnor.net>; seabios(a)seabios.org
Subject: RE: [SeaBIOS] SeaBIOS Digest, Vol 72, Issue 33
Wim Vervoorn <wvervoorn(a)eltan.com<mailto:wvervoorn@eltan.com>> wrote on 12/22/2015 09:15:55 AM:
>
> Hello Stefan,
>
> I think it will work perfectly for the higher level functions like :
> tpm_smbios_measure(void) etc. Here you can easily implement tpm 1.2
> and 2.0 handling. For the functions like tpm_add_measurement_to_log()
> I don’t think it is that easy or useful. For those it’s probably
> better to have a tpm 1.2 and a tpm 2.0 variant each with their own
> API but not with a wrapper.
If TPM 2 is not operated in sha1 mode, then we may need different *internal* functions, yes (tpm2_bar()).
Otherwise it's mostly byte streams being passed into the TPM parts to which sha1 is applied if needed; the
exception is the BIOS API which seems to return SHA1 hashes in some structures.
For the BIOS API functions where applications expect structures with embedded sha1 hashes, we will
need to restrict those APIs to sha1 mode, return failure otherwise. If the standard defines structures (for BIOS)
for sha256 etc., and possibly new API functions, then we can implement those for TPM 2 and they would result
in an error if invoked by TPM 1.2 (which only supports sha1).
Stefan
>
> Please note I did not look into all details so I might be seeing
> problems that aren’t there (or can be solved easily).
>
>
> Best Regards,
> Wim Vervoorn
>
> Eltan B.V.
> Ambachtstraat 23
> 5481 SM Schijndel
> The Netherlands
>
> T : +31-(0)73-594 46 64
> E : wvervoorn(a)eltan.com<mailto:wvervoorn@eltan.com>
> W : http://www.eltan.com<http://www.eltan.com/>
> "THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE
> INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS
> STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR,
> PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664
> OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES."
>
>
>
>
>
>
> From: Stefan Berger [mailto:stefanb@us.ibm.com]
> Sent: Tuesday, December 22, 2015 2:56 PM
> To: Wim Vervoorn <wvervoorn(a)eltan.com<mailto:wvervoorn@eltan.com>>
> Cc: Kevin O'Connor <kevin(a)koconnor.net<mailto:kevin@koconnor.net>>; seabios(a)seabios.org<mailto:seabios@seabios.org>
> Subject: RE: [SeaBIOS] SeaBIOS Digest, Vol 72, Issue 33
>
> Wim Vervoorn <wvervoorn(a)eltan.com<mailto:wvervoorn@eltan.com>> wrote on 12/22/2015 08:43:54 AM:
>
> >
> > Hello Stefan,
> >
> > I have my doubts. This will work fine as long as the toplevel
> > function tpm_foo() in your example can be implemented to have a
> > single API independent of the required support. If the API differs
> > between the tpm 1.2 and tpm 2.0 case I think it will only be
> confusing things.
> >
> > Given the differences between tpm 1.2 and 2.0 do you think you will
> > be able to maintain this single API?
>
> The top level function tpm_foo() will be called by other SeaBIOS
> code for doing TPM initialization,
> measurements, the menu, S3 resume, and for the BIOS API. For the API
> we would support the same API
> for TPM 1.2 and for TPM 2. The difference between the tpm12_foo and
> tpm2_foo functions are mainly
> that different TPM commands are created and sent to the TIS. So far,
> this works fine.
>
> Do you have concrete concerns regarding this? How else would you do it ?
>
> Regards,
> Stefan
>
> >
> >
> > Best Regards,
> > Wim Vervoorn
> >
> > Eltan B.V.
> > Ambachtstraat 23
> > 5481 SM Schijndel
> > The Netherlands
> >
> > T : +31-(0)73-594 46 64
> > E : wvervoorn(a)eltan.com<mailto:wvervoorn@eltan.com>
> > W : http://www.eltan.com<http://www.eltan.com/>
> > "THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE
> > INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS
> > STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR,
> > PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664
> > OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES."
> >
> >
> >
> >
> > From: Stefan Berger [mailto:stefanb@us.ibm.com]
> > Sent: Monday, December 21, 2015 5:50 PM
> > To: Kevin O'Connor <kevin(a)koconnor.net<mailto:kevin@koconnor.net>>
> > Cc: seabios(a)seabios.org<mailto:seabios@seabios.org>; Wim Vervoorn <wvervoorn(a)eltan.com<mailto:wvervoorn@eltan.com>>
> > Subject: Re: [SeaBIOS] SeaBIOS Digest, Vol 72, Issue 33
> >
> > "Kevin O'Connor" <kevin(a)koconnor.net<mailto:kevin@koconnor.net>> wrote on 12/17/2015 05:22:56 PM:
> >
> > >
> > > On Mon, Nov 30, 2015 at 11:32:05AM +0000, Wim Vervoorn wrote:
> > > > Hello,
> > > >
> > > > I noticed that a lot of work is going on for the TPM support in SeaBIOS.
> > > >
> > > > All of this work is TPM 1.2 based. I was wondering if there are any
> > > > plans to support TPM 2.0 in the future.
> > >
> > > I'm not aware of any plans.
> >
> > We're working on it...
> >
> >
> > So maybe you have some comments to the following:
> >
> > There will be a patch for probing the TPM TIS hardware interface for
> > whether there's a TPM 1.2 or a TPM 2.
> > We then have a patch for prefixing all TPM 1.2 functions with tpm12_
> > and then introduce functions like these ones here:
> >
> > static ... tpm12_foo() { ... }
> > static ... tpm2_foo() { ... }
> >
> > tpm_foo()
> > {
> > [...]
> >
> > switch (tpmversion) {
> > case TPM_VERSION_1_2:
> > tpm12_foo()
> > break;
> > case TPM_VERSION_2:
> > tpm2_foo();
> > break;
> > }
> >
> > [...]
> > }
> >
> > That way the probing will lead us to use either TPM1.2 or TPM 2
> > specific code. There will be multiple such constructs in tcgbios.c file.
> >
> > Stefan
On Tue, Dec 22, 2015 at 02:14:12AM +0000, Gonglei (Arei) wrote:
> > From: Kevin O'Connor [mailto:kevin@koconnor.net]
> > Sent: Tuesday, December 22, 2015 2:47 AM
> > To: Gonglei (Arei)
> > Cc: Xulei (Stone); Paolo Bonzini; qemu-devel; seabios(a)seabios.org;
> > Huangweidong (C); kvm(a)vger.kernel.org; Radim Krcmar
> > Subject: Re: [Qemu-devel] [PATCH] SeaBios: Fix reset procedure reentrancy
> > problem on qemu-kvm platform
> >
> > On Mon, Dec 21, 2015 at 09:41:32AM +0000, Gonglei (Arei) wrote:
> > > When the gurb of OS is booting, then the softirq and C function
> > > send_disk_op() may use extra stack of SeaBIOS. If we inject a NMI,
> > > romlayout.S: irqentry_extrastack is invoked, and the extra stack will
> > > be used again. And the stack of first calling will be broken, so that the
> > SeaBIOS stuck.
> > >
> > > You can easily reproduce the problem.
> > >
> > > 1. start on guest
> > > 2. reset the guest
> > > 3. inject a NMI when the guest show the grub surface 4. then the guest
> > > stuck
> >
> > Does the SeaBIOS patch below help?
>
> Sorry, it doesn't work. What's worse is we cannot stop SeaBIOS stuck by
> Setting "CONFIG_ENTRY_EXTRASTACK=n" after applying this patch.
Oops, can you try with the patch below instead?
> > I'm not familiar with how to "inject a
> > NMI" - can you describe the process in more detail?
> >
>
> 1. Qemu Command line:
>
> #: /home/qemu/x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 4096 -smp 8 -name suse -vnc 0.0.0.0:10 \
> -device virtio-scsi-pci,id=scsi0 -drive file=/home/suse11_sp3_32_2,if=none,id=drive-scsi0-0-0-0,format=raw,cache=none,aio=native \
> -device scsi-hd,bus=scsi0.0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0 \
> -chardev file,id=seabios,path=/home/seabios.log -device isa-debugcon,iobase=0x402,chardev=seabios \
> -monitor stdio -qmp unix:/tmp/qmp,server,nowait
>
> 2. Inject a NMI by QMP:
>
> #: /home/qemu/scripts/qmp # ./qmp-shell /tmp/qmp
> Welcome to the QMP low-level shell!
> Connected to QEMU 2.5.0
>
> (QEMU) system_reset
> {"return": {}}
> (QEMU) inject-nmi
> {"return": {}}
> (QEMU) inject-nmi
> {"return": {}}
>
I tried a few simple tests but was not able to reproduce.
-Kevin
--- a/src/romlayout.S
+++ b/src/romlayout.S
@@ -548,7 +548,10 @@ entry_post:
ENTRY_INTO32 _cfunc32flat_handle_post // Normal entry point
ORG 0xe2c3
- IRQ_ENTRY 02
+ .global entry_02
+entry_02:
+ ENTRY handle_02 // NMI handler does not switch onto extra stack
+ iretw
ORG 0xe3fe
.global entry_13_official
