Comment 9 for bug 294391

Revision history for this message
Stefan Richter (stefan-r-ubz) wrote :

Thanks for the information. We can add the firmware_revision and model_id to a quirks list in the sbp2 driver so that the workaround will activated automatically by upcoming releases of the kernel.

Until this made its way into the kernel, you can enable this workaround permantly by adding the following line either to /etc/modprobe.d/options or to a new file in /etc/modprobe.d/ with a filename of your choice:
options sbp2 workarounds=8

The workaround simply subtracts one from the disk size reported by the device. In your initial report, it is 29297520 sectors, while with the workaround the kernel takes it as 29297519 sectors. This size is determined from the SCSI command READ CAPACITY (10), to which devices are supposed to return the LBA (logical block address) of the last sector. Since the LBA of the 1st sector is 0, the LBA of the last sector is the number of sectors minus 1. Some firmware programmers get this wrong and return not the last LBA but the numbers of sectors. This is a problem of many USB devices and apparently also of USB iPods and some of the dual USB + FireWire iPods. When then the kernel accesses blocks near the supposed end of the disk, there will be I/O errors, or the firmware will even hang. Firmware programmers don't notice their bug because they only test with Windows which typically does not access disks right at the end. Linux does so for example to check for some types of partition tables which Windows does not support.

However, the 29297520 sectors, as an even number, are actually more plausible to me as the real disk size than 29297519 sectors, as an odd number. Perhaps the real issue here is that this iPod firmware has a problem with block accesses /near/ the end. There have been several different flavors of firmware bugs observed with USB devices which concern accesses near the end of the disk, such as expecting only small request sizes. So it could actually be that 29297520 sectors is the real size, but reducing it by one causes the Linux kernel to treat the las few sectors with more care. There have been some changes in the related kernel code in the latest kernels.

Lastly, the reason that it all worked fine for you before you updated Ubuntu may have been changes in the kernel's configuration and features, causing 8.10's kernel to issue requests to disks which the former kernel didn't.