* 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.
Great!
Thank you very much for the help, now I can use 2.4.22 :)
--
Fridtjof Busse
I'm just very selective about the reality I choose to accept.
--- Calvin
-------------------------------------------------------
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
