Hi again,
Following on from yesterday, I've now built 2.6.4 and I find that attaching my
hub fails with timeout errors. So it would appear that a change between 2.6.3
and 2.6.4 is what has stopped the usb system in my laptop working. I've
looked at the changelog on kernel.org and there were quite a few usb-related
patches in 2.6.4, so I guess my job now is to back them out one at a time and
see which one is the culprit, so to speak.
My question now is, where do I get the individual patches from? Also, it would
probably be helpful if I knew which were the most likely candidates.
Any advice/help in this area would be much appreciated.
Thanks
Chris
On Saturday 29 Jan 2005 22:01, David Brownell wrote:
> 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
