linux-kernel - Re: Intel-Quad on GA-P35-S3 motherboard with 4*2GB

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]

Message-ID: <20070921153835.GJ5386@csclub.uwaterloo.ca>
Date:	Fri, 21 Sep 2007 11:38:35 -0400
From:	lsorense@...lub.uwaterloo.ca (Lennart Sorensen)
To:	Wojciech Kromer <wojciech.kromer@....com.pl>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Intel-Quad on GA-P35-S3 motherboard with 4*2GB

On Wed, Sep 19, 2007 at 11:28:16AM +0200, Wojciech Kromer wrote:
> a)With mem=8GB parameter I had:
> 
> #free -m
> total used free shared buffers cached
> Mem: 6473 474 5999 0 29 278
> 
> 
> b) Without mem=8GM system slows down while booting and sometimes restart...
> 
> 
> ==== So the story begins ===========================
> 
> It's strange GIGABYTE missinformation, but:
> - my board came with F2 release
> - after detecting memory problem, I've upgraded it to F4 (latest at this 
> moment)
> - next day came with F5 release ,
> there was only one info: "Fix PS2 keyboard compatibility issues",
> so I decided *not* to upgrade BIOS
> 
> But yesterday I've finally upgraded to F5 release.
> ... and here is *surrprise*: MTRR changed to:

Never ever trust the "changelog" of the BIOS release to contain all the
changes.  That would be admiting to having made mistakes after all. :)

> #cat /proc/mtrr
> reg00: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
> reg01: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
> reg02: base=0xa0000000 (2560MB), size= 512MB: uncachable, count=1
> reg03: base=0x100000000 (4096MB), size=4096MB: write-back, count=1
> reg04: base=0x200000000 (8192MB), size=2048MB: write-back, count=1
> reg05: base=0x260000000 (9728MB), size= 512MB: uncachable, count=1
> reg06: base=0x9ff00000 (2559MB), size= 1MB: write-through, count=1

Well they are in sane order now (the previous order was weird)  And they
don't do as much setting a range as one thing and then deleting small
pieces from it afterwards.

> Now there are no complains about MTRR in dmesg.
> 
> E820 seems to be the same:
> 
> BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
> BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 000000009fee0000 (usable)
> BIOS-e820: 000000009fee0000 - 000000009fee3000 (ACPI NVS)
> BIOS-e820: 000000009fee3000 - 000000009fef0000 (ACPI data)
> BIOS-e820: 000000009fef0000 - 000000009ff00000 (reserved)
> BIOS-e820: 00000000c0000000 - 00000000c4000000 (reserved)
> BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
> BIOS-e820: 0000000100000000 - 0000000260000000 (usable)

Well that part always did look sane.

> And finally I have my 8GB working without any kernel parameter,
> 
> # free -m
> total used free shared buffers cached
> Mem: 7988 1120 6868 0 88 612
> 
> Now i need to rerun memory tests.
> Thank you for helping me with this stuff.

Well now things look good.  Nice to know BIOS updates occationally fix
things, even if they don't admit to it.

--
Len Sorensen
-
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/