Date: Thu, 19 Jul 2001 12:11:10 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: John Baldwin <jhb@FreeBSD.ORG> Cc: <alpha@FreeBSD.ORG> Subject: RE: multiple cpus on an 8200... Message-ID: <20010719120433.D50024-100000@wonky.feral.com> In-Reply-To: <XFMail.010719115943.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > second CPU even though SRM said it was present and availabele... > > Yuck. > > > 2. I came up, and it released it: > > > > release_aps: releasing secondary CPUs > > SMP: AP CPU #9 Launched! > > > > and I got to a login prompt... but very strangely the system locks up briefly > > and then runs okay again. It's quite bizaare. One has to wonder whether or > > not > > there are some implicit assumptions in the code in places about CPUId. > > > > It also might in fact be an efficiency issue. We're using PAL calls for > > interprocessor interrupts. That *might* be less efficient than using some h/w > > specific mechanisms for IPIs. Oh- actually, now that I think about it- I > > might > > not have enabled IPIs for the CPUs, which means, heh, that IPIs might only be > > sampled. Yick... I'll go check... > > If IPI's are sampled, then that would explain the hang, as the vm system uses > rendezvous to invalidate mappings, and in a rendezvous we wait for all CPU's to > ack the rendezvous before performing the action and returning. I assume you > mean enabling IPI's in a hardware specific sense in SRM or some such? > No, actually there's a TLSB register bit for this: #define TLINTRMASK0 0x1100 /* C: Interrupt Mask Register CPU 0 */ #define TLINTRMASK1 0x1140 /* C: Interrupt Mask Register CPU 1 */ .... /* * CPU Interrupt Mask Register * * The PAL code reads this register for each CPU on a TLSB CPU board * to see what is or isn't enabled. */ #define TLINTRMASK_CONHALT 0x100 /* Enable ^P Halt */ #define TLINTRMASK_HALT 0x080 /* Enable Halt */ #define TLINTRMASK_CLOCK 0x040 /* Enable Clock Interrupts */ #define TLINTRMASK_XCALL 0x020 /* Enable Interprocessor Interrupts */ #define TLINTRMASK_IPL17 0x010 /* Enable IPL 17 Interrupts */ #define TLINTRMASK_IPL16 0x008 /* Enable IPL 16 Interrupts */ #define TLINTRMASK_IPL15 0x004 /* Enable IPL 15 Interrupts */ #define TLINTRMASK_IPL14 0x002 /* Enable IPL 14 Interrupts */ #define TLINTRMASK_DUART 0x001 /* Enable GBUS Duart0 Interrupts */ It turns out that the XCALL (IPI) is enabled on both CPUs on jules: TLINTRMASK0 1ff TLINTRMASK1 fe That is, CPU0 has ^P halt set, while CPU1 doesn't have GBUS zs interrupts set. Interestingly enough, both have clock interrupts enabled- I might try fixing that. It's wierd- I had left jules booting yesterday- I was able to log in and run everything up until a ps (see below), whereupon it hangs for a while. -matt --------------------------- ... ---------------------------------------------------------------------- You have new mail. jules# jules# jules# jules# jules# ls .bash_history .cshrc .history .login .be-ok .forward .klogin .profile jules# df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0a 2965910 935498 1793140 34% / devfs 1 1 0 100% /dev procfs 8 8 0 100% /proc sun520:/export/home 41300003 2574027 38312976 6% /home evermeet:/space/distfiles 15352737 7577990 6546529 54% /usr/ports/distfiles evermeet:/space/devel/tstsys 15352737 7577990 6546529 54% /tstsys evermeet:/space/devel/src 15352737 7577990 6546529 54% /usr/src evermeet:/space/FreeBSD-CVS 15352737 7577990 6546529 54% /home/ncvs jules:/var/compile 2965910 935498 1793140 34% /tstsys/alpha/compile jules# sync jules# jules# jules# jules# ls .bash_history .cshrc .history .login .be-ok .forward .klogin .profile jules# ps ax ---------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010719120433.D50024-100000>