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. _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"