On Mar 31, 2005, at 12:27 AM, Scott Long wrote:
Jon Noack wrote:On 03/30/05 23:14, Greg 'groggy' Lehey wrote: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?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?
Jon
This is absolutely correct.
It might though. Notice the change in APIC version with 4GB of RAM vs 8GB. The APIC hardware is the same, so that's already indicative of something fishy going on. I think that his APIC address is correct though as otherwise no interrupts at all would work and it wouldn't claim to have 24 IRQs on the APIC in both cases. One can always boot an i386 non-PAE kernel with 8GB in the machine and get an acpidump though.
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
_______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
