Bug in kse_switchin()?

[Ken Smith]

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.

Andrew, I'm particularly interested in whether or not it has an
effect on what you reported given the symptoms you were seeing
seem to be very similar - no explanation for what was going wrong
given the code that's involved.

-- 
						Ken Smith
- From there to here, from here to      |       kensmith at cse.buffalo.edu
  there, funny things are everywhere.   |
                      - Theodore Geisel |