Kernel 2.4.5-ac2 OOPs when run pppd ?

Kernel 2.4.5-ac2 OOPs when run pppd ?

[Steve Kieu]

Hi,

Yeas it is stil the same as 2.4.5-ac1, but did not
happen with 2.4.5; You can try running pppd in the
console (tty1) without any argument.

Regards, 

SK

=====
S.KIEU

_____________________________________________________________________________
http://messenger.yahoo.com.au - Yahoo! Messenger
- Voice chat, mail alerts, stock quotes and favourite news and lots more!

Re: Kernel 2.4.5-ac2 OOPs when run pppd ?

[Alan Cox]

> Yeas it is stil the same as 2.4.5-ac1, but did not
> happen with 2.4.5; You can try running pppd in the
> console (tty1) without any argument.

Looks like an interaction with the newer console locking code. The BUG() is
caused when the ppp code tries to write to the console from inside an 
interrupt handler [now not allowed]

Alan

Re: Kernel 2.4.5-ac2 OOPs when run pppd ?

[Andrew Morton]

Alan Cox wrote:
> 
> > Yeas it is stil the same as 2.4.5-ac1, but did not
> > happen with 2.4.5; You can try running pppd in the
> > console (tty1) without any argument.
> 
> Looks like an interaction with the newer console locking code. The BUG() is
> caused when the ppp code tries to write to the console from inside an
> interrupt handler [now not allowed]

I wondered if there were more cases.

In the (as-yet-unsent) Linus patch I've added an

	if (in_interrupt()) {
		shout_loudly();
		return;
	}

in three places to catch this possibility.   I'll prepare
a -ac diff.


This is a fundamental problem.

- The console is a tty device
- tty devices are callable from interrupts
- the console is very stateful and needs locking
- the locking must be interrupt-safe (irqsave)
- the console is very slow.

net result: we block interrupts for ages.  It's
an exceptional situation.  I hope Linus buys this
line of reasoning :)

-

Re: Kernel 2.4.5-ac2 OOPs when run pppd ?

[Richard Gooch]

Andrew Morton writes:
> Alan Cox wrote:
> > 
> > > Yeas it is stil the same as 2.4.5-ac1, but did not
> > > happen with 2.4.5; You can try running pppd in the
> > > console (tty1) without any argument.
> > 
> > Looks like an interaction with the newer console locking code. The BUG() is
> > caused when the ppp code tries to write to the console from inside an
> > interrupt handler [now not allowed]
> 
> I wondered if there were more cases.
> 
> In the (as-yet-unsent) Linus patch I've added an
> 
> 	if (in_interrupt()) {
> 		shout_loudly();
> 		return;
> 	}
> 
> in three places to catch this possibility.   I'll prepare
> a -ac diff.
> 
> 
> This is a fundamental problem.
> 
> - The console is a tty device
> - tty devices are callable from interrupts
> - the console is very stateful and needs locking
> - the locking must be interrupt-safe (irqsave)
> - the console is very slow.
> 
> net result: we block interrupts for ages.  It's
> an exceptional situation.  I hope Linus buys this
> line of reasoning :)

How about having a helper function for interrupt handlers which queues
characters to be sent to the console? kconsoled anyone? Blocking
interrupts is quite distressing, so we need to be consoled ;-)

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: Kernel 2.4.5-ac2 OOPs when run pppd ?

[Andrew Morton]

Richard Gooch wrote:
> 
> How about having a helper function for interrupt handlers which queues
> characters to be sent to the console? kconsoled anyone? Blocking
> interrupts is quite distressing, so we need to be consoled ;-)

I don't think we need it, Richard.  These writes to tty
devices from interrupt context are coming from line
disciplines - n_hdlc, ppp, r3964, etc.

Now, while it may be amusing to see if you can successfully
negotiate a PPP session by typing raw LCP, there really isn't,
I believe, a useful reason for attaching one of these ldiscs
to the console tty.

Interrupt-context writes to the *console*, as opposed to
the console *tty* work just fine, of course.  printk.