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

[Ingo Molnar]

* Yinghai Lu <yinghai@xxxxxxxxxx> wrote:

> Ingo Molnar wrote:
> > * Yinghai Lu <yinghai@xxxxxxxxxx> wrote:
> > 
> >> On Mon, Feb 23, 2009 at 7:23 PM, Andy Isaacson <adi@xxxxxxxxxxxxx> 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@cvp-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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/