We have ~20 Dell servers with 6.x and Perc5.
Automatic PR is enabled on all of them, and happens once a week
without any problems (so far - since July).
Obviously, from the thread, manual Patrol Reads cause a definite
problem, but it's not clear that the initial problem had the same
symptoms - just that there was a correlation between the automatic
Patrol Reads and the server lockup?
I guess it may be that under heavy load (exacerbated by PR) something
else gets screwed up and causes the machine lockup?
Simon wrote:
So everyone that uses Dell servers with Perc5 and 6.x disables automatic PR?
-Simon
--Original Message Text---
From: Benjie Chen
Date: Tue, 13 Nov 2007 17:50:41 -0500
If you disable PR, the problem will go away. Below are some useful commands. Sean mentioned that you could disable it, then set it to do an automatic PR 1 hour after you restart the automatic PR. automatic PR does not crash the system
definitively, but manual PR does. So during your downtime, you could try to do an automatic PR...
# Disables patrol reads on all adapters
megacli -AdpPR -Dsbl -aALL
# Enables automatic patrol reads
megacli -AdpPR -EnblAuto -aALL
# Sets the interval for automatic reads to 1 hour - it only
# accepts whole numbers so that's the lowest you can go
megacli -AdpPR -SetDelay 1 -aALL
Some other useful ones:
# Patrol read settings and information
megacli -AdpPR -Info -aALL
# Extended information
megacli -AdpAllInfo -aALL
# Export controller's event log to file
megacli -AdpEventLog -IncludeDeleted -f <fileName> -aALL
# More logging
megacli -FwTermLog -Dsply -aALL
On 11/13/07, Simon <[EMAIL PROTECTED]> wrote: Hello,
I'm just wondering, was this ever resolved? I was about to start using
new 2950 with Perc5 in it, but now I'm afraid to as I cannot afford
downtime. Why this is still a linux hack is beyond me. The way Dell
is doing, they ought to have a port specifically for FreeBSD
If I disable PR altogether (not sure if this is possible, yet), although I
don't see why it wouldn't be, would the mentioned problem go away?
Thank you,
Simon
On Mon, 01 Oct 2007 17:26:29 -0400, Sean McAfee wrote:
John Baldwin wrote:
On Saturday 29 September 2007 09:18:17 pm Benjie Chen wrote:
Hmm, I haven't tried with megacli, but an internal tool at work is able to
start manual patrol reads w/o causing a crash, and I've also seen production
boxes running automatic patrol reads w/o causing crashes. Do you have to
have a certain load before it will crash?
The crashes that we've seen in production have occurred while patrol
reads kick off under moderate-high load, but in testing, an automatic
read will complete fine. Even with maxed-out I/O*, we haven't been able
to come up with reliable testing scenario to trigger crashes on
automatic patrol reads.
(*My base testing scenario involved running a pretty heavy stress [as in
the program available in ports], while repeatedly copying ports & src
from an NFS mount to another local mountpoint and SCPing a large file in
a loop from another machine.)
Sean McAfee
Collaborative Fusion, Inc.
[EMAIL PROTECTED]
412-422-3463 x 4025
1710 Murray Avenue, Suite 320
Pittsburgh, PA 15217
****************************************************************
IMPORTANT: This message contains confidential information
and is intended only for the individual named. If the reader of
this message is not an intended recipient (or the individual
responsible for the delivery of this message to an intended
recipient), please be advised that any re-use, dissemination,
distribution or copying of this message is prohibited. Please
notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The
sender therefore does not accept liability for any errors or
omissions in the contents of this message, which arise as a
result of e-mail transmission.
****************************************************************
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to " [EMAIL PROTECTED]"
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to " [EMAIL PROTECTED]"
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
