It's a "bit fade" problem. I ran memtest86 all night. No errors as I expected. I've tried several times to locate the problem with memtest86 without success. I was hoping perhaps it had become severe enough for memtest86 to catch.
The commercial version has a fade test, but the delay between write and read is a few seconds. I need a fade test delay of at least 24 hours. If I can find a simple example of a program that loads and runs in real address mode on x86 I can write a fade test. I downloaded the memtest86 code, but have not looked at it yet. New, larger DIMMs are becoming increasingly attractive. For $150 I can double the memory with new Samsung DIMMs. As a practical matter, that is the correct solution. But I have this perverse enthusiasm for the technically proper solution of identifying the bad DIMM by running a test program. While it's annoying that X11 is not starting up properly because of some issue with SMF I don't yet understand, it's very impressive to have recovered the system from corrupted zfs pools with no loss of data. The corruption was apparently just in memory. Reg _______________________________________________ openindiana-discuss mailing list [email protected] https://openindiana.org/mailman/listinfo/openindiana-discuss
