Date: Mon, 02 Sep 1996 16:27:37 -0600 From: Steve Passe <smp@csn.net> To: Terry Lambert <terry@lambert.org> Cc: freebsd-smp@FreeBSD.ORG, rv@groa.uct.ac.za, erich@uruk.org Subject: Re: SMP on Intel MG15 Message-ID: <199609022227.QAA07488@clem.systemsix.com> In-Reply-To: Your message of "Mon, 02 Sep 1996 14:36:26 PDT." <199609022136.OAA03128@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, again, answering 2 messages: =========================================================================== #1: >The evil motherboard that has the problems doesn't have an 82489DX, right? >And it is running a local APIC of version 1.x or higher, right? correct , and correct >In 1.1 compliant mode, I would expect the STARTUP IPI method to work >on the board, without any change to the Warm Reset vector, or use of >the INIT IPI. Clearly this fails. very clearly, but we just got the 2nd CPU to run to the point where it spins on "kern.smp_active == 2". this was accomplished by setting the warmstart vector to point @ the boot code (bootMP), doing the INIT/RESET IPI, AND then going on to do the STARTUP IPI. note that having the warmstart vector point to a HLT instruction had NO effect. it would appear that this machine NEEDS (as erich said, thanx erich!) the INIT/RESET IPI, AND that vector must actually run the boot code, AND it looks like it might even ignore the following STARTUP IPI!!! >I might be misunderstanding the 1.1 specification, but I don't think so As I said b4, the 1.4 document contradicts itself in several places, so I wouldn't take everything in the 1.1 document as gospel. =========================================================================== #2: >I think you can HALT everything, and do it one at a time with different >"VV" values for the 000VV000h real mode start address as part of the >STARTUP IPI with various VV's as vector. > >This would mean chopping the heck out of the first meg of memory, but >it *is* possible to do (assuming the damn thing listens to the STARTUP >IPI like it is supposed to for version 1.x or higher local APIC's). > >I envision something like: > >000VV00h: ... > ... > HLT > >Where you then modify the actual code, and startup per CPU ID using the >IPI method, to blow the bits. > >This would let you get to the INIT IPI method, as necessary (not that I >like doing things that way, but it *is* conceptually possible to do it). as I stated in the previous answer, this is essentually what I attempted to do, but it doesn't seem to work (too early to say who is not doing the right thing). my immediate goal is to get past the lockup when the second CPU is allowed to run via the sysctl! specifically what we get is: the 2nd CPU runs the boot code then waits for the sysctl. the 2nd CPU sees kern.smp_active == 2 and calls cpu_switch(curproc); the system wedges tight. Russel suggests that it is because the 2nd CPU's ID is 2, NOT 1, and this might cause the lockup. I believe he is correct, the ID is probably being used as an index into some array(s) somewhere (manywheres?). Russel and I are off chasing the source now. stay tuned... -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609022227.QAA07488>