lkml.org 
[lkml]   [2005]   [Jul]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRE: [linux-usb-devel] Kernel unable to read partition table on US B Memory Key
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/

\
 
 \ /
  Last update: 2005-07-06 00:25    [W:0.029 / U:0.976 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site