RE: [PATCH] Early USB handoff

RE: [PATCH] Early USB handoff

[Aleksey Gorelov]

 
>> I'm also not clear what kind of BIOS quirk it's trying to
>> resolve.  Is the issue just that PCI setup from Linux, long
>> before the HCD initializes, ends up confusing the BIOS
>> on those "summit" machines?  What symptoms would
>> suggest that I should try this option, on non-summit boxes?
>
>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=126984
>
>Here's the interesting part:
>
>> The hardware team here narrowed down the boot time hang to a 
>BIOS bug 
>> where the USB Legacy support feature causes register 
>corruption. This 
>> is unfortunately due to architecture timing constraints and 
>cannot be 
>> fixed with a BIOS update. Disabling Legacy USB support works around 
>> the issue, but leaves the user w/o keyboard support in grub.  
[snip]
>I suspect Aleks hits a similar issue with some other hardware.
>
>-- Pete
>

Pete, thanks for an explanation & reference. Though, I also got
"not authorized" while trying to access it.

Patch is supposed to resolve at least 2 issues (I ran into 
both of them on different laptops):
1. USB Legacy support problem Pete mentioned above
2. Boot lockup problem due to an interrupt shared with HC 
   on a platform with legacy free BIOS.

Symptoms for second one are described here:
http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg267
77.html

  Basically, in a case of legacy free BIOS, HC is not in 
SMM mode, and USB IRQ is routed to PCI IRQ line and generates
interrupts. When this IRQ is enabled in PIC (by driver that 
starts before HC driver), system is flooded with interrupts.
  One solution is to reset HC, but it takes some time (at 
least 50ms). I agree that it might duplicate SOME code in HC 
driver, but HC init executes too late. Well, if handoff has 
been done early, it might not be necessary to do the same in 
HC driver.

Aleks.

RE: [PATCH] Early USB handoff

[Alan Cox]

On Iau, 2004-09-02 at 20:03, Aleksey Gorelov wrote:
>   Basically, in a case of legacy free BIOS, HC is not in 
> SMM mode, and USB IRQ is routed to PCI IRQ line and generates
> interrupts. When this IRQ is enabled in PIC (by driver that 
> starts before HC driver), system is flooded with interrupts.

The BIOS should not be leaving the device generating interrupts surely ?
If that IRQ line ends up shared we are in trouble at boot time. 

>   One solution is to reset HC, but it takes some time (at 
> least 50ms). I agree that it might duplicate SOME code in HC 
> driver, but HC init executes too late. Well, if handoff has 
> been done early, it might not be necessary to do the same in 
> HC driver.

We don't always want to hand off. Some setups only work in USB legacy
mode because of other bugs. Thats why the SMM fixup I did for E750x is
triggered in specific cases. We can do such things with DMI table
blacklists easily enough.

My E750x fix already duplicates some of the hand off code so we are
going to need it anyway and if there are more reasons for needing it
then so be it. I happened to only need to fix UHCI thats all.

Alan

RE: [PATCH] Early USB handoff

[Aleksey Gorelov]

>>   Basically, in a case of legacy free BIOS, HC is not in 
>> SMM mode, and USB IRQ is routed to PCI IRQ line and generates
>> interrupts. When this IRQ is enabled in PIC (by driver that 
>> starts before HC driver), system is flooded with interrupts.
>
>The BIOS should not be leaving the device generating 
>interrupts surely ?
>If that IRQ line ends up shared we are in trouble at boot time. 
  Well, this is what happened on Motion tablet.
  While still in real mode, BIOS takes care of interrupts from 
devices. But once OS takes control over and goes to protected 
mode, there is no easy way for BIOS to detect that and disable HC.
So, one should either avoid 'sharing' it with other devices (at
IRQ routing stage), or reprogram HC in native OS mode first (at 
least disable interrupts).

>We don't always want to hand off. Some setups only work in USB legacy
>mode because of other bugs. That's why the SMM fixup I did for E750x is
>triggered in specific cases. We can do such things with DMI table
>blacklists easily enough.
  I was not aware of this. However, there is an option and handoff
is disabled by default. DMI table may be Ok if there are only 
a few such machines. Unfortunately, I personally had USB legacy 
problems on several laptops, plus saw some reports on the web.
But I guess it is not for me to decide ;)

Aleks.