diff options
author | Linus Torvalds <torvalds@woody.linux-foundation.org> | 2007-12-27 21:21:36 -0800 |
---|---|---|
committer | Linus Torvalds <torvalds@woody.linux-foundation.org> | 2007-12-27 21:21:36 -0800 |
commit | ad7edfe0490877864dc0312e5f3315ea37fc4b3a (patch) | |
tree | 5d73689cca22b683866d8c77406aefc26dbf7f40 /block/as-iosched.c | |
parent | c68cb23dde29fb107575656effa46f7b9440ac04 (diff) | |
download | linux-stable-ad7edfe0490877864dc0312e5f3315ea37fc4b3a.tar.gz linux-stable-ad7edfe0490877864dc0312e5f3315ea37fc4b3a.tar.bz2 linux-stable-ad7edfe0490877864dc0312e5f3315ea37fc4b3a.zip |
[PCI] Do not enable CRS Software Visibility by default
It appears that some PCI-E bridges do the wrong thing in the presense of
CRS Software Visibility and MMCONFIG. In particular, it looks like an
ATI bridge (device ID 7936) will return 0001 in the vendor ID field of
any bridged devices indefinitely.
Not enabling CRS SV avoids the problem, and as we currently do not
really make good use of the feature anyway (we just time out rather than
do any threaded discovery as suggested by the CRS specs), we're better
off just not enabling it.
This should fix a slew of problem reports with random devices (generally
graphics adapters or fairly high-performance networking cards, since it
only affected PCI-E) not getting properly recognized on these AMD systems.
If we really want to use CRS-SV, we may end up eventually needing a
whitelist of systems where this should be enabled, along with some kind
of "pcibios_enable_crs()" query to call the system-specific code.
Suggested-by: Loic Prylli <loic@myri.com>
Tested-by: Kai Ruhnau <kai@tragetaschen.dyndns.org>
Cc: Matthew Wilcox <matthew@wil.cx>
Cc: Greg Kroah-Hartman <greg@kroah.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'block/as-iosched.c')
0 files changed, 0 insertions, 0 deletions