Greg KH wrote:
Hm, with these two patches, and all of the EHCI patches from David, I'm seeing some very long delays in trying to get to data from a USB 2.0 hard drive. I'll go enable some debugging and see if I can notice where the problems are. Is anyone also seeing this?
I haven't noticed delays. How do you notice them, and what's "long"? Maybe I can try with an upcoming snapshot.
But a disk that sometimes reports errors (I don't think they're driver problems, though on this run the block numbers look more interesting than usual) gave me many "buffer layer error" messages. Kernel here is 2.5.50 with only my EHCI patches. I've had mail offline with Matt that made us suspect there are still buffer layer bugs getting shaken out. For one: "mkfs -c -c" (to do destructive badblocks) would oops if I next mounted the FS, but the less aggressive "mkfs -c" (non-destructive badblocks) wouldn't. - Dave Initializing USB Mass Storage driver... drivers/usb/core/usb.c: usb_device_probe drivers/usb/core/usb.c: usb_device_probe - got id scsi0 : SCSI emulation for USB Mass Storage devices Vendor: QUANTUM Model: FIREBALLlct1 Rev: A03. Type: Direct-Access ANSI SCSI revision: 02 WARNING: USB Mass Storage data integrity not assured USB Mass Storage device found at 2 drivers/usb/core/usb.c: registered new driver usb-storage USB Mass Storage support registered. sda : MODE SENSE failed. sda : status = 1, message = 00, host = 0, driver = 08 Current sd?: sense key Illegal Request Additional sense: Invalid command operation code sda : assuming drive cache: write through SCSI device sda: 20044080 512-byte hdwr sectors (10263 MB) sda: sda1 Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 that's as far as hotplug got me. then "fsck -fy /dev/sda1" SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 70000 end_request: I/O error, dev sda, sector 63 Buffer I/O error on device sd(8,1), logical block 0 SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 70000 end_request: I/O error, dev sda, sector 262207 Buffer I/O error on device sd(8,1), logical block 32768 SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 70000 end_request: I/O error, dev sda, sector 786495 Buffer I/O error on device sd(8,1), logical block 98304 SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 70000 end_request: I/O error, dev sda, sector 1310783 Buffer I/O error on device sd(8,1), logical block 163840 SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 70000 end_request: I/O error, dev sda, sector 1835071 Buffer I/O error on device sd(8,1), logical block 229376 SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 70000 end_request: I/O error, dev sda, sector 2359359 Buffer I/O error on device sd(8,1), logical block 294912 SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 70000 end_request: I/O error, dev sda, sector 6553663 Buffer I/O error on device sd(8,1), logical block 819200 SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 70000 end_request: I/O error, dev sda, sector 6553671 Buffer I/O error on device sd(8,1), logical block 819201 SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 70000 end_request: I/O error, dev sda, sector 12845119 Buffer I/O error on device sd(8,1), logical block 1605632 sometimes this device reports errors, lately "70000", which so far I've assumed are real but transient. that filesystem was probably made with destructive badblock mappings. buffer layer error at fs/buffer.c:2641 Pass this trace through ksymoops for reporting Call Trace: [<c0157db7>] drop_buffers+0x37/0xc0 [<c0157ed3>] try_to_free_buffers+0x93/0x120 [<c014d688>] invalidate_complete_page+0x28/0xe0 [<c014db01>] invalidate_inode_pages+0xa1/0x100 [<c015bf5f>] generic_writepages+0xf/0x13 [<c015a62d>] kill_bdev+0xd/0x30 [<c015bd1a>] blkdev_put+0xca/0x230 [<c0153fa5>] __fput+0x35/0x180 [<c013a48d>] filemap_fdatawait+0x11d/0x1d0 [<c01526ff>] filp_close+0x10f/0x120 [<c0152796>] sys_close+0x86/0xc0 [<c010926b>] syscall_call+0x7/0xb buffer layer error at fs/buffer.c:2690 Pass this trace through ksymoops for reporting Call Trace: [<c0157def>] drop_buffers+0x6f/0xc0 [<c0157ed3>] try_to_free_buffers+0x93/0x120 [<c014d688>] invalidate_complete_page+0x28/0xe0 [<c014db01>] invalidate_inode_pages+0xa1/0x100 [<c015bf5f>] generic_writepages+0xf/0x13 [<c015a62d>] kill_bdev+0xd/0x30 [<c015bd1a>] blkdev_put+0xca/0x230 [<c0153fa5>] __fput+0x35/0x180 [<c013a48d>] filemap_fdatawait+0x11d/0x1d0 [<c01526ff>] filp_close+0x10f/0x120 [<c0152796>] sys_close+0x86/0xc0 [<c010926b>] syscall_call+0x7/0xb both those traces repeated five more times. they seemed to happen right when 'fsck' finished. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
