External USB controller chips

Recently, customer needs made me concern myself with external hard disk cases. Or, to be more precisely, with hard disks in external cases that employ different connection types such as USB 2.0 and Firewire. Among these, Firewire in its conventional variant IEEE1394a is the "slowest" with 400 MBit/s, USB 2.0 is second with 480 MBit/s and the quite new IEEE1394b sets the speed mark with 800 MBit/s theoretical xfer rate.

Modern hard disks typically transfer between 50 and 70 MB/s on their ATA interface. In an external case, according to a test performed by German computer magazine c't, they reach between 33MB/s when connected via USB2.0, 37MB/s via IEEE1394a and up to 58MB/s via IEEE1394b. These values hold true for bulk data transfers only, which in reality occur rather seldom, but they show that through a wise choice of connection type one does not have to lose too much speed.

On the other hand, the mentioned test (issue 19/04, page 146) also showed that the choice of the controller chip is of quite some importance. All external cases, might they look as different as cars, employ one or more "standard chips" provided by chip providers such as Oxford Semiconductor and GenesysLogic. Some of these we can simply forget because they're simply too slow, compared to their competitors.

In reality, you'll quite often find one of the following chips resp. chip combinations:

Oxford Semiconductor OXUF922 for IEEE1394a/b/USB2.0 combined
Oxford Semiconductor OXFW911 for IEEE1394a, Cypress CY7C68300 for USB2.0
GenesysLogic GL711FW for IEEE1394a, GenesysLogic GL811USB or GL811E for USB 2.0
Prolific PL3507 for Firewire/USB2.0 combined

Among these, the OXUF922 excels due to its still unparalleled IEEE1394b support. The OXFW911 also enjoys a good standing performance-wise, as well as the Cypress CY7C68300, the Prolific PL3507 and the GenesysLogic GL811E (whereas the GL811USB is more of an easygoing worker).

Alas, in the chase for speed the chip providers seem to have forgotten to make their homework as regards the USB 2.0 specifications. Both the OXUF922 and the GenesysLogic GL811E did not withstand my stress tests for a particular long period of time...

Everything began with an ordinary copy process under Windows XP SP2, which suddenly resulted in messages about filesystem corruptions. The event log showed something like this (translated from German, I don't run english Windows versions, but you'll get the picture):

Event type:	Warning
Event source:	Ntfs
Event category:	None
Event id:	50
Date:		19.03.2005
Time:		22:04:43
User:		Not applicable
Computer:	DMC
Description:
(Data loss during Writing) Not all data for the file "" could be written
properly. Data was lost. Possible reasons include the computer's hardware and
the network connectivity. Try specifying a different path.

This was with the Macpower Pleaides 800+ case, which employs the OXUF922, connected via USB2.0.

Now I already thought of the possible reason for this: apparantly the USB controller disconnected from the bus or something similar. As always, booting Linux gives more answers, thanks to its verbosity:

Mar 19 23:24:22 dmc kernel: Current sde: sense key No Sense
Mar 19 23:24:22 dmc kernel: Current sde: sense key No Sense
Mar 19 23:24:41 dmc kernel: usb 5-6: control timeout on ep0in
Mar 19 23:25:11 dmc last message repeated 6 times
Mar 19 23:25:36 dmc last message repeated 5 times
Mar 19 23:25:37 dmc kernel: usb 5-6: reset high speed USB device using address 3
Mar 19 23:25:42 dmc kernel: usb 5-6: control timeout on ep0out
Mar 19 23:25:47 dmc kernel: usb 5-6: control timeout on ep0out
Mar 19 23:25:47 dmc kernel: usb 5-6: device not accepting address 3, error -110
Mar 19 23:25:47 dmc kernel: scsi: Device offlined - not ready after error recovery: host 3 channel 0 id 0 lun 0
Mar 19 23:25:47 dmc kernel: SCSI error : <3 0 0 0> return code = 0x70000
Mar 19 23:25:47 dmc kernel: end_request: I/O error, dev sde, sector 307303
Mar 19 23:25:47 dmc kernel: Buffer I/O error on device sde1, logical block 307240
Mar 19 23:25:47 dmc kernel: lost page write due to I/O error on sde1
Mar 19 23:25:47 dmc kernel: scsi3 (0:0): rejecting I/O to offline device
Mar 19 23:25:47 dmc kernel: Buffer I/O error on device sde1, logical block 307241
Mar 19 23:25:47 dmc kernel: lost page write due to I/O error on sde1
Mar 19 23:25:47 dmc kernel: Buffer I/O error on device sde1, logical block 307242
Mar 19 23:25:47 dmc kernel: lost page write due to I/O error on sde1
[...]
Mar 19 23:25:48 dmc kernel: FAT: bread(block 70) in fat_access failed
Mar 19 23:25:48 dmc kernel: scsi3 (0:0): rejecting I/O to device being removed
Mar 19 23:25:48 dmc kernel: FAT: bread(block 70) in fat_access failed
Mar 19 23:25:48 dmc kernel: scsi3 (0:0): rejecting I/O to device being removed
Mar 19 23:25:48 dmc kernel: FAT: unable to read inode block for updating (i_pos 2441345)
Mar 19 23:25:48 dmc kernel: scsi3 (0:0): rejecting I/O to dead device
Mar 19 23:25:48 dmc kernel: FAT: bread(block 70) in fat_access failed
Mar 19 23:25:48 dmc kernel: scsi3 (0:0): rejecting I/O to dead device
[...]

Do not get confused, Linux uses SCSI emulation although it is an USB device. Notice the "contol timeout" message and how later on Linux tries to reset the USB device, but the device does not respond. Succeedingly, the FAT32 filesystem can't get its data read and written, and the filesystems remains in a broken state.

Now that's fun, eh? The magic question is: am I the first to notice this? Is this due to some aspect of my system configuration?

The answer is: no. I did extensive tests:

on three different machines:
- MSI K8N Neo2 Platinum, nForce3-Chipsatz, Sockel 939 (Athlon 64)
- AOpen EA65-II Barebone, Intel i865G-Chipsatz, Sockel 478 (Pentium 4)
- Samsung P30 Notebook, Intel 855PM-Chipsatz, Pentium M
with two different hard disk types:
- on the one hand with two brandnew Samsung SP1614N 160GB hard disks
- on the other hand with an older, used IBM DTLA-307030 hard disk
under two operating systems:
- Windows XP SP2 with all updates
  - with FAT32 as filesystem
  - with NTFS as filesystem
- SuSE Linux 9.2 with all updates (SuSE kernel 2.6.8-24.11, in addition also with a brandnew vanilla 2.6.11.4 kernel)
  - with FAT32 as filesystem
  - with ext2 as filesystem
and with two different firmware versions:
- the shipped firmware (1.07, dated Sep 20 2004)
- the most recent firmware available on http://www.macpower.com.tw/resources/922firmware (also 1.07, but dated early September)

Not a single combination made the error go away. You can't tell me that three different systems and two different operating systems contain the same errors as regards USB storage drivers. You can't tell me it's a hard disk incompatibility. You can't tell me more recent firmware fixes it. The OXUF922 _is_ broken.

And it's known. Checks these links:

The second link suggests a workaround that doesn't help me much in Windows. The third link is about the GenesysLogic GL811E, and guess what? It is indeed broken as well. I tried a different case with such a controller chip -- while it doesn't fuck up the filesystem as fast as the OXUF922, eventually it happens as well. That third link suggests it's a firmware issue, but that doesn't help me much, since no updated firmware was available at all.

And these two are in "good" company: try googling for the Prolific PL-3507. You'll read tens, hundreds of reports about problems as well. What the heck is it with the USB data transfers that the chip providers can't get to work reliably? Is it so hard to cope with both isochronic bulk data transfers and short control messages or what?!

But fear not -- there is at least one controller chip that, although reporting control pin timeouts as well, performs correctly: the Cypress CY7C68300 passed all my tests successfully, without messing up the filesystem :) It might not have IEEE1394b and it's not the fastest USB2.0 controller chip, but it's fast and safe, which should be your primary interest.

There are several 3,5" cases with this chip, but unfortunately the case manufacturers usually don't mention the chip type, not even in the "technical specs". Based on the c't article, I can give you two names however:

Onnto SC-M12CI -- USB2.0/IEEE1394a combo, my recommendation! I'm very satisfied with this one, it's nice, it's fast, it's silent :)
CS-Glory CS-338

The CY7C68300 also appears in the "Sarotech MyBox 5,25", but as the name suggests, that's a larger case originally intended for external CD/DVD drives.

To close, I still owe you the question as to what my "stress tests" under Linux actually were. In order to reproduce the phenomena described above, you should:

have tail -f /var/log/messages running on a seperate console, so you can watch all syslog messages (in SuSE eg. the console behind ALT-F10 does not reveal everything).
attach your case to your Linux system and undo any automatic mounting, such as done by subfs in modern Linux distributions such as SuSE 9.1 and higher.
generate a fresh filesystem on the hard disk. I used FAT32 so as to maintain compatability with Windows, but you might just try ext2, reiser or whatever.
mount the fresh filesystem and start a copy of a large amount of data to it (I used my MP3 collection). Try "rsync" if you want something more verbose than "cp".
while the copy process is running, switch to a different console and have the following executed:
```
while true; do cat /proc/bus/usb/devices; sleep 2; done
```
This will generate some light load on the USB bus since every 2 seconds the USB bus will receive a number of control messages. Ideal to reproduce the firmware bugs described above.
Watch your syslog and wait. If it doesn't happen: just be lucky. While I believe that I can reproduce this bug on virtually any system and any external case with those controller chips (excluding future firmware) and just a bootable Linux CD, I can't know for sure, of course.

This page last changed:
March 23, 2005