linux-kernel - Re: [Fwd: Re: [PATCH 0/5]PCI: x86 MMCONFIG]

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 20 Dec 2007 11:16:03 -0700
From:	Matthew Wilcox <matthew@....cx>
To:	Tony Camuso <tcamuso@...hat.com>
Cc:	Greg KH <gregkh@...e.de>, linux-kernel@...r.kernel.org,
	linux-pci@...ey.karlin.mff.cuni.cz
Subject: Re: [Fwd: Re: [PATCH 0/5]PCI: x86 MMCONFIG]

On Thu, Dec 20, 2007 at 01:04:09PM -0500, Tony Camuso wrote:
> Sorry, that was the 82Q963/Q965 graphics controller, PCI ID 2992.
> 
> I can't remember why I thought PCI ID 2992 maps to 830M/MG. I think
> it was in some intel doc about the ICH8 or ICH9.
> 
> Nevertheless, I have an hp dc5700 microtower right here on the floor
> next to me, and it hangs when the bus sizing code does an mmconfig
> write to the BAR at offset 0x18 in this device (id 2992).

Oh, that's the same bug others (including me) have been complaining
about.

http://marc.info/?l=linux-kernel&m=118809338631160&w=2

> It hangs in exactly the same place every time.
> 
> I am surmising that the write to that BAR is causing a MCE.

Bad deduction.  What's happening is that the write to the BAR is causing
it to overlap the decode for mmconfig space.  So the mmconfig write to
set the BAR back never gets through.

I have a different idea to fix this problem.  Instead of writing
0xffffffff, we could look for an unused bit of space in the E820 map and
write, say, 0xdfffffff to the low 32-bits of a BAR.  Then it wouldn't
overlap, and we could find its size using MMCONFIG.

Does anyone know how Windows handles these machines?  Obviously, if it's
using MMCONFIG, it'd have the same problems.  Does it just use type 1
for initial sizing?  Or does it use type 1 for all accesses below 256
bytes?

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
--
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/