[prev in list] [next in list] [prev in thread] [next in thread]
List: linux-usb-users
Subject: Re: [Linux-usb-users] reset high speed USB device
From: Bernd Schubert <bernd-schubert () gmx ! de>
Date: 2006-10-15 23:30:51
Message-ID: 200610160130.52241.bernd-schubert () gmx ! de
[Download RAW message or body]
Hello Alan,
thanks a lot for your help
On Sunday 15 October 2006 17:40, you wrote:
> On Sat, 14 Oct 2006, Bernd Schubert wrote:
> > On Saturday 14 October 2006 17:44, Alan Stern wrote:
> > > > http://www.pci.uni-heidelberg.de/tc/usr/bernd/downloads/scsi-reset/re
> > > >set. log.bz2 (about 7MB bunziped, all messages between two resets).
> > >
> > > The file can't be downloaded:
> >
> > Sorry my mistake, I forgot to set the proper permissions. Works now.
>
> The log shows everything to be okay from after the first reset all the way
> until the end, some 30 seconds later. At that point the device
> transferred 1024 bytes less than the computer told it to, and didn't let
> the computer know it was doing so. Eventually the computer decided it
> wasn't going to get anything more from the drive, so it started another
> reset.
Ah, finally I understand meaning of the entries in the log.
>
> Although the problem may have been caused by the drive originally, the USB
> enclosure should have informed the computer about the short data transfer.
>
> It's possible that this happens only with sectors near the end of the
> disk. You might be able to stop the problems by avoiding that area.
Unfortunately not. I even rapartioned it and left the last 100MB free - still
the same problem. My test transfers showed this happens randomly all over the
device. However, the failed request of 120kB pointed me to the read_ahead
size. Reducing this size to 64kB (via /sys/block/sdX/queue/read_ahead_kb)
entirely solved the problem.
What do you think about a patch automatically reducing the read_ahead size
when this error happens and read size is srb->request_bufflen? I have
absolutely no experience with kernel programming and couldn't find the call
of usb_stor_Bulk_transport(). Well, I see it must be done as function pointer
to us->transport, but so fast I didn't find the call of us->transport().
Anyway, I think struct us_data *us is per device, isn't it? So I could simply
set us->srb->request_bufflen and it would only affect the current device,
wouldn't it?
However, somehow I think it would be better to modify the read_ahead size as
showed by the sysfs entry, but I have absolutely now idea how the access the
values for the underlying block device. I see there is block/ll_rw_blk.c and
the read-ahead size there is q->backing_dev_info.ra_pages, but I don't know
how to access it from the usb layer.
While I experimented with the read ahead values via sysfs, I think I also
found a small other bug. The value in queue/read_ahead_kb is 128 at the
beginning (without setting a value myself), but since max_hw_sectors_kb is
120, read_ahead_kb is also limited to 120 (as by block/ll_rw_blk.c). So there
seem to be two mismatches,
1.) us->srb->request_bufflen != q->backing_dev_info.ra_pages (120k vs. 128k)
2.) q->backing_dev_info.ra_pages must be <= q->max_hw_sectors, but isn't.
Sorry for my long mail, but due to my limited kernel knowlegde I have to
assume several things, which I'm entirely uncertain about.
Cheers,
Bernd
--
Bernd Schubert
PCI / Theoretische Chemie
Universität Heidelberg
INF 229
69120 Heidelberg
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Linux-usb-users@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic