On Sun, 2 Sep 2007, Chuck Anderson wrote: > Please Cc me on any replies, since I'm not subscribe to this list. > Thanks. > > I'm evaluating MXI Security's Stealth MXP 4 GB hardware encrypted USB > thumb drive w/biometric reader. It works okay in Windows and MacOS X, > but fails under Linux with data corruption issues. Here is the output > of lsusb: ...
> As you can see, the corruption is always 16 bytes in size and the > offsets seem to fall into a pattern of sorts. The corruption is also > always the same for this specific data set. When I looked at the > corruption in the files that I stored when it was formatted as FAT32, > it was different and seems to be data-dependent. > > If I repeat the exact test on MacOS X, there is no problem. All zeros > get written and read back from the device. If I then take the zeroed > USB stick back to a Linux system and try to read it, I get corrupted > data. So the corruption definately happens when Linux reads from the > device. > > If I re-zero the device on Linux and take it back to MacOS X, the same > corruption shows up there. So the corruption also happens when Linux > writes to the device. > > I'm using Fedora 5 and 6 for my testing, and I've tried several > kernels including 2.6.18-1.2798.fc6, 2.6.20-1.2962.fc6, and > 2.6.22.2-42.fc6. My colleague has also tried Slackware Linux with > kernel 2.6.21.5, and the problem appears there as well. That's on a different computer? Hardware differences are more likely to matter here than kernel version differences. > Does anyone know what might be going on here? It seems there is a bug > somewhere in Linux usb-storage. I've never head issues with regular > USB sticks before--could the problem here be due to the multiple LUNs? I doubt there's a bug in usb-storage or in the LUN handling code. If there were, it would likely show up much more frequently than 16 bytes out of every 128 KB -- and it would show up with every storage device, not just this one. It's quite possible there's a bug in the device, one that is somehow triggered by Linux but not by Windows or Mac OS X. However I have no idea what such a bug might be or how to avoid it. If you have access to a USB bus analyzer, it would be possible to prove or disprove that the bug is in the device. But even then, it wouldn't be clear how to cope with it. Have you tried using the device at full speed instead of high speed? Do "rmmod ehci-hcd" before plugging it in and then see how it behaves. Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Linux-usb-users@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
