Date: Thu, 26 Sep 1996 15:01:51 -0600 From: Steve Passe <smp@csn.net> To: garyh@agora.rdrop.com (Gary Hanson) Cc: freebsd-smp@FreeBSD.org Subject: Re: mptable results for IBM 704 (dual PPro) Message-ID: <199609262101.PAA28605@clem.systemsix.com> In-Reply-To: Your message of "Thu, 26 Sep 1996 09:26:58 PDT." <m0v6JH8-000927C@agora.rdrop.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, > Enclosed is the long (and mostly boring) output of mptable.c on a 2 boring to you perhaps, but quite useful to me. > processor IBM 704 system (Orion B0 chipset). This is with the system set > to MPS 1.1; with MPS 1.4, the system repeats mostly the same things > over-and-over-and-over, 89K worth. I think that is because EBDA support in mptable is 'broken'. I'm assumming that the 1.1 spec doesn't deal will EBDA (or at least the implimentors of this BIOS chose to ignore EBDA when emulating 1.1, but use it for 1.4). Unfortunately Intel doesn't post the 1.1 spec anymore. If someone has an archive copy please email it to me. The 'broken-ness' of the program is that I couldn't seem to access the EBDA pointer @ 40:e0h (0x04e0) from /dev/kmem. If someone will tell me the trick to this I will fix this bug. > > If I send the mptable output to a file, I get "Warning: EBDA support is > BROKEN!!!" on the screen, but I don't seem to see that without > redirecting stdout. that line goes to stderr, the rest to stdout. I'm guessing it just scrolls by so fast it gets lost in the second (non-redirected) case. > Found MP Table in BIOS, physical addr: 0x000f78c0 > ... > version: 1.1 > checksum: 0xb0 > OEM ID: 'INTEL ' > Product ID: 'ALDER ' > ... > local APIC address: 0xfec08000 > ... > -- > Processor > apic ID: 0, version: 17 > CPU is usable, CPU is the bootstrap processor > ... > -- > Processor > apic ID: 1, version: 17 > CPU is usable, CPU is NOT the bootstrap processor > ... > I/O APIC > apic ID: 14, version: 17 > APIC is usable > apic address: 0xfec00000 from the above we see that the CPU APIC numbering will not break the current SMP kernel, ie boot CPU == 0, 2nd CPU == 1. But they chose to relocate the CPU APIC address from the standard address (0xfee0000) to 0xfec08000 as erich predicted. This will break the current SMP kernel. I am currently working on this problem and expect to be finished with it today. It turned out to be harder that I predicted previously because of a "chicken and egg" problem. Out of curiousity, have you ever attempted to run the FreeBSD SMP kernel on this hardware? If so, with what results? -- Steve Passe | powered by smp@csn.net | FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609262101.PAA28605>