2.6.20 (+2.6.21-rc4) write hang modifier
If I set /proc/sys/vm/dirty_ratio to 5 the write lockup happens within the first MilliSecond, at about 100MB per file system. If I slew the dirty_ratio to 80, the lockup happens at about 2GB per file system. 2.6.21-rc4 has the same symptoms, and same lockups. It appears that mptsas is dropping something. berkley -- //E. F. Berkley Shands, MSc// **Exegy Inc.** 3668 S. Geyer Road, Suite 300 St. Louis, MO 63127 Direct: (314) 450-5348 Cell: (314) 303-2546 Office: (314) 450-5353 Fax: (314) 450-5354 The Usual Disclaimer follows... This e-mail and any documents accompanying it may contain legally privileged and/or confidential information belonging to Exegy, Inc. Such information may be protected from disclosure by law. The information is intended for use by only the addressee. If you are not the intended recipient, you are hereby notified that any disclosure or use of the information is strictly prohibited. If you have received this e-mail in error, please immediately contact the sender by e-mail or phone regarding instructions for return or destruction and do not use or disclose the content to others. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quick fix for LSI8888ELP overruns in 2.6.20 and 2.6.21-rc4
My local kernel guru recognized this problem as a duplicate of the
LSI8408E bus lockup problem. The controller gets flooded with work,
and just climbs under a rock to hide. In the 8408E case, it
froze the PCI-e bus :-)
#!/bin/csh
#
# set the max request queue down from 128. any more than 32
# quickly slows down from 810MB/Sec to 11MB/Sec.
#
setenv X 32
#
foreach i ( /sys/block/sd{g,h,i,j,k,l,m,n}/queue/nr_requests)
echo $X $i
end
Lots of time was spent in the congestion queue, like 99% of the time.
Berkley
This e-mail and any documents accompanying it may contain legally privileged
and/or confidential information belonging to Exegy, Inc. Such information may
be protected from disclosure by law. The information is intended for use by
only the addressee. If you are not the intended recipient, you are hereby
notified that any disclosure or use of the information is strictly prohibited.
If you have received this e-mail in error, please immediately contact the
sender by e-mail or phone regarding instructions for return or destruction and
do not use or disclose the content to others.
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Adaptec SC4100 AltEvo reports 64 bits of LUN - kernel panics (2.6.9-2.6.12)
I have an Adaptec 12 bay U320 scsi disk array. It is divided in this case into 2 sections of 6 drives each. Each string of drives reports a Processor on unit #15. Why would the scsi layer scan unit #15 for LUN's? it reports a HUGE number of LUN's, many times more than 511. 0x908789244a030402 LUNs in some cases. The scsi layer then attempts to ask each of these LUNS what it is doing, overruns the allocated space, and panics the kernel. This is independent of the controller. AIC79XX (39320A-R) or LSI Fusion (LSI22320) all see this device, duly report it to the scsi layer, which 75% of the time panics and then panics during the panic, or OOPSes and then panics in the OOPS. Mar 18 12:01:11 typhoon kernel: Vendor: ADAPTEC Model: AltEvo U320 Rev: 0028 Mar 18 12:01:11 typhoon kernel: Type: Processor ANSI SCSI revision: 03 If the reported LUN count is odd, don't bother scanning it. If the reported unit is NOT a disk, don't scan it. drivers/scsi/scsi_scan.c happily scans ALL the given units, and walks over itself. I used a redhat es4.0 base on an AMD64 dual opteron with vanilla 2.6.9 - 2.6.12-rc1, all will crash with this hardware being present. details are available via email. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
