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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |