Messages in this thread | | | Date | Wed, 6 Jul 2005 10:30:09 -0400 (EDT) | From | Alan Stern <> | Subject | RE: [linux-usb-devel] Kernel unable to read partition table on US B Memory Key |
| |
On Wed, 6 Jul 2005, Roberts-Thomson, James wrote:
> Alan, > > > Try putting delays at various spots in sd_revalidate_disk: > > the beginning, the middle, and the end. > > OK, the attached patch works for me when sd_mod was loaded with delay_use=1. > > Now I'm quite prepared to be told that this is a really horrible and > inapproprate hack (given that I am not a kernel developer, I don't really > know the "correct" way to solve this problem); and I'll cheerfully admit > that it doesn't really solve the problem cleanly as can be seen below:
It would have been better simply to call msleep, but never mind.
> Jul 6 14:44:52 pc196344 kernel: sd: waiting for device to get ready. > Jul 6 14:44:53 pc196344 kernel: sda: Unit Not Ready, sense: > Jul 6 14:44:53 pc196344 kernel: : Current: sense key: Unit Attention > Jul 6 14:44:53 pc196344 kernel: Additional sense: Not ready to ready > change, medium may have changed > Jul 6 14:44:53 pc196344 kernel: sda : READ CAPACITY failed. > Jul 6 14:44:53 pc196344 kernel: sda : status=1, message=00, host=0, > driver=08 > Jul 6 14:44:53 pc196344 kernel: sd: Current: sense key: Unit Attention > Jul 6 14:44:53 pc196344 kernel: Additional sense: Not ready to ready > change, medium may have changed > Jul 6 14:44:53 pc196344 kernel: sda: test WP failed, assume Write Enabled > Jul 6 14:44:53 pc196344 kernel: sda: assuming drive cache: write through
> Jul 6 14:44:53 pc196344 kernel: sd: waiting for device to get ready. > Jul 6 14:44:54 pc196344 kernel: sda: Unit Not Ready, sense: > Jul 6 14:44:54 pc196344 kernel: : Current: sense key: Unit Attention > Jul 6 14:44:54 pc196344 kernel: Additional sense: Not ready to ready > change, medium may have changed > Jul 6 14:44:54 pc196344 kernel: sda : READ CAPACITY failed. > Jul 6 14:44:54 pc196344 kernel: sda : status=1, message=00, host=0, > driver=08 > Jul 6 14:44:54 pc196344 kernel: sd: Current: sense key: Unit Attention > Jul 6 14:44:54 pc196344 kernel: Additional sense: Not ready to ready > change, medium may have changed > Jul 6 14:44:54 pc196344 kernel: sda: test WP failed, assume Write Enabled > Jul 6 14:44:54 pc196344 kernel: sda: assuming drive cache: write through
> Jul 6 14:44:54 pc196344 kernel: sd: waiting for device to get ready. > Jul 6 14:44:55 pc196344 kernel: SCSI device sda: 255488 512-byte hdwr > sectors (131 MB) > Jul 6 14:44:55 pc196344 kernel: sda: Write Protect is off > Jul 6 14:44:55 pc196344 kernel: sda: Mode Sense: 03 00 00 00 > Jul 6 14:44:55 pc196344 kernel: sda: assuming drive cache: write through > Jul 6 14:44:55 pc196344 kernel: /dev/scsi/host5/bus0/target0/lun0: p1 > Jul 6 14:44:55 pc196344 kernel: Attached scsi removable disk sda at scsi5, > channel 0, id 0, lun 0 > > There are three delays from my patch in the above list,
Yes. Why are there three instead of just one? The sd_revalidate_disk routine should only be called once (although a bug in recent kernels causes it to be called twice).
> and increasing the > delay to 3 seconds didn't help, as I got three one-second delays.
I don't understand. Why didn't you get three three-second delays?
> However, if someone with the appropriate knowledge could transform my kludge > into a proper fix, then I would be very happy.
Can you try adding delays before, after, and inbetween the calls to sd_read_capacity, sd_read_write_protect_flag, and sd_read_cache_type, all near the end of sd_revalidate_disk?
> Alan, thanks very much for your help - I really appreciate the quick > responses you have given me. > > Note that I now have the output from the USB Snoop tool under Windows if > anyone wants it - please ask if needed to help solve the issue "correctly".
Can you make it available on a web or ftp site and post the URL for interested parties?
Alan Stern
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |