From owner-freebsd-stable@FreeBSD.ORG Thu Mar 31 05:30:02 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 41F5516A4CF; Thu, 31 Mar 2005 05:30:02 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39A2343D41; Thu, 31 Mar 2005 05:29:57 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.21] (rat.samsco.home [192.168.254.21]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j2V5XX8W014716; Wed, 30 Mar 2005 22:33:33 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <424B8A4F.7050607@samsco.org> Date: Wed, 30 Mar 2005 22:27:43 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.5) Gecko/20050321 X-Accept-Language: en-us, en MIME-Version: 1.0 To: noackjr@alumni.rice.edu References: <20050330222439.GU84137@wantadilla.lemis.com> <20050330223546.GA4705@troutmask.apl.washington.edu> <20050330224445.GW84137@wantadilla.lemis.com> <200503311032.33718.doconnor@gsoft.com.au> <20050331015429.GH6252@wantadilla.lemis.com> <657eb6604d1e00368d77f047a8b5e074@FreeBSD.org> <20050331040811.GL6252@wantadilla.lemis.com> <424B7C74.4060203@samsco.org> <20050331051458.GM6252@wantadilla.lemis.com> <424B8A94.5070300@alumni.rice.edu> In-Reply-To: <424B8A94.5070300@alumni.rice.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: Greg 'groggy' Lehey cc: freebsd-stable@FreeBSD.org cc: John Baldwin cc: FreeBSD-amd64@FreeBSD.org Subject: Re: Problems with AMD64 and 8 GB RAM? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2005 05:30:02 -0000 Jon Noack wrote: > On 03/30/05 23:14, Greg 'groggy' Lehey wrote: > >> On Wednesday, 30 March 2005 at 21:28:36 -0700, Scott Long wrote: >> >>> Greg 'groggy' Lehey wrote: >>> >>>> On Wednesday, 30 March 2005 at 23:01:03 -0500, John Baldwin wrote: >>>> >>>>> On Mar 30, 2005, at 8:54 PM, Greg 'groggy' Lehey wrote: >>>>> >>>>>>> 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 >>>>> >>>>> >>>>> This shows that in the - case the APIC is broken somehow (0.0 isn't a >>>>> valid I/O APIC version). >>>> >>>> >>>> You mean the + case, I suppose. Yes, that's what I suspected. >>>> >>>> >>>>> It would seem that the system has mapped RAM over top of the I/O >>>>> APIC perhaps? >>>> >>>> >>>> That's what I suspected too, but imp doesn't think so. >>> >>> >>> I'd be more inclined to believe that there is an erroneous mapping >>> by the OS, not that things are fundamentally broken in hardware. >> >> >> Agreed. This has been my favourite hypothesis all along. But isn't >> that what jhb is saying? >> >>> Your SMAP table shows everything correctly. It's becoming hard to >>> break through your pre-concieved notions here and explain how things >>> actually work. >> >> >> No, there's nothing to break through. I think you're just having >> problems >> >> 1. expressing yourself, and >> 2. understanding what I'm saying. >> >> I have no preconceived notions. All I can see here is an antagonistic >> attitude on your part. What's the problem? You'll recall from my >> first message that I asked for suggestions about how to approach the >> issue. jhb provided some; you haven't so far. From what you've >> written, it's unclear whether you disagree with jhb or not. If you >> do, why? If you don't, what's your point here? >> >>>>> It would be interesting to see the contents of your MADT to see if >>>>> it's trying to use a 64-bit PA for your APIC. >>>> >>>> >>>> Any suggestions about how to do so? >>> >>> >>> man acpidump >> >> >> How do you run that on a system that won't boot? > > > You said the system worked with 4 GB (albeit detecting only 3.5 GB). My > perception of this whole ACPI thing is that it is fixed in your BIOS > (although it can be overridden by the OS). As such, the amount of RAM > you have in the machine shouldn't change acpidump results. Is that not > correct? > > Jon This is absolutely correct. Scott