Hello,
I use intense HTB processing (about 50kpps - on bridge with two gigabit interfaces) on a dual Opteron running kernel 2.6.8.1 x86_64 (and the x86_64 version of Fedora Core 2). Everything's working fine, until i get an "Unable to handle kernel paging request" error (I've attached it to bypass the 72 column wrap); from this point on, every command trying to access the networking subsystem (i.e. ifconfig, tc) freezes; the strange thing is that bridge forwarding and HTB continue to work.
Can this be a userspace problem (a bug in tc), or is it a kernel issue?
I'm not that good at kernel debugging (have never done that, actually), so could you please help me in further debugging this problem?
Currently, i have HTB support compiled as a module; I'll try to recompile the kernel without module support; but I hardly think this is a module issue.
If you reply to the list, please CC me, as i'm not subscribed.
Thanks in advance, Bogdan
Sep 26 15:04:44 server kernel: Unable to handle kernel paging request at 0000000000100100 RIP:
Sep 26 15:04:44 server kernel: <ffffffff8027a964>{qdisc_lookup+52}
Sep 26 15:04:44 server kernel: PML4 33914067 PGD 2ec4c067 PMD 0
Sep 26 15:04:44 server kernel: Oops: 0000 [1] SMP
Sep 26 15:04:44 server kernel: CPU 1
Sep 26 15:04:44 server kernel: Modules linked in: sch_sfq cls_u32 sch_htb tg3 e100 mii ipt_LOG ipt_pkttype iptable_filter iptable_mangle ip_tables
Sep 26 15:04:44 server kernel: Pid: 20560, comm: tc Not tainted 2.6.8.1
Sep 26 15:04:44 server kernel: RIP: 0010:[<ffffffff8027a964>] <ffffffff8027a964>{qdisc_lookup+52}
Sep 26 15:04:44 server kernel: RSP: 0018:000001001accfa90 EFLAGS: 00010286
Sep 26 15:04:44 server kernel: RAX: 00000000001000b8 RBX: 000001001bb14940 RCX: 00000000001000b8
Sep 26 15:04:44 server kernel: RDX: 0000000000100100 RSI: 0000000000110000 RDI: 000001003e6df1a8
Sep 26 15:04:44 server kernel: RBP: 0000000000010000 R08: 0000000000000007 R09: 000000000000001c
Sep 26 15:04:44 server kernel: R10: ffffffff8032e420 R11: 000001001accfb38 R12: 00000100175d2200
Sep 26 15:04:44 server kernel: R13: 00000100175d2210 R14: 00000100175d2200 R15: 0000000000110000
Sep 26 15:04:44 server kernel: FS: 0000002a95b6b4c0(0000) GS:ffffffff803be800(0000) knlGS:0000000000000000
Sep 26 15:04:44 server kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Sep 26 15:04:44 server kernel: CR2: 0000000000100100 CR3: 000000000214a000 CR4: 00000000000006e0
Sep 26 15:04:44 server kernel: Process tc (pid: 20560, threadinfo 000001001acce000, task 0000010018816530)
Sep 26 15:04:44 server kernel: Stack: ffffffff8027cc9c ffffffff803f0c80 0000000000000246 0000000000000246
Sep 26 15:04:44 server kernel: 0000000000000000 000001003e1a74f0 ffffffffa0022e08 000001003e6df000
Sep 26 15:04:44 server kernel: 0000000800010000 000001001accfb38
Sep 26 15:04:44 server kernel: Call Trace:<ffffffff8027cc9c>{tc_ctl_tfilter+172} <ffffffffa0022e08>{:tg3:tg3_get_stats+664}
Sep 26 15:04:44 server kernel: <ffffffff80276f57>{rtnetlink_rcv+599} <ffffffff802769d0>{rtnetlink_dump_ifinfo+0}
Sep 26 15:04:44 server kernel: <ffffffff8027ec76>{netlink_data_ready+22} <ffffffff8027e33a>{netlink_sendskb+138}
Sep 26 15:04:44 server kernel: <ffffffff8027ea3f>{netlink_sendmsg+687} <ffffffff80265e05>{sock_sendmsg+181}
Sep 26 15:04:44 server kernel: <ffffffff80125d20>{autoremove_wake_function+0} <ffffffff8026bb84>{verify_iovec+68}
Sep 26 15:04:44 server kernel: <ffffffff802677af>{sys_sendmsg+351} <ffffffff80267330>{sys_sendto+208}
Sep 26 15:04:44 server kernel: <ffffffff80267167>{sys_getsockname+135} <ffffffff80265b54>{sock_map_fd+356}
Sep 26 15:04:44 server kernel: <ffffffff8027dac0>{netlink_create+160} <ffffffff80266b38>{__sock_create+296}
Sep 26 15:04:44 server kernel: <ffffffff8011074a>{system_call+126}
Sep 26 15:04:44 server kernel:
Sep 26 15:04:44 server kernel: Code: 48 8b 40 48 0f 18 08 48 39 fa 75 e0 31 c0 c3 66 66 66 90 66
Sep 26 15:04:44 server kernel: RIP <ffffffff8027a964>{qdisc_lookup+52} RSP <000001001accfa90>
Sep 26 15:04:44 server kernel: CR2: 0000000000100100
