libkse and SMP (was Re: USB bulk read & pthreads)

David Xu davidxu at freebsd.org
Thu May 22 17:03:58 PDT 2003


----- Original Message ----- 
From: "Julian Elischer" <julian at elischer.org>
To: "Dan Nelson" <dnelson at allantgroup.com>
Cc: <threads at freebsd.org>; "Daniel Eischen" <eischen at pcnet1.pcnet.com>; <davidxu at freebsd.org>
Sent: Friday, May 23, 2003 5:13 AM
Subject: Re: libkse and SMP (was Re: USB bulk read & pthreads)


> 
> 
> On Thu, 22 May 2003, Dan Nelson wrote:
> 
> > In the last episode (May 22), Dan Nelson said:
> > > In the last episode (May 22), Julian Elischer said:
> > > > AHA!
> > > > I've seen this panic from ksetest..
> > > > can you go to /usr/src/tools/KSE/ksetest
> > > > and 
> > > > make
> > > > ./ksetest
> > > > 
> > > > it may not do it the first time so let it run 10 seconds then kill
> > > > it with ^C and retry about 10 times..
> > > 
> > > It's not cooperating..  It hasn't crashed for me yet.  Sometimes it
> > > exits cleanly on its own immediately after starting (see below), but
> > > it's never caused a panic.  I'll try automating it by running it in a
> > > loop with a 2nd script running killall -9 ksetest every 10 seconds.
> > 
> > Ok, after an hour still no panics.  Should it really be exiting on its
> > own this often, though?
> > 
> > $ lastcomm ksetest | cut -c1-20 | sort | uniq -c
> > 
> >   75 ksetest          -
> >  366 ksetest          -X
> > 
> > The above proceses were generated by the following loops in two
> > different vtys:
> 
> no it's not supposed to stop.. I wonder why it does it..
> I have seen it a few ties on my system.. I'll try track it down..
> 
> 
> > 
> > while sleep 10 ; do killall -9 ksetest ; done
> > while : ; do ./ksetest; done
> >  
> Thanks..
> 
> it's almost as if after a system has seen this crash  few times
> it gets immune from it in some way..
> 
> my system has stopped doing it.. :-(
> 
> thanks for trying however..
> 
> 
It must be caused by an invalid thread pointer or some memory blocks belong
zoombie threads are corrupted,  but I don't know where it came from.
cpu_thread_clean only frees pcb_ext,  and it is just an i386 hardware I/O port
map page,  in normal case pcb_ext is zero, because we never access
hardware I/O port in ksetest.

> > -- 
> > Dan Nelson
> > dnelson at allantgroup.com
> > 
> 

Dvaid Xu



More information about the freebsd-threads mailing list