Re: [PATCH v1 2/3] x86/PCI: trim _CRS windows when they conflictwith previous reservations

From: Kenji Kaneshige
Date: Wed Mar 17 2010 - 04:48:48 EST


Bjorn Helgaas wrote:
On Wed, 2010-03-17 at 12:25 +0900, Kenji Kaneshige wrote:
Bjorn Helgaas wrote:
Yanko's GA-MA78GM-S2H (BIOS F11) reports a host bridge window that overlaps
system memory:

PCI window: [mem 0xcff00000-0x10ed0ffff]
System RAM: [mem 0x100000000-0x22fffffff]

We can be pretty confident that the System RAM region is correct (if it
were wrong, we'd crash as soon as we tried to use any memory in that area),
so this patch tries to correct the PCI window by trimming it so it doesn't
conflict with any previous reservations.
Though I might misunderstand something, it looks Yanko's machine specific
workaround. I'm wondering if trimming _CRS is a generic workaround for
broken _CRS machine.

How about doing this when GA-MA78GM-S2H (BIOS F11) (and known machines
that have the same problem) is detected? Or how about switching nocrs
mode if the problem (resource conflict) is detected?

It's certainly a possibility to do this only for specific machines, but
I'd like to avoid tripping over issues one-by-one.

I think there are three ways to address BIOS _CRS defects:

1) Ship an OEM-specific host bridge driver
2) Put a platform- or BIOS-specific quirk into Windows

"into Linux"?

3) Change the BIOS

The first two sound like such a hassle to me that I doubt they would be
practical.

I agree.
For 1), we need OEM-specific driver, not chipset specific driver.

For 2), I thought it depends on how many machines with broken _CRS are
there, and I didn't think there are so many, but...


But it's clear that there are systems like this with what appear to be
_CRS defects. It's quite possible that it's not really a defect, and we
just don't understand how to parse _CRS correctly yet. Or, Windows
might have a few heuristics to clean up obvious errors.

Indeed, it might be true. Now I realize I need to change my opinion
about 2).


For example, I think Windows aligns host bridge windows, as documented
here: http://bugzilla.kernel.org/show_bug.cgi?id=14337

I think Windows also knows to ignore the Consumer/Producer bit in
Address Space Descriptors, and assume that all resources on bridges are
Producers.

Hmm, what we really need is a way to run Windows in a virtualized
environment where we could manipulate the _CRS method and see what
Windows does with it...

Anyway, I'd like to make Linux behave as much like Windows as possible
in this area so we can take advantage of all the testing that's done
with Windows.

Okey, thank you very much for explanation. I understood the background
of your change.

Thanks,
Kenji Kaneshige



--
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/