Most recent kernel where this bug did not occur: none, just bought the enclosure
Hardware Environment: Intel 440BX MB, Celeron 1.3GHz, USB 2.0 pci card
Software Environment: udev 079, glibc 2.3.5, gcc 4.0.3, xorg 6.8.2, xfce 4.2.3
When I connected my new usb enclosure to my system, I did not get a scsi device
node in /dev. I brought the device to a different computer running windows
2000, which recognized the disk and could read and write it. I reattached the
enclosure to my linux computer, and watched the kernel send a bunch of usb
errors to ther kernel log file. This error also occurs in version 2.6.13 of the
kernel. I decided to upgrade my kernel version since I needed to compile in
some debug support for this problem.
Steps to reproduce:
Plug in a PPA Int'l Model 1998
(http://www.ppa-usa.com/product_pages/enclosures/1998.htm). I looked at the
chip this enclosure uses; it's a usb4500 from DataStor.
Created attachment 7054 [details]
kernel log file with error messages
Created attachment 7055 [details]
kernel config file
Looks like you've got one of those messed-up devices that tell the system they
have one more sector than they really do and then crash when the system tries to
read the nonexistent "last" sector. The attached patch ought to help.
Created attachment 7065 [details]
unusual_devs blacklist entry for DATASTOR unit
I forgot to mention that the patch is for 2.6.16-rc1. If you want to apply it
to 2.6.15 you'll have to edit the file by hand. The new entry can simply be
added to the end of the file.
I used the posted patch to make my own patch for 2.6.15, and then I recompiled
my kernel. I got the same output as before on the kernel log.
Not possible if you applied the patch correctly. In particular, the lines that
say "SCSI device sda: 120103201 512-byte hdwr sectors" should now say
"120103200". And the command that caused the original error, a READ_10 with
command bytes "28 00 07 28 a1 20 00 00 01 00", should not occur at all. Note
that 0x0728a120 is hex for 120103200, the so-called "last" sector which actually
I editied the patch to work for my 2.5.15 kernel, and it worked perfectly. My
distro recently moved to using an initramfs for loading boot time kernel
modules. Before I was only using one for my gensplash theme. Apparently I
recompiled my kernel modules a couple times and generated new initramfs images,
but I had an old image with a different name that was loading instead. Anyway
the drive works now. I'd like to thank everyone for their speedy reply to my
dilemma. I was a bit worried about having possibly purchased a big paper
weight. And I would like to know what version of the kernel will contain this fix.
I'll submit the fix now. If it's not already too late in the 2.6.16 development
process then the fix will appear in the final version of 2.6.16, otherwise it
won't appear until 2.6.17-rc1.