Date: Thu, 31 Mar 2005 10:05:55 -0800 (PST) From: Michael Bernstein <mb_jobs@yahoo.com> To: freebsd-amd64@freebsd.org Subject: question about quantum computing with 64 bit Message-ID: <20050331180556.92368.qmail@web20026.mail.yahoo.com>
next in thread | raw e-mail | index | archive | help
Can FreeBSD 64 bit on parallel opterons as a core connected via gigabit cards with cross-over cables to other 64 AMD Athlon running FreeBSD and the right algorithm "make a quantum computing network". ?????? Would much RAM be required? and SCSI disks needed as well. Thanks. Mike --- freebsd-amd64-request@freebsd.org wrote: > From: freebsd-amd64-request@freebsd.org > Subject: freebsd-amd64 Digest, Vol 95, Issue 5 > To: freebsd-amd64@freebsd.org > Date: Thu, 31 Mar 2005 11:17:52 +0000 (GMT) > > Send freebsd-amd64 mailing list submissions to > freebsd-amd64@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, > visit > > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > or, via email, send a message with subject or body > 'help' to > freebsd-amd64-request@freebsd.org > > You can reach the person managing the list at > freebsd-amd64-owner@freebsd.org > > When replying, please edit your Subject line so it > is more specific > than "Re: Contents of freebsd-amd64 digest..." > > > Today's Topics: > > 1. Re: Problems with AMD64 and 8 GB RAM? (Peter > Wemm) > 2. Re: Problems with AMD64 and 8 GB RAM? (M. > Warner Losh) > 3. Re: Problems with AMD64 and 8 GB RAM? (Greg > 'groggy' Lehey) > 4. Re: Problems with AMD64 and 8 GB RAM? (Greg > 'groggy' Lehey) > 5. [OT] memtest86 (Was: Problems with AMD64 and 8 > GB RAM?) > (Mike Hunter) > 6. Re: Problems with AMD64 and 8 GB RAM? (Daniel > O'Connor) > 7. Re: Problems with AMD64 and 8 GB RAM? (Steve > Kargl) > 8. Re: Problems with AMD64 and 8 GB RAM? (Daniel > O'Connor) > 9. Re: Tyan k8sr lockups (Vivek Khera) > 10. Re: Problems with AMD64 and 8 GB RAM? (Greg > 'groggy' Lehey) > 11. Re: Problems with AMD64 and 8 GB RAM? (Daniel > O'Connor) > 12. Re: Problems with AMD64 and 8 GB RAM? > (Matthias Buelow) > 13. Re: Problems with AMD64 and 8 GB RAM? (Greg > 'groggy' Lehey) > 14. Re: Problems with AMD64 and 8 GB RAM? (John > Baldwin) > 15. Re: Problems with AMD64 and 8 GB RAM? (Greg > 'groggy' Lehey) > 16. Re: Problems with AMD64 and 8 GB RAM? (Scott > Long) > 17. Re: Problems with AMD64 and 8 GB RAM? (Greg > 'groggy' Lehey) > 18. Re: Problems with AMD64 and 8 GB RAM? (Jon > Noack) > 19. Re: Problems with AMD64 and 8 GB RAM? (Scott > Long) > 20. Re: Tyan k8sr lockups (Sven Willenberger) > 21. Re: Problems with AMD64 and 8 GB RAM? (Greg > 'groggy' Lehey) > 22. Re: Problems with AMD64 and 8 GB RAM? (Jon > Noack) > 23. Re: [OT] memtest86 (Was: Problems with AMD64 > and 8 GB RAM?) > (Damian Gerow) > 24. Re: Problems with AMD64 and 8 GB RAM? (Greg > 'groggy' Lehey) > 25. Re: Problems with AMD64 and 8 GB RAM? (Peter > Wemm) > 26. Re: Asus K8S-MX (Patrik Backlund) > 27. Re: Cross-compiling/porting to Linux (Ulrik > Guenther) > 28. AMD64 kernel config file question > (ray@redshift.com) > 29. Working and broken Linux ports on amd64 > (Michael Hopkins) > 30. Re: AMD64 kernel config file question (Marc > Olzheim) > 31. Re: Problems with AMD64 and 8 GB RAM? (Peter > Wemm) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 30 Mar 2005 15:27:28 -0800 > From: Peter Wemm <peter@wemm.org> > Subject: Re: Problems with AMD64 and 8 GB RAM? > To: freebsd-amd64@freebsd.org > Cc: AskBj?rn Hansen<ask@develooper.com> > Message-ID: <200503301527.28612.peter@wemm.org> > Content-Type: text/plain; charset="iso-8859-1" > > On Wednesday 30 March 2005 03:22 pm, Ask Bjørn > Hansen wrote: > > ...... Original Message ....... > > On Thu, 31 Mar 2005 08:14:45 +0930 "Greg 'groggy' > Lehey" > > <grog@FreeBSD.org> > > > > wrote: > > >> Have you run sysutils/memtest86 with the 8 GB? > > > > > >Heh. Difficult when the system doesn't run. > > > > There is a bootable ISO version of memtest86 that > you could try. > > Thats what the port does.. It produces a bootable > floppy or ISO. > > -- > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; > peter@yahoo-inc.com > "All of this is for nothing if we don't go to the > stars" - JMS/B5 > > ------------------------------ > > Message: 2 > Date: Wed, 30 Mar 2005 16:37:47 -0700 (MST) > From: "M. Warner Losh" <imp@bsdimp.com> > Subject: Re: Problems with AMD64 and 8 GB RAM? > To: grog@freebsd.org > Cc: freebsd-stable@freebsd.org > Message-ID: > <20050330.163747.105583958.imp@bsdimp.com> > Content-Type: Text/Plain; charset=us-ascii > > In message: > <20050330231753.GA84137@wantadilla.lemis.com> > "Greg 'groggy' Lehey" <grog@freebsd.org> > writes: > : I've booted with the other 2 DIMMs now (I have 4 2 > GB DIMMs, all the > : MB will hold). No problems. See my last reply to > Scott: I'm > : wondering if the system is ignoring the PCI hole. > > Unlikely. If it was, you'd not have enough of a > system to complain > about. > > Warner > > ------------------------------ > > Message: 3 > Date: Thu, 31 Mar 2005 09:08:23 +0930 > From: Greg 'groggy' Lehey <grog@FreeBSD.org> > Subject: Re: Problems with AMD64 and 8 GB RAM? > To: Scott Long <scottl@samsco.org> > Cc: FreeBSD Stable Users > <freebsd-stable@FreeBSD.org> > Message-ID: > <20050330233823.GA6252@wantadilla.lemis.com> > Content-Type: text/plain; charset="us-ascii" > > [Format recovered--see > http://www.lemis.com/email/email-format.html] > > [gratuitous empty lines removed] > > On Wednesday, 30 March 2005 at 16:23:34 -0700, Scott > Long wrote: > > Greg 'groggy' Lehey wrote: > >> On Wednesday, 30 March 2005 at 16:04:44 -0700, > Scott Long wrote: > >>> Greg 'groggy' Lehey wrote: > >>>> On Wednesday, 30 March 2005 at 15:30:37 -0700, > Scott Long wrote: > >>>>> Greg 'groggy' Lehey wrote: > >>>>>> I've recently acquired an AMD64 box ... > >>>>>> > >>>>>> What's unstable? ... The amd64 > 5.4-PRERELEASE kernel just > >>>>>> hangs/freezes. > >>>>> > >>>>> 5.3-RELEASE has a lot of problems with >4GB > due to busdma issues. > >>>>> Those should no longer be an issue in > RELENG_5, including 5.4-PRE. > >>>> > >>>> They appear to be. > >>> > >>> I don't understand what you mean here. > >> > >> As I said above (and trimmed for convenience), > this problem occurs on > >> 5.4-PRERELEASE as of yesterday morning. The > dmesg shows that too. > > > > And you're certain that it's due to the same > busdma issues that I > > was describing? > > No. > > > I must have missed the evidence that you use to > support this. > > I didn't give any. It appears that I misunderstood > what you were > saying. > > >>>> As I described, it doesn't appear to be the > drivers. > >>> > >>> I don't see how you proved or disproved this. > >> > >> Shall I resend the original message? It seems > independent of any > >> particular driver. That's not proof, of course, > but I didn't claim it > >> was. > > > > Again, I must have missed the part where you > investigated the drivers > > that apply to your particular system. > > The description is still there. > > > I highly doubt that they apply to every 8GB > Opteron system available > > on the market. > > I never suggested that they did. There's every > reason to believe that > it's something to do with this particular > motherboard, but that > doesn't mean that FreeBSD is blameless. > > Greg > -- > When replying to this message, please take care not > to mutilate the > original text. > For more information, see > http://www.lemis.com/email.html > See complete headers for address and phone numbers. > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 187 bytes > Desc: not available > Url : > http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20050331/ed6de15f/attachment-0001.bin > > ------------------------------ > > Message: 4 > Date: Thu, 31 Mar 2005 09:09:47 +0930 > From: Greg 'groggy' Lehey <grog@FreeBSD.org> > Subject: Re: Problems with AMD64 and 8 GB RAM? > To: Peter Wemm <peter@wemm.org> > Cc: FreeBSD Stable Users > <freebsd-stable@freebsd.org> > Message-ID: > <20050330233946.GB6252@wantadilla.lemis.com> > Content-Type: text/plain; charset="us-ascii" > > On Wednesday, 30 March 2005 at 15:25:37 -0800, Peter > Wemm wrote: > > On Wednesday 30 March 2005 03:09 pm, Greg 'groggy' > Lehey wrote: > >> On Wednesday, 30 March 2005 at 16:04:44 -0700, > Scott Long wrote: > >>> Greg 'groggy' Lehey wrote: > >>>> As I described, it doesn't appear to be the > drivers. > >>> > >>> I don't see how you proved or disproved this. > >> > >> Shall I resend the original message? It seems > independent of any > >> particular driver. That's not proof, of course, > but I didn't claim > >> it was. > > > > Greg: The busdma problems from 5.3-RELEASE are > fixed. That doesn't > > mean that there are no *other* problems. Scott is > saying "the old > > busdma bug shouldn't be affecting 5.4-PRE", and > he's correct. > > Yes, now I understand. > > > Most likely, something else is happening, eg: > you're running out of KVM > > or something silly like that. I know we're right > on the brink at 8GB. > > The layout of the devices may be just enough to > tip it over the edge. > > Yes, this seems reasonable. Where should I look > next? I'm currently > rebuilding world and will attempt a verbose boot via > serial console > when it's done. Anything else I should try? > > Greg > -- > See complete headers for address and phone numbers. > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 187 bytes > Desc: not available > Url : > http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20050331/0221a9f4/attachment-0001.bin > > ------------------------------ > > Message: 5 > Date: Wed, 30 Mar 2005 15:46:03 -0800 > From: Mike Hunter <mhunter@ack.Berkeley.EDU> > Subject: [OT] memtest86 (Was: Problems with AMD64 > and 8 GB RAM?) > To: Peter Wemm <peter@wemm.org> > Cc: Ask =?unknown-8bit?Q?Bj=F8rn?= Hansen > <ask@develooper.com> > Message-ID: > <20050330234603.GA18631@ack.Berkeley.EDU> > Content-Type: text/plain; charset=unknown-8bit > > On Mar 30, "Peter Wemm" wrote: > > > On Wednesday 30 March 2005 03:22 pm, Ask Bjørn > Hansen wrote: > > > ...... Original Message ....... > > > On Thu, 31 Mar 2005 08:14:45 +0930 "Greg > 'groggy' Lehey" > > > <grog@FreeBSD.org> > > > > > > wrote: > > > >> Have you run sysutils/memtest86 with the 8 > GB? > > > > > > > >Heh. Difficult when the system doesn't run. > > > > > > There is a bootable ISO version of memtest86 > that you could try. > > > > Thats what the port does.. It produces a bootable > floppy or ISO. > > This reminds me, I noticed that gentoo includes a > memtest86 "kernel" in > their install ISO. Would this be a hard feature to > include in FreeBSD? > > Mike > > ------------------------------ > > Message: 6 > Date: Thu, 31 Mar 2005 10:32:33 +0930 > From: "Daniel O'Connor" <doconnor@gsoft.com.au> > Subject: Re: Problems with AMD64 and 8 GB RAM? > To: freebsd-stable@freebsd.org > Cc: FreeBSD-amd64@freebsd.org > Message-ID: > <200503311032.33718.doconnor@gsoft.com.au> > Content-Type: text/plain; charset="utf-8" > > 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 :( > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 > DC20 7B3F CE8C > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 187 bytes > Desc: not available > Url : > http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20050331/b5b8ee65/attachment-0001.bin > > ------------------------------ > > Message: 7 > Date: Wed, 30 Mar 2005 17:10:10 -0800 > From: Steve Kargl <sgk@troutmask.apl.washington.edu> > Subject: Re: Problems with AMD64 and 8 GB RAM? > To: "Daniel O'Connor" <doconnor@gsoft.com.au> > Cc: freebsd-stable@freebsd.org > Message-ID: > <20050331011010.GA6151@troutmask.apl.washington.edu> > Content-Type: text/plain; charset=us-ascii > > On Thu, Mar 31, 2005 at 10:32:33AM +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 :( > > > > http://www.memtest.org/ > > -- > Steve > > ------------------------------ > > Message: 8 > Date: Thu, 31 Mar 2005 10:49:38 +0930 > From: "Daniel O'Connor" <doconnor@gsoft.com.au> > Subject: Re: Problems with AMD64 and 8 GB RAM? > To: Steve Kargl <sgk@troutmask.apl.washington.edu> > Cc: freebsd-stable@freebsd.org > Message-ID: > <200503311049.38443.doconnor@gsoft.com.au> > Content-Type: text/plain; charset="iso-8859-1" > > On Thu, 31 Mar 2005 10:40, Steve Kargl wrote: > > On Thu, Mar 31, 2005 at 10:32:33AM +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 :( > > > > http://www.memtest.org/ > > Ahh well there you go :) > Thanks! > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 > DC20 7B3F CE8C > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 187 bytes > Desc: not available > Url : > http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20050331/d52257da/attachment-0001.bin > > ------------------------------ > > Message: 9 > Date: Wed, 30 Mar 2005 20:22:52 -0500 > From: Vivek Khera <vivek@khera.org> > Subject: Re: Tyan k8sr lockups > To: freebsd-amd64@freebsd.org > Message-ID: > <97964ce32490a368d64fa9b3500a8ba6@khera.org> > Content-Type: text/plain; charset=US-ASCII; > format=flowed > > > On Mar 29, 2005, at 7:39 PM, Sten Spans wrote: > > > There was an amr panic related to the management > ioctls > > which was fixed and backported to RELENG_5. You > should have > > this fix. amr controllers a supported quite well > on freebsd > > thanks to Scott's great work. > > > > Yes, that was part of the reason I cvsup'd again > last week... to ensure > I had the latest fixes to the amr driver. > > > The only way to get closer to solving these > problems > > is to dig and try to narrow it down: > > > > - Have you tried running with debugging ? > > any more than having the kernel debugger installed? > When the box > locked up I couldn't even drop into the kernel > debugger from the serial > console. neither the BREAK signal nor the alt key > sequence invoked it. > > > > > - Have you tried using other network cards ? > > ( yeah that sucks I know ) > > Nope. Machine is brand spanking new. Was in > service a whole of 5 days > before it locked up. The twin of this machine also > has issues with the > BIOS reporting "memory size changed" while the > machine is running... so > I'm a bit concerned that there is some generic > problem with the K8SR > and a megaraid controller. But that one never had > any complaints about > the ethernet, and the memory size error persisted > across two > motherboards. > > I have yet to try the other ethernet port on this > box as well. > > > > > - Are you absolutely sure that all the disks are > working ? > > ( there have been reports of amr cards acting > strange with > > silently failing disks ) > > The megaraid bios showed all disks as active. How > would one tell if > you had a silently failing disk? :-( > > > - Have you got the ufs fixes recently backported > to releng_5 ? > > If it was prior to March 22, then yes I have them. > Where in cvsweb > might I look to test? > > > These are the first I can think of. RELENG_5 seems > to be > > a bit of a moving target with some quite critical > fixes > > going in ( which is good offcourse :). > > Yes, it is good.... until you can't figure out if it > is your hardware > or software flaking out on ya... > > Thanks so much for responding. > > For price-no-object, which vendor would you choose > for an AMD system > today? Same question if price is somewhat of a > concern. Thanks. > > > ------------------------------ > > Message: 10 > Date: Thu, 31 Mar 2005 11:24:29 +0930 > From: Greg 'groggy' Lehey <grog@FreeBSD.org> > Subject: Re: Problems with AMD64 and 8 GB RAM? > To: Daniel O'Connor <doconnor@gsoft.com.au> > Cc: freebsd-stable@freebsd.org > Message-ID: > <20050331015429.GH6252@wantadilla.lemis.com> > Content-Type: text/plain; charset="us-ascii" > > 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<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2> > > @@ -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: <VIAK8 AWRDACPI> > > 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 <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 > > The last lines in the 8 GB dmesg are: > > > bge0: <Broadcom BCM5705 Gigabit Ethernet, ASIC > rev. 0x3003> 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. > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 187 bytes > Desc: not available > Url : > http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20050331/ef36ee32/attachment-0001.bin > > ------------------------------ > > Message: 11 > Date: Thu, 31 Mar 2005 11:30:31 +0930 > From: "Daniel O'Connor" <doconnor@gsoft.com.au> > Subject: Re: Problems with AMD64 and 8 GB RAM? > To: "Greg 'groggy' Lehey" <grog@FreeBSD.org> > Cc: freebsd-stable@FreeBSD.org > Message-ID: > <200503311130.39539.doconnor@gsoft.com.au> > Content-Type: text/plain; charset="utf-8" > > On Thu, 31 Mar 2005 11:24, Greg 'groggy' Lehey > wrote: > > 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. > > Could be a marginal timing issue.. You could try > winding out the RAM timing > slightly. > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 > DC20 7B3F CE8C > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 187 bytes > Desc: not available > Url : > http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20050331/77399356/attachment-0001.bin > > ------------------------------ > > Message: 12 > Date: Thu, 31 Mar 2005 05:54:17 +0200 > From: Matthias Buelow <mkb@incubus.de> > Subject: Re: Problems with AMD64 and 8 GB RAM? > To: "Greg 'groggy' Lehey" <grog@freebsd.org> > Cc: Daniel O'Connor <doconnor@gsoft.com.au> > Message-ID: > <20050331035417.GD10394@drjekyll.mkbuelow.net> > Content-Type: text/plain; charset=us-ascii > > Greg 'groggy' Lehey wrote: > > >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'm sure you have checked this aswell but just for > completeness, > they aren't different pairs? Like one pair is > single-sided and the > other double-sided (had some nasty and obscure > problems with such > a combination myself)? > > mkb. > > > ------------------------------ > > Message: 13 > Date: Thu, 31 Mar 2005 12:56:43 +0930 > From: Greg 'groggy' Lehey <grog@FreeBSD.org> > Subject: Re: Problems with AMD64 and 8 GB RAM? > To: Matthias Buelow <mkb@incubus.de> > Cc: Daniel O'Connor <doconnor@gsoft.com.au> > Message-ID: > <20050331032643.GJ6252@wantadilla.lemis.com> > Content-Type: text/plain; charset="us-ascii" > > On Thursday, 31 March 2005 at 5:54:17 +0200, > Matthias Buelow wrote: > > Greg 'groggy' Lehey wrote: > > > >> 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'm sure you have checked this aswell but just for > completeness, > > they aren't different pairs? Like one pair is > single-sided and the > > other double-sided (had some nasty and obscure > problems with such > > a combination myself)? > > No, they're all the same. > > Greg > -- > See complete headers for address and phone numbers. > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 187 bytes > Desc: not available > Url : > http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20050331/d100ba50/attachment-0001.bin > > ------------------------------ > > Message: 14 > Date: Wed, 30 Mar 2005 23:01:03 -0500 > From: John Baldwin <jhb@FreeBSD.org> > Subject: Re: Problems with AMD64 and 8 GB RAM? > To: "Greg 'groggy' Lehey" <grog@FreeBSD.org> > Cc: Daniel O'Connor <doconnor@gsoft.com.au> > Message-ID: > <657eb6604d1e00368d77f047a8b5e074@FreeBSD.org> > Content-Type: text/plain; charset=US-ASCII; > format=flowed > > > 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). It would seem that the > system has mapped RAM > over top of the I/O APIC perhaps? 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. The local APIC portion seems ok though. > > -- > > John Baldwin <jhb@FreeBSD.org> <>< > http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve" = > http://www.FreeBSD.org > > > ------------------------------ > > Message: 15 > Date: Thu, 31 Mar 2005 13:38:11 +0930 > From: Greg 'groggy' Lehey <grog@FreeBSD.org> > Subject: Re: Problems with AMD64 and 8 GB RAM? > To: John Baldwin <jhb@FreeBSD.org> > Cc: Daniel O'Connor <doconnor@gsoft.com.au> > Message-ID: > <20050331040811.GL6252@wantadilla.lemis.com> > Content-Type: text/plain; charset="us-ascii" > > 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. > > > 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? > > Greg > -- > See complete headers for address and phone numbers. > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 187 bytes > Desc: not available > Url : > http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20050331/51140500/attachment-0001.bin > > ------------------------------ > > Message: 16 > Date: Wed, 30 Mar 2005 21:28:36 -0700 > From: Scott Long <scottl@samsco.org> > Subject: Re: Problems with AMD64 and 8 GB RAM? > To: "Greg 'groggy' Lehey" <grog@freebsd.org> > Cc: Daniel O'Connor <doconnor@gsoft.com.au> > Message-ID: <424B7C74.4060203@samsco.org> > Content-Type: text/plain; charset=us-ascii; > format=flowed > > 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. Your SMAP > table shows everything correctly. It's becoming > hard to break through > your pre-concieved notions here and explain how > things actually work. > > > > >>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 > > ------------------------------ > > Message: 17 > Date: Thu, 31 Mar 2005 14:44:58 +0930 > From: Greg 'groggy' Lehey <grog@FreeBSD.org> > Subject: Re: Problems with AMD64 and 8 GB RAM? > To: Scott Long <scottl@samsco.org> > Cc: Daniel O'Connor <doconnor@gsoft.com.au> > Message-ID: > <20050331051458.GM6252@wantadilla.lemis.com> > Content-Type: text/plain; charset="us-ascii" > > [gratuitous empty lines removed] > > 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? > > Greg > -- > See complete headers for address and phone numbers. > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 187 bytes > Desc: not available > Url : > http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20050331/3878297d/attachment-0001.bin > > ------------------------------ > > Message: 18 > Date: Wed, 30 Mar 2005 23:28:52 -0600 > From: Jon Noack <noackjr@alumni.rice.edu> > Subject: Re: Problems with AMD64 and 8 GB RAM? > To: "Greg 'groggy' Lehey" <grog@FreeBSD.org> > Cc: freebsd-stable@FreeBSD.org > Message-ID: <424B8A94.5070300@alumni.rice.edu> > Content-Type: text/plain; charset=ISO-8859-1; > format=flowed > > 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 > > ------------------------------ > > Message: 19 > Date: Wed, 30 Mar 2005 22:27:43 -0700 > From: Scott Long <scottl@samsco.org> > Subject: Re: Problems with AMD64 and 8 GB RAM? > To: noackjr@alumni.rice.edu > Cc: Greg 'groggy' Lehey <grog@FreeBSD.org> > Message-ID: <424B8A4F.7050607@samsco.org> > Content-Type: text/plain; charset=us-ascii; > format=flowed > > 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 > > ------------------------------ > > Message: 20 > Date: Thu, 31 Mar 2005 00:32:35 -0500 > From: Sven Willenberger <sven@dmv.com> > Subject: Re: Tyan k8sr lockups > To: Vivek Khera <vivek@khera.org> > Cc: freebsd-amd64@freebsd.org > Message-ID: <424B8B73.8040100@dmv.com> > Content-Type: text/plain; charset=ISO-8859-1; > format=flowed > > > > Vivek Khera presumably uttered the following on > 03/30/05 20:22: > > > > On Mar 29, 2005, at 7:39 PM, Sten Spans wrote: > > > >> There was an amr panic related to the management > ioctls > >> which was fixed and backported to RELENG_5. You > should have > >> this fix. amr controllers a supported quite well > on freebsd > >> thanks to Scott's great work. > >> > > > > Yes, that was part of the reason I cvsup'd again > last week... to ensure > > I had the latest fixes to the amr driver. > > > >> The only way to get closer to solving these > problems > >> is to dig and try to narrow it down: > >> > >> - Have you tried running with debugging ? > > > > > > any more than having the kernel debugger > installed? When the box locked > > up I couldn't even drop into the kernel debugger > from the serial > > console. neither the BREAK signal nor the alt key > sequence invoked it. > > > >> > >> - Have you tried using other network cards ? > >> ( yeah that sucks I know ) > > > > > > Nope. Machine is brand spanking new. Was in > service a whole of 5 days > > before it locked up. The twin of this machine > also has issues with the > > BIOS reporting "memory size changed" while the > machine is running... so > > I'm a bit concerned that there is some generic > problem with the K8SR and > > a megaraid controller. But that one never had any > complaints about the > > ethernet, and the memory size error persisted > across two motherboards. > > > > I have yet to try the other ethernet port on this > box as well. > > > >> > >> - Are you absolutely sure that all the disks are > working ? > >> ( there have been reports of amr cards acting > strange with > >> silently failing disks ) > > > > > > The megaraid bios showed all disks as active. How > would one tell if you > > had a silently failing disk? :-( > > > >> - Have you got the ufs fixes recently backported > to releng_5 ? > > > > > > If it was prior to March 22, then yes I have them. > Where in cvsweb > > might I look to test? > > > >> These are the first I can think of. RELENG_5 > seems to be > >> a bit of a moving target with some quite critical > fixes > >> going in ( which is good offcourse :). > > > > > > Yes, it is good.... until you can't figure out if > it is your hardware or > > software flaking out on ya... > > > > Thanks so much for responding. > > > > For price-no-object, which vendor would you choose > for an AMD system > > today? Same question if price is somewhat of a > concern. Thanks. > > > > For a piece of anecdotal evidence we are running a > dual opteron k8s pro > with 8GB of RAM and the 320-2x Megaraid controller > (which controls all > the harddrives) Except for a problem with fxp (which > I haven't gone back > to reinvestigate but rather just used the Broadcom > gigE instead) the > system so far has run fairly stable (running > Postgres under a medium > load at the moment). We had one issue of a > "spontaneous" reboot that > left no indication of what happened in messages; > this box is still in > our testing area so it is possible that it was the > result of a > power[cord] issue. This is running 5.4-PRERELEASE > from 17 March. Also, > we disabled the onboard adaptec controllers in the > bios (as we don't use > them). > > Sven > > ------------------------------ > > Message: 21 > Date: Thu, 31 Mar 2005 15:19:11 +0930 > From: Greg 'groggy' Lehey <grog@FreeBSD.org> > Subject: Re: Problems with AMD64 and 8 GB RAM? > To: Scott Long <scottl@samsco.org> > Cc: freebsd-stable@FreeBSD.org > Message-ID: > <20050331054911.GN6252@wantadilla.lemis.com> > Content-Type: text/plain; charset="us-ascii" > > On Wednesday, 30 March 2005 at 22:27:43 -0700, Scott > Long wrote: > > 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: > >>>>>> 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). > > Yes, this is correct. A number of people have > explained why it only > detected 3.5 GB in this configuration. > > >> 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? > > > > This is absolutely correct. > > Ah, so you meant to say that the output from the > system running with 4 > GB memory is useful? That wasn't in the man page > you pointed to. > What it does say is: > > > When invoked with the -t flag, the acpidump > utility dumps contents of > > the following tables: > > > > ... MADT > > This may be the case, but between man page and > output some terminology > must have changed. I can't see any reference to > anything like an MADT > there. Does that mean that there isn't one, or that > ACPI can't find > it, or does the section APIC refer to/dump the MADT? > Here's the > complete output of acpidump -t, anyway: > > /* > RSD PTR: OEM=VIAK8, ACPI_Rev=1.0x (0) > RSDT=0xdfee3000, cksum=97 > */ > /* > RSDT: Length=44, Revision=1, Checksum=4, > OEMID=VIAK8, OEM Table ID=AWRDACPI, OEM > Revision=0x42302e31, > Creator ID=AWRD, Creator Revision=0x0 > Entries={ 0xdfee3040, 0xdfee7b40 } > */ > /* > FACP: Length=116, Revision=1, Checksum=255, > OEMID=VIAK8, OEM Table ID=AWRDACPI, OEM > Revision=0x42302e31, > Creator ID=AWRD, Creator Revision=0x0 > FACS=0xdfee0000, DSDT=0xdfee30c0 > INT_MODEL=PIC > Preferred_PM_Profile=Unspecified (0) > SCI_INT=9 > SMI_CMD=0x402f, ACPI_ENABLE=0xa1, > ACPI_DISABLE=0xa0, S4BIOS_REQ=0x0 > PSTATE_CNT=0x0 > PM1a_EVT_BLK=0x4000-0x4003 > PM1a_CNT_BLK=0x4004-0x4005 > PM_TMR_BLK=0x4008-0x400b > GPE0_BLK=0x4020-0x4023 > P_LVL2_LAT=101 us, P_LVL3_LAT=1001 us > FLUSH_SIZE=0, FLUSH_STRIDE=0 > DUTY_OFFSET=0, DUTY_WIDTH=1 > DAY_ALRM=125, MON_ALRM=126, CENTURY=50 > IAPC_BOOT_ARCH= > > Flags={WBINVD,PROC_C1,SLP_BUTTON,RTC_S4,RESET_REG} > RESET_REG=0x00000000:0[0] (Memory), > RESET_VALUE=0x44 > */ > /* > FACS: Length=64, HwSig=0x00000000, > Firm_Wake_Vec=0x00000000 > Global_Lock= > Flags= > Version=0 > */ > /* > DSDT: Length=19020, Revision=1, Checksum=28, > OEMID=VIAK8, OEM Table ID=AWRDACPI, OEM > Revision=0x1000, > Creator ID=MSFT, Creator Revision=0x100000e > */ > /* > APIC: Length=104, Revision=1, Checksum=145, > OEMID=VIAK8, OEM Table ID=AWRDACPI, OEM > Revision=0x42302e31, > Creator ID=AWRD, Creator Revision=0x0 > Local APIC ADDR=0xfee00000 > Flags={PC-AT} > > Type=Local APIC > ACPI CPU=0 > Flags={ENABLED} > APIC ID=0 > > Type=Local APIC > ACPI CPU=1 > Flags={ENABLED} > APIC ID=1 > > Type=IO APIC > APIC ID=2 > INT BASE=0 > ADDR=0x00000000fec00000 > > Type=INT Override > BUS=0 > IRQ=0 > INTR=2 > Flags={Polarity=conforming, > Trigger=conforming} > > Type=INT Override > BUS=0 > IRQ=9 > INTR=9 > Flags={Polarity=active-lo, Trigger=level} > > Type=Local NMI > ACPI CPU=0 > LINT Pin=1 > Flags={Polarity=active-hi, Trigger=edge} > > Type=Local NMI > ACPI CPU=1 > LINT Pin=1 > Flags={Polarity=active-hi, Trigger=edge} > */ > > Since I don't know anything about ACPI, this doesn't > say too much to > me. Suggestions welcome. If the APIC section is > the MADT, it looks > as if we should update the docco. > > Greg > -- > See complete headers for address and phone numbers. > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 187 bytes > Desc: not available > Url : > http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20050331/3d97eaaa/attachment-0001.bin > > ------------------------------ > > Message: 22 > Date: Thu, 31 Mar 2005 00:00:22 -0600 > From: Jon Noack <noackjr@alumni.rice.edu> > Subject: Re: Problems with AMD64 and 8 GB RAM? > To: "Greg 'groggy' Lehey" <grog@FreeBSD.org> > Cc: freebsd-stable@FreeBSD.org > Message-ID: <424B91F6.4000400@alumni.rice.edu> > Content-Type: text/plain; charset=ISO-8859-1; > format=flowed > > On 03/30/05 23:49, Greg 'groggy' Lehey wrote: > > On Wednesday, 30 March 2005 at 22:27:43 -0700, > Scott Long wrote: > >>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: > >>>>>>>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). > > > > Yes, this is correct. A number of people have > explained why it only > > detected 3.5 GB in this configuration. > > > >>>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? > >> > >>This is absolutely correct. > > > > Ah, so you meant to say that the output from the > system running with 4 > > GB memory is useful? That wasn't in the man page > you pointed to. > > What it does say is: > > > >>When invoked with the -t flag, the acpidump > utility dumps contents of > >>the following tables: > >> > >>... MADT > > > > This may be the case, but between man page and > output some terminology > > must have changed. I can't see any reference to > anything like an MADT > > there. Does that mean that there isn't one, or > that ACPI can't find > > it, or does the section APIC refer to/dump the > MADT? Here's the > > complete output of acpidump -t, anyway: > > > > <snip acpidump output> > > > > Since I don't know anything about ACPI, this > doesn't say too much to > > me. Suggestions welcome. If the APIC section is > the MADT, it looks > > as if we should update the docco. > > My limited research (as in, Google) shows that the > MADT was defined as > part of ACPI 2.0: > http://www.microsoft.com/whdc/system/platform/64bit/IA64_ACPI.mspx > > According to your previous link the motherboard > specs, it supports both > ACPI 1.0A and 2.0. Perhaps there is a BIOS knob to > toggle between the two? > > Jon > > ------------------------------ > > Message: 23 > Date: Thu, 31 Mar 2005 01:15:28 -0500 > From: Damian Gerow <dgerow@afflictions.org> > Subject: Re: [OT] memtest86 (Was: Problems with > AMD64 and 8 GB RAM?) > To: freebsd-amd64@freebsd.org > Message-ID: <20050331061527.GF701@afflictions.org> > Content-Type: text/plain; charset=us-ascii > > Thus spake Mike Hunter (mhunter@ack.Berkeley.EDU) > [30/03/05 18:46]: > : This reminds me, I noticed that gentoo includes a > memtest86 "kernel" in > : their install ISO. Would this be a hard feature > to include in FreeBSD? > > In the case of AMD64, it'd be almost pointless. > I've not yet been able to > run a copy of memtest86 on my machine (though it > could have been due to > memory problems at the time). > > memtest86+[1] works great, though. It's a fork from > memtest86. > > [1] http://www.memtest.org/ > > ------------------------------ > > Message: 24 > Date: Thu, 31 Mar 2005 15:48:11 +0930 > From: Greg 'groggy' Lehey <grog@FreeBSD.org> > Subject: Re: Problems with AMD64 and 8 GB RAM? > To: Jon Noack <noackjr@alumni.rice.edu> > Cc: freebsd-stable@FreeBSD.org > Message-ID: > <20050331061811.GQ6252@wantadilla.lemis.com> > Content-Type: text/plain; charset="us-ascii" > > On Thursday, 31 March 2005 at 0:00:22 -0600, Jon > Noack wrote: > > On 03/30/05 23:49, Greg 'groggy' Lehey wrote: > >> Here's the complete output of acpidump -t, > anyway: > >> > >> <snip acpidump output> > >> > >> Since I don't know anything about ACPI, this > doesn't say too much to > >> me. Suggestions welcome. If the APIC section is > the MADT, it looks > >> as if we should update the docco. > > > > My limited research (as in, Google) shows that the > MADT was defined as > > part of ACPI 2.0: > > > http://www.microsoft.com/whdc/system/platform/64bit/IA64_ACPI.mspx > > Thanks for the link. > > > According to your previous link the motherboard > specs, it supports > > both ACPI 1.0A and 2.0. Perhaps there is a BIOS > knob to toggle > > between the two? > > I've taken a look, but I can't find anything. > > Greg > -- > See complete headers for address and phone numbers. > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 187 bytes > Desc: not available > Url : > http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20050331/bab59d62/attachment-0001.bin > > ------------------------------ > > Message: 25 > Date: Thu, 31 Mar 2005 00:30:56 -0800 > From: Peter Wemm <peter@wemm.org> > Subject: Re: Problems with AMD64 and 8 GB RAM? > To: freebsd-amd64@freebsd.org > Cc: freebsd-stable@freebsd.org > Message-ID: <200503310030.57519.peter@wemm.org> > Content-Type: text/plain; charset="iso-8859-1" > > On Wednesday 30 March 2005 09:49 pm, Greg 'groggy' > Lehey wrote: > > On Wednesday, 30 March 2005 at 22:27:43 -0700, > Scott Long wrote: > > > 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: > > >>>>>> 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). > > > > Yes, this is correct. A number of people have > explained why it only > > detected 3.5 GB in this configuration. > > > > You're also being confused by the implementation of > the 'real memory' report. > If you take a 30 second glance at the code, you'll > see that it is reporting > the same units that the hw.maxmem tunable uses. ie: > it is the LIMIT or > Highest Address that the system has, not the sum > total of all the parts. > > eg: see the machdep.c comment next to the printf > * Maxmem isn't the "maximum memory", it's > one larger than the > * highest page of the physical address > space. It should be > * called something like "Maxphyspage". We > may adjust this > * based on ``hw.physmem'' and the results > of the memory test. > > The SMAP lines are what you need to pay attention > to. In the output you > posted with 8G, you can see the 4GB going from the > 4->8GB range, exactly. > SMAP type 1 is "usable memory". > > -Peter > > ------------------------------ > > Message: 26 > Date: Thu, 31 Mar 2005 12:28:46 +0300 > From: Patrik Backlund <pbacklun@cc.hut.fi> > Subject: Re: Asus K8S-MX > To: freebsd-amd64@freebsd.org > Message-ID: <20050331092846.GA30291@backi.iki.fi> > Content-Type: text/plain; charset=iso-8859-1 > > On Wed, Feb 16, 2005 at 09:40:31AM -0800, David > O'Brien wrote: > > On Wed, Feb 16, 2005 at 11:44:18AM +0000, Joseph > Koshy wrote: > > > > There are also SiS and ALi based motherboards. > I haven't heard of any > > > > problems with them. > > > > > > I tried FreeBSD on an ASUS K8S-MX which is based > on the SiS > > > SiS760GX and 965L chipsets. Our ATA driver had > problems with > > > UDMA modes with the 965 chipset; it only worked > in PIO4 mode. > > > > Can you try ATA-mkIII? > > Otherwise can you report the issue to Soren? > > Søren has now committed the necessary device ids for > this board to work in > current. I've applied his ata patches to my RELENG_5 > and at least the SATA > part works just fine. > > See kern/70296 for a one line patch to get the > on-board sound working. > > -Patrik > > ------------------------------ > > Message: 27 > Date: Thu, 31 Mar 2005 12:16:29 +0200 > From: Ulrik Guenther <ulrik@00t.org> > Subject: Re: Cross-compiling/porting to Linux > To: Michael Hopkins > <michael.hopkins@hopkins-research.com> > Cc: "freebsd-amd64@freebsd.org" > <freebsd-amd64@freebsd.org> > Message-ID: <424BCDFD.8050701@00t.org> > Content-Type: text/plain; charset=ISO-8859-1; > format=flowed > > Hi Michael, > > the following commands have to be issued for correct > installation of the > packages: > mkdir /compat/linux > cd /compat/linux > tar xvpzf /somewhere/aaa_base-10.0.0-noarch-1.tgz > sh install/doinst.sh > rmdir dev home root tmp var/tmp > tar xvpzf /somewhere/aaa_elflibs-9.2.0-i486-1.tgz > sh install/doinst.sh > tar xvpzf /somewhere/glibc-solibs-2.3.2-i486-6.tgz > !!! sed -e 's,/sbin/ldconfig,/nonexistent,g' -e > 's,cp -a,cp -p,g' -i '' > install/doinst.sh > sh install/doinst.sh > tar xvpzf /somewhere/x11-6.7.0-i486-4.tgz > sh install/doinst.sh > echo '/usr/X11R6/lib' >etc/ld.so.conf > brandelf -t Linux sbin/ldconfig > sbin/ldconfig > > The sed command (before which I put the three !) is > of utmost > importance, otherwise one *will* get the error you > got. > If you have done all correctly, just try it again, > it's a bit tricky. > I already used this procedure on about three > installations (two i386 and > one amd64) and for me it works better than the > redhat rpms from the > ports. But I have to say that I had the same problem > like you once, I > think it was on the amd64 machine, I tried it again > and it worked very > well. Have you used Slackware 10 or 10.1 by the way? > > Have fun ;) > > Ulrik > Michael Hopkins wrote: > > Hmmm... > > > > All Linux commands fail with this :o{ > > > > root@Athlon /usr/compat/linux/usr/bin # ./gcc -v > > > > ELF interpreter /lib/ld-linux.so.2 not found > > Abort trap > > > > > > I wonder if this is to do with the error message I > got when running this at > > the end of section 2? > > > > sbin/ldconfig > > > > M > > > > > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > > > > _/ _/ _/_/_/ Hopkins > Research Ltd > > _/ _/ _/ _/ > > _/_/_/_/ _/_/_/ > http://www.hopkins-research.com/ > > _/ _/ _/ _/ > > _/ _/ _/ _/ 'touch the > future' > > > > > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > > > > > > > ------------------------------ > > Message: 28 > Date: Thu, 31 Mar 2005 03:04:34 -0800 > From: ray@redshift.com > Subject: AMD64 kernel config file question > To: freebsd-amd64@freebsd.org > Message-ID: > <3.0.1.32.20050331030434.00a8f798@pop.redshift.com> > Content-Type: text/plain; charset="us-ascii" > > Hi, > > I'm setting up FreeBSD 5.3 for the first time on > an Tyan dual opteron board. > I've done plenty of i386 installs, but this is the > first on AMD. Anyway, I'm > stripping down the kernel for a re-compile and I was > wondering if anyone either > had a sample config file they could send over and/or > if someone could let me > know what they are running for these lines? > > For the CPU/machine stuff, does this look okay (i.e. > is K8 the correct option > for the Opteron 246's?) > > machine amd64 > cpu K8 > ident AMD64 > > And for dual CPU's, I use this on i386 - is it the > same for AMD? > > # To make an SMP kernel, the next two are needed > options SMP # Symmetric > MultiProcessor Kernel > device apic # I/O APIC > > Thanks! > > Ray > > > ------------------------------ > > Message: 29 > Date: Thu, 31 Mar 2005 12:14:47 +0100 > From: Michael Hopkins > <michael.hopkins@hopkins-research.com> > Subject: Working and broken Linux ports on amd64 > To: "freebsd-amd64@freebsd.org" > <freebsd-amd64@freebsd.org>, > <freebsd-ports@freebsd.org>, > <freebsd-emulation@freebsd.org>, > <freebsd-ports-bugs@freebsd.org> > Message-ID: > <BE719A37.36B77%michael.hopkins@hopkins-research.com> > Content-Type: text/plain; charset="US-ASCII" > > > > Hi all > > I have been installing a few Linux environments from > the ports in the last > few days to try and establish a cross-compiler for > 32-bit Linux on amd64 > (see my other post for the story so far). > > I thought it might be useful for others on this path > to be told about what > works and what doesn't. System is: > > root@Athlon ~ # uname -a > FreeBSD Athlon 5.3-RELEASE-p5 FreeBSD 5.3-RELEASE-p5 > #2: Wed Mar 30 01:46:52 > BST 2005 root@Athlon:/usr/obj/usr/src/sys/ATHLON > amd64 > > > First steps > ----------- > First of all, I believe you need to do this as > pointed out by Axel Gonzalez. > > Add these to the kernel and rebuild: > > options LINPROCFS > options COMPAT_43 > options COMPAT_LINUX32 > > and on rc.conf: > > linux_enable="YES" > > > Working > ------- > linux_base-8 (redhat 8) > linux_base-suse (suse 9.2) > linux_base-debian (debian woody) > > All installed OK and gave correct answers to > /compat/linux/bin/uname -a > > > emulators/linux_base-gentoo-stage1 > ---------------------------------- > Starting Terminal in > /usr/ports/emulators/linux_base-gentoo-stage1... > > bash-2.05b# make > ===> linux_base-gentoo-stage1-2004.3 is marked as > broken: Incorrect > pkg-plist. > > > devel/linux_devtools-7 > ---------------------- > Starting Terminal in > /usr/ports/devel/linux_devtools-7... > > bash-2.05b# make > ===> linux_devtools-7.1_3 is marked as broken: > Incomplete pkg-plist. > > > emulators/linux_base-rh-9 > ------------------------- > Makes OK but fails on install with a message > something like "script error > for glibc-..." - sorry I didn't copy output so > that's from memory. > > > Slackware 10.1 > -------------- > I also followed the instructions from here to try > slackware which was > suggested by Ulrik Guenther > > http://people.freebsd.org/~tjr/linux32.html > > Unfortunately the install process didn't happen > exactly like on the page: > > # sbin/ldconfig > sbin/ldconfig: Can't open configuration file > /etc/ld.so.conf: No such file > or directory > > And all Linux commands gave this error: > > # ./gcc -v > ELF interpreter /lib/ld-linux.so.2 not found > Abort trap > > Ulrik has just sent me some more detailed > instructions, so I may give this > another go. > > mkdir /compat/linux > cd /compat/linux > tar xvpzf /somewhere/aaa_base-10.0.0-noarch-1.tgz > sh install/doinst.sh > rmdir dev home root tmp var/tmp > tar xvpzf /somewhere/aaa_elflibs-9.2.0-i486-1.tgz > sh install/doinst.sh > tar xvpzf /somewhere/glibc-solibs-2.3.2-i486-6.tgz > sed -e 's,/sbin/ldconfig,/nonexistent,g' -e 's,cp > -a,cp -p,g' -i '' > install/doinst.sh > sh install/doinst.sh > tar xvpzf /somewhere/x11-6.7.0-i486-4.tgz > sh install/doinst.sh > echo '/usr/X11R6/lib' >etc/ld.so.conf > brandelf -t Linux sbin/ldconfig > sbin/ldconfig > > > In general > ---------- > A lot of Linux ports are giving this message which I > suspect may not always > be appropriate: > > ...is only for i386, and you are running amd64. > > > hth > > Michael > > > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > > _/ _/ _/_/_/ Hopkins > Research Ltd > _/ _/ _/ _/ > _/_/_/_/ _/_/_/ > http://www.hopkins-research.com/ > _/ _/ _/ _/ > _/ _/ _/ _/ 'touch the > future' > > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > > > > ------------------------------ > > Message: 30 > Date: Thu, 31 Mar 2005 13:14:55 +0200 > From: Marc Olzheim <marcolz@stack.nl> > Subject: Re: AMD64 kernel config file question > To: ray@redshift.com > Cc: freebsd-amd64@freebsd.org > Message-ID: <20050331111455.GC34216@stack.nl> > Content-Type: text/plain; charset="us-ascii" > > On Thu, Mar 31, 2005 at 03:04:34AM -0800, > ray@redshift.com wrote: > > Hi, > > > > I'm setting up FreeBSD 5.3 for the first time on > an Tyan dual opteron board. > > I've done plenty of i386 installs, but this is the > first on AMD. Anyway, I'm > > stripping down the kernel for a re-compile and I > was wondering if anyone either > > had a sample config file they could send over > and/or if someone could let me > > know what they are running for these lines? > > See /usr/src/sys/amd64/conf/* (GENERIC for instance) > > Use "cpu HAMMER" > > Marc > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 187 bytes > Desc: not available > Url : > http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20050331/57577e4a/attachment.bin > > ------------------------------ > > Message: 31 > Date: Thu, 31 Mar 2005 00:30:56 -0800 > From: Peter Wemm <peter@wemm.org> > Subject: Re: Problems with AMD64 and 8 GB RAM? > To: freebsd-amd64@freebsd.org > Cc: freebsd-stable@freebsd.org > Message-ID: <200503310030.57519.peter@wemm.org> > Content-Type: text/plain; charset="iso-8859-1" > > On Wednesday 30 March 2005 09:49 pm, Greg 'groggy' > Lehey wrote: > > On Wednesday, 30 March 2005 at 22:27:43 -0700, > Scott Long wrote: > > > 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: > > >>>>>> 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). > > > > Yes, this is correct. A number of people have > explained why it only > > detected 3.5 GB in this configuration. > > > > You're also being confused by the implementation of > the 'real memory' report. > If you take a 30 second glance at the code, you'll > see that it is reporting > the same units that the hw.maxmem tunable uses. ie: > it is the LIMIT or > Highest Address that the system has, not the sum > total of all the parts. > > eg: see the machdep.c comment next to the printf > * Maxmem isn't the "maximum memory", it's > one larger than the > * highest page of the physical address > space. It should be > * called something like "Maxphyspage". We > may adjust this > * based on ``hw.physmem'' and the results > of the memory test. > > The SMAP lines are what you need to pay attention > to. In the output you > posted with 8G, you can see the 4GB going from the > 4->8GB range, exactly. > SMAP type 1 is "usable memory". > > -Peter > > ------------------------------ > > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to > "freebsd-amd64-unsubscribe@freebsd.org" > > > End of freebsd-amd64 Digest, Vol 95, Issue 5 > ******************************************** > __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050331180556.92368.qmail>