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
