From owner-freebsd-amd64@FreeBSD.ORG Thu Mar 31 01:54:36 2005 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9E5516A4CE; Thu, 31 Mar 2005 01:54:36 +0000 (GMT) Received: from blackwater.lemis.com (wantadilla.lemis.com [192.109.197.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61F3B43D41; Thu, 31 Mar 2005 01:54:33 +0000 (GMT) (envelope-from grog@lemis.com) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 5320B85689; Thu, 31 Mar 2005 11:24:29 +0930 (CST) Date: Thu, 31 Mar 2005 11:24:29 +0930 From: Greg 'groggy' Lehey To: Daniel O'Connor Message-ID: <20050331015429.GH6252@wantadilla.lemis.com> References: <20050330222439.GU84137@wantadilla.lemis.com> <20050330223546.GA4705@troutmask.apl.washington.edu> <20050330224445.GW84137@wantadilla.lemis.com> <200503311032.33718.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X0cz4bGbQuRbxrVl" Content-Disposition: inline In-Reply-To: <200503311032.33718.doconnor@gsoft.com.au> User-Agent: Mutt/1.4.2.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 cc: freebsd-stable@freebsd.org cc: FreeBSD-amd64@freebsd.org Subject: Re: Problems with AMD64 and 8 GB RAM? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2005 01:54:37 -0000 --X0cz4bGbQuRbxrVl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thursday, 31 March 2005 at 10:32:33 +0930, Daniel O'Connor wrote: > On Thu, 31 Mar 2005 08:14, Greg 'groggy' Lehey wrote: >>> Have you run sysutils/memtest86 with the 8 GB? >> >> Heh. Difficult when the system doesn't run. > > You could try http://www.memtest86.com although that doesn't do >4Gb :( I'm pretty sure it's not the memory. I've tried each pair individually, and it's only when they're both in there together that it's a problem. And yes, I've tried them in each pair of slots. I now have dmesg output for verbose boots with both 4 GB and 8 GB memory. The complete dmesg output is at http://www.lemis.com/grog/Images/20050331/dmesg.4GB and http://www.lemis.com/grog/Images/20050331/dmesg.8GB. The diffs are at http://www.lemis.com/grog/Images/20050331/dmesg.diff. Here's a truncated summary: > --- dmesg.4GB Thu Mar 31 10:47:16 2005 > +++ dmesg.8GB Thu Mar 31 10:52:32 2005 > @@ -64,6 +10,7 @@ > SMAP type=01 base=0000000000100000 len=00000000dfde0000 > SMAP type=03 base=00000000dfee3000 len=000000000000d000 > SMAP type=04 base=00000000dfee0000 len=0000000000003000 > +SMAP type=01 base=0000000100000000 len=0000000100000000 > Copyright (c) 1992-2005 The FreeBSD Project. > @@ -75,7 +22,7 @@ > Calibrating clock(s) ... i8254 clock: 1193283 Hz > CLK_USE_I8254_CALIBRATION not specified - using default frequency > Timecounter "i8254" frequency 1193182 Hz quality 0 > -Calibrating TSC clock ... TSC clock: 1603647337 Hz > +Calibrating TSC clock ... TSC clock: 1603647241 Hz > CPU: AMD Opteron(tm) Processor 242 (1603.65-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0xf5a Stepping = 10 > Features=0x78bfbff > @@ -90,11 +37,12 @@ > L2 4KB data TLB: 512 entries, 4-way associative > L2 4KB instruction TLB: 512 entries, 4-way associative > L2 unified cache: 1024 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative > -real memory = 3756916736 (3582 MB) > +real memory = 8589934592 (8192 MB) This is interesting in that it has gained 4.5 GB. > Physical memory chunk(s): > 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages) > -0x0000000000a05000 - 0x00000000d95b7fff, 3636146176 bytes (887731 pages) > -avail memory = 3623817216 (3455 MB) > +0x0000000000a09000 - 0x00000000dfedffff, 3746394112 bytes (914647 pages) > +0x0000000100000000 - 0x00000001f0fcffff, 4043112448 bytes (987088 pages) > +avail memory = 7777177600 (7416 MB) > ACPI APIC Table: > APIC ID: physical 0, logical 0:0 > APIC ID: physical 1, logical 0:1 > @@ -138,41 +86,12 @@ > ioapic0: intpin 9 trigger: level > ioapic0: intpin 9 polarity: low > lapic0: Routing NMI -> LINT1 > -A IRQ 3 (edge, high) > -ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) > -ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) > -ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) > -ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) > -ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) > -ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) > -ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) > -ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) > -ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) > -ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) > -ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) > -ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) > -ioapic0: intpin 16 -> PCI IRQ 16 (level, low) > -ioapic0: intpin 17 -> PCI IRQ 17 (level, low) > -ioapic0: intpin 18 -> PCI IRQ 18 (level, low) > -ioapic0: intpin 19 -> PCI IRQ 19 (level, low) > -ioapic0: intpin 20 -> PCI IRQ 20 (level, low) > -ioapic0: intpin 21 -> PCI IRQ 21 (level, low) > -ioapic0: intpin 22 -> PCI IRQ 22 (level, low) > -ioapic0: intpin 23 -> PCI IRQ 23 (level, low) > -MADT: Interrupt override: source 0, irq 2 > -ioapic0: Routing IRQ 0 -> intpin 2 > -ioapic0: intpin 2 trigger: edge > -ioapic0: intpin 2 polarity: high > -MADT: Interrupt override: source 9, irq 9 > -ioapic0: intpin 9 trigger: level > -ioapic0: intpin 9 polarity: low > -lapic0: Routing NMI -> LINT1 This stuff is puzzling. I suppose it could be related. Does anybody have any ideas? > lapic0: LINT1 trigger: edge > lapic0: LINT1 polarity: high > lapic1: Routing NMI -> LINT1 > lapic1: LINT1 trigger: edge > lapic1: LINT1 polarity: high > -ioapic0 irqs 0-23 on motherboard > +ioapic0 irqs 0-23 on motherboard > cpu0 BSP: > ID: 0x00000000 VER: 0x00040010 LDR: 0x01000000 DFR: 0x0fffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff The last lines in the 8 GB dmesg are: > bge0: mem 0xfa000000-0xfa00ffff irq 16 at device 11.0 on pci0 > bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfa000000 They're identical in each probe. Greg -- See complete headers for address and phone numbers. --X0cz4bGbQuRbxrVl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFCS1hVIubykFB6QiMRArcQAJ9GqhMKnFIjw1m6TcPkLFDNNQh6iACaAnUq KDp8Cg6RH7e8+/A0ShUTuv0= =5UnY -----END PGP SIGNATURE----- --X0cz4bGbQuRbxrVl--