(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 > 10901 18.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