Wrong SSD sector count with current F17 (right with live)

[Michael J Gruber]

F17 with current updates gets the sector count wrong (too large by 5)
for my SSD (Jetflash USB), resulting in read errors (during boot, fdisk
reading the disk etc.) for those sectors. While everything "seems to
work" this is not OK, of course. I'd be grateful for any clue.

Test systems
============
F16 with updates (kernel 3.4.9-2)
F17 live (kernel 3.3.4-5)
F17 with updates (kernels 3.3.4-5, 3.5.0-2, 3.5.2-3, 3.5.3-1)

F16 and F17 live are OK, F17 with updates is not (no matter which
kernel), where "OK" means no read errors. So the relevant difference is
not in the kernel but something else which has been updated since release.

lsusb
=====
Bus 002 Device 003: ID 2174:07d0

dmesg
=====
(after a common part about the USB to S-ATA device)

F16 (booted from a different device):
[  287.229149] scsi6 : usb-storage 2-1.5:1.0
[  288.230862] scsi 6:0:0:0: Direct-Access     JetFlash TS128GSSD18C3
 0004 PQ: 0 ANSI: 0
[  288.231591] sd 6:0:0:0: Attached scsi generic sg7 type 0
[  288.232184] sd 6:0:0:0: [sdg] 250069676 512-byte logical blocks: (128
GB/119 GiB)
[  288.234815] sd 6:0:0:0: [sdg] Write Protect is off
[  288.234820] sd 6:0:0:0: [sdg] Mode Sense: 03 00 00 00
[  288.235676] sd 6:0:0:0: [sdg] No Caching mode page present
[  288.235680] sd 6:0:0:0: [sdg] Assuming drive cache: write through

F17 (booted from that SSD):
[    2.661796] scsi5 : usb-storage 2-1.5:1.0
[    3.665597] scsi 5:0:0:0: Direct-Access     JetFlash TS128GSSD18C3
 0004 PQ: 0 ANSI: 0
[    3.666375] sd 5:0:0:0: Attached scsi generic sg6 type 0
[    3.666917] sd 5:0:0:0: [sdf] 250069681 512-byte logical blocks: (128
GB/119 GiB)
[    3.667784] sd 5:0:0:0: [sdf] Write Protect is off
[    3.667789] sd 5:0:0:0: [sdf] Mode Sense: 03 00 00 00
[    3.668657] sd 5:0:0:0: [sdf] No Caching mode page present
[    3.668661] sd 5:0:0:0: [sdf] Assuming drive cache: write through

Note the different sector count!
After enumerating the partitions, dmesg throws:
[    3.674173]  sdf: sdf1 sdf2 sdf3 sdf4 < sdf5 >
[    3.678160] sd 5:0:0:0: [sdf] No Caching mode page present
[    3.678165] sd 5:0:0:0: [sdf] Assuming drive cache: write through
[    3.678168] sd 5:0:0:0: [sdf] Attached SCSI disk

[    3.694795] sd 5:0:0:0: [sdf] Unhandled sense code
[    3.694798] sd 5:0:0:0: [sdf]  Result: hostbyte=invalid
driverbyte=DRIVER_SENSE
[    3.694802] sd 5:0:0:0: [sdf]  Sense Key : Medium Error [current]
[    3.694806] sd 5:0:0:0: [sdf]  Add. Sense: Recorded entity not found
[    3.694811] sd 5:0:0:0: [sdf] CDB: Read(10): 28 00 0e e7 c2 b0 00 00
01 00
[    3.694821] end_request: critical target error, dev sdf, sector 250069680
[    3.694824] Buffer I/O error on device sdf, logical block 250069680

The last few lines get repeated.

The same difference in sector size is reported by fdisk and hdparm:
 geometry      = 15566/255/63, sectors = 250069676, start = 0
vs.
 geometry      = 15566/255/63, sectors = 250069681, start = 0

Interestingly, "hdparm -N" agrees in both cases:
max sectors   = 250069680/1(250069680?), HPA setting seems invalid
(buggy kernel device driver?)

But ignore_hpa=0 for the libata module in all cases (Fedora default).

Stomped!

I can provide the full dmesg, of course. Please help :|