Re: [tip:x86/mce] x86, mce: Rename cpu_specific_poll to mce_cpu_specific_poll

From: Mauro Carvalho Chehab
Date: Wed Feb 24 2010 - 12:43:10 EST


Mauro Carvalho Chehab wrote:
> The EDAC data model needs some discussion, as, currently, the memory is represented
> per csrow, and modern MCU don't allow such level of control (and it doesn't
> make much sense on representing this way, as you can't replace a csrow). The
> better is to use DIMM as the minumum unit.

Just to start the data model, this is what a typical EDAC driver presents:

/sys/devices/system/edac/mc/mc0/
|-- ce_count
|-- ce_noinfo_count
|-- csrow0
| |-- ce_count
| |-- ch0_ce_count
| |-- ch0_dimm_label
| |-- ch1_ce_count
| |-- ch1_dimm_label
| |-- ch2_ce_count
| |-- ch2_dimm_label
| |-- ch3_ce_count
| |-- ch3_dimm_label
| |-- dev_type
| |-- edac_mode
| |-- mem_type
| |-- size_mb
| `-- ue_count
|-- csrow1
| |-- ce_count
| |-- ch0_ce_count
| |-- ch0_dimm_label
| |-- ch1_ce_count
| |-- ch1_dimm_label
| |-- ch2_ce_count
| |-- ch2_dimm_label
| |-- ch3_ce_count
| |-- ch3_dimm_label
| |-- dev_type
| |-- edac_mode
| |-- mem_type
| |-- size_mb
| `-- ue_count
|-- device -> ../../../../pci0000:3f/0000:3f:03.0
|-- mc_name
|-- reset_counters
|-- sdram_scrub_rate
|-- seconds_since_reset
|-- size_mb
|-- ue_count
`-- ue_noinfo_count

In the case of i7core_edac, there's no way to identify csrows by using
the public registers (I've no idea is is there any non-documented register
for it). So, the driver maps one dimm per "edac csrow".

It would be good to see a better struct for it.

With respect to error injection, this is the way i7core maps it:

|-- inject_addrmatch
| |-- bank
| |-- channel
| |-- col
| |-- dimm
| |-- page
| `-- rank
|-- inject_eccmask
|-- inject_enable
|-- inject_section
|-- inject_type

The inject_addrmatch leaves control a match filter for the error
where the error will be inject. I doubt we would find a way to standardize it.

Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/