Last week my ZFS cache device — an USB mem­ory stick — showed xxxM write errors. I got this stick for free as a promo, so I do not expect it to be of high qual­ity (or wear-leveling or sim­i­lar life-saving things). The stick sur­vived about 9 months, dur­ing which it pro­vided a nice speed-up for the access to the cor­re­spond­ing ZFS stor­age pool. I replaced it by another stick which I got for free as a promo. This new stick sur­vived… one long week­end. It has now 8xxM write errors and the USB sub­sys­tem is not able to speak to it any­more. 30 min­utes ago I issued an “usb­con­fig reset” to this device, which is still not fin­ished. This leads me to the ques­tion if such sticks are really that bad, or if some prob­lem crept into the USB subsystem?

If this is a prob­lem with the mem­ory stick itself, I should be able to repro­duce such a prob­lem on a dif­fer­ent machine with a dif­fer­ent OS. I could test this with FreeBSD 8.1, Solaris 10u9, or Win­dows XP. What I need is an auto­mated test. This rules out the Win­dows XP machine for me, I do not want to spend time to search a suit­able test which is avail­able for free and allows to be run in an auto­mated way. For FreeBSD and Solaris it prob­a­bly comes down to use some disk-I/O bench­mark (I think there are enough to chose from in the FreeBSD Ports Col­lec­tion) and run it in a shell-loop.

I had a look at some USB PRs and wrote a list of those with patches to Warner (as he is work­ing on USB stuff cur­rently). I also cat­e­go­rized them (easy, not easy, maybe already fixed, …). The easy ones he han­dled already, for the rest I don’t know his cur­rent plans.

Regard­ing lin­ux­u­la­tor stuff I’m work­ing on a MFC patch (no TLS, no futexes). As I don’t have a -sta­ble box I need some help test­ing it before I can com­mit it. I only com­pile tested this on –cur­rent with the new gcc 4.2. What I need is:

• test­ing on i386, amd64 (if I for­got some­thing, it may panic your system)
• “make uni­verse” test (you have to grep all the logs for “Error 1″ and inves­ti­gate the error if there’s one)
• LTP test run, see the wiki for more (best would be a diff of the logs in the result direc­tory of no-patch/patch runs)
• nor­mal linux appli­ca­tion use-tests

What the patch pro­vides is:

• mmap fixes
• fix mem­leaks
• add mprotect/iopl/lstat/ftruncate/statfs64/timer_*/mq_*
• more errno value mapping
• don’t limit num­ber of syscalls to 255
• allow to exec libs
• ioctl TIOCGPTN
• han­dle more socket options
• de-COMPAT_43-ify
• add dummy syscalls so that we know what is needed (reports from users)
• style(9)
• lin­procfs enhance­ments

I did shoot down some USB related PR’s today. We have now sup­port for more devices in uscan­ner, umo­dem and one new PDA in uvi­sor. Addi­tion­ally all peo­ple which use the con­troller of a XBOX 360 will now notice that the LEDs on them stop blink­ing, when the uhid dri­ver attaches to it (like on the XBOX 360).

This affects -cur­rent and -sta­ble.