Crash with FreeBSD 6.1 STABLE of today

[Martin Blapp]

Hi,

> Is the problem actually understood?  Do we know what's racing with what?
> Given there only ever seems to be a single backtrace involved, as far as
> I can tell, it's ttymodem racing with tty_close - can those two
> functions alone be locked?

Correct: The only place there tp->t_session is set to NULL is in tty_close().

         tp->t_pgrp = NULL;
         tp->t_session = NULL;
         tp->t_state = 0;

But I've seen this comment on peters page (http://people.freebsd.org/~peter/smp.html)

> At the moment I've hacked all the console code to obtain the scheduler mutex 
> instead of spltty()'ing all over the place, because in a word: it can't 
> spltty() any more. It's illegal because the console code may be called at any time (see 
> the next section). This is a hack because it isn't MP safe against tty 
> interrupts running on another cpu. Since the current tty interrupt is a fast 
> interrupt, I'm not sure that we're any worse off (fastints aren't masked by the 
> cpl anyway).

IMHO it explains why we need the proctree_lock (in early SMP times 
scheduler mutex). Maybe this should be replaced with a proper tty subsystem 
mutex ...)

After looking at our SMPnewgen Page, Poul Henning and Thomas Moestel
are working on locking the tty subsystem. I'll CC those :-)

Martin