linux-kernel - Re: [Bug 11103] Can't use framebuffer or vesa Xorg with two memory modules

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: <49DFABCC.3070001@kernel.org>
Date:	Fri, 10 Apr 2009 13:27:56 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	bugzilla-daemon@...zilla.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-pci@...r.kernel.org
Subject: Re: [Bug 11103] Can't use framebuffer or vesa Xorg with two memory
 modules

bugzilla-daemon@...zilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=11103
> 
> 
> 
> 
> 
> --- Comment #16 from Yannick <yannick.roehlly@...e.fr>  2009-04-10 19:13:43 ---
> Created an attachment (id=20928)
>  --> (http://bugzilla.kernel.org/attachment.cgi?id=20928)
> Boot log (from dmesg) with "debug pci=earlydump" passed to kernel 2.6.29.1
> 
root cause:
when 4G installed.
BIOS put ACPI etc need the hole
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009bc00 (usable)
[    0.000000]  BIOS-e820: 000000000009bc00 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000e3000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 00000000bffa0000 (usable)
[    0.000000]  BIOS-e820: 00000000bffa0000 - 00000000bffae000 (ACPI data)
[    0.000000]  BIOS-e820: 00000000bffae000 - 00000000bfff0000 (ACPI NVS)
[    0.000000]  BIOS-e820: 00000000bfff0000 - 00000000c0000000 (reserved)
[    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
[    0.000000]  BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
so resource will be reserved for 0xbffa0000 - 0xbfff0000 for ACPI
0x100000 -  0xbffa0000 for RAM...

then BIOS set 
[    0.240007] pci 0000:00:01.0: bridge 64bit mmio pref: [0xbdf00000-0xddefffff]
[    0.237102] pci 0000:01:00.0: reg 10 32bit mmio: [0xc0000000-0xcfffffff]
that is conflict with reserved res.
so it can not be reserved Kernel.

then Kernel try to get range from 0x140000000 ( above the RAM, 5G and above 4g)
and set let the bridge to use it, and your ATI cards to use it.

but the problem is that your ATI only support 32bit ...

solution:
1. get updated BIOS?
2. kernel side:
a. reserved return one could use range ( shrinked range ), and set it back to pci bridge?
b. or add pci=earlyset like to hack the pci conf in early stage.

also in kernel side, we should not assign 64bit range to pci device that only take 32bit pref, it mess up the pci conf.

01:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 3400 Series (prog-if 00 [VGA controller])
	Subsystem: ASUSTeK Computer Inc. Device 19d3
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at 140000000 (32-bit, prefetchable) [size=256M]
	Region 1: I/O ports at 9000 [size=256]
	Region 2: Memory at fddf0000 (32-bit, non-prefetchable) [size=64K]
	Expansion ROM at fddc0000 [disabled] [size=128K]
..
00: 02 10 c4 95 07 01 10 00 00 00 00 03 08 00 00 00
10: 08 00 00 40 01 90 00 00 00 00 df fd 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 d3 19
30: 00 00 dc fd 50 00 00 00 00 00 00 00 0a 01 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 d3 19


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