netdev
[Top] [All Lists]

Re: ISDN is killing interrupt handler on L2.4.0test9

To: hgfelger@xxxxxxxxxxx
Subject: Re: ISDN is killing interrupt handler on L2.4.0test9
From: Henner Eisen <eis@xxxxxxxxxxxxx>
Date: Tue, 17 Oct 2000 19:15:33 +0200
Cc: netdev@xxxxxxxxxxx, i4ldeveloper@xxxxxxxxxxxxxxxxxxxxxx
In-reply-to: <Pine.LNX.4.10.10010171620350.554-100000@frog.athome> (message from Hartwig Felger on Tue, 17 Oct 2000 16:29:46 +0200 (CEST))
References: <Pine.LNX.4.10.10010171620350.554-100000@frog.athome>
Sender: owner-netdev@xxxxxxxxxxx
>>>>> "Hartwig" == Hartwig Felger <hgfelger@xxxxxxxxxxx> writes:

    Hartwig> That's it - I tryed to switch-off some before, but forgot
    Hartwig> to disable bsdcomp and ccp. The CCP is the bad thing!

Does `-bsdcomp' alone already fix the problem?

Does the problem only occur with demand dial-up or even if you start
the connection manually (isdnctrl dial ippp0)?

    Hartwig> Does anybody know, where ccp is implemented (ipppd
    Hartwig> vs. kernel).

The classical pppd approach is that the kernel just passes the ccp
frames to user space such that pppd implements the protocol (and just
controls the compressor by means of some ioctls). I guess when LCS
compression support was added, it was necessary to handle certain
parts of ccp inside the kernel, but I´m not familar with the details.

    Hartwig> Best would be, if somebody tells me, which
    Hartwig> source-file it is, then I may dig a bit further.  After

drivers/net/isdn/isdn_ppp.c for the kernel. In the [i]pppd source, it
should be in ccp.c.

    Hartwig> adding "noccp" everything works again for me.  Is there a
    Hartwig> way, to make ipppd put out the logging to stderr, instead

As far as I know, there isn´t (beside editing the ipppd sources ;).
But it should be possible to let the ippp kernel modules writing
debugging messages. Try setting the kdebug option of ipppd to 0xff
and do (as root) `klogkonsole -l 7 -r 1' before you start the connection
and whatch the kernel's debug messages on virtual console 1.

Ss you can reproduce the problem with a Linux 2.2.x peer server
in your office (which does not crash), it should also be possible to 
additinally capture the (syslog-based) log at the server side.

Henner

<Prev in Thread] Current Thread [Next in Thread>