All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Yanko Kaneti <yaneti@declera.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Thomas Renninger <trenn@suse.de>,
	maciej.rutecki@gmail.com
Subject: Re: [PATCH v1 2/3] x86/PCI: trim _CRS windows when they conflict with	previous reservations
Date: Wed, 17 Mar 2010 17:47:54 +0900	[thread overview]
Message-ID: <4BA0973A.5070701@jp.fujitsu.com> (raw)
In-Reply-To: <1268799725.13147.29.camel@dc7800.home>

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




  reply	other threads:[~2010-03-17  8:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-12  0:01 [PATCH v1 0/3] [RFC] resource, PCI: work around pci=use_crs conflicts Bjorn Helgaas
2010-03-12  0:01 ` [PATCH v1 1/3] resources: add interfaces that return conflict information Bjorn Helgaas
2010-03-19 20:46   ` Jesse Barnes
2010-03-12  0:01 ` [PATCH v1 2/3] x86/PCI: trim _CRS windows when they conflict with previous reservations Bjorn Helgaas
2010-03-17  3:25   ` Kenji Kaneshige
2010-03-17  4:22     ` Bjorn Helgaas
2010-03-17  8:47       ` Kenji Kaneshige [this message]
2010-03-17 13:15         ` Bjorn Helgaas
2010-03-12  0:01 ` [PATCH v1 3/3] PCI: for address space collisions, show conflicting resource Bjorn Helgaas
2010-03-12 14:49 ` [PATCH v1 0/3] [RFC] resource, PCI: work around pci=use_crs conflicts Yanko Kaneti
2010-03-16 19:59 ` Bjorn Helgaas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BA0973A.5070701@jp.fujitsu.com \
    --to=kaneshige.kenji@jp.fujitsu.com \
    --cc=bjorn.helgaas@hp.com \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=maciej.rutecki@gmail.com \
    --cc=rjw@sisk.pl \
    --cc=torvalds@linux-foundation.org \
    --cc=trenn@suse.de \
    --cc=yaneti@declera.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.