[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [microblaze-uclinux] kernel BUG at sched.c:687!



hi
 I had the same crash when I run "heavy" ethernet traffic with the smsc
driver. I was assuming this was a driver problem, but had got a chance
to get back to it. Does your crash happen under a heavy load?

gesmith


On Fri, 2006-02-17 at 09:08, Brettschneider Falk wrote:
> Hi,
> 
> as soon as I strip it down to a test case I don't hit the bad time frame
> anymore.
> The kernel is from middle of November 05, after you changed the entry.S
> stuff. I haven't seen changes in arch/microblaze/kernel after that. The file
> sched.c wasn't changed since ages.
> 
> Now I sometimes also see the output:
> kernel BUG at sched.c:562!
> 
> Furthermore I've seen crashes of the program and the last output was logging
> from a logically completely senseless function of my program, instead of
> switching the thread.
> 
> Cheers,
> F@lk
> 
> 
> > -----Original Message-----
> > From: owner-microblaze-uclinux@xxxxxxxxxxxxxx
> > [mailto:owner-microblaze-uclinux@xxxxxxxxxxxxxx]On Behalf Of John
> > Williams
> > Sent: Friday, February 17, 2006 9:02 AM
> > To: microblaze-uclinux@xxxxxxxxxxxxxx
> > Subject: Re: [microblaze-uclinux] kernel BUG at sched.c:687!
> > 
> > 
> > Hi Falk,
> > 
> > If you can produce a minimal test case that demonstrates the 
> > behaviour,
> > I'll take a look at it.  I realise this may be tricky, but 
> > isolating it
> > is half the battle, before fixing it.
> > 
> > I believe the platform context switch code to be correct.  There was a
> > bug fix that I checked in in Nov/Dec last year - I assume you are
> > running on latest kernel sources?
> > 
> > Regards,
> > 
> > John
> > 
> > Brettschneider Falk wrote:
> > > Hi,
> > > I have 4 pthreads with SCHED_RR and different priorities 
> > and when a certain
> > > thread is killed due a timeout, I sometimes get 
> > > 	kernel BUG at sched.c:687!
> > > and usually just a Linux crash. This all only happens if 
> > many context
> > > switches happen during the killing of that pthread. All 
> > threads heavily use
> > > mutexes, semaphores and 1 of them uses poll() to wait for 
> > events of a kernel
> > > driver.
> > > 
> > > Are you sure the microblaze's platform code for context 
> > switches is really
> > > OK?
> > > Otherwise I wish we used kernel 2.6.
> > > 
> > > Once I thought I worked around such scheduler problems by 
> > using pthread_join
> > > to catch a dying thread but now I often hit a time frame 
> > where that doesn't
> > > help either.
> > > 
> > > I've played around with some ideas for workaround for the 
> > last 5 days but
> > > now I'm stranded again. *sigh*
> > > 
> > > Cheers
> > > F@lk
> > > ___________________________
> > > microblaze-uclinux mailing list
> > > microblaze-uclinux@xxxxxxxxxxxxxx
> > > Project Home Page : 
> http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
> > Mailing List Archive :
> http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
> 
> ___________________________
> microblaze-uclinux mailing list
> microblaze-uclinux@xxxxxxxxxxxxxx
> Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
> Mailing List Archive :
> http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
> ___________________________
> microblaze-uclinux mailing list
> microblaze-uclinux@xxxxxxxxxxxxxx
> Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
> Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
-- 
George Smith
VP Engineering
Linear Acoustic, Inc

___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/