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

From: Roberts-Thomson, James (James.Roberts-Thomson_at_NBNZ.CO.NZ)
Date: 07/05/05

  • Next message: randy_dunlap: "Re: page allocation/attributes question (i386/x86_64 specific)" 
    To: 'Alan Stern' <stern@rowland.harvard.edu>
Date:	Wed, 6 Jul 2005 09:19:30 +1200

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

  • Next message: randy_dunlap: "Re: page allocation/attributes question (i386/x86_64 specific)"

    Relevant Pages

    • Re: Probleme mit USB 2.0 Controller
      ... Ein Treiber damit Windows Files im ext2 Dateisystem lesen ... Partition 2 soll FAT32 beherbergen damit ich auch Daten mit Windows ... jetzt ist das Problem das die Geschwindigkeit beim ... nix mit USB 2.0 zu tun. ...
      (de.comp.os.unix.linux.hardware)
    • Re: Non-destructive fdisk working with USB sticks?
      ... Windows tool - or a Linux-based tool with a GUI. ... DFSee could do that ... The DOS most likely will access the USB stick when using ... of partition tables, bootsectors and such ... ...
      (comp.sys.ibm.pc.hardware.storage)
    • Re: Delayed Write Failed on external USB drive
      ... HP Compaq Presario SR1750NX, 1 Gb RAM, Windows XP SP2 ... SimpleTech 250 Gb external USB disk, ... and a single primary partition, which I bought for cheap backup. ...
      (microsoft.public.windowsxp.help_and_support)
    • Re: Parallels or Boot Camp
      ... What about USB flash drives? ... is to just use the USB device on the OS X side. ... and Windows are running at the same time, so this is simple to do. ... the Windows partition, ...
      (comp.sys.mac.apps)
    • Re: Can someone else help? Was changing partition size.
      ... with one hard drive, that Windows 98 does not list. ... My Computer still does not list the partition that has ... two hard drives. ... This should fix the boot sector on the C: drive and allow you to boot ...
      (microsoft.public.windowsxp.general)