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

[Alan Stern <stern@rowland.harvard.edu>]

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

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