PE2650 & PERC3/Di experience

Robert Cope robert at gonkgonk.com
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
them.

Sounds like you got a lemon,

robert 

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

Right now we're currently running one PE2650 with a PERC3/Di, but we
have
it severely locked down. This box has been nothing but problems ever
since
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
the
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
we
tried both in performance and obviously cost :).
With Hardware RAID the box would consistently lock at least once a day
and
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
disabled
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,
using
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
erratic,
there were no error messages despite turning on:
[*] - Verbose SCSI error reporting (kernel size +=12K)
and
[*] - SCSI logging facility - echo "scsi log token [level]" >
/proc/scsi/scsi, requires that you read drivers/scsi/scsi.c to figure
out
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
did
_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
functionality
w/o having to restart the system, but we never made much head way. We
got
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
day.
It just so happened that day was also the first day the system didn't
hard
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
PERC
RAID functionality entirely and then setting up a software raid config.
Anyways, I hope this saves someone else the hassle of having to figure
all
of this out on their own.
Cheers,
-Dustin



_______________________________________________
Linux-PowerEdge mailing list
Linux-PowerEdge at dell.com
http://lists.us.dell.com/mailman/listinfo/linux-poweredge
Please read the FAQ at http://lists.us.dell.com/faq or search the list
archives at http://lists.us.dell.com/htdig/




More information about the Linux-PowerEdge mailing list