This is a followup to my earlier mail 'ksoftirqd using mysteriously high
amounts of CPU time'. After working briefly with Andrew Morton on the
issue we seem to have identified the 'pppoe' userspace program as the
culprit for that issue.
After some playing with kernel options I switched my PPPoE connection
options from asynctty to synctty, and observed almost no usage of
ksoftirqd/0 at all, as it should be.
However, the pppoe process maintains an extreme amount of CPU
utilization, cutting off the machines ability to send and receive at its
fastest possible rate. Additionally the attached error fills dmesg after
a couple of days (vanilla 2.6.3 kernel).
I'm hoping the PPP stuff in the kernel is well enough maintained that a
problem/solution can be identified..
Thanks in advance!
Brad
On Sat, 2004-03-20 at 11:40, Brad Laue wrote:
> This is a followup to my earlier mail 'ksoftirqd using mysteriously high
> amounts of CPU time'. After working briefly with Andrew Morton on the
> issue we seem to have identified the 'pppoe' userspace program as the
> culprit for that issue.
>
> After some playing with kernel options I switched my PPPoE connection
> options from asynctty to synctty, and observed almost no usage of
> ksoftirqd/0 at all, as it should be.
>
> However, the pppoe process maintains an extreme amount of CPU
> utilization, cutting off the machines ability to send and receive at its
> fastest possible rate. Additionally the attached error fills dmesg after
> a couple of days (vanilla 2.6.3 kernel).
>
> I'm hoping the PPP stuff in the kernel is well enough maintained that a
> problem/solution can be identified..
>
> Thanks in advance!
>
> Brad
I apparently need to be reminded to actually attach attachments. :-)
* Brad Laue <[email protected]>:
> I apparently need to be reminded to actually attach attachments. :-)
Yep. I get the very same backtrace, whenever pppoe or pppd (dunno
which) is shut down e.g. for rebooting the box.
--
Ralf Hildebrandt (Im Auftrag des Referat V a) [email protected]
Charite - Universit?tsmedizin Berlin Tel. +49 (0)30-450 570-155
Gemeinsame Einrichtung von FU- und HU-Berlin Fax. +49 (0)30-450 570-916
IT-Zentrum Standort Campus Mitte AIM. ralfpostfix
On Sat, 2004-03-20 at 11:41, Brad Laue wrote:
> On Sat, 2004-03-20 at 11:40, Brad Laue wrote:
> > This is a followup to my earlier mail 'ksoftirqd using mysteriously high
> > amounts of CPU time'. After working briefly with Andrew Morton on the
> > issue we seem to have identified the 'pppoe' userspace program as the
> > culprit for that issue.
> >
> > After some playing with kernel options I switched my PPPoE connection
> > options from asynctty to synctty, and observed almost no usage of
> > ksoftirqd/0 at all, as it should be.
> >
> > However, the pppoe process maintains an extreme amount of CPU
> > utilization, cutting off the machines ability to send and receive at its
> > fastest possible rate. Additionally the attached error fills dmesg after
> > a couple of days (vanilla 2.6.3 kernel).
> >
> > I'm hoping the PPP stuff in the kernel is well enough maintained that a
> > problem/solution can be identified..
> >
> > Thanks in advance!
> >
> > Brad
>
> I apparently need to be reminded to actually attach attachments. :-)
I should also expand on this - this is Linux 2.6.3, .config attached
Brad Laue <[email protected]> wrote:
>
> Badness in local_bh_enable at kernel/softirq.c:126
> Call Trace:
> [<c0121d46>] local_bh_enable+0x86/0x90
> [<d087ac3b>] ppp_sync_push+0x5b/0x170 [ppp_synctty]
> [<d087a63d>] ppp_sync_wakeup+0x2d/0x60 [ppp_synctty]
> [<c024363a>] do_tty_hangup+0x3ea/0x460
> [<c0244bcd>] release_dev+0x62d/0x660
> [<c0142d53>] unmap_page_range+0x43/0x70
> [<c0168b62>] dput+0x22/0x210
> [<c0244faa>] tty_release+0x2a/0x60
> [<c0152ec0>] __fput+0x100/0x120
> [<c0151529>] filp_close+0x59/0x90
> [<c011f594>] put_files_struct+0x54/0xc0
> [<c01201fd>] do_exit+0x18d/0x410
> [<c012051a>] do_group_exit+0x3a/0xb0
> [<c0109387>] syscall_call+0x7/0xb
This is reminding us that nobody has fixed the tty locking yet. It's
generally harmless in practice.