Re: 2.6.19 - MCA in dmi_scan on an Orca

[Bjorn Helgaas <bjorn.helgaas@hp.com>]

On Monday 12 February 2007 12:34, Karthik Gopalakrishnan wrote:
> When I booted 2.6.19 on an IA Superdome (Orca), the kernel caused an
> MCA around the "dmi_scan" function. When I set "CONFIG_DMI = n", it
> was automatically set back to "y" during the build. I had to
> workaround the problem by commenting out
> "core_initcall(run_dmi_scan)". On doing so, the MCA went away.
> 
> So, my questions are:
> 1. Does the Orca actually have a DMI Interconnect, or is the Kernel
> detecting it wrongly?
> 2. Is there a cleaner way to disable DMI in such situations?

How much memory is in your Superdome?  If you have "only" 2GB of
memory, you might be running into this issue:  In such a partition,
firmware puts the SMBIOS table in a granule that is not fully-
populated by WB memory, so the kernel maps the SMBIOS table with
a UC mapping.  But Superdome doesn't support UC accesses to memory,
so you get an MCA.

We really ought to just fail the mapping attempt, but the kernel
isn't smart enough to do that yet.  And I hate to have this special
case where machines with 2GB or less or memory can't read the SMBIOS
table, while larger-memory machines can.  So we just decided to make
those "small-memory" configs unsupported.

If you collect the address of the SMBIOS table and compare it with
the output of "memmap" from the EFI shell, you should be able to
tell whether this is the problem.  The SMBIOS table needs to live
in a 16MB (or 64MB, depending on whether you set CONFIG_IA64_GRANULE_16MB
or CONFIG_IA64_GRANULE_64MB) granule that is fully-populated with
WB memory.

Bjorn