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 188.8.131.52 and laptop 184.108.40.206.
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
and at last:
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,
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.
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 :)
|All times are GMT -5. The time now is 10:17 PM.|