December 2015 - SeaBIOS - mail.coreboot.org

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by edward wandasiewicz Dec. 19, 2015

Dec. 19, 2015

---------- Forwarded message ---------- From: "edward wandasiewicz" <0.w3ntd(a)gmail.com> Date: 19 Dec 2015 1:44 a.m. Subject: Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly To: "Kevin O'Connor" <kevin(a)koconnor.net> Cc: Is it a technically a manufacturer messing up the USB spec definitions it should be following? Of all the USB drives I've come across, this Philips one is the only one that behaves like this. It's like its saying "hey, I'm a USB 2.0 spec device, no wait a moment, I'm really a USB 3.0 spec device." and we turn around and say "make ya mind up", by which time it's too late. Sometimes we just can't fix every problem. Granted this one is a tough one to solve. Edward. On Sat, Dec 19, 2015 at 01:51:15AM +0100, Peter Stuge wrote: > Kevin O'Connor wrote: > > > Doesn't it effectively take the same amount of wall clock time? > .. > > If you're asking if current state vs unregistering/delaying would take > > the same wall time - thinking about that now, it might be true. > > Right - that's what I meant. I think it will, because .. > > > > I guess the implementaiton and how things like CONFIG_THREADS=n are > > handled would determine that. > > .. by the time the menu is shown and/or SeaBIOS boots automatically > there is only one thread running anyway, right? > > (Or is this where I am missing something?) Thinking about this further, USB hubs are the real issue. In theory, a hub could have the same issue of being detected initially as USB2 and then later as USB3. In this situation, delaying does fix the issue, but it adds more wall time as then one can't query the devices downstream of the hub until after the delay. Unregistration doesn't work well with hubs, because it's complicated to determine connectivity for devices downstream of a hub that's been removed, and because it would require different code for unregistration of mice and keyboards. -Kevin _______________________________________________ SeaBIOS mailing list SeaBIOS(a)seabios.org http://www.seabios.org/mailman/listinfo/seabios

1 0

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by edward wandasiewicz Dec. 19, 2015

Dec. 19, 2015

---------- Forwarded message ---------- From: "edward wandasiewicz" <0.w3ntd(a)gmail.com> Date: 19 Dec 2015 1:44 a.m. Subject: Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly To: "Kevin O'Connor" <kevin(a)koconnor.net> Cc: Is it a technically a manufacturer messing up the USB spec definitions it should be following? Of all the USB drives I've come across, this Philips one is the only one that behaves like this. It's like its saying "hey, I'm a USB 2.0 spec device, no wait a moment, I'm really a USB 3.0 spec device." and we turn around and say "make ya mind up", by which time it's too late. Sometimes we just can't fix every problem. Granted this one is a tough one to solve. Edward. On Sat, Dec 19, 2015 at 01:51:15AM +0100, Peter Stuge wrote: > Kevin O'Connor wrote: > > > Doesn't it effectively take the same amount of wall clock time? > .. > > If you're asking if current state vs unregistering/delaying would take > > the same wall time - thinking about that now, it might be true. > > Right - that's what I meant. I think it will, because .. > > > > I guess the implementaiton and how things like CONFIG_THREADS=n are > > handled would determine that. > > .. by the time the menu is shown and/or SeaBIOS boots automatically > there is only one thread running anyway, right? > > (Or is this where I am missing something?) Thinking about this further, USB hubs are the real issue. In theory, a hub could have the same issue of being detected initially as USB2 and then later as USB3. In this situation, delaying does fix the issue, but it adds more wall time as then one can't query the devices downstream of the hub until after the delay. Unregistration doesn't work well with hubs, because it's complicated to determine connectivity for devices downstream of a hub that's been removed, and because it would require different code for unregistration of mice and keyboards. -Kevin _______________________________________________ SeaBIOS mailing list SeaBIOS(a)seabios.org http://www.seabios.org/mailman/listinfo/seabios

1 0

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by Kevin O'Connor Dec. 19, 2015

Dec. 19, 2015

On Fri, Dec 18, 2015 at 08:12:22PM +0000, edward wandasiewicz wrote: > As requested. Thanks. It appears this particular device is being fully detected as a USB2 device (connection is detected, address is assigned, drive configuration is downloaded, and the drive is registered internally) before the controller/device negotiate a USB3 connection. Once the device is recognized as USB3, the controller disconnects it from USB2, but by that point SeaBIOS has already fully registered it and isn't even checking the connection status. The device is then fully detected as a USB3 device, which is why the duplicate shows up. I don't have a good way to fix that. It's possible to add a delay to USB2 device detection on XHCI controllers to try and make sure they are really USB2 devices, but that isn't a great solution as it adds an unnecessary delay to all other drives (that behave properly). In some of your other emails, you mention type-c cables and different behavior with different cables. The cabling choice has no impact on the software, so I wonder if one of the cables you have (or combination of cables) isn't fully insulated and if it could be causing a delay in USB3 negotiation. If it's possible to fix this with a different cable, that may be the easiest solution. -Kevin

2 8

Re: [SeaBIOS] [Qemu-devel] [PATCH] SeaBios: Fix reset procedure reentrancy problem on qemu-kvm platform
by Kevin O'Connor Dec. 19, 2015

Dec. 19, 2015

On Thu, Nov 19, 2015 at 12:42:50PM +0000, Xulei (Stone) wrote: > Kevin, > > After deeply analyzing, i think there may be 3 possible reasons: > 1)wrong CountCPUs value. It seems CountCPUs++ in handle_smp() has no > lock to protect. So, sometimes, 2 or more vcpu may get the same > current value of CountCPUs. Then we'll get a single incrementation > instead of 2 or more and "while (cmos_smp_count != CountCPUs)" will > loop forever; The handle_smp() code is called from romlayout.S:entry_smp() which does take a lock. So, all of handle_smp() should run synchronous. > 2)wrong cmos_smp_count value. SeaBIOS rtc reads an incorrect number? Not sure - the last time there were problems in this area of the code others used kvmtrace to try and track this down. Since you are getting dprintf statements, you could also try outputting cmos_smp_count prior to the loop (see patch below). > 3)yield() stuck. Is it possible that SeaBIOS is stuck during yield? > I've tested, when yield() is running, SeaBIOS seems has not created > some other threads except the main thread. So I don't know what's > the function of yield() here.? The yield() allows hardware interrupts to occur. But note that yield() isn't called in the loop - is is only called after the loop completes. If you are only getting this on massive repetitive reboot requests, there are some other possible explanations: - perhaps the SIPI is getting lost because one of the CPUs is still resetting or still processing a SIPI from the last reboot? - the seabios code itself may have been corrupted if the memcpy() in qemu_prep_reset() got far enough along to clear HaveRunPost, but did not get far enough along to fully complete the memcpy(). If the failure is reproducible, the patch below could help narrow the possibilities. -Kevin --- a/src/fw/smp.c +++ b/src/fw/smp.c @@ -125,6 +125,7 @@ smp_setup(void) // Wait for other CPUs to process the SIPI. u8 cmos_smp_count = rtc_read(CMOS_BIOS_SMP_COUNT) + 1; + dprintf(1, "cmos_smp_count=%d\n", cmos_smp_count); while (cmos_smp_count != CountCPUs) asm volatile( // Release lock and allow other processors to use the stack. @@ -136,6 +137,7 @@ smp_setup(void) " jc 1b\n" : "+m" (SMPLock), "+m" (SMPStack) : : "cc", "memory"); + dprintf(1, "finish smp\n"); yield(); // Restore memory.

3 2

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by Kevin O'Connor Dec. 18, 2015

Dec. 18, 2015

On Fri, Dec 18, 2015 at 07:08:24PM +0000, edward wandasiewicz wrote: > Wrong file. Correct file attached. I checked for rel-1.9.0-45-gec65068 Thanks, can you retry with 46-g0cc3233 ? -Kevin

2 1

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by edward wandasiewicz Dec. 18, 2015

Dec. 18, 2015

Wrong file. Correct file attached. I checked for rel-1.9.0-45-gec65068 Edward. On Fri, Dec 18, 2015 at 6:40 PM, edward wandasiewicz <0.w3ntd(a)gmail.com> wrote: > Done. > > On Fri, Dec 18, 2015 at 6:25 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote: >> On Fri, Dec 18, 2015 at 06:11:56PM +0000, edward wandasiewicz wrote: >>> As requested. >> >> Thanks, but I had an off-by-one error in the patch - can you do the >> same thing with 45-gec65068? >> >> -Kevin

1 0

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by Kevin O'Connor Dec. 18, 2015

Dec. 18, 2015

On Fri, Dec 18, 2015 at 06:11:56PM +0000, edward wandasiewicz wrote: > As requested. Thanks, but I had an off-by-one error in the patch - can you do the same thing with 45-gec65068? -Kevin

2 1

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by edward wandasiewicz Dec. 18, 2015

Dec. 18, 2015

---------- Forwarded message ---------- From: "edward wandasiewicz" <0.w3ntd(a)gmail.com> Date: 18 Dec 2015 6:11 p.m. Subject: Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly To: "Kevin O'Connor" <kevin(a)koconnor.net> Cc: As requested. Edward. On Fri, Dec 18, 2015 at 6:00 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote: > On Fri, Dec 18, 2015 at 11:51:16AM +0000, edward wandasiewicz wrote: >> I managed to replicate a scenario 2 but with Type-C instead of USB 3, >> with both 42-g9c58583 and 43-g55de21d >> >> 2(b) NO - Type C & Type C - once each (Philips & Muskin) - but double >> Philips showing >> >> cbmem.yes.both.TypeC.TypeC.DoublePhilips.42-g9c58583 >> >> cbmem.yes.both.TypeC.TypeC.DoublePhilips.43-g55de21d > > The 43-g55de21d revision was supposed to address the "double philips" > issue. I need some additional debug information - can pull down > 44-g809467a, decrease the debug level to 3, and forward the log from a > "double philips" boot? > > -Kevin

1 0

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by Kevin O'Connor Dec. 18, 2015

Dec. 18, 2015

On Fri, Dec 18, 2015 at 11:51:16AM +0000, edward wandasiewicz wrote: > I managed to replicate a scenario 2 but with Type-C instead of USB 3, > with both 42-g9c58583 and 43-g55de21d > > 2(b) NO - Type C & Type C - once each (Philips & Muskin) - but double > Philips showing > > cbmem.yes.both.TypeC.TypeC.DoublePhilips.42-g9c58583 > > cbmem.yes.both.TypeC.TypeC.DoublePhilips.43-g55de21d The 43-g55de21d revision was supposed to address the "double philips" issue. I need some additional debug information - can pull down 44-g809467a, decrease the debug level to 3, and forward the log from a "double philips" boot? -Kevin

1 0

Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
by Kevin O'Connor Dec. 18, 2015

Dec. 18, 2015

On Sun, Dec 13, 2015 at 09:16:02PM +0000, edward wandasiewicz wrote: > On Sun, Dec 13, 2015 at 9:05 PM, edward wandasiewicz <0.w3ntd(a)gmail.com> wrote: > > Hooray, it works... minus 2 scenarios :( > > > > With both Philips USB and Mushkin USB attached, and I perform a cold boot > > > > 1. YES - USB 3 & USB 3 - once each (Philips & Mushkin) > > > > cbmem.yes.both.USB3.USB3.gz > > > > 2. NO - USB 3 & USB 3 - once each (Philips & Muskin) - but double > > Philips showing > > > > cbmem.yes.both.USB3.USB3.DoublePhilips.gz > > > > 3. YES - USB 3 & Type C - once each (Philips & Mushkin) > > > > cbmem.yes.both.USB3.TypeC.gz > > > > I can't get a double Philips to appear > > > > 4. YES - Type C & Type C - once each (Philips & Mushkin) > > > > cbmem.yes.both.TypeC.TypeC.gz > > > > 5. NO - Type C & Type C - one Philiips & no Mushkin > > > > I forgot to save > > > > $ cbmem -c > > > > and now can't replicate it. :( If you can't reproduce, it may have been a transient hardware issue (eg, loose plug). Otherwise, to summarize, the devices are now detected pretty reliably, but you still have an issue with double detection of the Philips drive? The double detection looks like the controller doing something weird. I need to look closer at the spec, but I don't think I'll be able to do that until later in the week. > > When I do, I will post output. > > When attempting a cold boot - shutdown - cold boot - shutdown - cold > boot - shutdown - .... > > It seems the list of bootable devices can change order, yet the > devices are plugged into the same ports all the time, and never > unplugged. By default, the order of USB drives in the menu is basically random. If you want to ensure a particular order for USB then a "bootorder" file can be created. You can look at the wiki for info on how to do that, or you can try to extract the bootorder file that John Lewis uses in his roms. -Kevin

3 3