Date: Thu, 24 Jul 2003 16:21:17 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: John Baldwin <jhb@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libthr/arch/alpha/alpha _curthread.c Message-ID: <20030724232117.GA1913@dhcp01.pn.xcllnt.net> In-Reply-To: <XFMail.20030724170013.jhb@FreeBSD.org> References: <20030724191943.GA1028@dhcp01.pn.xcllnt.net> <XFMail.20030724170013.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 24, 2003 at 05:00:13PM -0400, John Baldwin wrote: > > There is a chicken and egg problem. We use the unique value to > initialize the per-cpu pointer on kernel entry. We only have one > such beast, and in the kernel we cache it in a register that userland > gets to clobber (and frequently does). If you can think of a better > way to store the per-cpu pointer such that kernel entry can load it > into the register go for it. I see where the confusion is: > pcpup = (struct pcpu *) alpha_pal_rdval(); ^^^^^^^^^^^^^^^^^^^^^^ This is not the per-CPU unique value. I had to add alpha_pal_rdunique() in order to access it. In numbers: PAL_rdval = PAL_OSF1_rdval = 0x0032 PAL_rdunique = 0x009e PAL_rdval is a privileged operation PAL_rdunique isn't. There is no fundamental problem (although my alpha does reboot when I run a 1:1-threaded application, so there is a problem :-) -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030724232117.GA1913>