Date: Thu, 7 Oct 2004 11:26:02 -0400 From: John Baldwin <jhb@FreeBSD.org> To: freebsd-sparc64@FreeBSD.org Cc: freebsd-threads@FreeBSD.org Subject: Re: Bug in kse_switchin()? Message-ID: <200410071126.02612.jhb@FreeBSD.org> In-Reply-To: <20041006201849.GC21875@electra.cse.Buffalo.EDU> References: <Pine.GSO.4.43.0409220743460.857-100000@sea.ntplx.net> <20041006031406.GB26037@electra.cse.Buffalo.EDU> <20041006201849.GC21875@electra.cse.Buffalo.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 06 October 2004 04:18 pm, Ken Smith wrote:
> On Tue, Oct 05, 2004 at 11:14:06PM -0400, Ken Smith wrote:
> > On Thu, Sep 23, 2004 at 02:20:51PM +0400, Andrew Belashov wrote:
> > > Where bug?
> > > - In sparc64 specific core?
> > > - In kern/kern_kse.c and kern/kern_thr.c code?
> >
> > Can you humor me and test this patch please?
> >
> > Index: sys/conf/kern.pre.mk
> > ===================================================================
> > RCS file: /home/ncvs/src/sys/conf/kern.pre.mk,v
> > retrieving revision 1.57
> > diff -u -r1.57 kern.pre.mk
> > --- sys/conf/kern.pre.mk 23 Sep 2004 22:53:22 -0000 1.57
> > +++ sys/conf/kern.pre.mk 6 Oct 2004 03:09:09 -0000
> > @@ -24,7 +24,7 @@
> > . elif ${MACHINE_ARCH} == "ia64"
> > COPTFLAGS?=-O2 -pipe
> > . elif ${MACHINE_ARCH} == "sparc64"
> > -COPTFLAGS?=-O2 -pipe
> > +COPTFLAGS?=-O -pipe
> > . elif ${MACHINE_ARCH} == "arm"
> > COPTFLAGS?=-O2 -pipe
> > . else
> >
> > You'll need to go through a complete kernel build cycle after applying
> > it (starting with 'config').
>
> FYI...
>
> While working on adding a KASSERT() to some other code last week I
> had tripped across what appeared to be a section of code where the
> addition of the KASSERT() was "position sensitive". It was in the
> sparc64/sparc64/rwindow.c file, in code that's mucking around with
> register windows so admittedly that's somewhat special code. But
> a few people I asked including jake and jhb didn't see any obvious
> reason for where the KASSERT() went being position sensitive. In
> the "bad case" the result was corruption of processes, most of
> what the system tried to run during boot-up died. And if I shifted
> the kernel compile to use -O instead of -O2 with no other changes
> at all the resulting kernel didn't have the process corruption issues.
>
> Between Andrew's report above and a few other things (John reports
> his kernels built from custom config files instead of GENERIC fail
> to run) I decided to go ahead with shifting to -O instead of -O2
> in HEAD now. Under normal circumstances I would have been more
> patient and asked for more input/testing here before making that
> sort of change but I want to be in a position I would be allowed
> to MFC this change for RC1 if it does turn out this fixes even
> just a few of the problems that seem to be floating around. If
> it turns out to be a false alarm I won't MFC it.
FWIW, -O didn't help me to compile a custom kernel. I get a page fault very
early due to running out of UMA preallocated pages I think. I have no idea
why though.
--
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200410071126.02612.jhb>