On Mon, 16 Oct 2006, Bernd Schubert wrote: > > 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.
You should try modifying max_sectors instead of read_ahead. See the entry on max_sectors in the FAQ at www.linux-usb.org. Or modify max_sectors_kb instead; the two sysfs interfaces affect the same variable. > 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. I'm not too certain about how ra_pages is interpreted either. However I don't think either 1) or 2) is a bug. At worst it means that read-ahead will require two transfers to fill the buffer. Alan Stern ------------------------------------------------------------------------- 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
