lkml.org 
[lkml]   [1999]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Linux-2.2.2-pre2..
From
Date
Alexander Viro <viro@math.psu.edu> writes:

> On 6 Feb 1999, Philippe Troin wrote:
>
> > Rebooted, ran them on the console.
> > Got a really bad oops, the log was garbled, the only thing I could
> > note down was EIP, which translates to:
> >
> > 0xc01115d2 is in del_timer (sched.c:475).
> > 470 static inline int detach_timer(struct timer_list *timer)
> > 471 {
> > 472 struct timer_list *prev = timer->prev;
> > 473 if (prev) {
> > 474 struct timer_list *next = timer->next;
> > 475 prev->next = next;
> > 476 if (next)
> > 477 next->prev = prev;
> > 478 return 1;
> > 479 }
> >
> > ...which is rather unusable.
> >
> > Methinks there's still a problem, and just checking for tty->termios
> > to be non-null fixes one symptom.
> >
> > Are these 'dev (03:00) tty->count(0) != #fd's(2) in do_tty_hangup'
> > and 'null tty in fasync' really harmless ?
>
> It means that either you've got a struct file leak or something is playing
> bad games with filp->private_data. In theory it may be any other subsystem
> using the same field. IIRC tty code more or less blindly assumes that
> meaningful value in private_data means that we have a tty-related struct
> file. Potential candidates: AFFS, CODA(?), drivers/net/cosa.c(?), ISDN,
> APM(?), MTRR(?). Do you have any of those beasts?

First it only happens in SMP.
The only thing I've got from the above list is MTRR. However I don't
see how it might play with filp->private data.
Enclosed is the .condig file I use.

Phil.

[unhandled content-type:application/octet-stream]
\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.108 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site