From owner-freebsd-smp Fri Dec 6 14:02:10 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA13190 for smp-outgoing; Fri, 6 Dec 1996 14:02:10 -0800 (PST) Received: from uruk.org (root@ns.uruk.org [198.145.95.253]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id OAA13183 for ; Fri, 6 Dec 1996 14:02:05 -0800 (PST) Received: from uruk.org [127.0.0.1] (erich) by uruk.org with esmtp (Exim 0.53 #1) id E0vW8OA-0008PE-00; Fri, 6 Dec 1996 14:04:58 -0800 To: Peter Wemm cc: smp@csn.net, smp@freebsd.org Subject: Re: P6 and FreeBSD/SMP (was -> Re: last major problem) In-reply-to: Your message of "Sat, 07 Dec 1996 01:36:44 +0800." <199612061736.BAA18860@spinner.DIALix.COM> Date: Fri, 06 Dec 1996 14:04:58 -0800 From: Erich Boleyn Message-Id: Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Peter Wemm writes: ... > > "kernel trap 12: supervisor read/write, page not present" break to > > the kernel debugger, going into pmap_enter. It is always that error > > (I think I've seen a "write" once, with it saying a "read" trap the > > other times). This implies that the answer to #2 is "no" (at least > > on my test box). I tried this about a dozen times, with the same > > results each time. > > Question: what are the offending faulting addresses? We use two PTD slots, > one for accessing the "current" process (addresses 0xefc00000-0xeffeffff), > and the other being for an "alternate" process or address space (range: > 0xffc00000 - 0xfffeffff). These 4MB chunks are a sparse end-to-end set > of page table pages representing the 4GB of process address space. I don't have many available offhand, but I do remember they were always in the second (0xffc00000 - 0xfffeffff) range you listed. The one I have offhand was at 0xffc00144, for "sh". I'll try generating some more tonight. Maybe a more complete look at the other parameters present too. > > -- If I don't activate the other CPUs, I can do a dozen builds in a raw > > with no problems. This implies the answwer to #1 is "yes". > > How does it go without SMP_INVLTLB BTW? Do you use a scsi or ide system? > I think we've pretty much discovered that the IDE driver is very vulnerable > to missing the invltlb calls on the alternate cpu's for some reason. My test system is on a SCSI disk (adaptec 2940 PCI, or more accurately a motherboard 7870 chip on a part of the PCI bus). I won't be able to test on IDE for a little while. I could test without SMP_INVLTLB, but I'm quite leery of simply shutting off the only way of propagating invalidates, which will probably cause as many problems as it solves (earlier on, I could never get kernel compiles to run very far anyway... many wierd things would happen, from segfaults to system hangs... I much prefer dropping into the kernel debugger where in theory I can look for something). > smp_invltlb() is called from the invltlb() function. When compiling > with SMP_INVLTLB, invltlb() is no longer inlined.. it's a called > function in mp_machdep.c > > Yes, this is extreme overkill, probably 90% of those calls to smp_invltlb() > are unnecessary.. They should not be harmful, but once it's working we can > optimise it quite a lot. Yes, I very much think getting it to work right in the first place is the most important thing. Question: is "smp_invltlb()" called from all the variants of "invltlb()", including the 1-page version? ...[my panic deleted]... > urk, sorry if I gave the impression that we were deliberately doing this.. > No, it was an *accident* that the early smp code did this, it worked fine > on the P5, but failed on the P6. I was thinking out aloud to the effect > of "Hmm, I wonder if there's somewhere else that this kind of thing is > happening that we're not aware of?". OK. Sorry about the panic here. You're saying this was already dealt with, so good enough. -- Erich Stefan Boleyn \_ E-mail (preferred): Mad Genius wanna-be, CyberMuffin \__ (finger me for other stats) Web: http://www.uruk.org/~erich/ Motto: "I'll live forever or die trying"