PE2650 & PERC3/Di experience

Robert Cope robert at
Wed May 26 21:14:00 CDT 2004

Not that I really feel the need to defend Dell, but I have many 1650s,
1750s, and 2650s in production with the 3/DI, 4/DC, and uh, other PERC
controllers. All of them run Redhat 7.3. They are all rock solid and
perform well under load. In the past year, I've had to reboot one of

Sounds like you got a lemon,


-----Original Message-----
From: linux-poweredge-admin at
[mailto:linux-poweredge-admin at] On Behalf Of ddarcy at
Sent: Wednesday, May 26, 2004 8:15 PM
To: Linux-PowerEdge at
Subject: PE2650 & PERC3/Di experience

Right now we're currently running one PE2650 with a PERC3/Di, but we
it severely locked down. This box has been nothing but problems ever
we first got it. Between having a failed power supply, a faulty dvd-rom,
and performing poorly all-round while we were using the percraid
functionality, I'd say the purchase hasn't been worth the money.
After much trial and error we came up with a few tricks to work around
short-comings of the model.
First, disable hyper-threading it slows down performance under linux.
Second, turn off the RAID functionality in the BIOS and three go with a
software RAID solution. That or go and buy a 3/DC or a 4/DC. During our
testing, software raid surpassed any of the various hardware solutions
tried both in performance and obviously cost :).
With Hardware RAID the box would consistently lock at least once a day
that was under a light testing load. After stepping up the tests and
thereby increasing the I/O activity, it failed consistently two to three
times a day! When I say failed, I mean that the machine would stop
accepting input of any kind (keyboard, mouse, serial port, telnet
session), but remained pingable oddly enough. It was only till we
RAID in the BIOS that we were able to get decent up times.
This was all done using a RAID1+0 configuration under Gentoo 2004.0,
AAC0: kernel 2.7.4 build 3170, AAC0: monitor 2.7.4 build 3170, and AAC0:
bios 2.7.0 build 3170. Whether the problem lies in the aacraid driver or
the physical hardware it's hard to say. Overall the behavior was
there were no error messages despite turning on:
[*] - Verbose SCSI error reporting (kernel size +=12K)
[*] - SCSI logging facility - echo "scsi log token [level]" >
/proc/scsi/scsi, requires that you read drivers/scsi/scsi.c to figure
the tokens.
Also, it's probably noteworthy to point out, that afacli would cause the
system to outright halt and disabling the caching options in the Bios
_not_ help.
Additionally we tried to make our own custom initrd so we could load and
unload the aacraid driver when it failed to try and restore
w/o having to restart the system, but we never made much head way. We
the idea to first try a module versus building it directly in to the
kernel after letting the system run off of the livecd for more than a
It just so happened that day was also the first day the system didn't
lock. At which point it was fairly obvious that the problem probably had
more to do with the driver than it did with the hardware.
Anyways, the only thing that finally turned results was disabling the
RAID functionality entirely and then setting up a software raid config.
Anyways, I hope this saves someone else the hassle of having to figure
of this out on their own.

Linux-PowerEdge mailing list
Linux-PowerEdge at
Please read the FAQ at or search the list
archives at

More information about the Linux-PowerEdge mailing list