Date: Fri, 06 Dec 1996 14:04:58 -0800 From: Erich Boleyn <erich@uruk.org> To: Peter Wemm <peter@spinner.dialix.com> Cc: smp@csn.net, smp@freebsd.org Subject: Re: P6 and FreeBSD/SMP (was -> Re: last major problem) Message-ID: <E0vW8OA-0008PE-00@uruk.org> In-Reply-To: Your message of "Sat, 07 Dec 1996 01:36:44 %2B0800." <199612061736.BAA18860@spinner.DIALix.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Wemm <peter@spinner.dialix.com> 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): <erich@uruk.org> Mad Genius wanna-be, CyberMuffin \__ (finger me for other stats) Web: http://www.uruk.org/~erich/ Motto: "I'll live forever or die trying"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E0vW8OA-0008PE-00>