On Tue, 1 Mar 2005, Gerd v. Egidy wrote:
> Hi,
>
> I'm back from hardware-hell.
Welcome, Orpheus! :-)
> I changed every part of the system (cpu, ram,
> board, case/power-supply, pci-cards, disk, usb-frame,...), one at a time, and
> the problem still persists. In the first email I reported that it ran on a
> different system. I tried that again and now it is failing too - seems like
> it was luck back then.
>
> The only thing I did not change is the usb controller card type. I have two
> cards but of the same brand & type:
This seems to narrow down the possible causes to: the USB controller, the
controller driver, too-large transfer lengths, and the Cypress controller.
Still a fairly large range. I think the ehci-hcd driver is a very
low-probability suspect and the transfer length is high probability.
> > > Maybe it'd be happier with a slightly shorter read?
> >
> > Could be. Gerd, have you changed the max_sectors value associated with
> > the device? The default value used by usb-storage is 240, which
> > corresponds to a maximum transfer length of 120 KB. But your log shows
> > attempted transfers of length 128 KB -- perhaps that sometimes causes
> > trouble. Hmmm... Maybe the block layer isn't honoring max_sectors any
> > more...
>
> I haven't changed or patched anything with the max_sectors. Or nothing that
> I'm aware of. Where/How would that be done?
There's a description of max_sectors in the FAQ at www.linux-usb.org.
Can you verify that it is still set to 240? Maybe something we're not
aware of has changed it.
Also, I just tried doing some usb-storage READs. On my system the
transfer lengths never went above 120 KB. So I'd like to know why it went
up to 128 KB in your test. Suppose you try doing what I did:
dd if=/dev/sda of=/dev/null bs=64k
Does that cause 128 KB transfers? If not, what did you do to cause them?
It would be great if I could reproduce it here.
> I'm not sure if that is a problem only related to cypress. I've got another
> usb frame with a genesys chip that shows the same behavior. I tried it and I
> got a disconnect after some time too. I don't know if the log message is
> exactly the same tough and I don't have the log anymore (was just a test
> install). If you need this log I can reinstall and reproduce it.
We know from previous tests and other users that the Genesys controllers
can't handle more than 64 KB at a time.
> I don't understand the protocol details but as far as I understood the reason
> for the resets (and finally the disconnect too) can be that the data
> transferred in one request is too large to fit into fixed-size buffer. Is
> there any quick hack to reduce the transfer size (regardless of what the scsi
> systems thinks and does)? Just to prove this theory.
> Or would it help to add some additional debug kprintfs to the ehci or
> usb_storage driver to get more info about the resets?
The way to reduce the transfer lengths is to decrease max_sectors. At
least, that's how it's _supposed_ to work. I don't think any additional
debugging will help; it's already pretty clear that the device isn't
behaving the way it should.
Alan Stern
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
