linux-kernel - Re: [Linux 2.6.29-rc6] [drm:i915_set_status_page] *ERROR* can not ioremap virtual address for G33 hw status page

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:	Tue, 24 Feb 2009 22:39:07 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Yinghai Lu <yinghai@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
	"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>,
	Suresh Siddha <suresh.b.siddha@...el.com>,
	Arjan van de Ven <arjan@...radead.org>
Cc:	Andy Isaacson <adi@...apodia.org>,
	Maciej Rutecki <maciej.rutecki@...il.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Eric Anholt <eric@...olt.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	"lenb@...nel.org" <lenb@...nel.org>, mjg@...hat.com,
	Andrew Morton <akpm@...ux-foundation.org>, rui.zhang@...el.com,
	airlied@...hat.com
Subject: Re: [Linux 2.6.29-rc6] [drm:i915_set_status_page] *ERROR* can not
	ioremap virtual address for G33 hw status page


* Yinghai Lu <yinghai@...nel.org> wrote:

> Ingo Molnar wrote:
> > * Yinghai Lu <yinghai@...nel.org> wrote:
> > 
> >> On Mon, Feb 23, 2009 at 7:23 PM, Andy Isaacson <adi@...apodia.org> wrote:
> >>> On Mon, Feb 23, 2009 at 05:01:10PM -0800, Yinghai Lu wrote:
> >>>> CONFIG_MTRR=y
> >>>> CONFIG_MTRR_SANITIZER=y
> >>>> CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
> >>>> CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
> >>>>
> >>>> should help mtrr ones.
> >>>>
> >>>> please post bootlog with those option set.
> >>> Doesn't help here (Dell E6400).
> >>>
> >>> [    0.000000] Initializing cgroup subsys cpuset
> >>> [    0.000000] Initializing cgroup subsys cpu
> >>> [    0.000000] Linux version 2.6.29-rc6-dirty (adi@...-loaner-01) (gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu12) ) #14 SMP Mon Feb 23 19:05:31 PST 2009
> >>> [    0.000000] Command line: root=/dev/sda1 ro
> >>> [    0.000000] KERNEL supported cpus:
> >>> [    0.000000]   Intel GenuineIntel
> >>> [    0.000000]   AMD AuthenticAMD
> >>> [    0.000000]   Centaur CentaurHauls
> >>> [    0.000000] BIOS-provided physical RAM map:
> >>> [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
> >>> [    0.000000]  BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
> >>> [    0.000000]  BIOS-e820: 0000000000100000 - 000000007d04d400 (usable)
> >>> [    0.000000]  BIOS-e820: 000000007d04d400 - 000000007d04f400 (ACPI NVS)
> >>> [    0.000000]  BIOS-e820: 000000007d04f400 - 0000000080000000 (reserved)
> >>> [    0.000000]  BIOS-e820: 00000000f8000000 - 00000000fc000000 (reserved)
> >>> [    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
> >>> [    0.000000]  BIOS-e820: 00000000fed18000 - 00000000fed1c000 (reserved)
> >>> [    0.000000]  BIOS-e820: 00000000fed20000 - 00000000fed90000 (reserved)
> >>> [    0.000000]  BIOS-e820: 00000000feda0000 - 00000000feda6000 (reserved)
> >>> [    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee10000 (reserved)
> >>> [    0.000000]  BIOS-e820: 00000000ffe60000 - 0000000100000000 (reserved)
> >>> [    0.000000] DMI 2.4 present.
> >>> [    0.000000] last_pfn = 0x7d04d max_arch_pfn = 0x100000000
> >>> [    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
> >>> [    0.000000] original variable MTRRs
> >>> [    0.000000] reg 0, base: 0GB, range: 32GB, type WB
> >>> [    0.000000] reg 1, base: 3584MB, range: 512MB, type UC
> >>> [    0.000000] reg 2, base: 2012MB, range: 4MB, type UC
> >>> [    0.000000] reg 3, base: 2016MB, range: 32MB, type UC
> >> the BIOS is so sick
> >> according to MTRR, it said:
> >> [0,2012M) is WB
> >> [2048M, 3.5G) is WB too
> >> [4G, 32G) is WB
> >>
> >> but according to e820: about [0,2g) is RAM...
> >>
> >> really not how to workaround in BIOS.
> > 
> > I suspect the box was tested with other OSs and limped along 
> > there. Should we perhaps clear non-sensical MTRR entries?
> > 
> 
> according to e820 to update MTRR?
> 
> in the previous discussion, some SMI region that is not stated 
> in e820 could still need to be covered by MTRR with WB

Indeed. Nasty. Those tend to be in pretty specific places 
though, typically next to RAM. (they are taken off RAM usually) 
So if we leave the boundary around real e820 RAM alone, we could 
zap the other bogosities perhaps?

Dunno, removing MTRRs does indeed sound somewhat dangerous. A WB 
MTRR region could also be defined for some PCI card.

The other question is, why did the ioremap_wc() fail? Why doesnt 
it fall back to UC transparently?

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