On Thu, 27 Dec 2007, Kai Ruhnau wrote:
> Linus Torvalds wrote:
> > On Thu, 27 Dec 2007, Linus Torvalds wrote:
> >
> >> Kai, can you try that? Just remove the call to pci_enable_crs() in
> >> pci_scan_bridge() in drivers/pci/probe.c, and see if mmconfig starts
> >> working for you?
> >>
> >
> > We could also make the error handling more permissive, and just check for
> > the low 16 bits, which is the part that the CRS spec mentions the actual
> > value for. The whole vendor ID of 0x0001 is mentioned int he CRS spec as
> > being explicitly chosen exactly because it's invalid.
> >
> > That said, given that we don't actually reap any benefits from CRS support
> > right now *anyway*, I think the right thing to do is disable it by
> > default. But it would be interesting to know if this patch makes it work
> > on those ATI bridges..
> >
> > Linus
> >
> > ---
> > drivers/pci/probe.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> > index 2f75d69..94cd3a4 100644
> > --- a/drivers/pci/probe.c
> > +++ b/drivers/pci/probe.c
> > @@ -908,7 +908,7 @@ pci_scan_device(struct pci_bus *bus, int devfn)
> > return NULL;
> >
> > /* Configuration request Retry Status */
> > - while (l == 0xffff0001) {
> > + while ((l & 0xffff) == 0x0001) {
> > msleep(delay);
> > delay *= 2;
> > if (pci_bus_read_config_dword(bus, devfn, PCI_VENDOR_ID, &l)
>
> That one did not work out so well.
> I reenabled the call to pci_enable_crs() and changed the line as above.
> That resulted in two timeouts (from dmesg):
>
> [....]
> ACPI: Interpreter enabled
> ACPI: (supports S0 S3 S4 S5)
> ACPI: Using IOACPI for interrupt routing
> ACPI: PCI Root Bridge [PCI0] (0000:00)
> Device 0000:01:00.0 not responding
> Device 0000:02:00.0 not responding
> [....]
>
> Then, the kernel boots up normally except of graphics and network card
> not showing up at all in lspci.
Uh, right. We already know that your northbridge, mmconfig, CRS, and this
device combine to always return 0001 for the Vendor ID. If we loop on
getting that, we must time out.
I'd actually bet that the hardware bug is actually that any device that
gives a CRS response the first time will have its Vendor ID appear as 0001
on subsequent mmconfig accesses, which means that it's actually a bus
quirk that probably only affects mmconfig access to something in the
conf1-visible space. The only per-device aspect would be that it uses CRS
(possibly correctly), and that doesn't mean that mmconfig won't be safe in
general for the device, or even that it won't be necessary. Actually, we
already know that per-driver enabling mmconfig is broken: sky2 is one that
wants to opt in but there are also reports of the Vendor ID 0001 bug with
it.
-Daniel
*This .sig left intentionally blank*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
