lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B60E946.4040903@kernel.org>
Date:	Wed, 27 Jan 2010 17:32:54 -0800
From:	Yinghai Lu <yinghai@...nel.org>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Bjorn Helgaas <bjorn.helgaas@...com>
CC:	Jeff Garrett <jeff@...rrett.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Kernel Testers List <kernel-testers@...r.kernel.org>,
	Linux PCI <linux-pci@...r.kernel.org>,
	Myron Stowe <myron.stowe@...com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

On 01/27/2010 01:02 PM, Jesse Barnes wrote:
> On Wed, 27 Jan 2010 12:59:05 -0800
> Jesse Barnes <jbarnes@...tuousgeek.org> wrote:
> 
>> On Wed, 27 Jan 2010 12:50:12 -0800 (PST)
>> Linus Torvalds <torvalds@...ux-foundation.org> wrote:
>>
>>>
>>>
>>> On Wed, 27 Jan 2010, Bjorn Helgaas wrote:
>>>>
>>>> Without intel_bus.c, we essentially assume config 1 all the time.
>>>> If we keep intel_bus.c and this patch for .33, things should work
>>>> for configs 1 and 4.  Adding support for config 4 is good.
>>>
>>> Quite frankly, is there any major downside to just disabling/removing 
>>> intel_bus.c for 2.6.33? If we're not planning on having it in the long run 
>>> anyway - or even if we are, but we can't be really happy about the state 
>>> of it as it would be in 2.6.33, not using it at all seems to be the 
>>> smaller headache.
>>>
>>> The machines that it helps are also the machines where you can fix things 
>>> up with 'use_csr', no? And they are pretty rare, and they didn't use to 
>>> work without that use_csr in 2.6.32 either, so it's not even a regression.
>>>
>>> Am I missing something?
>>
>> No that's the plan.  intel_bus.c was a good effort, but it's just too
>> different from what Windows does, and it'll always be behind.  We'll
>> disable it for 2.6.33 and try again to move to _CRS in 2.6.34 (but
>> fixing the problem with large numbers of _CRS resources this time).
> 
> Should say "disable it for 2.6.33 for all but multi-IOH configs", which
> seem to be fairly rare anyway, and were what intel_bus.c was designed
> to accommodate.  On the one machine that motivated it, use_crs was
> broken (though it likely isn't now), so it seems the safest route.

will try to produce one patch to handle subtract decoding for legacy IOH aka the one with ESI.

the structure could be something like amd_bus.c, need to do it early, but it need after pci_arch_init to get mmconf.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ