RE: [linux-usb-devel] Kernel unable to read partition table on US B Memory Key

RE: [linux-usb-devel] Kernel unable to read partition table on US B Memory Key

[Roberts-Thomson, James]

Alan,

>How about the patch below instead?  It's a bit easier to use, in that it 
>doesn't require users to know about a new parameter.  Also it retries at 
>1-second intervals for up to 5 seconds, which makes it a little more 
>flexible.  If this works for you, I'll submit it for inclusion in the 
>official kernel.

Thanks; this patch works nicely for me, as can be seen here (the two-second
delay occurs before "ready" below):

Jul 12 11:22:20 pc196344 kernel: usb 1-6: new high speed USB device using
ehci_hcd and address 12
Jul 12 11:22:20 pc196344 kernel: scsi9 : SCSI emulation for USB Mass Storage
devices
Jul 12 11:22:20 pc196344 kernel: usb-storage: device found at 12
Jul 12 11:22:20 pc196344 kernel: usb-storage: waiting for device to settle
before scanning
Jul 12 11:22:22 pc196344 kernel:   Vendor: OTi       Model: Flash Disk
Rev: 2.00
Jul 12 11:22:22 pc196344 kernel:   Type:   Direct-Access
ANSI SCSI revision: 02
Jul 12 11:22:24 pc196344 kernel: ready
Jul 12 11:22:24 pc196344 kernel: SCSI device sda: 255488 512-byte hdwr
sectors (131 MB)
Jul 12 11:22:24 pc196344 kernel: sda: Write Protect is off
Jul 12 11:22:24 pc196344 kernel: sda: Mode Sense: 03 00 00 00
Jul 12 11:22:24 pc196344 kernel: sda: assuming drive cache: write through
Jul 12 11:22:24 pc196344 kernel: SCSI device sda: 255488 512-byte hdwr
sectors (131 MB)
Jul 12 11:22:24 pc196344 kernel: sda: Write Protect is off
Jul 12 11:22:24 pc196344 kernel: sda: Mode Sense: 03 00 00 00
Jul 12 11:22:24 pc196344 kernel: sda: assuming drive cache: write through
Jul 12 11:22:24 pc196344 kernel:  /dev/scsi/host9/bus0/target0/lun0: p1
Jul 12 11:22:24 pc196344 kernel: Attached scsi removable disk sda at scsi9,
channel 0, id 0, lun 0
Jul 12 11:22:24 pc196344 kernel: Attached scsi generic sg2 at scsi9, channel
0, id 0, lun 0,  type 0
Jul 12 11:22:24 pc196344 kernel: usb-storage: device scan complete
Jul 12 11:22:24 pc196344 scsi.agent[27155]: disk at
/devices/pci0000:00/0000:00:1d.7/usb1/1-6/1-6:1.0/host9/target9:0:0/9:0:0:0
Jul 12 11:26:43 pc196344 kernel: usb 1-6: USB disconnect, address 12

Also, I checked with my older key, and as expected there was no problem
there either (patch had no effect):

Jul 12 11:26:55 pc196344 kernel: usb 4-2: new full speed USB device using
uhci_hcd and address 2
Jul 12 11:26:56 pc196344 kernel: scsi10 : SCSI emulation for USB Mass
Storage devices
Jul 12 11:26:56 pc196344 kernel: usb-storage: device found at 2
Jul 12 11:26:56 pc196344 kernel: usb-storage: waiting for device to settle
before scanning
Jul 12 11:26:58 pc196344 kernel:   Vendor: IBM       Model: Memory Key
Rev: 1.01
Jul 12 11:26:58 pc196344 kernel:   Type:   Direct-Access
ANSI SCSI revision: 00
Jul 12 11:26:58 pc196344 kernel: SCSI device sda: 64000 512-byte hdwr
sectors (33 MB)
Jul 12 11:26:58 pc196344 kernel: sda: Write Protect is off
Jul 12 11:26:58 pc196344 kernel: sda: Mode Sense: 43 00 00 00
Jul 12 11:26:58 pc196344 kernel: sda: assuming drive cache: write through
Jul 12 11:26:58 pc196344 kernel: SCSI device sda: 64000 512-byte hdwr
sectors (33 MB)
Jul 12 11:26:58 pc196344 kernel: sda: Write Protect is off
Jul 12 11:26:58 pc196344 kernel: sda: Mode Sense: 43 00 00 00
Jul 12 11:26:58 pc196344 kernel: sda: assuming drive cache: write through
Jul 12 11:26:58 pc196344 kernel:  /dev/scsi/host10/bus0/target0/lun0: p1
Jul 12 11:26:58 pc196344 kernel: Attached scsi removable disk sda at scsi10,
channel 0, id 0, lun 0
Jul 12 11:26:58 pc196344 kernel: Attached scsi generic sg2 at scsi10,
channel 0, id 0, lun 0,  type 0
Jul 12 11:26:58 pc196344 kernel: usb-storage: device scan complete
Jul 12 11:26:58 pc196344 scsi.agent[27309]: disk at
/devices/pci0000:00/0000:00:1d.2/usb4/4-2/4-2:1.0/host10/target10:0:0/10:0:0
:0

So, works very well.  Thanks very much for your help in solving this issue,
and hopefully we'll see this patch in 2.6.13 onwards.

James Roberts-Thomson
----------
Hardware:  The parts of a computer system that can be kicked.

Mailing list Readers:  Please ignore the following disclaimer - this email
is explicitly declared to be non confidential and does not contain
privileged information.

This communication is confidential and may contain privileged material.
If you are not the intended recipient you must not use, disclose, copy or retain it.
If you have received it in error please immediately notify me by return email
and delete the emails.
Thank you.

RE: [linux-usb-devel] Kernel unable to read partition table on US B Memory Key

[Alan Stern]

On Mon, 11 Jul 2005, Roberts-Thomson, James wrote:

> OK, it turns out that for this particular key, a two second pause after
> "sd_spinup_disk" is called and before "sd_read_capacity" will make it work.
> The 'dmesg' (or syslog) output is still ugly, however; but once I realised
> that it was "sd_spinup_disk" that:
> 
> A) needed the delay, and 
> B) causes the first ugly message to be printed in the first place, then a
> better patch came to mind.
> 
> So, after combining Alan's suggestion to use "msleep" rather than my
> previous convoluted method, and moving the location of the pause to inside
> sd_spinup_disk (and targeting it to remove the first "ugly"), I came up with
> a better patch, which is attached.
> 
> This patch adds the module parameter 'firmware_delay', and will cause a
> pause for "firmware_delay" seconds inside sd_spinup_disk when the first SCSI
> command returns UNIT_ATTENTION as the sense key.
> 
> Again, I have deliberately made the default value for this parameter 0,
> which means that the end-user will need to ensure insmod or modprobe
> supplies a >0 value to firmware_delay before the patch takes effect.
> 
> I'm not sure what the procedure is for getting this patch officially
> recognised for inclusion into the kernel - Alan, are you able to "sponsor"
> this patch for inclusion?

How about the patch below instead?  It's a bit easier to use, in that it 
doesn't require users to know about a new parameter.  Also it retries at 
1-second intervals for up to 5 seconds, which makes it a little more 
flexible.  If this works for you, I'll submit it for inclusion in the 
official kernel.

Alan Stern


Index: usb-2.6/drivers/scsi/sd.c
===================================================================
--- usb-2.6.orig/drivers/scsi/sd.c
+++ usb-2.6/drivers/scsi/sd.c
@@ -987,7 +987,7 @@ static void
 sd_spinup_disk(struct scsi_disk *sdkp, char *diskname,
 	       struct scsi_request *SRpnt, unsigned char *buffer) {
 	unsigned char cmd[10];
-	unsigned long spintime_value = 0;
+	unsigned long spintime_expire = 0;
 	int retries, spintime;
 	unsigned int the_result;
 	struct scsi_sense_hdr sshdr;
@@ -1074,12 +1074,27 @@ sd_spinup_disk(struct scsi_disk *sdkp, c
 				scsi_wait_req(SRpnt, (void *)cmd, 
 					      (void *) buffer, 0/*512*/, 
 					      SD_TIMEOUT, SD_MAX_RETRIES);
-				spintime_value = jiffies;
+				spintime_expire = jiffies + 100 * HZ;
+				spintime = 1;
 			}
-			spintime = 1;
 			/* Wait 1 second for next try */
 			msleep(1000);
 			printk(".");
+
+		/*
+		 * Wait for USB flash devices with slow firmware.
+		 * Yes, this sense key/ASC combination shouldn't
+		 * occur here.  It's typical of these devices.
+		 */
+		} else if (sense_valid &&
+				sshdr.sense_key == UNIT_ATTENTION &&
+				sshdr.asc == 0x28) {
+			if (!spintime) {
+				spintime_expire = jiffies + 5 * HZ;
+				spintime = 1;
+			}
+			/* Wait 1 second for next try */
+			msleep(1000);
 		} else {
 			/* we don't understand the sense code, so it's
 			 * probably pointless to loop */
@@ -1091,8 +1106,7 @@ sd_spinup_disk(struct scsi_disk *sdkp, c
 			break;
 		}
 				
-	} while (spintime &&
-		 time_after(spintime_value + 100 * HZ, jiffies));
+	} while (spintime && time_before_eq(jiffies, spintime_expire));
 
 	if (spintime) {
 		if (scsi_status_is_good(the_result))

RE: [linux-usb-devel] Kernel unable to read partition table on US B Memory Key

[Roberts-Thomson, James]

[-- Attachment #1: Type: text/plain, Size: 2010 bytes --]

All,

> > 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?
> 
> Yes, will do this and post results.

OK, it turns out that for this particular key, a two second pause after
"sd_spinup_disk" is called and before "sd_read_capacity" will make it work.
The 'dmesg' (or syslog) output is still ugly, however; but once I realised
that it was "sd_spinup_disk" that:

A) needed the delay, and 
B) causes the first ugly message to be printed in the first place, then a
better patch came to mind.

So, after combining Alan's suggestion to use "msleep" rather than my
previous convoluted method, and moving the location of the pause to inside
sd_spinup_disk (and targeting it to remove the first "ugly"), I came up with
a better patch, which is attached.

This patch adds the module parameter 'firmware_delay', and will cause a
pause for "firmware_delay" seconds inside sd_spinup_disk when the first SCSI
command returns UNIT_ATTENTION as the sense key.

Again, I have deliberately made the default value for this parameter 0,
which means that the end-user will need to ensure insmod or modprobe
supplies a >0 value to firmware_delay before the patch takes effect.

I'm not sure what the procedure is for getting this patch officially
recognised for inclusion into the kernel - Alan, are you able to "sponsor"
this patch for inclusion?

Thanks,

James Roberts-Thomson
----------
Hardware:  The parts of a computer system that can be kicked.

Mailing list Readers:  Please ignore the following disclaimer - this email
is explicitly declared to be non confidential and does not contain
privileged information.


This communication is confidential and may contain privileged material.
If you are not the intended recipient you must not use, disclose, copy or retain it.
If you have received it in error please immediately notify me by return email
and delete the emails.
Thank you.

[-- Attachment #2: oti-usb-key-v2.patch --]
[-- Type: application/octet-stream, Size: 1119 bytes --]

--- /home/n202042/src/kernel2612/linux-2.6.12/drivers/scsi/sd.c	2005-06-18 07:48:29.000000000 +1200
+++ /usr/src/linux/drivers/scsi/sd.c	2005-07-11 15:40:45.000000000 +1200
@@ -89,6 +89,10 @@
 #define SD_MAX_RETRIES		5
 #define SD_PASSTHROUGH_RETRIES	1
 
+static unsigned int firmware_delay = 0;
+module_param(firmware_delay, uint, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(firmware_delay, "Optional number of seconds delay for dodgy USB keys to settle");
+
 static void scsi_disk_release(struct kref *kref);
 
 struct scsi_disk {
@@ -1080,6 +1084,12 @@ sd_spinup_disk(struct scsi_disk *sdkp, c
 			/* Wait 1 second for next try */
 			msleep(1000);
 			printk(".");
+		} else if (sense_valid && sshdr.sense_key == UNIT_ATTENTION && firmware_delay > 0 ) {
+				/* Some USB flash drives need a small delay (perhaps to allow internal firmware
+				 * time to initialise
+				 */
+				printk(KERN_NOTICE "%s: Allowing time for firmware initialisation\n", diskname);
+				msleep(firmware_delay * HZ);
 		} else {
 			/* we don't understand the sense code, so it's
 			 * probably pointless to loop */

RE: [linux-usb-devel] Kernel unable to read partition table on US B Memory Key

[Roberts-Thomson, James]

Back again!  (had a 2 day course last week).

> > 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).

Don't know; just call them as I see them.

> >  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?

I did, I just can't type.  Sorry.

> 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?

Yes, will do this and post results.

> > 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?

(Smacks head)  Why didn't I think of that?

http://users.actrix.co.nz/rtfamily/USBLog1.usblog.bz2 for the Snoopy tool
output and
http://users.actrix.co.nz/rtfamily/USBDebugMsgs.bz2 for the other output I
emailed to this list last week.

Thanks,

James Roberts-Thomson
----------
Hardware:  The parts of a computer system that can be kicked.

Mailing list Readers:  Please ignore the following disclaimer - this email
is explicitly declared to be non confidential and does not contain
privileged information.

This communication is confidential and may contain privileged material.
If you are not the intended recipient you must not use, disclose, copy or retain it.
If you have received it in error please immediately notify me by return email
and delete the emails.
Thank you.

RE: [linux-usb-devel] Kernel unable to read partition table on US B Memory Key

[Alan Stern]

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

RE: [linux-usb-devel] Kernel unable to read partition table on US B Memory Key

[Roberts-Thomson, James]

[-- Attachment #1: Type: text/plain, Size: 4616 bytes --]

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:

Jul  6 14:44:50 pc196344 kernel: usb 1-6: new high speed USB device using
ehci_hcd and address 6
Jul  6 14:44:50 pc196344 kernel: Initializing USB Mass Storage driver...
Jul  6 14:44:50 pc196344 kernel: scsi5 : SCSI emulation for USB Mass Storage
devices
Jul  6 14:44:50 pc196344 kernel: usbcore: registered new driver usb-storage
Jul  6 14:44:50 pc196344 kernel: USB Mass Storage support registered.
Jul  6 14:44:50 pc196344 kernel: usb-storage: device found at 6
Jul  6 14:44:50 pc196344 kernel: usb-storage: waiting for device to settle
before scanning
Jul  6 14:44:52 pc196344 kernel:   Vendor: OTi       Model: Flash Disk
Rev: 2.00
Jul  6 14:44:52 pc196344 kernel:   Type:   Direct-Access
ANSI SCSI revision: 02
Jul  6 14:44:52 pc196344 kernel: Attached scsi generic sg1 at scsi5, channel
0, id 0, lun 0,  type 0
Jul  6 14:44:52 pc196344 kernel: usb-storage: device scan complete
Jul  6 14:44:52 pc196344 scsi.agent[27245]: disk at
/devices/pci0000:00/0000:00:1d.7/usb1/1-6/1-6:1.0/host5/target5:0:0/5:0:0:0
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, and increasing the
delay to 3 seconds didn't help, as I got three one-second delays.  

However, if someone with the appropriate knowledge could transform my kludge
into a proper fix, then I would be very happy.

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".

James Roberts-Thomson
----------
Hardware:  The parts of a computer system that can be kicked.

Mailing list Readers:  Please ignore the following disclaimer - this email
is explicitly declared to be non confidential and does not contain
privileged information.


This communication is confidential and may contain privileged material.
If you are not the intended recipient you must not use, disclose, copy or retain it.
If you have received it in error please immediately notify me by return email
and delete the emails.
Thank you.

[-- Attachment #2: oti-usb-key.patch --]
[-- Type: application/octet-stream, Size: 947 bytes --]

--- linux-2.6.12/drivers/scsi/sd.c	2005-06-18 07:48:29.000000000 +1200
+++ linux-2.6.12-jrt1/drivers/scsi/sd.c	2005-07-06 14:33:27.000000000 +1200
@@ -89,6 +89,10 @@
 #define SD_MAX_RETRIES		5
 #define SD_PASSTHROUGH_RETRIES	1
 
+static unsigned int delay_use = 0;
+module_param(delay_use, uint, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(delay_use, "Optional number of seconds delay for dodgy USB keys to settle");
+
 static void scsi_disk_release(struct kref *kref);
 
 struct scsi_disk {
@@ -1483,6 +1487,14 @@ static int sd_revalidate_disk(struct gen
 	sdkp->WCE = 0;
 	sdkp->RCD = 0;
 
+	/* Wait for the timeout to expire */
+	if (delay_use > 0) {
+		printk(KERN_DEBUG "sd: waiting for device to get ready.\n");
+		wait_queue_head_t delay_wait;
+		init_waitqueue_head(&delay_wait);
+		wait_event_interruptible_timeout(delay_wait, 0, delay_use * HZ);
+	}
+	
 	sd_spinup_disk(sdkp, disk->disk_name, sreq, buffer);
 
 	/*

RE: [linux-usb-devel] Kernel unable to read partition table on US B Memory Key

[Alan Stern]

On Wed, 6 Jul 2005, Roberts-Thomson, James wrote:

> One more additional note is that the key came with some s/w that allows you
> to partition the key into "private" and "public" areas, where the private
> area is accessed by a password.  Naturally, this s/w (Ustorage) is Windows
> only; but looking at how it works under Windows it would appear that the key
> has some firmware inside that is controlling access etc - could it be that
> this firmware hasn't finished initialising by the time Linux tries to read
> block 0, which is why the messages occur?

That's certainly possible.  The question is, at what time does that 
firmware start initializing and how long does it take?  You mentioned 
before that setting "delay_use" to 30 seconds didn't make any difference.

> If this is the case, then a subtle delay somewhere in the initialisation
> chain may help.  I'm not a Kernel Guru by any stretch, but I imagine the
> sequence is something like this:
> 
> <key insert>
> <usb subsystem identifies device>
> <usb-storage driver takes device control> (existing specifiable delay in
> here, via "delay_use")
> <usb-storage drivers creates /dev/sdX> (via some form of udev interaction, I
> guess...)
> <sd_mod informed that new SCSI disk exists>
> *
> <sd_mod tries to read partition table etc>
> <sd_mod creates /dev/sdXn entries> (also via udev)
> ...etc....

That's not quite right.  It really goes like this:

<key insert>
<usb subsystem identifies device>
<usb-storage driver takes device control> (existing specifiable delay in
	here, via "delay_use")
<sd_mod informed that new SCSI disk exists>
<sd_mod gets total disk capacity, write-protection setting, and other
	stuff>
<sd_mod registers /dev/sdX as a disk and udev learns about it>
<the general disk driver tries to read partition table etc>
<gendisk creates /dev/sdXn entries> (also via udev)
...etc....

It's not clear how any of this affects the device's internal state.

> Perhaps the ability to create an additional "settle" delay at the "*" above
> may help - presumably, I'd need to hack the sd_mod driver, so I'll have a
> look there, too.

Try putting delays at various spots in sd_revalidate_disk: the beginning,
the middle, and the end.

Alan Stern

RE: [linux-usb-devel] Kernel unable to read partition table on US B Memory Key

[Roberts-Thomson, James]

Alan,

Thanks very much for the input.

> > I'm trying to diagnose an issue with a USB "Memory Key" 
> (128Mb Flash 
> > drive) on my workstation (i386 Linux 2.6.12 kernel, using udev 058).
> > 
> > When connecting the key, the kernel fails to read the 
> partition table, 
> > and therefore the block device /dev/sda1 isn't created, so I can't 
> > mount the volume.  Calling "fdisk" manually, however, makes 
> it all work.
> 
> You don't even have to call fdisk.  Probably "touch /dev/sda" 
> would be enough.

Yes, indeed that does make it work.

> The device is not supposed to send the "Unit Attention, Not 
> ready to ready change" message more than once.  It's 
> violating the SCSI protocol by doing so.  (In fact it's not 
> supposed to send that message at all; it's supposed to send 
> "Power on or reset".)

Oh well, so much for the "Linux Compatible" markings on the box... :-)

> Replacing 
> the device won't help, because the device is behaving as 
> designed and the design is broken.

Yes, I'd imagine so, but I just wanted to make sure that it wasn't a bad
chip etc - generally speaking QA isn't what it used to be for most products
on the market these days.....

> What might help would be a direct comparison of the commands 
> being sent by Linux and by Windows.  If you turn on USB Mass 
> Storage verbose debugging
> (CONFIG_USB_STORAGE_DEBUG) in the kernel configuration then 
> the system debugging log will contain the commands sent by 
> usb-storage.  You can use a USB sniffer program like USB 
> Snoop (available from Sourceforge) to record the commands 
> sent by Windows.  Perhaps looking over the two logs will 
> reveal what magic command the device is waiting for.

OK, I'll try and do that today, and if I get anything meaningful, I'll send
it to the list(s).

One more additional note is that the key came with some s/w that allows you
to partition the key into "private" and "public" areas, where the private
area is accessed by a password.  Naturally, this s/w (Ustorage) is Windows
only; but looking at how it works under Windows it would appear that the key
has some firmware inside that is controlling access etc - could it be that
this firmware hasn't finished initialising by the time Linux tries to read
block 0, which is why the messages occur?

If this is the case, then a subtle delay somewhere in the initialisation
chain may help.  I'm not a Kernel Guru by any stretch, but I imagine the
sequence is something like this:

<key insert>
<usb subsystem identifies device>
<usb-storage driver takes device control> (existing specifiable delay in
here, via "delay_use")
<usb-storage drivers creates /dev/sdX> (via some form of udev interaction, I
guess...)
<sd_mod informed that new SCSI disk exists>
*
<sd_mod tries to read partition table etc>
<sd_mod creates /dev/sdXn entries> (also via udev)
...etc....

Perhaps the ability to create an additional "settle" delay at the "*" above
may help - presumably, I'd need to hack the sd_mod driver, so I'll have a
look there, too.

Thanks,

James Roberts-Thomson
----------
f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng.

Mailing list Readers:  Please ignore the following disclaimer - this email
is explicitly declared to be non confidential and does not contain
privileged information.

This communication is confidential and may contain privileged material.
If you are not the intended recipient you must not use, disclose, copy or retain it.
If you have received it in error please immediately notify me by return email
and delete the emails.
Thank you.