Messages in this thread | | | Subject | Re: Linux-2.2.2-pre2.. | From | Philippe Troin <> | Date | 06 Feb 1999 17:17:01 -0800 |
| |
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] | |