On Mon, 2007-08-06 at 14:00 +0100, Gavin Maltby wrote: > Could you try one more experiment, please. Leave the Solaris > /etc/system setting below to stop us enabling the scrubber, > but look for the BIOS option (if any) to enable dram scrubbing. > Note what it is set to before changing it, and then try > enabling the scrubber from there and see if the OS will run. > The BIOS option to enable dram scrubbing sometimes > hides within an option named something like > "ECC protection" which you can set from "none" to "good" > "better" etc - higher levels enable the scrubbers at higher > rates. > I've had a good look (the RBSU I'm using is version 2.10, BIOS "A05 03/01/2006") and the only settable options that look like they have anything to do with DRAM are "Enable Node Interleaving" and "Page Directory Cache". I doubt that these are anything to do with ECC protection, but I tried switching them on and off anyway, with the following results:
"Enable Node Interleaving": initially disabled, when turned on the operating system booted, but I got the following error message: "MPO disabled because memory is interleaved" "Page Directory Cache": initially enabled, when disabled the OS booted and ran for over 90 minutes, so appears to be ok. > If Solaris runs ok with the dram scrubber enabled via BIOS > (I think the hang will likely still occur) then this may be > a case of starting the scrubber incorrectly from Solaris. > Actually all we do is set it going at the node dram base > address, so there is little to get wrong! There doesn't appear to sufficiently many knobs to tweak on the G1 version of this hardware to force scrubbing on or off, alas. I'll run it with the advised /etc/system setting as this seems to work fine. Incidentally, this system needed a mainboard replacement the other week due to a crash whilst updating the onboard Smart Array firmware; both the original and replacement board exhibited the same behaviour, so I'm surprised this hasn't been a more commonly seen problem. Or maybe I'm just unlucky.. Anyway, thanks very much for your help. Chris _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org