Subject: Re: Hard lockups on 2.0_BETA when using python?
To: glen mccready <gkm+nb@petting-zoo.net>
From: Andrey Petrov <petrov@netbsd.org>
List: port-sparc
Date: 06/23/2004 14:42:14
On Wed, Jun 23, 2004 at 12:51:38PM -0700, glen mccready wrote:
> joachim wrote:
> > On Wednesday 23 June 2004 14:07, glen mccready wrote:
> > > does it look something like this panic? :-)
> > >
> > > http://mail-index.netbsd.org/port-sparc64/2004/02/26/0000.html
> > 
> > Not sure, I don't have a kernel with DDB handy; I'll build one and see what 
> > happens.  For now, I just did a little stress test - it seems that using 
> > (n)curses is needed for the crash - just btlaunchmany.py is not causing it, 
> > even with a compile running in the background.
> > 
> > I got (on the standard GENERIC kernel)
> > data fault: pc=0xd0193478 addr=0x0 sf
> > sr=126<PERR=0,LVL=1,AT=1,FT=1,FAV,OW>
> > panic: kernel fault
> > syncing disks...  (then nothing until I hit L1-A)
> 
> hm. for me it was just bittorrent on the ultra10 that panic'd
> things... i didn't need to have curses going... sometimes it
> happened quickly, sometimes it ran for hours... i'm not sure
> anybody ever ended up with a [quickly] reproducible case.
> 

I was unable to reproduce exact crash but I found that multithreaded python
core dumps on some of it's tests and from there it looks like python corrupts
stack pointer and crashes when kernel flushes register windows. I suspect
that under different (bittorrent) conditions it can lead to panic Glen experiences.

I have that PR on my task list, but not sure when ...

	Andrey