linux-kernel - lots of "bridge window ... (disabled)" messages

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <4bb0dbec213331313b@agluck-desktop.sc.intel.com>
Date:	Mon, 29 Mar 2010 09:57:16 -0700
From:	"Luck, Tony" <tony.luck@...el.com>
To:	"Bjorn Helgaas" <bjorn.helgaas@...com>
Cc:	linux-kernel@...r.kernel.org
Subject: lots of "bridge window ... (disabled)" messages

Hi Bjorn,

I just booted Linus latest git tree on my Tukwila system. I'm
seeing a lot of bridge windows marked as disabled. Here's the
start of a diff of dmesg output comparing a kernel from last
week to today's kernel (git 01e7770 vs. b72c409):

< pci 0000:00:01.0:   bridge window [mem 0xfff00000 - 000fffff pref] reg reading
---
> pci 0000:00:01.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
222,224c222,224
< pci 0000:00:03.0:   bridge window [io  f000 - 0000] reg reading
< pci 0000:00:03.0:   bridge window [mem 0xfff00000 - 0x000fffff] reg reading
< pci 0000:00:03.0:   bridge window [mem 0xfff00000 - 000fffff pref] reg reading
---
> pci 0000:00:03.0:   bridge window [io  0xf000-0x0000] (disabled)
> pci 0000:00:03.0:   bridge window [mem 0xfff00000-0x000fffff] (disabled)
> pci 0000:00:03.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)
233c233
< pci 0000:00:05.0:   bridge window [mem 0xfff00000 - 000fffff pref] reg reading
---
> pci 0000:00:05.0:   bridge window [mem 0xfff00000-0x000fffff pref] (disabled)

   ... many more such diffs.

This is the same system that you helped out with a couple of months
ago that had some issues in _CRS tables with ranges marked as
"consumer".  The BIOS team fixed the one range that was needed
to allow access to my EHCI - but they didn't touch anything else.

Are these new checks related to the same sort of issues in _CRS?
Or is this some other stuff?  I don't appear to have lost access
to any devices in today's kernel.

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