Re: [linux-usb-devel] OHCI root_port_reset() deadly loop...

On Tue, 9 Oct 2007, David Brownell wrote:

From: Greg KH <greg@xxxxxxxxx>

Here's some information from Intel about where they have seen this
happen for UHCI controllers, so it's not just an OHCI issue :(

...


The Intel error reports here are kind of unclear.

1) We see that the ports with low speed devices are still in EHCI mode
(port owner bit not written to in EHCI driver).

_When_ are they still in EHCI mode?

In our analyzer captures
we see the reads from the Port Status & Control register and it is
indicating that there are low speed devices on the ports. Can you tell
us why the driver would not be doing the write to the port owner bit
when it sees that low speed devices are attached to that port? Is there
something specific that it looks for and decides not to do the write?

It's hard to say without more info about what's going on. It
might be on a non-enumeraton code path -- where nothing expects
to set the OWNER bit -- or the CONNECT bit might not be set.
See host/ehci-hub.c for details about exactly what the EHCI parts
are doing, and core/hub.c for how it's driven.

Right. In general the driver _does_ write to the port owner bit when
it sees a low-speed device is attached to the port. If that didn't
happen in this case, maybe it's because the driver didn't see it.
There are only one or two places in the code where the driver checks.

(It can be tricky to make sense of all that, easier if debugging
messages are turned on. But that changes timings. Better yet
would be being non-intrusive tracing of the actual code paths
that the CPU follows.)

It certainly would help us if the tests were made on a kernel with
CONFIG_USB_DEBUG enabled.

2) In other cases we see that the ports with the low speed devices are
back in UHCI mode but the ports are disabled. In this case we see from
the analyzer traces that the UHCI driver has completed setting up the
port. It has actually enabled that port in UHCI mode.

This implies that the reset sequence finished successfully. Did that
actually happen?

We then see the
EHCI driver comes in and it resets everything. The driver then gives
control back to the UCHI controller (by setting the port owner bit)
but...since the UHCI driver has already setup this port once it seems
that it does not go back and set it up again. In this case we do not
think that the UHCI driver has completed running when the EHCI driver
comes in and does the reset.

But above they said that it _had_ completed! Did they mean that the
reset was complete but the driver hadn't yet detected that it was
complete?

Can you tell us if the UHCI driver was
interrupted in the middle but after the ports with the low speed devices
had been enabled would the UHCI driver ever go back and reinitialize the
ports with the low speed devices?

If the UHCI driver got disconnect and reconnect notifications,
I expect it would do so. At least OHCI seems *not* to have gotten
such notifications. I'm speculating that the "just a switch"
behavior for the CF (and OWNER) bits may not allow notifications
like that to happen when the companion controllers are resetting.

That seems likely. There's no way (as far as I can tell) for a host to
see a disconnect while a reset is in progress. Of course, as soon as
the reset is over then the host should see the disconnect, and it
should set the corresponding Connect-Status-Changed bit.

Amusing scenario: Suppose that ehci-hcd initializes the EHCI controller
(taking control of the port), sees that the device isn't high speed,
and switches port ownership back to the companion controller, all
during the span of the companion's reset. The companion would never
know anything had happened! But then everything should just work --
the port would be enabled and communication should proceed normally.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Explain this about threads
    ... Basically I'm trying to do synchronous communication with the parallel port. ... I cannot control the delays that other processes and task switching introduce so since its beyond my control I have to ignore it. ... The data transfer rate on a parallel port is a matter of handshake protocol between the port and the device, basically it's the device who decides the rate. ... You can't accurately time the IO transfer rate, all you can do is insert waits in your code user mode or in a driver driver) and as such define a top level rate but no lower rate! ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Parallel port not functioning after Win 2k install
    ... >> parallel port ... >> driver, the computer never saw the printer (I had the box ... >> is listed correctly under the printers folder in Control ...
    (microsoft.public.win2000.hardware)
  • Re: Seagate Barracuda 160 GB IDE becomes corrupted. RMA?
    ... Operating System Microsoft Windows 2000 Professional ... System Memory 512 MB ... Communication Port Communications Port ... Driver Download http://www.viaarena.com/?PageID=2 ...
    (comp.sys.ibm.pc.hardware.storage)
  • Re: sata_nv times out for BD-ROM iHOS104-08
    ... generic IDE driver loaded? ... ACPI: PM-Timer IO Port: 0x4008 ... CPU: Physical Processor ID: 0 ... USB 2.0 'Enhanced' Host Controller Driver ...
    (Linux-Kernel)
  • soft lockup disease (2.6.14-rc1, x86_64)
    ... IA-32 Microcode Update Driver: v1 ... IO window: 1000-1fff] L ... ACPI: PM-Timer IO Port: 0x408 ACPI: Local APIC address 0xfee00000 ...
    (Linux-Kernel)