(cc's added)
On Tue, 11 Jul 2006 00:20:22 -0400
[EMAIL PROTECTED] wrote:
> (This is *NOT* new with 2.6.18-rc1-mm1, I've seen it a few times before, no
> idea when it started... I think I've seen it as far back as 2.6.16-mm2 or so).
>
> Most of the time, the VPN comes up just fine.
>
> Jul 10 22:44:28 turing-police kernel: [ 7180.696000] CSLIP: code copyright
> 1989 Regents of the University of California
> Jul 10 22:44:28 turing-police kernel: [ 7180.701000] PPP generic driver
> version 2.4.2
> Jul 10 23:00:26 turing-police kernel: [ 8137.903000] PPP MPPE Compression
> module registered
>
> However, sometimes (usually when restarting after the VPN gets dropped due to
> a network burp, etc), it will start up, get connected, and then the the first
> (or one of the first) data packets over the VPN will suddenly spike the
> CPU to 100% (about 50% userspace and 50% kernel). A quick oprofile check
> shows the kernel CPU getting sucked:
>
> samples %image name app name symbol
> name
> 1090118.2805 arc4.ko arc4 .text
> 5046 8.4619 ppp_async.ko ppp_async
> ppp_async_push
> 4865 8.1584 pptp pptp (no
> symbols)
> 4382 7.3484 arc4.ko arc4
> arc4_set_key
> 4331 7.2629 vmlinux vmlinux
> sha_transform
> 4203 7.0482 libfb.so libfb.so
> fbCopyAreammx
> 3342 5.6044 vmlinux vmlinux
> ecb_process
> 1324 2.2203 libgdk_imlib.so.1.9.13 libgdk_imlib.so.1.9.13 (no
> symbols)
> 1149 1.9268 ip_tables.ko ip_tables
> ipt_do_table
> 1071 1.7960 vmlinux vmlinux
> local_bh_enable
> 848 1.4221 vmlinux vmlinux
> acpi_pm_read
> 816 1.3684 vmlinux vmlinux
> __local_bh_disable
> 698 1.1705 vmlinux vmlinux
> n_tty_receive_buf
> 651 1.0917 vmlinux vmlinux
> do_page_fault
>
> (pptp is the userspace control process)
>
> gkrellm reports that about 4 mbytes/sec is being sent on ppp0 - but shows
> zero traffic on eth0 (the underlying interface). When working properly,
> both ppp0 and eth0 show the traffic.
>
> This continues until I get fed up and manually take the VPN down, at which
> point it happily gets rid of ppp0 and CPU load returns to normal.
>
> I haven't found a clean way to reproduce it - sometimes I won't see it for
> 2-3 weeks, then it will pop up several times in an evening.
>
> Any suggestions/hints (besides rebuilding the implicated .ko with debugging
> symbols so oprofile can be more granular - that's already on the to-do list)?
>
I'd suggest you whack sysrq-T 5-10 times when it happens, capture a few
stack traces.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
