Bug 42786

Summary:	When booting with 32GB ram linux fails to find optimal mtrr when i915 (HD 3000) has 512 MB
Product:	Platform Specific/Hardware	Reporter:	Andrew Smith (andrew)
Component:	x86-64	Assignee:	platform_x86_64 (platform_x86_64)
Status:	NEW ---
Severity:	low	CC:	szg00000
Priority:	P1
Hardware:	All
OS:	Linux
URL:	https://bugs.launchpad.net/ubuntu/+source/linux/+bug/930007
Kernel Version:	v3.3-rc3	Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	DMESG DMESG-256 cat /proc/mtrr cat /proc/mtrr (256) lscvi-vnvn

Description Andrew Smith 2012-02-16 22:04:37 UTC

I have an ASUS P8Z68-V PRO, W/ BIOS 1101, 32GB of RAM and I am running Ubuntu precise 12.04.

In the BIOS you can set the amount of memory for the "iGPU", the HD3000 GPU built into my i7-2600K.

I just upgraded to 32GB of ram. Before the upgrade, I had this set to 512, had mtrr_spare_reg_nr=1 and everything worked fine. After the upgrade to 32GB of RAM: mtrr_cleanup: can not find optimal value, please specify mtrr_gran_size/mtrr_chunk_size etc. No matter what I set mtrr_spare_reg_nr to I got this error. However, I found that if I turned the amount of memory for the iGPU down to 256, everything works again.

I have found this to be the case even on the latest git pull, v3.3-rc3.

 Other notes, patches, fixes, workarounds: disabling "all memory to be remapped" in bios

Comment 1 Andrew Smith 2012-02-16 22:05:35 UTC

Created attachment 72414 [details]
DMESG

Comment 2 Andrew Smith 2012-02-16 22:05:54 UTC

Created attachment 72415 [details]
DMESG-256

Comment 3 Andrew Smith 2012-02-16 22:06:22 UTC

Created attachment 72416 [details]
cat /proc/mtrr

Comment 4 Andrew Smith 2012-02-16 22:06:52 UTC

Created attachment 72417 [details]
cat /proc/mtrr (256)

Comment 5 Andrew Smith 2012-02-16 22:09:44 UTC

Created attachment 72418 [details]
lscvi-vnvn

Comment 6 Andrew Morton 2012-02-16 22:11:27 UTC

hm, we really shouldn't have a MM/MTRR section here.  Oh well.

I recategorised it as x86_64, thanks.

Comment 7 Szőgyényi Gábor 2017-03-06 19:58:21 UTC

Please try this bug with latest kernel image.