On Wednesday 26 January 2005 7:55 am, Chris Clayton wrote:
>
> I'm having trouble getting on on-board USB port working on my Compaq
> Aramada 7400. Well. I should qualify that and say that I can't get it to
> wotk with a 2.6 kernel - devices that I plug in when running a
> 2.4.{26,28} kernel or, for that matter, Windows ME, work fine. In fact
> they work fine with 2.6.10 (haven't tried others) if I attach them
> through a cardbus USB2 adapater. The devices I am referring to are a
> Belkin F5D6050 wireless adapter, a STIR4200 IrDA adapter, a plain
> (unpowered) hub and a CF Card adapter. The 2.6 kernels I have tried are
> 2.6.5 and 2.6.10.
So it looks like there's some chip-specific quirk that isn't handled
by the current OHCI code ... or potentially usbcore's hub driver. I'll
assume 2.6.11-rc2 has the same results, and that you tried all the
devices you have ready access to ... :)
This is relatively old hardware -- a Pentium II -- and I think the OHCI
silicon was relatively new at that time. It was before I started working
with OHCI at all, fwiw, and I've never seen Compaq silicon myself. So
it's easy to believe that silicon has constraints that aren't found on
newer hardware (== what most folk test with).
It looked like there were no particular issues during chip initialization,
but I saw a few interesting points there and during enumeration:
- New to me: it doesn't disable the Ownership Change (OC) IRQ (harmless?)
- Hmm, PCI power management "version 1" -- shouldn't matter here
- Seems to read the device descriptors OK, and config descriptor length
- Problems crop up later, when reading the entire config descriptor
- ... or sometimes when reading a string descriptor
- ... or fetching the external hub (class) status
- ... or setting configuration
- Takes a long time to reset ports _after_ any of those errors
- ... often fails completely!
- ... issue seems tied to the root hub port, even with external hubs
The failure mode seems to suggest that the root port goes AWOL
and has a hard time recovering.
On the theory that this silicon wants more time between control requests,
you might try adding an msleep(10) in drivers/usb/core/message.c right
before issuing a control request, at the top of usb_internal_control_msg().
(The OHCI hardware should have gotten rid of all relevant hardware state
after two or three milliseconds; so even 5 msec ought to be plenty...)
Did you try not using ACPI at all? I suspect that won't matter, but
this is APM-era hardware so it's worth verifying this ... lots of
ACPI from that era didn't work according to spec.
A complementary BIOS-interaction theory might be that applying
patch [1] and modprobing with distrust_firmware=N could help.
On the theory that it's a hub driver bug, try [2]. Maybe an even
longer timeout is needed after reset; or maybe one's needed after
set_address().
If none of that helps, can you send /sys/class/usb_host/usb1/registers
files, both after init and after enumeration failure? (And if possible,
during...) They may cast some light on what's going on, especially if
there are interesting changes.
If all else fails, another useful data point would be whether there's
some 2.6 kernel before 2.6.5 that works. There've been two classes
of changes that interact here: in usbcore (notably the hub driver),
and in ohci. Either one could be at fault here. Try 2.6.3, maybe.
- Dave
[1] http://marc.theaimsgroup.com/?l=linux-usb-devel&m=110628457424684&w=2
[2] http://marc.theaimsgroup.com/?l=linux-usb-devel&m=110672516013383&w=2
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
