Date: Thu, 10 Jun 1999 14:47:01 -0400 From: Richard Cownie <tich@ma.ikos.com> To: Luoqi Chen <luoqi@watermarkgroup.com>, freebsd-current@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG, tich@ma.ikos.com Subject: Re: 4-way SMP broken ? Message-ID: <99061014582200.19512@par28.ma.ikos.com> References: <199906100001.UAA07014@lor.watermarkgroup.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 09 Jun 1999, Luoqi Chen wrote: > > I've been trying to install 19990604-CURRENT on a couple of SC450NX > > boxes. It works fine with 2 cpu's, but an SMP kernel with 4 cpu's > > falls over very quickly (I think while it's setting up the APIC > > stuff, or very shortly after - the messages about APIC bus ids appear > > on the screen very briefly, then the machine reboots itself). > > > Do you mean messages like these? > FreeBSD/SMP: Multiprocessor motherboard > cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfec08000 > cpu1 (AP): apic id: 12, version: 0x00040011, at 0xfec08000 > io0 (APIC): apic id: 13, version: 0x00170011, at 0xfec00000 > By the time you see these messages, all cpus should have been booted up > successfully, any crash immediately follows is not likely to be SMP related. > It's helpful to pinpoint the crash if you could include the last few lines > from a verbose boot. I have added more debugging messages, and the crash appears to be inside mp_start(). I don't have a log because this is too early in the boot to get the messages saved anywhere, and they go by too quickly to write it down. The evidence that this is an SMP problem is simple - with 2 cpu's plugged in, it works fine; with 3 or 4 cpu's plugged in, it crashes. I believe the hardware is fine because I was previously running 19990421-CURRENT with all 4 cpu's without serious problems (it was a little unstable, but always booted ok). > > Does anyone know a) when was the last time it worked on 4 cpu's > > b) what's changed recently which might relate to this. So if anyone has an answer to these questions I'd still be interested. > > Also in trying to figure this out I looked at the DRAM probing > > code in /usr/src/sys/i386/i386/machdep.c:getmemsize(), and it looks > > as though it's not safe for >2GB (e.g. comparisons of byte addresses > > against signed "int end"). It would also be good if this probing I've tried various hacks to this code, but have not succeeded in making it work for 4GB. Changing "int end" to "vm_offset_t end" is not sufficient. It has a tendency to say "Too many holes in address space" ... Even defining MAXMEM does not solve the problem. Richard Cownie (tich@ma.ikos.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99061014582200.19512>