Monthly Archives: March 2015

LSI 9207-8i and P20 firmware

Leave a reply

This is a tale of woe on Centos 6.

Resetting drives. iuCRC errors. Bad blocks in ZFS. These are not things you want to see from your brand new 5000$ storage machine.

We just finished setting up the first storage server for my group at work. I ran badblocks on the drives as an acceptance test, and started noticing that the HBA, a LSI 9207-8i, would randomly freeze I/O complaining that the drives had timed out an operation, then eventually resend the command. Reducing the NCQ depth and increasing the command timeout did not help. The errors were intermittent but consistent on all drives. Badblocks passed, with no reallocated sectors so the disks platters should be fine.

Turns out, using mpt2sas driver version 16 and P20 firmware on the HBA does not work. I had to downgrade the firmware to P16, at which point things seemed to start working again. Downgrading required booting into the UEFI shell provided by the motherboard, and was actually not a bad experience. I like the idea of a recovery shell built in – no more digging around trying to find a live dos USB image that works.

This also demonstrates ZFS might be a good burn in tool… it detected silent data corruption the HBA likely caused.

zfs on linux

Leave a reply

ZFS on linux seems to be much more stable than the last time I looked several years ago. It is now running happily on 3 systems, using the kernel module from http://zfsonlinux.org/.

The data integrity checks also helped identify a host bus adapter with bad firmware… The whole concept of checksumming all data has already been shown to identify silent data corruption. Performance is about the same as the software mdadm raid5 I was using before, with the exception that the scrubs are *much* faster on partially filled pools.

I suppose I will keep watching it, but I am rather happy so far.

LUFA & Printf on XMEGA

Leave a reply

LUFA, my favorite XMEGA USB driver also supports controling the serial ports. And connecting streams to printf, which makes for a happy, if lazy, embedded programmer. I just couldn’t figure out how to wire it up.

Turns out I was calling fdev_set_udata too soon, it must be called after the stream is created. Which makes sense. Perhaps I need to check the caffiene levels in my coffee.

Example:

Serial_Init(&USARTC0, 9600, false);

FILE stream;
Serial_CreateStream(&stream);
fdev_set_udata(&stream, &USARTC0);

fprintf(&stream, "Hello");