Re: I'm rather embarrassed to even be asking this...
Jimmy Johnson wrote:
I manual says it detects the "type" of memory installed and it says with
ECC that it takes 25-40 seconds for video to start, I would say that is
the time needed to check RAM, so I would say that it is auto, 2-4 in the
manual.
Actually, it reads that it /may/ take 25-40 seconds for the VGA to
display. I read that as it might take that long, it might not.
That being said, while it does seem to take longer than most desktop
systems I've used that didn't have ECC and it does seem roughly
equivalent to the 4 gig Xeon system at work. However, without something
that shows that 'ECC is ON', as it were, I'm not going to know for sure,
and that kind of bugs me not knowing.
Upon doing more digging, I did find the edac-util package. This merry
chase led to the i$FOO_EDAC.ko modules, to which the 3200 chipset isn't
supported at this time.
Supposedly it's been submitted to Linus' tree, but it's not been
accepted yet.
So right now, as far as I can tell, I won't be able to see any ECC
errors, assuming it's working, in the syslogs at this time until that
drive is approved, put into the kernel, and backported to Lenny or
whatever kernel version is current at the time.
However, dmidecode has shown stuff such as this:
Handle 0x0011, DMI type 15, 29 bytes
System Event Log
Area Length: 16 bytes
Header Start Offset: 0x0000
Header Length: 16 bytes
Data Start Offset: 0x0010
Access Method: General-purpose non-volatile data functions
Access Address: 0x0000
Status: Valid, Not Full
Change Token: 0x0000000F
Header Format: Type 1
Supported Log Type Descriptors: 3
Descriptor 1: POST error
Data Format 1: POST results bitmap
Descriptor 2: Single-bit ECC memory error
Data Format 2: Multiple-event
Descriptor 3: Multi-bit ECC memory error
Data Format 3: Multiple-event
...as well as....
Handle 0x0012, DMI type 16, 15 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: None
Maximum Capacity: 8 GB
Error Information Handle: Not Provided
Number Of Devices: 4
...which compared to the previously mentioned Dell 2950 running Etch...
(System Event Log section above not found)
Handle 0x1000, DMI type 16, 15 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: Multi-bit ECC
Maximum Capacity: 32 GB
Error Information Handle: Not Provided
Number Of Devices: 8
This is why I asked and felt embarrassed asking, I figured that it would
be a fairly easy thing to find, especially considering the chipset isn't
all that new, but it's looking to be a bit more involved that I thought.
On one hand, there apparently isn't kernel support for edac
On the other, dmidecode shows that it appears there is some kind of ECC
going on, but at the same time it makes it look like there isn't.
So what the utils are showing might be caused by a lack of support from
kernel modules and other assorted internal databases that need to be
updated (for example, dmidecode reports the CPU Family as out of spec
and I'm running an 8400, and the bastille package doesn't support
Lenny), or the board just isn't running the ECC code like it should be.
I've shot a message off to SuperMicro's support address, I'll have to
see what they say as well, but if any one else has any ideas, I'm all ears.
Reply to: