I have generally had good luck with Promise products. Today I had an order put in for two Promise TX4 cards. These are potential replacements for my RocketRAID 1820 cards. If they work I might be getting twentytwo more of them.
On June fourth I resolved my HighPoint RocketRAID 1820 issues, or so I thought. The drives on the RocketRAID 1820 cards have been getting little use until yesterday when I tried copying some data on them. Linux, probably because of the proprietary driver, started returning errors:
SCSI error : <0 0 4 0> return code = 0x25050000 end_request: I/O error, dev sde, sector 614175 Abort called pid: 5357 target: 4 lun: 0 reason 0 Abort called pid: 5358 target: 4 lun: 0 reason 0 Abort called pid: 5359 target: 4 lun: 0 reason 0 Abort called pid: 5360 target: 4 lun: 0 reason 0 Abort called pid: 5361 target: 4 lun: 0 reason 0 Abort called pid: 5362 target: 4 lun: 0 reason 0 Abort called pid: 5363 target: 4 lun: 0 reason 0 Abort called pid: 5364 target: 4 lun: 0 reason 0 RR182x: Bus Reset: host=0, channel=0 target=4
I can’t get the systems to consistently do it.
My I²C woes continued today. I have twelve SUPER X5DPA-GG systems with HighPoint RocketRAID 1820s. HighPoint provides an “OpenBuild”, currently v1.02, but this doesn’t build on Linux kernels above 2.6.3. I need I²C working because these machines are in a room with a history of AC problems. The SMBus devices on the SUPER X5DPA-GG don’t work with the I²C drivers from the 2.6.3 kernel, but with the 2.6.6 kernel do.
After I submitted a support request to HighPoint, I set of finding my own solution. I got lucky. I simply replaced the I2C directory in the 2.6.3 kernel source tree with the one from the 2.6.6 kernel. Reconfigure and rebuilt the kernel, and it works like a charm!
I hope HighPoint gets back with a new driver. Hopefully this time they will open source it and not just “OpenBuild” it. Whatever “OpenBuild” means. I might of tried to fix it myself if it was open source.
On Tuesday I got
Using Debian’s debootstrap package I installed an extra partition with on a separate server with Sarge. In order to use the lm-sensors detection I wanted a kernel that has the I²C configured as much like Debian’s shipped kernel as possible but also be NFS root bootable. I took the latest stable 2.6.x kernel from The Linux Kernel Archives, and the latest 2.6.y kernel configuration file from the latest configured Sarge package; x=6 and y=5 at the time I built them. I made sure CONFIG_ROOT_NFS, CONFIG_IP_PNP_DHCP was on, and the network card was staticly linked too. After building the kernel I installed the modules in the Sarge partition.
I configured an NFS server to export said made Sarge partition with no_root_squash on. Set up TFTP with PXE files. Then set up a DHCP server to boot that system via PXE. Remote booting the system went fine and the sensors-detect command mostly reported accurate information.
I build a kernel with our in-house specifications, included the discovered I²C packages. Now it gleefully reports the CPU temperatures. Even though it feels like I used a jack hammer to plant a daisy, it now works.
Since my Kernel build seems to be taking forever, here is what I’ve been up to. I’ve been trying to get
Working with the mixed system has been a pain in the butt, even though I followed §3.8 of the APT HOWTO I think I’m having package version issues. So I’m making a pure Sarge system just to boot via of them. It seems a bit overkill, but you gotta do what you gotta do.
While all my Promise RM8000s are fine, somebody else in the building started having problems with his. After two days of experiments by our lovely system administrators the current working theory is that it was plugged into a RAID SCSI device, and the RAID on RAID action seems to confuse it when use gets heavy. Its been getting use plugged into a normal SCSI card, and all seems to be functioning. My Promise RM8000s where always plugged into a non-RAID SCSI device.
Powered by WordPress