Hi Dave,
>-----Original Message-----
>From: [email protected]
>[mailto:[email protected]] On Behalf Of David Brownell
>Sent: Monday, January 23, 2006 11:01 AM
>To: [email protected]
>Cc: Andrew Morton; Carlo E. Prelz; [email protected]
>Subject: Re: [linux-usb-devel] Re: ATI RS480-based
>motherboard: stuck while booting with kernel >= 2.6.15 rc1
>
>
>> OK, so it sounds like quirk_usb_disable_ehci() caused your
>machine to hang
>> with the old BIOS. That's fairly bad behaviour from the kernel, even
>> though the BIOS presumably had some problems.
>
>I think what happened is the "always run quirks" code got turned into
>the default too early, before the EHCI "quirk" version of the handoff
>code got checked against what most systems have been using for the past
>several years.
>
>I noticed at least one suspicous thing: it enables an SMI IRQ.
As far as I recall, some BIOSes can be stuck at handoff forever
waiting for SMI if this is not enabled. No doubt BIOS bug, and seems
like work around brakes some other systems, grrr...
>Even in cases when the boot firmware says it's not using EHCI ...
That's what I do not understand. SOOE is enabled only if BIOS ownes
EHCI - check for ECHI_USBLEGSUP_BIOS in previous 'if' statement. Am I
missing something ?
Thanks,
Aleks.
>easy to imagine that causing hangage.
>
>
>Maybe this time it'd help to tell your BIOS "yes, DO use USB".
>Or, the attached patch might help. Please try both experiments.
>
>- Dave
>
>
>
On Monday 06 February 2006 6:03 pm, Aleksey Gorelov wrote:
> Hi Dave,
>
> >....
> >
> >I think what happened is the "always run quirks" code got turned into
> >the default too early, before the EHCI "quirk" version of the handoff
> >code got checked against what most systems have been using for the past
> >several years.
> >
> >I noticed at least one suspicous thing: it enables an SMI IRQ.
>
> As far as I recall, some BIOSes can be stuck at handoff forever
> waiting for SMI if this is not enabled. No doubt BIOS bug, and seems
> like work around brakes some other systems, grrr...
I gathered as much and that's why I preserved that behavior.
But it would be nice to know _which_ BIOS versions have that bug;
it's clearly a BIOS bug, and given the other problems we've seen,
it might be better to have that "turn on the SMI" be keyed by some
"real" quirk logic or kernel parameters.
(The fact that USB handoff is being driven by "quirk" logic, even
when it's not a quirk, also raises little warning flags...)
> >Even in cases when the boot firmware says it's not using EHCI ...
>
> That's what I do not understand. SOOE is enabled only if BIOS ownes
> EHCI - check for ECHI_USBLEGSUP_BIOS in previous 'if' statement. Am I
> missing something ?
That's how it works now, but it didn't do that before. Previously it
always turned on the SMI, and then never turned it off, causing issues
on various platforms.
Of course, the BIOS that Carlo is struggling with seems terminally
broken, and is blatantly ignoring the spec for how those handoff
flags are supposed to work.
- Dave
On Tue, 2006-02-07 at 14:05 -0800, David Brownell wrote:
> On Monday 06 February 2006 6:03 pm, Aleksey Gorelov wrote:
> > Hi Dave,
> >
> > >....
> > >
> > >I think what happened is the "always run quirks" code got turned into
> > >the default too early, before the EHCI "quirk" version of the handoff
> > >code got checked against what most systems have been using for the past
> > >several years.
> > >
> > >I noticed at least one suspicous thing: it enables an SMI IRQ.
> >
> > As far as I recall, some BIOSes can be stuck at handoff forever
> > waiting for SMI if this is not enabled. No doubt BIOS bug, and seems
> > like work around brakes some other systems, grrr...
>
> I gathered as much and that's why I preserved that behavior.
>
> But it would be nice to know _which_ BIOS versions have that bug;
> it's clearly a BIOS bug, and given the other problems we've seen,
> it might be better to have that "turn on the SMI" be keyed by some
> "real" quirk logic or kernel parameters.
Agree with this. At the time the code was written I did not run into
any issues with it, hence it was the default. Unfortunately, I do not
remember exact platforms. (yes, platforms, not BIOS versions -
unfortunately, lots of bugs are introduced during tailoring BIOS to
particular platform).
>
> (The fact that USB handoff is being driven by "quirk" logic, even
> when it's not a quirk, also raises little warning flags...)
Frankly, we are still not doing it early enough. On some platforms it
causes huge delays during some of ACPI code, and quirks are working
afterward... Moving handoff earlier resolves the issue, but this may be
a bit of extreme...
>
>
> > >Even in cases when the boot firmware says it's not using EHCI ...
> >
> > That's what I do not understand. SOOE is enabled only if BIOS ownes
> > EHCI - check for ECHI_USBLEGSUP_BIOS in previous 'if' statement. Am I
> > missing something ?
>
> That's how it works now, but it didn't do that before. Previously it
> always turned on the SMI, and then never turned it off, causing issues
> on various platforms.
No, it's been like this all the time. Compare 'switch' and 'if'
statements in the patch against single original 'if' but with 2
conditions. Your patch is actually different in the following ways:
- it goes over all possible capabilities instead of processing just
first one - right thing to do;
- it always sets OS ownership, even if BIOS did not have it.
- it always disables SMI, not just in case when handoff failed. This
probably right way to cleanup after BIOS which does handoff, but does
not disable SMI afterward.
In other words, it does stop doing what previous code was doing, it
just extends it. And according to Greg, it extends it in right way ;-)
>
> Of course, the BIOS that Carlo is struggling with seems terminally
> broken, and is blatantly ignoring the spec for how those handoff
> flags are supposed to work.
Agree.
Aleks.
>
> - Dave
>
>