I have an issue which is kind of grave. I bought an external hard drive case with an Super Top M6116 SATA Bridge controller (USB ID 14cd:6116). The problem is that the kernel driver is not working correctly and corrupts completely the information on the hard drive. First, I thought that the hard drive was bad but it was not. The external drive work correctly in Windows XP with the generic mass storage controller. I investigated further and found a posting on the Arch Linux forum referring to the same issues I have. I also have the same issue on Fedora as well. It seams to affect all upstream Linux Kernels. Link to the forum discussion. https://bbs.archlinux.org/viewtopic.php?id=152011 The issue comes from a patch applied in 2010 to the kernel called unusual_cypress.h The last device added is the one I have and that causes the problem. UNUSUAL_DEV( 0x14cd, 0x6116, 0x0000, 0x9999, "Super Top", "USB 2.0 SATA BRIDGE", USB_SC_CYP_ATACB, USB_PR_DEVICE, NULL, 0), The devide information is following ... $ lsusb -vd 14cd:6116 idVendor 0x14cd Super Top idProduct 0x6116 M6116 SATA Bridge bcdDevice 2.20 People in the forum offered the solution to remove the line which affect the cypress driver for this device. I will try this today. I filed already a bug report in the Red Hat Bugzilla and I thought I should do the same here since since this issue damages the information on the hard drive and makes it impossible to recover the data! So to speak, the backup to the external drive are useless and someone will be screwed. Bug report at Red Hat. https://bugzilla.redhat.com/show_bug.cgi?id=909591
I tried the Fedora fix and tested it. All works now. I can create partitions, format and move files from and to the drive without any data corruption. The solution applied at drivers/usb/storage/unusual_cypress.h -UNUSUAL_DEV( 0x14cd, 0x6116, 0x0000, 0x9999, +UNUSUAL_DEV( 0x14cd, 0x6116, 0x0000, 0x0219, "Super Top", "USB 2.0 SATA BRIDGE", USB_SC_CYP_ATACB, USB_PR_DEVICE, NULL, 0), I hope this will help.
This bug has been fix in Fedora with the last update I made. The Gentoo Kernel 3.7.9 still has this bug. What can be done to speed things up? This bug corrupts the partition table and file system. I think it is grave problem.
This issue is misassigned and not a security issue.
If you backups getting wiped out, than that is a security issue. What would be the proper assigned for this issue?
(In reply to comment #4) > If you backups getting wiped out, than that is a security issue. What would > be the proper assigned for this issue? No, that's a data integrity issue. It's like the difference between safety and security.
Thanks Jeroen, I understand the separation you like to express. How would be the proper way of reporting this data safety issue? As far as I can tell it is a kernel issue and a simply one to resolve.
I'll look into this patch with future releases / revision bumps. The best place to report this would be at LKML or the Kernel Bugzilla, that way it gets merged upstream (if an acceptable patch) such that everyone can benefit.
Has this ever been reported upstream at the Linux Kernel?
This patch has been in the upstream mainline kernel since v3.9-rc1. If you don't see this patch on earlier (not EOL'd) kernels and need to have it backported, please comment back here.
