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]
Date:	Wed, 27 Jan 2010 15:34:49 -0800
From:	Yinghai Lu <yinghai@...nel.org>
To:	Bjorn Helgaas <bjorn.helgaas@...com>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	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:03 PM, Bjorn Helgaas wrote:
> On Wednesday 27 January 2010 01:50:12 pm Linus Torvalds 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?
> 
> Only that when we added intel_bus.c, Yinghai reported that the reason
> was because a machine had a broken _CRS, so "pci=use_crs" wouldn't help.
> 
> At the time, Windows hadn't been brought up on that box.  My
> speculation is that by now, they've done that bringup and probably
> fixed the _CRS issue, so it might work now.
> 
> If that's the case, we could drop intel_bus.c from .33 and just use
> "pci=use_crs" on those boxes until we can figure out how to turn it
> on automatically.

BIOS fixed that problem already. but
1. how to turn that pci=use_crs for that box automatically ?
how about our other kind of boxes?
2. how about when apci is disabled?

let's apply that patch at first, and wait for intel give us info about which bit is used to enable routing set up.

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