linux-kernel - Re: git pull] drm for v4.1-rc1

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFyVMfTBB0oz_yx8+eQOEJnzGtCsYSj9QuhEpdZ9BHdq5A@mail.gmail.com>
Date:	Tue, 21 Apr 2015 09:07:45 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Dave Airlie <airlied@...ux.ie>,
	Daniel Vetter <daniel.vetter@...el.com>,
	Jani Nikula <jani.nikula@...ux.intel.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>
Cc:	DRI mailing list <dri-devel@...ts.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	intel-gfx <intel-gfx@...ts.freedesktop.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>
Subject: Re: git pull] drm for v4.1-rc1

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?

            Linus
--
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/