Re: Problems with AMD64 and 8 GB RAM?

From: Scott Long (scottl_at_samsco.org)
Date: 03/31/05

  • Next message: Karl Denninger: "Re: DANGER WILL ROBINSON! SERIOUS problem with current 5.4-PRERELEASE" 
    Date: Wed, 30 Mar 2005 22:27:43 -0700
To: noackjr@alumni.rice.edu

    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
    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"

  • Next message: Karl Denninger: "Re: DANGER WILL ROBINSON! SERIOUS problem with current 5.4-PRERELEASE"