Different USB device 'Voyager Mini' is connected correct

[root@homedesk ~]# dmesg
usb 1-1: new high speed USB device using ehci_hcd and address 6
usb 1-1: New USB device found, idVendor=1b1c, idProduct=0b29
usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1: Product: Voyager Mini
usb 1-1: Manufacturer: Corsair
usb 1-1: SerialNumber: 899801162008011514250E56
usb 1-1: configuration #1 chosen from 1 choice
scsi10 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 6
usb-storage: waiting for device to settle before scanning
usb-storage: device scan complete
scsi 10:0:0:0: Direct-Access     Corsair  Voyager Mini     1.00 PQ: 0 ANSI: 2
sd 10:0:0:0: [sdd] 8097792 512-byte hardware sectors: (4.14 GB/3.86 GiB)
sd 10:0:0:0: [sdd] Write Protect is off
sd 10:0:0:0: [sdd] Mode Sense: 23 00 00 00
sd 10:0:0:0: [sdd] Assuming drive cache: write through
sd 10:0:0:0: [sdd] 8097792 512-byte hardware sectors: (4.14 GB/3.86 GiB)
sd 10:0:0:0: [sdd] Write Protect is off
sd 10:0:0:0: [sdd] Mode Sense: 23 00 00 00
sd 10:0:0:0: [sdd] Assuming drive cache: write through
 sdd: sdd1
sd 10:0:0:0: [sdd] Attached SCSI removable disk
sd 10:0:0:0: Attached scsi generic sg5 type 0

what happens when you run fdisk on that device? can it parse the partition table?

is this the state it came in when you bought it new? or could something have corrupted it?

[root@homedesk ~]# export LC_AL=C ; export LANG=C
[root@homedesk ~]# fdisk /dev/sdd

Command (m for help): p

Disk /dev/sdd: 4194 MB, 4194303488 bytes
255 heads, 63 sectors/track, 509 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x91f72d24

   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1               1         509     4088511    b  W95 FAT32

Command (m for help): d
Selected partition 1

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table.
The new table will be used at the next reboot.

Error closing file

--------

[root@homedesk ~]# fdisk /dev/sdd

Command (m for help): p

Disk /dev/sdd: 4194 MB, 4194303488 bytes
255 heads, 63 sectors/track, 509 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x91f72d24

   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1               1         509     4088511    b  W95 FAT32

---

[root@homedesk ~]# fdisk /dev/sdd

Unable to read /dev/sdd
---

[root@homedesk ~]# fdisk /dev/sdd

Command (m for help): p

Disk /dev/sdd: 4194 MB, 4194303488 bytes
255 heads, 63 sectors/track, 509 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x91f72d24                     

   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1               1         509     4088511    b  W95 FAT32

Command (m for help): d
Selected partition 1   

Command (m for help): p

Disk /dev/sdd: 4194 MB, 4194303488 bytes
255 heads, 63 sectors/track, 509 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x91f72d24

   Device Boot      Start         End      Blocks   Id  System

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

---

[root@homedesk ~]# fdisk /dev/sdd

Command (m for help): p

Disk /dev/sdd: 4194 MB, 4194303488 bytes
130 heads, 62 sectors/track, 1016 cylinders
Units = cylinders of 8060 * 512 = 4126720 bytes
Disk identifier: 0x91f72d24

   Device Boot      Start         End      Blocks   Id  System

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-1016, default 1):
Using default value 1
Last cylinder, +cylinders or +size{K,M,G} (1-1016, default 1016):
Using default value 1016

Command (m for help): p

Disk /dev/sdd: 4194 MB, 4194303488 bytes
130 heads, 62 sectors/track, 1016 cylinders
Units = cylinders of 8060 * 512 = 4126720 bytes
Disk identifier: 0x91f72d24

   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1               1        1016     4094449   83  Linux

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

-------

I can access to device, but from time to time...

On eee901 (Fedora-11 betta) with the same kernel the result is the same too.
:)

PS: On Fedora-8 (last kernel) and Fedora-10 (current kernel) result is good.

I found yet another USB storage device with the same problem.

It is Transcend JetFlash JF168 (1GB). 

If I understand good, all Transcend JF168 (hi-speed serie)  will not work with Fedora-11 correct.

Same problem with Adata myflash 2Gb. Absolutely same behavior and logs. This flash works on windows.
Also i have another flash - corsair, and it works well.

Another problem flash: pqi Traveling Disk U230.

And another one which is working fine in F9/F10: 
ID 1307:0163 Transcend Information, Inc. 512MB/1GB Flash Drive

I'm seeing this too, and I've done some debugging, this is not a kernel issue,
or atleast not 100%.

Atleast in my case the kernel detects the partition table 100% ok the first time,
and then for some reason starts rescanning it, sometimes succeeding and
sometimes giving the "unable to read RDB block 0" error.

This rescanning behaviour, which makes things break is caused by
DeviceKit-disks, downgrading DeviceKit-disks to 003-9, available here:
http://koji.fedoraproject.org/koji/buildinfo?buildID=95674

Fixes things. Changing the component to DeviceKit-disks.

Not at all sure this is a DeviceKit-disks issue; looks more like a driver bug to me. Anyway, it would be helpful to try the latest DeviceKit-disks release (which causes this bug) and experiment with moving one of these out of the way

 /lib/udev/devkit-disks-probe-ata-smart
 /lib/udev/devkit-disks-part-id
 /lib/udev/devkit-disks-dm-export

in order to find out which helper is causing this. Thanks.

(In reply to comment #9)
> Not at all sure this is a DeviceKit-disks issue; looks more like a driver bug
> to me. Anyway, it would be helpful to try the latest DeviceKit-disks release
> (which causes this bug) and experiment with moving one of these out of the way
> 
>  /lib/udev/devkit-disks-probe-ata-smart
>  /lib/udev/devkit-disks-part-id
>  /lib/udev/devkit-disks-dm-export
> 
> in order to find out which helper is causing this. Thanks.  

Ok, moving /lib/udev/devkit-disks-probe-ata-smart to my home dir, makes things
work again with devkit-disks 004.

Created attachment 342664 [details]
lsusb -vvv output as requested on irc

Ok, interesting, if I mv the devkit-disks-probe-ata-smart helper to my homedir, the problem goes away, if I then run it once from my homedir manually I get the following in dmesg:
sd 17:0:0:0: [sdg] 2015231 512-byte hardware sectors: (1.03 GB/983 MiB)
sd 17:0:0:0: [sdg] Write Protect is off
sd 17:0:0:0: [sdg] Mode Sense: 00 00 00 00
sd 17:0:0:0: [sdg] Assuming drive cache: write through
sd 17:0:0:0: [sdg] 2015231 512-byte hardware sectors: (1.03 GB/983 MiB)
sd 17:0:0:0: [sdg] Write Protect is off
sd 17:0:0:0: [sdg] Mode Sense: 00 00 00 00
sd 17:0:0:0: [sdg] Assuming drive cache: write through
 sdg:Dev sdg: unable to read RDB block 0
 unable to read partition table
sd 17:0:0:0: [sdg] 2015231 512-byte hardware sectors: (1.03 GB/983 MiB)
sd 17:0:0:0: [sdg] Write Protect is off
sd 17:0:0:0: [sdg] Mode Sense: 00 00 00 00
sd 17:0:0:0: [sdg] Assuming drive cache: write through
sd 17:0:0:0: [sdg] 2015231 512-byte hardware sectors: (1.03 GB/983 MiB)
sd 17:0:0:0: [sdg] Write Protect is off
sd 17:0:0:0: [sdg] Mode Sense: 00 00 00 00
sd 17:0:0:0: [sdg] Assuming drive cache: write through
 sdg: sdg1
SELinux: initialized (dev sdg1, type vfat), uses genfs_contexts

And because of the second successfull rescan of the part table, I get the stick automounted again.

Now what happens when the helper is in /lib/udev, is that it gets called again due to the rescan, then causes another rescan, etc.

Created attachment 342667 [details]
strace output of single run of devkit-disks-probe-ata-smart on problem usbstick

See [1] - this is probably what is calling the device to fail. Lennart, any chance we can avoid poking the device if the usb vid/pid does not match?

ioctl(3, SG_IO, {'S', SG_DXFER_FROM_DEV, cmd[12]=[a1, 08, 2e, 00, 01, 00, 00, 00, 00, ec, 00, 00], mx_sb_len=32, iovec_count=0, dxfer_len=512, timeout=2000, flags=0, data[512]=["\0\0\0\0\0\0\0\0\0\0\0\0\0\0\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...], status=02, masked_status=01, sb[18]=[70, 00, 05, 00, 00, 00, 00, 0a, 00, 00, 00, 00, 20, 00, 00, 00, 00, 00], host_status=0, driver_status=0x8, resid=512, duration=2, info=0x1}) = 0

Hmm, thing is that devices don't announce if they can do SAT or not. Hence if the device is USB we try SAT. That's as good as we can do it.

Hmm, so the only command issued here by libatasmart according to the strace seems to be IDENTIFY which then seems to confuse the partition table reading code.

Dave, why could issuing IDENTIFY confuse the partition table code like that?

David, any chance we cann delay execution of the smart reading code after the partition table was fully read?

Oh, reassigning to kernel because it's not libatasmart that is as easily confused, but the kernel...

(In reply to comment #15)
> Hmm, thing is that devices don't announce if they can do SAT or not. Hence if
> the device is USB we try SAT. That's as good as we can do it.

Ah, right, crap. We do want to try to poke the disk even if it's not in the libatasmart whitelist. E.g. I have several disks in USB enclosures myself that does SMART just fine without being in the libatasmart whitelist.

> Hmm, so the only command issued here by libatasmart according to the strace
> seems to be IDENTIFY which then seems to confuse the partition table reading
> code.
> 
> Dave, why could issuing IDENTIFY confuse the partition table code like that?
> 
> David, any chance we cann delay execution of the smart reading code after the
> partition table was fully read?  

The kernel would have to delay the event for the device until the partition table has been read (If I understand correctly). I'm adding Kay to the Cc as he's a lot more familiar with this code than I am (e.g. when events are fired).

(We could also just sleep(1) but that's not really a solution.)

(In reply to comment #17)
> The kernel would have to delay the event for the device until the partition
> table has been read (If I understand correctly). I'm adding Kay to the Cc as
> he's a lot more familiar with this code than I am (e.g. when events are fired).
> 

Delaying is not going to help, somehow devkit-disks-probe-ata-smart
issuing that ioctl, causes the kernel to rescan the partition table.

I've moved devkit-disks-probe-ata-smart from /lib/udev to my homedir,
and if I now wait 5 minutes and then start it from my homedir (as root
with the usb stick whole disk device node as arg) I still get the following in dmesg:
 sdg:Dev sdg: unable to read RDB block 0
 unable to read partition table
sd 17:0:0:0: [sdg] 2015231 512-byte hardware sectors: (1.03 GB/983 MiB)
sd 17:0:0:0: [sdg] Write Protect is off
sd 17:0:0:0: [sdg] Mode Sense: 00 00 00 00
sd 17:0:0:0: [sdg] Assuming drive cache: write through
sd 17:0:0:0: [sdg] 2015231 512-byte hardware sectors: (1.03 GB/983 MiB)
sd 17:0:0:0: [sdg] Write Protect is off
sd 17:0:0:0: [sdg] Mode Sense: 00 00 00 00
sd 17:0:0:0: [sdg] Assuming drive cache: write through
 sdg: sdg1
SELinux: initialized (dev sdg1, type vfat), uses genfs_contexts
gvfs-gdu-volume[10491]: segfault at 18 ip 00007fad1c60e3d1 sp 00007fff24a42ed0 error 4 in libgdu.so.0.0.0[7fad1c603000+22000]
sd 17:0:0:0: [sdg] 2015231 512-byte hardware sectors: (1.03 GB/983 MiB)
sd 17:0:0:0: [sdg] Write Protect is off
sd 17:0:0:0: [sdg] Mode Sense: 00 00 00 00
sd 17:0:0:0: [sdg] Assuming drive cache: write through
sd 17:0:0:0: [sdg] 2015231 512-byte hardware sectors: (1.03 GB/983 MiB)
sd 17:0:0:0: [sdg] Write Protect is off
sd 17:0:0:0: [sdg] Mode Sense: 00 00 00 00
sd 17:0:0:0: [sdg] Assuming drive cache: write through
sd 17:0:0:0: [sdg] 2015231 512-byte hardware sectors: (1.03 GB/983 MiB)
sd 17:0:0:0: [sdg] Write Protect is off
sd 17:0:0:0: [sdg] Mode Sense: 00 00 00 00
sd 17:0:0:0: [sdg] Assuming drive cache: write through

(In reply to comment #17)
> The kernel would have to delay the event for the device until the partition
> table has been read (If I understand correctly).

Hmm, I added that, I think, more than a year ago. There is no event before the partitions have been fully created, all events are delayed in the kernel, until all is alive.

As an temporary workaround, we could 

  o change devkit-disks-probe-ata-smart to not run if
    DKD_ATA_SMART_IS_AVAILABLE=0 is set

  o have udev rules that run before 95-devkit-disks.rules to set
    DKD_ATA_SMART_IS_AVAILABLE=0
    (these would live in udev-extras probably)

but blacklists really suck. Ideally we'd find another way to determine if the device is ATA SMART capable... Lennart?

Since adding delays is not going to help, reassigning back to libatasmart. Not sure how we can fix this...

Humpf. I still think this is either a kernel or an hw bug. All libatasmart does is issue IDENTIFY. And the kernel due to that thinks it needs to reread the pt table and fails while doing that. Not sure why that happens. Is it possible that the hw resets itself after IDENTIFY? That would be weird, wouldn't it? Dave, any idea?

The kernel caches IDENTIFY anyway, doesn't it? Is there a way we can access that from userspace?

Hans, when you run skdump like this, does skdump fail itself too or does it suceed in reading IDENTIFY?

Hmm, ok. I think I understand what is ging on here. Hans, your device probably simply resets when we try to issue IDENTIFY via a SAT request (which it cannot handle). Shitty device.

Grr, question is of course how to fix this. Whitelisting SAT-capable devices? Blacklisting SAT-incapable devices which reset themselves when they receive SAT requests?

The latter is probably the better choice, but sucks, too.

I think this blacklist should be maintained as part of dk-disks. Reassigning.

(In reply to comment #18)
> I've moved devkit-disks-probe-ata-smart from /lib/udev to my homedir,
> and if I now wait 5 minutes and then start it from my homedir (as root
> with the usb stick whole disk device node as arg) I still get the following in

>  sdg:Dev sdg: unable to read RDB block 0

fs/partitions/amiga.c: printk("Dev %s: unable to read RDB block %d\n",

Maybe there is weird data on it? Can you possibly erase the volume and retry?

Also, Hans, please try with a kernel where the Amiga partition table prober is disabled. Thanks.

(In reply to comment #23)
> Hans, when you run skdump like this, does skdump fail itself too or does it
> suceed in reading IDENTIFY?  

If I run "sudo skdump /dev/whole-disk-node-for-usbstick" I get:

[hans@localhost ~]$ sudo skdump /dev/sdb
Device: /dev/sdb
Type: 12 Byte SCSI ATA SAT Passthru
Size: 983 MiB
Awake: Operation not supported
ATA SMART not supported.

And in dmesg I then get the following *new* lines:
sd 10:0:0:0: [sdb] 2015231 512-byte hardware sectors: (1.03 GB/983 MiB)
sd 10:0:0:0: [sdb] Write Protect is off
sd 10:0:0:0: [sdb] Mode Sense: 00 00 00 00
sd 10:0:0:0: [sdb] Assuming drive cache: write through
sd 10:0:0:0: [sdb] 2015231 512-byte hardware sectors: (1.03 GB/983 MiB)
sd 10:0:0:0: [sdb] Write Protect is off
sd 10:0:0:0: [sdb] Mode Sense: 00 00 00 00
sd 10:0:0:0: [sdb] Assuming drive cache: write through

Note, no partitiontable rescanning, and in general no problem.

Hmm, interesting, so I also tried doing the standalone run of
devkit-disks-probe-ata-smart, and that did not cause the problem now
either. So I've dug a little deeper. It turns out that if the device
is mounted, the kernel delays the rescanning of the partition table.

So if one does:
1 insert stick
2 wait for automount
3 run skdump (or devkit-disks-probe-ata-smart)
4 umount

Then after the umount the kernel rescans the partition table, and the device
immediately gets automounted again.

Whats interesting here, is that when this happens, the:
"unable to read RDB block 0" message goes away, iow the
"unable to read RDB block 0" only happens when the partitiontable
rescan does not get delayed. Also note btw, that in the end
the partition table scan always succeeds, after the
"unable to read RDB block 0", there always is another successfull
scan.

The *biggest* problem with devkit-disks-probe-ata-smart present in /lib/udev is that the part-table rescan triggers another devkit-disks-probe-ata-smart run,
resulting in an endless loop (and many many cannot mount /dev/sdX1 dialogs popping up)

Ok,

I've done some more experimenting using sg3_utils, and I think I've found a way around employing a blacklist.

First of all trying an identify command from sg3_utils yields in:

[hans@localhost ~]$ sudo sg_sat_identify /dev/sdb
ATA PASS-THROUGH (16) not supported

Which results in the folowwing 2 familiar error recovery messages in dmesg:
sd 11:0:0:0: [sdb] 2015231 512-byte hardware sectors: (1.03 GB/983 MiB)
sd 11:0:0:0: [sdb] Write Protect is off
sd 11:0:0:0: [sdb] Mode Sense: 00 00 00 00
sd 11:0:0:0: [sdb] Assuming drive cache: write through
sd 11:0:0:0: [sdb] 2015231 512-byte hardware sectors: (1.03 GB/983 MiB)
sd 11:0:0:0: [sdb] Write Protect is off
sd 11:0:0:0: [sdb] Mode Sense: 00 00 00 00
sd 11:0:0:0: [sdb] Assuming drive cache: write through

Which makes me wonder, has the kernel always done partition table rescanning
after errors like these, or is that new behaviour?

Anyways while reading sg_sat_identify manpage it mentioned that a SAT capable
scsi device also has a special vpd table entry with ata information, so I tried doing sg_vpd on /dev/sdb:

[hans@localhost ~]$ sudo sg_vpd --page=0x89 /dev/sdb
ATA information VPD page:
invalid VPD response; probably a STANDARD INQUIRY response
fetching VPD page failed

Where as doing this on my harddisk results in:
[hans@localhost ~]$ sudo sg_vpd --page=0x89 /dev/sda
ATA information VPD page:
  SAT Vendor identification: linux   
  SAT Product identification: libata          
  SAT Product revision level: 1AA0
  ATA command IDENTIFY DEVICE response summary:
    model: SAMSUNG HD502IJ                         
    serial number: S13TJ9BQ804662      
    firmware revision: 1AA01113

The interesting thing here is, that my usb stick did not go crazy over the
sg_vpd --page=0x89, so I think we can use that to detect SAT support, as the
issue seems to be trying any SAT command at all.

---

Question to the original and other reporters, can you please do:
yum install sg3_utils
tail -f /var/log/messages

And then in another terminal:
sg_vpd --page=0x89 /dev/sd#

Where # is the letter assigned to your usbstick ? And then let us know if any
new messages show up while running the sg_vpd command.

On my SAT capable device here page 0x89 does not exist:

664 [lennart@omega] ~$ sudo sg_vpd --page=0x89 /dev/sdf
ATA information VPD page:
fetching VPD page failed

[root@homedesk ~]# sg_vpd --page=0x89 /dev/sdf
ATA information VPD page:
invalid VPD response; probably a STANDARD INQUIRY response
fetching VPD page failed


[root@homedesk ~]# dmesg
---
...
sd 7:0:0:0: [sdf] 8191999 512-byte hardware sectors: (4.19 GB/3.90 GiB)
sd 7:0:0:0: [sdf] Write Protect is off
sd 7:0:0:0: [sdf] Mode Sense: 00 00 00 00
sd 7:0:0:0: [sdf] Assuming drive cache: write through
sd 7:0:0:0: [sdf] 8191999 512-byte hardware sectors: (4.19 GB/3.90 GiB)
sd 7:0:0:0: [sdf] Write Protect is off
sd 7:0:0:0: [sdf] Mode Sense: 00 00 00 00
sd 7:0:0:0: [sdf] Assuming drive cache: write through
 sdf:Dev sdf: unable to read RDB block 0
 unable to read partition table
sd 7:0:0:0: [sdf] 8191999 512-byte hardware sectors: (4.19 GB/3.90 GiB)
sd 7:0:0:0: [sdf] Write Protect is off
sd 7:0:0:0: [sdf] Mode Sense: 00 00 00 00
sd 7:0:0:0: [sdf] Assuming drive cache: write through
sd 7:0:0:0: [sdf] 8191999 512-byte hardware sectors: (4.19 GB/3.90 GiB)
sd 7:0:0:0: [sdf] Write Protect is off
sd 7:0:0:0: [sdf] Mode Sense: 00 00 00 00
sd 7:0:0:0: [sdf] Assuming drive cache: write through
 sdf: sdf1
sd 7:0:0:0: [sdf] 8191999 512-byte hardware sectors: (4.19 GB/3.90 GiB)
sd 7:0:0:0: [sdf] Write Protect is off
sd 7:0:0:0: [sdf] Mode Sense: 00 00 00 00
sd 7:0:0:0: [sdf] Assuming drive cache: write through
sd 7:0:0:0: [sdf] 8191999 512-byte hardware sectors: (4.19 GB/3.90 GiB)
sd 7:0:0:0: [sdf] Write Protect is off
sd 7:0:0:0: [sdf] Mode Sense: 00 00 00 00
sd 7:0:0:0: [sdf] Assuming drive cache: write through
 sdf:Dev sdf: unable to read RDB block 0
 unable to read partition table
...

thing is, checking page 0x89 doesn't really help if devices which can do SAT don't support it. It's not useful for detecting whether SAT is supported or not.

So far the only SAT capable bridge I found that supports 0x89 properly is Linux libata itself. Also, I wouldn't be surprised if equally many drives choke on reading page 0x89 as choke on SAT commands.

I think a blacklist is the way to go. As Kay suggested, that blacklist should probably live in dk-disks and include a blanket black list for all usb devices < 32gb. Such small (and hence old) drives usually cannot do SMART anyway and this also filers out all sd/mmc devices.

*** Bug 495334 has been marked as a duplicate of this bug. ***

I've experiencing this same problem:

From /var/log/messages, when I connect the device:

May 14 10:12:44 mcpierce-server kernel: sd 11:0:0:0: [sdb] 983808 512-byte hardware sectors: (503 MB/480 MiB)
May 14 10:12:44 mcpierce-server kernel: sd 11:0:0:0: [sdb] Write Protect is off
May 14 10:12:44 mcpierce-server kernel: sd 11:0:0:0: [sdb] Assuming drive cache: write through
May 14 10:12:44 mcpierce-server kernel: sd 11:0:0:0: [sdb] 983808 512-byte hardware sectors: (503 MB/480 MiB)
May 14 10:12:44 mcpierce-server kernel: sd 11:0:0:0: [sdb] Write Protect is off
May 14 10:12:44 mcpierce-server kernel: sd 11:0:0:0: [sdb] Assuming drive cache: write through
May 14 10:12:44 mcpierce-server kernel: sdb: sdb1

When I unplug it:

May 14 10:12:45 mcpierce-server usb_id[16223]: unable to access '/devices/pci0000:00/0000:00:1d.7/usb1/1-7/1-7:1.0/host11/target11:0:0/11:0:0:0/block/sdb'

(repeats endlessly)

Issuing the sg_vpd command:

[root@mcpierce-server ~]# sg_vpd --page=0x89 /dev/sdb
ATA information VPD page:
invalid VPD response; probably a STANDARD INQUIRY response
fetching VPD page failed

>>
>> downgrading DeviceKit-disks to 003-9
>>

Dowgrading has solved this problem but brought, at least, a lot of unsatisfied dependencies.

Hey, please try this build

 http://koji.fedoraproject.org/koji/taskinfo?taskID=1364728

which includes this patch

 http://cgit.freedesktop.org/DeviceKit/DeviceKit-disks/commit/?id=458200bcc1e2b30940251d9b4c6c45a3b3757b54

that avoids checking for ATA SMART if the device claims it supports removable media (no ATA disk that I know of claims this so it is generally safe). It should fix the problem being reported here.

Please let me know if it works. Thanks!

>> Hey, please try this build
>> http://koji.fedoraproject.org/koji/taskinfo?taskID=1364728
>> (DeviceKit-disks-004-3.fc11.i586)
>>

It work for me. 

Thanks

---
May 20 08:12:43 eee901 kernel: usb 1-3: new high speed USB device using ehci_hcd and address 6
May 20 08:12:43 eee901 kernel: usb 1-3: New USB device found, idVendor=1307, idProduct=0163
May 20 08:12:43 eee901 kernel: usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
May 20 08:12:43 eee901 kernel: usb 1-3: Product: USB Mass Storage Device
May 20 08:12:43 eee901 kernel: usb 1-3: Manufacturer: USBest Technology
May 20 08:12:43 eee901 kernel: usb 1-3: SerialNumber: d350de421eb25c
May 20 08:12:43 eee901 kernel: usb 1-3: configuration #1 chosen from 1 choice
May 20 08:12:43 eee901 kernel: scsi4 : SCSI emulation for USB Mass Storage devices
May 20 08:12:48 eee901 kernel: scsi 4:0:0:0: Direct-Access     JetFlash TS4GJF168        0.00 PQ: 0 ANSI: 2
May 20 08:12:48 eee901 kernel: sd 4:0:0:0: [sdd] 8191999 512-byte hardware sectors: (4.19 GB/3.90 GiB)
May 20 08:12:48 eee901 kernel: sd 4:0:0:0: [sdd] Write Protect is off
May 20 08:12:48 eee901 kernel: sd 4:0:0:0: [sdd] Assuming drive cache: write through
May 20 08:12:48 eee901 kernel: sd 4:0:0:0: [sdd] 8191999 512-byte hardware sectors: (4.19 GB/3.90 GiB)
May 20 08:12:48 eee901 kernel: sd 4:0:0:0: [sdd] Write Protect is off
May 20 08:12:48 eee901 kernel: sd 4:0:0:0: [sdd] Assuming drive cache: write through
May 20 08:12:48 eee901 kernel: sdd: sdd1
May 20 08:12:48 eee901 kernel: sd 4:0:0:0: [sdd] Attached SCSI removable disk
May 20 08:12:48 eee901 kernel: sd 4:0:0:0: Attached scsi generic sg3 type 0
---

>Hey, please try this build

Works for me.

This appears to have fixed things for me as well. I was able to insert the same thumbdrive that experienced problems previous and format it.

May 20 08:11:08 mcpierce-beta kernel: usb 1-8: new high speed USB device using ehci_hcd and address 5
May 20 08:11:08 mcpierce-beta kernel: usb 1-8: New USB device found, idVendor=1307, idProduct=0163
May 20 08:11:08 mcpierce-beta kernel: usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=3
May 20 08:11:08 mcpierce-beta kernel: usb 1-8: Product: USB Mass Storage Device
May 20 08:11:08 mcpierce-beta kernel: usb 1-8: Manufacturer: USBest Technology
May 20 08:11:08 mcpierce-beta kernel: usb 1-8: SerialNumber: 0809060962a4ed
May 20 08:11:08 mcpierce-beta kernel: usb 1-8: configuration #1 chosen from 1 choice
May 20 08:11:08 mcpierce-beta kernel: Initializing USB Mass Storage driver...
May 20 08:11:08 mcpierce-beta kernel: scsi9 : SCSI emulation for USB Mass Storage devices
May 20 08:11:08 mcpierce-beta kernel: usbcore: registered new interface driver usb-storage
May 20 08:11:08 mcpierce-beta kernel: USB Mass Storage support registered.
May 20 08:11:13 mcpierce-beta kernel: scsi 9:0:0:0: Direct-Access                               0.00 PQ: 0 ANSI: 2
May 20 08:11:13 mcpierce-beta kernel: sd 9:0:0:0: [sdb] 983808 512-byte hardware sectors: (503 MB/480 MiB)
May 20 08:11:13 mcpierce-beta kernel: sd 9:0:0:0: [sdb] Write Protect is off
May 20 08:11:13 mcpierce-beta kernel: sd 9:0:0:0: [sdb] Assuming drive cache: write through
May 20 08:11:13 mcpierce-beta kernel: sd 9:0:0:0: [sdb] 983808 512-byte hardware sectors: (503 MB/480 MiB)
May 20 08:11:13 mcpierce-beta kernel: sd 9:0:0:0: [sdb] Write Protect is off
May 20 08:11:13 mcpierce-beta kernel: sd 9:0:0:0: [sdb] Assuming drive cache: write through
May 20 08:11:13 mcpierce-beta kernel: sdb: unknown partition table
May 20 08:11:13 mcpierce-beta kernel: sd 9:0:0:0: [sdb] Attached SCSI removable disk
May 20 08:11:13 mcpierce-beta kernel: sd 9:0:0:0: Attached scsi generic sg2 type 0
May 20 08:11:13 mcpierce-beta kernel: kjournald starting.  Commit interval 5 seconds
May 20 08:11:13 mcpierce-beta kernel: EXT3 FS on sdb, internal journal
May 20 08:11:13 mcpierce-beta kernel: EXT3-fs: mounted filesystem with ordered data mode.
...
(mcpierce@mcpierce-beta:~)$ sudo mkfs -t ext3 /dev/sdb
mke2fs 1.41.4 (27-Jan-2009)
/dev/sdb is entire device, not just one partition!
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
122976 inodes, 491904 blocks
24595 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67633152
61 block groups
8192 blocks per group, 8192 fragments per group
2016 inodes per group
Superblock backups stored on blocks: 
	8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409

Writing inode tables: done                            
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 28 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

The above normally quit around block group 5 of 61.

The big test is writing an ISO to the disk via livecd-iso-to-disk:

(mcpierce@mcpierce-beta:~)$ sudo livecd-iso-to-disk --format --reset-mbr rhev-hypervisor.iso /dev/sdb
Verifying image...
/home/mcpierce/rhev-hypervisor.iso:   797c9f0922ed8a926f4998e1a631ec67
Fragment sums: 13ba8b9459771cdaf638954cebff4824485ac65171d18d621234ac2b52dc
Fragment count: 20
Checking: 100.0%

The media check is complete, the result is: PASS.

It is OK to use this media.
WARNING: THIS WILL DESTROY ANY DATA ON /dev/sdb!!!
Press Enter to continue or ctrl-c to abort

Waiting for devices to settle...
mkdosfs 3.0.1 (23 Nov 2008)
Copying live image to USB stick
Updating boot config file
Installing boot loader
USB stick set up as live image!

All works well for me! The thumbdrive was built and booted perfectly.

Releng request: https://fedorahosted.org/rel-eng/ticket/1853

This fix is now in F11. Closing.

*** Bug 501872 has been marked as a duplicate of this bug. ***

*** Bug 501317 has been marked as a duplicate of this bug. ***