On Mon, 6 Feb 2006, Aleksey Gorelov wrote:
> 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 ?
On Tue, 7 Feb 2006, Carlo E. Prelz wrote:
> Quoting Alan Stern ([EMAIL PROTECTED]):
>
> > What happens if you get rid of the whole "if" statement below the "case
> > 1:" line? In other words, don't set the EHCI_USBLEGCTLSTS_SOOE bit in the
> > EHCI_USBLEGCTLSTS dword? (Dave asked this question before but you didn't
> > answer.) Perhaps by not notifying the BIOS of the ownership change, you
> > will avoid a hang.
>
> Ok. I have commented out the whole if right after 1: - the one
> beginning with
>
> if ((cap & EHCI_USBLEGSUP_BIOS)) {
>
> and uncommented the line that used to freeze my machine. The machine
> is *not* freezing anymore. This printout still appears:
>
> 0000:00:13.2 EHCI: BIOS handoff failed (BIOS bug ?)
>
> at this point cap has one more bit on than before: it is 0x1010001
> instead of 0x10001
>
> Also in this case, USB works OK.
This looks like another one of those bad situations, where buggy firmware
will bite you no matter what. Some BIOSes will fail if you don't set the
SOOE bit and others will fail if you do.
What's going on here could be that the BIOS doesn't expect ever to receive
an owner-change SMI interrupt. Maybe it polls for owner changes; maybe it
just ignores them. Whatever the reason, when the interrupt does arrive it
crashes the BIOS.
On the whole, I think it's better to stick to the letter of the spec. The
BIOS is supposed to enable SOOE if it has taken over the host controller.
If SOOE isn't enabled, we should assume the BIOS doesn't want those
interrupts. Since the code does clear all the SMI-enable bits at the end
of the routine, the worst that's likely to happen is we time out on that
5-second delay (which maybe could be shortened to 1 second?) and log an
error.
Alan Stern
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
