Re: Possible EHCI bugs

On Sun, Jun 15, 2003 at 03:59:48PM -0700, Bill Paul wrote:
> 
> I was recently contacted by an individual at Transmeta who was trying
> to use FreeBSD current with a board containing an EHCI USB controller
> and encountered some problems with it. He original intent was to use
> FreeBSD's USB 2.0 support and the if_axe driver to help debug a problem
> with said hardware combination with another OS which shall remain
> nameless. Along the way, he discovered the following:
> 
> - The USB_ATTACH() routine in if_axe.c would lead to a panic because
>   uaa->iface was NULL. I consider this a bit peculiar because a) with
>   my own test setup (my laptop, with UHCI controller), uaa->iface is
>   always populated, and b) uaa->iface is set to something during
>   the USB_PROBE() routine (it must be, otherwise the probe would fail).
>   I worked around this by grabbing the interface handle using
>   usbd_device2interface_handle(), but having the EHCI driver behave
>   inconsistently with respect to the UHCI and OHCI driver seems a
>   bit counterintuitive.

After the first quick reply now with a bit rethinking...

The parameter is handled with common code - no differences here.
This could possibly happen with every controller.
And we have a hardware problem with the OHCI controller.
As it's a companion controller sharing the mechanical port this could
result in problems.

> ohci0: <AcerLabs M5237 (Aladdin-V) USB controller> mem 0xe0000-0xe0fff irq 11 at device 15.0 on pci0
> usb0: OHCI version 1.0, legacy support
> usb0: SMM does not respond, resetting

Workaround code responds here - I can't say if successfully, but I've
seen other negative reports with OHCI part of Acer chips.

> usb0: <AcerLabs M5237 (Aladdin-V) USB controller> on ohci0
> usb0: USB revision 1.0
> uhub0: AcerLabs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
> uhub0: 2 ports with 2 removable, self powered
> uhub0: device problem, disabling port 2

The connected device failed!
I asume it's the axe device, which should get probed here, because
the ehci controller is not active yet.
USB_DEBUG should tell us more about the cause.
Note: we are strictly USB1.x at this time.

> ohci1: <AcerLabs M5237 (Aladdin-V) USB controller> mem 0xe8002000-0xe8002fff irq 10 at device 15.1 on pci0
> usb1: OHCI version 1.0, legacy support
> usb1: <AcerLabs M5237 (Aladdin-V) USB controller> on ohci1
> usb1: USB revision 1.0
> uhub1: AcerLabs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
> uhub1: 2 ports with 2 removable, self powered

No problems reported with the second OHCI controller.

> ehci0: <EHCI (generic) USB 2.0 controller> mem 0xe8003400-0xe80034ff irq 7 at device 15.3 on pci0
> ehci_pci_attach: companion usb0
> ehci_pci_attach: companion usb1
> usb2: EHCI version 1.0
> usb2: companion controllers, 2 ports each: usb0 usb1
> usb2: <EHCI (generic) USB 2.0 controller> on ehci0
> usb2: USB revision 2.0
> uhub2: AcerLabs EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
> uhub2: 6 ports with 6 removable, self powered

6 Ports, but we have only 4 found by companion controllers!
Those numbers should be identic.
I'm missing PCI device 15:2!
Maybe that should be a third OHCI controller with the remaning 2 ports.
I'm not saying, that this is the reason for the reported problems, but
I can tell you for shure that EHCI depends on working companion
controllers.
After this mass of problems I could also easily imagine hardwarebugs in
the EHCI controller as well.

We should get the hardware working first, befor we start fixing
possibly symptoms in upper layers.

> This seems to indicate something in the USB code is re-using a
> free()ed memory buffer. Unfortunately, I don't have this particular
> hardware available to me, and I don't know how much debugging support
> the individual at Transmeta will be able to offer. (He has his own
> problems.) Hopefully this will at least help spur some investigation.

It would be good if theres a chance to retry this test with a NEC based
controller.
Currently I'm not shure if it's really a software bug.

-- 
B.Walter                   BWCT                http://www.bwct.de
ticso_at_bwct.de                                  info_at_bwct.de