* David Brownell <[EMAIL PROTECTED]>:
Aug 11 07:49:05 artus kernel: hub.c: port 2, portstatus 503, change 10, 480 Mb/s Aug 11 07:49:05 artus kernel: hub.c: new USB device 00:02.2-2, assigned address 4 Aug 11 07:49:05 artus kernel: usb.c: kmalloc IF deeb3400, numif 1 Aug 11 07:49:05 artus kernel: usb.c: new device strings: Mfr=0, Product=1, SerialNumber=0 Aug 11 07:49:05 artus kernel: usb.c: USB device number 4 default language ID 0x409 Aug 11 07:49:05 artus kernel: Product: USB TO IDE
Looking like one of the currently-problematic GeneSys adapters...
I'm pretty sure it's a GeneSys, yes.
Any suggestions on a well working device (it's quite difficult to get any information at all about the used adapters)?
Are the FireWire adapters also that "problematic"?
The nForce2 also seems to be a quite "picky", I very often get those "device not accepting address" (not using ACPI), but after a few "unplugs", it works again very often
Thanks for this more detailed kernel log information. The diagnostics in that patch really do suggest hardware flakiness to me -- assuming that I interpreted those bit patterns correctly. You wouldn't be able to do anything like watch usb traffic on a CATC would you?
No.
What's odd is that you report older code working better with this particular hardware. Nothing here suggests driver bugs. So I'm wondering if the difference is that 2.4.22 code talks faster to that hardware, which doesn't like that.
As an experiment, try modifying "ehci-hcd.c". There's a line in ehci_start() that masks a register value with 0x0fff (that constant only lives in that one place). In 2.4.22 that changed, so the 0x0f00 bits were preserved ... speeding up NForce2 by leaving the "park" mode enabled.
Try making that mask be 0x00ff, disabling "park" so the host won't try three consecutive OUT packets. If that helps, please also try 0x0aff, which still gets some speed improvements from the "park" mode but won't push double-buffered devices as hard.
BTDT.
- temp = readl (&ehci->regs->command) & 0x0fff; + temp = readl (&ehci->regs->command) & 0x00ff;
And know what? It fixed my problem, drive works fine with dump at 10500 kB/s.
And with the 0x0aff -- does it still work?
The "park" mode makes a significant difference with some
devices, giving an extra dozen MByte/sec throughput. The
controller can issue one ("0x00ff", "0x09ff"), two ("0x0aff"),
or at most three ("0x0bff" or "0x0fff") packets in a row.If I'm going to de-tune the driver defaults due to flakey hardware, I'd like to de-tune it as little as possible. And I guess I'll want to add module option to let people get top performance, if they don't need that de-tuning...
- Dave
Great! Thank you very much for the help, now I can use 2.4.22 :)
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
