lkml.org 
[lkml]   [2006]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [discuss] Re: 2.6.19-rc4: known unfixed regressions (v3)
On 11/8/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Wed, 8 Nov 2006, Adrian Bunk wrote:
> > >
> > > Anyway, I do not consider this a regression. MMCONFIG has _never_ worked
> > > reliably. It has always been a case of "we can make it work on some
> > > machines by making it break on others".
> >
> > It is a serious regression:
> >
> > The problem is that with the default CONFIG_PCI_GOANY, MMCONFIG is the
> > _first_ method tried.
>
> No. That was a bug at some point, but it's not that way now. See
>
> pci_access_init(void)
>
> which checks the pci_direct_probe() first, and only _then_ calls
> pci_mmcfg_init(). And pci_mmcfg_init() will refuse to even use MMCONFIG
> unless either the direct probe failed _or_ the MMCONFIG area is marked
> entirely reserved in the e820 tables. Exactly because MMCONFIG generally
> doesn't _work_.
>

It appears in both i386 and x86-64 that the check is only on the first MCFG
entry and it only checks a hard-coded value of 16 buses. This check is only
done if pci access type == 1. The patches I posted yesterday have a few more
checks and warnings concerning the MCFG region, but these checks are only for
the resource allocation. They do not concern actual config access. With those
patches applied we should be at least able to track more buggy BIOS's provided
that people notice messages in their dmesg.

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

\
 
 \ /
  Last update: 2006-11-08 19:21    [W:0.094 / U:0.420 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site