Trouble reading usb key partition table
 

Bit of an odd problem:
As a background, I have 2 machines, a desktop and a laptop both running LFS 6.0, configured pretty much the same way.
Desktop is running kernel 2.6.11.11 and laptop 2.6.8.1.

First up, I've been happily using a few different types of usb drives / mp3 players / digital cameras on both of them, but now I've gotten a new, higher capacity usb stick, whose behaviour is identical on both machines. Plugging it in results in the normal lines in dmesg about a new speed device, followed by a stack of error messages along the lines of
etc.

and at last:
As you'd expect, this means that /dev/sdb exists, but not any partitions, ie /dev/sdb1, which makes mounting rather difficult.

The interesting thing, though, is that if i use any command that touches the device, like fdisk, cfdisk, mkfs.*, it adds the following lines to dmesg,
successfully reads the partition table, and hey presto, /dev/sdb1 is created and I can mount the filesystem.
Also, I can get the same effect by manually creating the block device with mknod.

So clearly the machine can read the partition table and data, but for some reason not on the first run through. It's a pain having to su to root and fdisk -l /dev/sdb every time i want to use this drive, so any suggestions?

This is an educated guess, but...

I don't think there's anything you can do directly. The reasoning comes from my experience with SCSI (that has similar messages), so it may not directly apply.

As you can probably guess (if you don't already know), a sense key is a hardware-based error message. The key is supposed to tell what specific error the hardware encountered. I would assume the ASC and ASCQ fields provide further detailed information, but the "Unit Not Ready" is usually good enough. That usually means the device is running through some sort of initialization. Once the device receives power, it may take some time to "boot up" to a point where the device can satisfy requests. Unit/Device "not ready" messages are often sent during that time, or when the device is occupied performing some other request.

This would be the command sent to the device that received the error. The system was asking what size the device was (among other things probably). Of course, the system needs to know that information and can't take appropriate steps until it is known.

My assumption of what's happening is, the device is going through some sort of power-up (which is odd for a USB mass storage device), the device stays in this power-up state long enough to refuse the initial requests made by the kernel, the kernel gives up trying, X amount of time elapses, the device leaves power-up, and the fdisk -l command issued forces the kernel to try again. Since the device isn't in power-up, the READ_CAPACITY requests succeed, and the kernel can continue on.

So, I would have to say the only way you could fix this is to read on what options the kernel supports for initial USB device requests. See if there's something to tell the kernel to try a couple more times initially; the kernel may quit making requests just before the device leaves power-up. Or another possibility would be to find out if there's an option to control how much time the kernel should wait between requests. I've never touched kernel parameters much, and can't help much with them...

Or you could always crack open the kernel source and add it :)