Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933623AbbDUVND (ORCPT ); Tue, 21 Apr 2015 17:13:03 -0400 Received: from mail-qk0-f172.google.com ([209.85.220.172]:35153 "EHLO mail-qk0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932603AbbDUVMz (ORCPT ); Tue, 21 Apr 2015 17:12:55 -0400 MIME-Version: 1.0 In-Reply-To: References: From: Bjorn Helgaas Date: Tue, 21 Apr 2015 16:12:34 -0500 Message-ID: Subject: Re: git pull] drm for v4.1-rc1 To: Linus Torvalds Cc: Dave Airlie , Daniel Vetter , Jani Nikula , DRI mailing list , Linux Kernel Mailing List , intel-gfx , "linux-pci@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2813 Lines: 64 On Tue, Apr 21, 2015 at 11:07 AM, Linus Torvalds wrote: > Hmm. The odd Intel PCI resource mess is back. > > Or maybe it never went away. > > I get these when suspending. Things *work*, but it's really spamming > my logs a fair bit: > > i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment > pci_bus 0000:01: Allocating resources > pci_bus 0000:02: Allocating resources > i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment > i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment > i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment > i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment > i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment > i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment > > That resource is complete garbage. "flags 0x2" is not even a valid > flag value. I'm *guessing* it might be IORESOURCE_ROM_SHADOW, but if > that is valid, then it should also have have had the IORESOURCE_MEM > bit, and it doesn't. > > (The low 8 bits of the resource flags depend on the high bits, which > is why I say that I'm "guessing" at that ROM_SHADOW bit. It could be > something else, like a IORESOURCE_MEM_CACHEABLE PnP bit - but that > should not show up for PCI, and "BAR 6" is normally the ROM resource, > so the ROM_SHADOW bit makes some sense. > > The only place that sets IORESOURCE_ROM_SHADOW that I find is the x86 > pci_fixup_video() function. That one checks for PCI_COMMAND_IO | > PCI_COMMAND_MEMORY in the PCI command word, though. Why are the other > bits not set? > > Both i915/dri people and PCI people on the Cc. This warning does *not* > happen at bootup, but only at suspend time. So my suspicion is that > somebody messes with the PCI ROM resource, and disables it or > something, but the IORESOURCE_ROM_SHADOW never gets cleared. And then > because res->flags is non-zero, the PCI scanning code doesn't ignore > the resource. > > Just before the whole bogus alignment check, the PCI code does > > if (!(r->flags) || r->parent) > continue; > > (don't ask me about the odd parenthesis) which *should* have > triggered, but that IORESOURCE_ROM_SHADOW bit screws things up. > > Anybody? I'll look into this. It's been around a long time, but hasn't percolated to the top of my list until now. https://bugzilla.kernel.org/show_bug.cgi?id=16063 says "echo 1 >/sys/bus/pci/rescan" is also a reproducer. Bjorn -- 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/