2.6.19 - MCA in dmi_scan on an Orca

2.6.19 - MCA in dmi_scan on an Orca

[Karthik Gopalakrishnan]

Hi Folks.

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?

I am sorry if these questions were answered on another list. I will be
grateful if someone can point me to those posts.

Thanks & Regards,
Karthik

Re: 2.6.19 - MCA in dmi_scan on an Orca

[Bjorn Helgaas]

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