LSI/amr driver controller cache problem?
Doug Ambrisko
ambrisko at ambrisko.com
Thu Sep 7 10:09:16 PDT 2006
Patrick M. Hausen writes:
| > > Also, check the cache
| > > setting on the drives itself. Maybe the drives are loosing power or
| > > getting reset while data is in their cache.
| >
| > I'm starting to suspect something like this. The controller's setting
| > for the individual drives' caches is "OFF". But these (Seagate ST3500841NS)
| > would not be the first ATA/SATA drives to "lie" about their cache for
| > "performance".
|
| Seems like
|
| for i in 0 1 2 3 4 5
| do
| megarc -pSetCache -WCE0 -SaveCacheSetting -ch0 -id$i -a0
| done
|
| did the trick. This is supposed to disable the physical drives'
| write cache and save this setting in the drives' NVRAM, if supported.
|
| I don't know why simply setting the WC to "off" in the controller's
| BIOS setup tool didn't have the same effect. I'm keeping my fingers
| crossed ;-)
|
| Time to re-enable softupdates and do some more stress testing.
|
| Up to now the system survived two times "make installworld && reboot"
| after I changed the settings.
|
| Thanks to the guys keeping the amr driver up-to-date. The Linux
| "megamgr" utility works just fine. If I find the time, I'll make
| a port.
That would be great. I'd discourage the idea of MegaMon though since
it leaks shared memory and exits unless LSI has finally fixed it.
So monitoring is a pain. I guess a watcher script would be okay
but it has a nasty habit of reporting prior errors every time it
starts :-( We have a native local tool that works but we can't
re-distribute it.
The mfi driver doesn't have this issues since the driver reports all
events directly. However, MegaCli doesn't actually create or delete a
RAID (even with Linux). I have patches in the wings that deals with
discovery while the system is up but we need clearance on them.
Doug A.
More information about the freebsd-stable
mailing list