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