Date: Wed, 30 Mar 2005 22:27:43 -0700 From: Scott Long <scottl@samsco.org> To: noackjr@alumni.rice.edu Cc: FreeBSD-amd64@FreeBSD.org Subject: Re: Problems with AMD64 and 8 GB RAM? Message-ID: <424B8A4F.7050607@samsco.org> In-Reply-To: <424B8A94.5070300@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <Version 0.3> irqs 0-23 on motherboard >>>>>>> +ioapic0 <Version 0.0> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?424B8A4F.7050607>