Thanks for the reply David.
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...)
That has made some difference. With a delay 10 milliseconds, I can can now
attach the hub and it gets set up OK. I can also attach the STIR4200 IrDA
adapter, either directly through the built-in port or through the hub and it
too installs OK (lsusb shows the device and the output from dmesg shows the
device but no error messages). However, if I attach the CF adapter, I still
get timeout errors.
All subsequent tests are against a kernel that includes this 10 millisecind
delay and using the CF adapter.
>
> 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.
This wouldn't apply against 2.6.10, so figuring it is against 2.6.11-rcX, I
grabbed and built 2.6.11-rc2, and found that the patch is already applied.
However, it doesn't appear to make a difference, either on it's own or in
conjunction with patch [2] - I still see the same error messages as I get
with 2.6.10 plus the 10 millisec delay.
>
> On the theory that it's a hub driver bug, try [2]. Maybe an even
This applied to 2.6.11-rc2 with some fuzz and offsets, but the resultant code
looked OK to me (as if I would know :) ). It made no difference though - same
errors as before.
> longer timeout is needed after reset; or maybe one's needed after
> set_address().
I tried adding delays (ranging from 10 to 100 millisecs) in the places you
suggest, plus a few others were calls that appeared to be generating comms
with the adapter were returning errors that weer being reported in the
diagnostic messages I see through dmesg.
>
> 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.
I'll get these diags to you later (when I get the laptop back off my son -
that may be tomorrow), Hopefully I will also have built and tried 2.6.3 by
tomorrow evening.
>
> 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
Thanks for your help and advice so far.
Chris
-------------------------------------------------------
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
