Bug 24062 - pppoe: pppd softlockup at bootup with IPv6 enabled
Summary: pppoe: pppd softlockup at bootup with IPv6 enabled
Status: RESOLVED CODE_FIX
Alias: None
Product: Networking
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 low
Assignee: Arnaldo Carvalho de Melo
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-30 02:57 UTC by Matthew Stapleton
Modified: 2012-08-14 13:52 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.26
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Matthew Stapleton 2010-11-30 02:57:27 UTC
My ISP is currently trialing IPv6 over PPPoE so I have been trying it out, but
if I load pppd with the "ipv6 ," option via the bootup scripts I get a kernel softlockup a few seconds after the IPv6 default route comes up.  Even if I bootup with the wan network cable unplugged and then plug it in after the system has finished booting I will often get a lockup.  If I login and load pppd from the bash shell I don't get a lockup no matter how many times I disconnect and reconnect the connection.

I am running Gentoo Linux x86_64 on an Athlon 64 X2 Dual Core CPU, currently running kernel version: 2.6.36-gentoo-r1, but I also had the problem on the 2.6.35 series as well.  I also was running Gentoo ppp-2.4.4-r13 but recent updated to gentoo ppp-2.4.4-r25

Sometimes the backtrace changes a little but the following is what it normally looks like:

[<ffffffff810020ab>] ? system_call_fastpath+0x16/0x1b
Kernel - panic - not syncing: softlockup: hung tasks
Pid: 7932, comm: pppd Not tainted 2.6.36-gentoor1 #1
Call Trace:
<IRQ> [<ffffffff814ba518>] ? panic+0xac/0x1b0
[<ffffffff81004e10>] ? dump_trace+0x270/0x27f
[<ffffffff81002a0e>] ? apic_timer_interrupt+0xe/0x20
[<ffffffff81076683>] ? watchdog_timer_fn+0x17c/0x1b3
[<ffffffff81076507>] ? watchdog_timer_fn+0x0/0x1b3
[<ffffffff81053c70>] ? __run_hrtimer+0x50/0xa9
[<ffffffff81053ec8>] ? hrtimer_interrupt+0xaa/0x192
[<ffffffff81019371>] ? smp_apic_timer_interrupt+0x81/0x94
[<ffffffff81002a13>] ? apic_timer_interrupt+0x13/0x20
<EOI> [<ffffffff8142c096>] ? dev_deactivate_queue+0x0/0x63
[<ffffffff814bc4ba>] ? _raw_spin_lock_bh+0x28/0x2e
[<ffffffff814bc49b>] ? _raw_spin_lock_bh+0x9/0x2e
[<ffffffff8142c0be>] ? dev_deactivate_queue+0x20/0x63
[<ffffffff8142c12d>] ? dev_deactivate_queue+0x34/0xdb
[<ffffffff8141a00e>] ? __dev_close+0x54/0x70
[<ffffffff8141803f>] ? __dev_change_flags+0xaf/0x129
[<ffffffff81419ed1>] ? dev_change_flags+0x12/0x42
[<ffffffff8146070b>] ? devinet_ioctl+0x273/0x528
[<ffffffff81409324>] ? sock_do_ioctl+0x1b/0x36
[<ffffffff8140954f>] ? sock_ioctl+0x210/0x21a
[<ffffffff810c1e0a>] ? do_vfs_ioctl+0x40b/0x44c
[<ffffffff81023632>] ? do_page_fault+0x210/0x259
[<ffffffff810c1e9c>] ? sys_ioctl+0x51/0x70
[<ffffffff810020ab>] ? [<ffffffff814ba518>] ? system_call_fastpath+0x16/0x1b
Comment 1 Matthew Stapleton 2011-02-04 04:41:54 UTC
It looks like I am no longer getting the softlockup problem with kernel version: 2.6.37

Note You need to log in before you can comment on or make changes to this bug.