All,
I'm seeing another USB issue with our platform(s). I've been following the other active USB mail list issue "usb ohci pipe free fix" but don't exactly know where that one started. I'm only guessing that this could be related.
The description of my h/w setup is ... - AMD/Persimmon platform (also observed failure on IEI/Kino) - USB thumbdrive with GRUB (menu options for Ubuntu,memtest86,etc) - USB wireless keyboard/mouse (also observed failure with wired USB keyboard)
I using the SeaBIOS master source.
The failure occurs when the system boots up to the GRUB menu. If I let the menu timeout it will boot the default option which is Ubuntu. If I hit the <Enter> key the system will lock-up with no output on the debug COM port. If at the GRUB menu and I <down arrow> to the memtest86 option, it will sometimes work and sometimes lockup.
I then changed the SeaBIOS debug message level to 8. Then at the point where I hit <ENTER> for the default GRUB option. I will see several debug messages indicating traffic related to the USB thumbdrive and then never ending "handle_hwpic1 irq=0" messages.
Then as I was browsing through the usb code I noticed that some of the keyboard messages only occur at level 9, so I set the level to 9 and all of my booting failures went away. ?. I tracked the message that was somehow fixing my problem down to the file usb-hid.c, in ftn handle_key() (~line 216). If I change that "dprintf(9,..." to "dprintf(1,...", and change the debug message level down below 9, everything still works.
So the delay due to that one debug message fixes some issue related to using a USB keyboard and thumbdrive at the same time. I don't see this issue if I use a SATA drive instead of the USB thumbdrive. Our in-house USB guru (whose not familiar with coreboot) suggests it could be an issue with the OHCI stack.
Does anybody have any suggestions on what this could be? Or where I should start looking?
thanks in advance, Dave
On Wed, Mar 07, 2012 at 03:47:58PM -0700, Dave Frodin wrote:
All,
I'm seeing another USB issue with our platform(s). I've been following the other active USB mail list issue "usb ohci pipe free fix" but don't exactly know where that one started. I'm only guessing that this could be related.
The description of my h/w setup is ...
- AMD/Persimmon platform (also observed failure on IEI/Kino)
- USB thumbdrive with GRUB (menu options for Ubuntu,memtest86,etc)
- USB wireless keyboard/mouse (also observed failure with wired USB keyboard)
I using the SeaBIOS master source.
The failure occurs when the system boots up to the GRUB menu. If I let the menu timeout it will boot the default option which is Ubuntu. If I hit the <Enter> key the system will lock-up with no output on the debug COM port. If at the GRUB menu and I <down arrow> to the memtest86 option, it will sometimes work and sometimes lockup.
In the processes of looking through the OHCI code, I did see what appears to be a race with USB "interrupt" pipe reading. The code is assuming the TD is complete when the ED acknowledges the change, but the spec is pretty clear that the TD can be modified after the ED is updated. However, I'd be quite surprised that such a small race would lead to reproducible failures. I also don't see how it would relate to EHCI thumbdrive usage.
-Kevin
Kevin, I mentioned in a response to the "Re: [SeaBIOS] usb-msc.c: TEST_UNIT_READY needs USB_DIR_OUT?" email thread that when I applied the patches related to that thread the Ubuntu booting issue that I see in this thread actually increases the passing rate from ~0% to ~50%. Perhaps setting the DIR bit twice will solve my problem :)
I also was wondering if you could point me to the code that you referred to when you wrote ... "I did see what appears to be a race with USB "interrupt" pipe reading" ?
thanks in advance, Dave
The failure occurs when the system boots up to the GRUB menu. If I let the menu timeout it will boot the default option which is Ubuntu. If I hit the <Enter> key the system will lock-up with no output on the debug COM port. If at the GRUB menu and I <down arrow> to the memtest86 option, it will sometimes work and sometimes lockup.
In the processes of looking through the OHCI code, I did see what appears to be a race with USB "interrupt" pipe reading. The code is assuming the TD is complete when the ED acknowledges the change, but the spec is pretty clear that the TD can be modified after the ED is updated. However, I'd be quite surprised that such a small race would lead to reproducible failures. I also don't see how it would relate to EHCI thumbdrive usage.
-Kevin
On Fri, Mar 16, 2012 at 03:37:37PM -0600, Dave Frodin wrote:
Kevin, I mentioned in a response to the "Re: [SeaBIOS] usb-msc.c: TEST_UNIT_READY needs USB_DIR_OUT?" email thread that when I applied the patches related to that thread the Ubuntu booting issue that I see in this thread actually increases the passing rate from ~0% to ~50%.
That's odd.
Perhaps setting the DIR bit twice will solve my problem :)
I also was wondering if you could point me to the code that you referred to when you wrote ... "I did see what appears to be a race with USB "interrupt" pipe reading" ?
In ohci_control() the function exits when the pipe->ed indicates the transfer is complete. However, the controller can write to the tds[] structs after the pipe->ed is updated. Therefore there could be a race between the controller and driver. Similarly, ohci_poll_intr() has the same issue. This is just in the OHCI code - I don't know of any issues in the UHCI/EHCI code.
I tried to fix this when I was working on the USB patch series I recently posted. However, the stuff I tried made the OHCI controller less stable on my e350m1 machine.
-Kevin
-
Dave Frodin -
Dave Frodin -
Kevin O'Connor