I'd appreciate an opinion on this scenario as to whether this is a driver bug and whether it's known. I'm running these tests on 10.01.4 and 12.04.1 and the results are the same. Here's what I first noticed:
I have a new 640GB 2.5" SATA drive attached via a Supertop chipset SATA-USB bridge.
Scenario 1) Create a primary partition under Linux using fdisk - save the partition data. Unplug the drive, re-attach it. fdisk now shows a virgin partition record.
Scenario 2) Create the partition table under Windows. Unplug and attached the device to Linux. Use fdisk to view the partition table. It appears as setup as under windows. Now format one of the partitions using mkfs.ext4. fdisk now shows a virgin partition table. It has completely vanished. Scenario 3) Use Windows to create an NTFS partition. Copy a file to the partition under windows. Attach the device to a linux system. It mounts and the windows file is readble. Next create another partition. Cleanly removed the device and reattach. The NTFS partition has gone.
Further investigation shows that the CWB header is being written to the disk in the place whether the data should go. I see the USBC signature where the data should be.
So to prove this I traced the USB packets using wireshark while using hexedit to write to sector 0 offset 0, 40 bytes of 11x.
I see the packet to write my data, actually 1KB is written. My data begins at +18x into the user data area. There's no USBC characters in that packet.
When I use hexedit a second time I see the USBC command packet written to sector 0 and my data written to sector 1.
If I write to sector 2, then sectors 2 and 3 get globbered and sector 3 has the data I intended for sector 2. If I edit 2 consequtive sectors at once the second sector goes to a completely different disk location.
Now compare the with an external IDE drive pluged into a USB bridge.
I see them same type of data packet from wireshark. My data at +18 into the data buffer. IDE seems to want to write to the disk in 4K chunks (not relevant I think). This time data stays where I put it. And there are no USBC strings on the disk - at least none that I could see.
I'm hoping there's a simple config work-around to this.
Dmesg shows the the usb device is frequently reset, I think this is a consequence of the mishandled packet rather than the cause. I've also tried a second USB caddy. It gives the same results. In both cases the Supertop chip set is being used.
Any ideas?
Richard.
Bookmarks