* Kernel crash in bridge module: unable to handle kernel paging request @ 2014-04-17 9:00 Michael Maier 2014-04-18 18:10 ` Michael Maier 0 siblings, 1 reply; 3+ messages in thread From: Michael Maier @ 2014-04-17 9:00 UTC (permalink / raw) To: netdev Hello! I'm using the following configuration on CentOS 6.5 w/ lt-kernel (3.10.37) - or any other kernel version. brctl addbr br0 brctl addif br0 eth0 ip li add vxlan0 type vxlan id 1 group 239.1.1.1 ttl 1 dev ra0 brctl addif br0 vxlan0 This is one end of a vxlan tunnel via WLAN. At the moment the first package arrives the bridge, the 64 bit-kernel crashes (32 bit kernel works perfectly). What could be the reason for the crash w/ 64 bit kernel? Btw: there isn't any problem even w/ 64 bit kernel as long as the bridge code isn't involved. Thanks for any hint! Michael BUG: unable to handle kernel paging request at ffff880077998000 IP: [<ffffffff812a663d>] memcpy+0xd/0x110 PGD 20d9067 PUD 20dc067 PMD 77a85063 PTE 8000000077998161 Oops: 0003 [#1] SMP Modules linked in: vxlan ip_tunnel bridge stp llc rfkill xt_multiport iptable_filter ip_tables ipv6 acpi_cpufreq freq_table mperf kvm_amd kvm microcode pcspkr sg rt5572sta(O) k10temp hwmon sp5100_tco i2c_piix4 r8169 mii ext4 jbd2 mbcache sd_mod crc_t10dif usb_storage atd CPU: 1 PID: 0 Comm: swapper/1 Tainted: G O 3.10.37-1.el6.elrepo.x86_64 #1 Hardware name: PC Engines APU, BIOS unknown 12/24/2013 task: ffff88007a866ad0 ti: ffff88007a86a000 task.ti: ffff88007a86a000 RIP: 0010:[<ffffffff812a663d>] [<ffffffff812a663d>] memcpy+0xd/0x110 RSP: 0018:ffff88007df03698 EFLAGS: 00010202 RAX: ffff880077992800 RBX: ffff88007a4a24c0 RCX: 000000000f4b42e0 RDX: 0000000000000002 RSI: ffff88007a5ac640 RDI: ffff880077998000 RBP: ffff88007df036e0 R08: 0000000000000000 R09: ffff88007df03848 R10: ffff880079a5a4b0 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000020 R14: ffff880077992800 R15: ffff880077992800 FS: 00007fab767fc700(0000) GS:ffff88007df00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: ffff880077998000 CR3: 0000000079db6000 CR4: 00000000000007e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Stack: ffffffff81515155 0000000000000000 000002c0a034bd2a 0000000000000000 ffff88007a4a24c0 000000000000000e ffff88007a6de000 ffffffff81d197a0 0000000000000002 ffff88007df03700 ffffffffa0365afd ffff88007a4a24c0 Call Trace: <IRQ> [<ffffffff81515155>] ? pskb_expand_head+0xb5/0x250 [<ffffffffa0365afd>] nf_bridge_copy_header+0x14d/0x170 [bridge] [<ffffffffa035e375>] br_dev_queue_push_xmit+0xa5/0xd0 [bridge] [<ffffffffa036614a>] br_nf_dev_queue_xmit+0x2a/0xa0 [bridge] [<ffffffffa0366f18>] br_nf_post_routing+0x2b8/0x2e0 [bridge] [<ffffffff8154faa7>] nf_iterate+0x87/0xb0 [<ffffffffa035e2d0>] ? deliver_clone+0x60/0x60 [bridge] [<ffffffff8154fccd>] nf_hook_slow+0x7d/0x150 [<ffffffffa035e2d0>] ? deliver_clone+0x60/0x60 [bridge] [<ffffffffa03661c0>] ? br_nf_dev_queue_xmit+0xa0/0xa0 [bridge] [<ffffffffa035e883>] br_forward_finish+0x43/0x60 [bridge] [<ffffffffa0366358>] br_nf_forward_finish+0x198/0x1b0 [bridge] [<ffffffffa0366bf8>] br_nf_forward_ip+0x3a8/0x410 [bridge] [<ffffffff8154faa7>] nf_iterate+0x87/0xb0 [<ffffffffa035e840>] ? br_flood_deliver+0x20/0x20 [bridge] [<ffffffff8154fccd>] nf_hook_slow+0x7d/0x150 [<ffffffffa035e840>] ? br_flood_deliver+0x20/0x20 [bridge] [<ffffffffa035e444>] __br_forward+0xa4/0x100 [bridge] [<ffffffff815149b2>] ? skb_clone+0x62/0xc0 [<ffffffffa035e3a0>] ? br_dev_queue_push_xmit+0xd0/0xd0 [bridge] [<ffffffffa035e2ae>] deliver_clone+0x3e/0x60 [bridge] [<ffffffffa035e3a0>] ? br_dev_queue_push_xmit+0xd0/0xd0 [bridge] [<ffffffffa035e7c4>] br_flood+0x84/0xc0 [bridge] [<ffffffffa035f5c0>] ? NF_HOOK.clone.0+0x70/0x70 [bridge] [<ffffffffa035e815>] br_flood_forward+0x15/0x20 [bridge] [<ffffffffa035f8bf>] br_handle_frame_finish+0x2ff/0x320 [bridge] [<ffffffffa0367110>] br_nf_pre_routing_finish+0x1d0/0x350 [bridge] [<ffffffffa0366f40>] ? br_nf_post_routing+0x2e0/0x2e0 [bridge] [<ffffffffa0365456>] NF_HOOK_THRESH+0x56/0x60 [bridge] [<ffffffffa036679f>] br_nf_pre_routing+0x2df/0x390 [bridge] [<ffffffff81589ae0>] ? __udp4_lib_rcv+0x390/0x6c0 [<ffffffff815597a0>] ? ip_rcv+0x350/0x350 [<ffffffff8154faa7>] nf_iterate+0x87/0xb0 [<ffffffff815597a0>] ? ip_rcv+0x350/0x350 [<ffffffffa035f5c0>] ? NF_HOOK.clone.0+0x70/0x70 [bridge] [<ffffffff8154fccd>] nf_hook_slow+0x7d/0x150 [<ffffffffa035f5c0>] ? NF_HOOK.clone.0+0x70/0x70 [bridge] [<ffffffffa035faa4>] br_handle_frame+0x1c4/0x260 [bridge] [<ffffffffa035f8e0>] ? br_handle_frame_finish+0x320/0x320 [bridge] [<ffffffff8152380e>] __netif_receive_skb_core+0x27e/0x6d0 [<ffffffff81523c87>] __netif_receive_skb+0x27/0x70 [<ffffffff81523dd3>] process_backlog+0x103/0x200 [<ffffffff81524612>] net_rx_action+0x112/0x2a0 [<ffffffff814ccd06>] ? cpuidle_enter_state+0x56/0xd0 [<ffffffff81063cc7>] __do_softirq+0xf7/0x270 [<ffffffff8103bc18>] ? ack_apic_level+0x78/0x150 [<ffffffff815fcf1c>] call_softirq+0x1c/0x30 [<ffffffff81014535>] do_softirq+0x65/0xa0 [<ffffffff810639f5>] irq_exit+0xc5/0xd0 [<ffffffff815fd826>] do_IRQ+0x66/0xe0 [<ffffffff815f312d>] common_interrupt+0x6d/0x6d <EOI> [<ffffffff8101a2e3>] ? native_sched_clock+0x13/0x80 [<ffffffff814ccd06>] ? cpuidle_enter_state+0x56/0xd0 [<ffffffff814cccff>] ? cpuidle_enter_state+0x4f/0xd0 [<ffffffff814cd15d>] cpuidle_idle_call+0xcd/0x160 [<ffffffff8101ad6e>] arch_cpu_idle+0xe/0x30 [<ffffffff810aea9e>] cpu_idle_loop+0x9e/0x250 [<ffffffff810aecc0>] cpu_startup_entry+0x70/0x80 [<ffffffff815e6a12>] start_secondary+0xcd/0xcf Code: 0f b6 c0 5b c9 c3 0f 1f 84 00 00 00 00 00 e8 6b f8 ff ff 80 7b 25 00 74 c8 eb d3 90 90 90 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 <f3> 48 a5 89 d1 f3 a4 c3 20 4c 8b 06 4c 8b 4e 08 4c 8b 56 10 4c RIP [<ffffffff812a663d>] memcpy+0xd/0x110 RSP <ffff88007df03698> CR2: ffff880077998000 ---[ end trace d8c8412df40453b6 ]--- Kernel panic - not syncing: Fatal exception in interrupt ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Kernel crash in bridge module: unable to handle kernel paging request @ 2014-04-18 18:10 ` Michael Maier 0 siblings, 0 replies; 3+ messages in thread From: Michael Maier @ 2014-04-18 18:10 UTC (permalink / raw) To: netdev, users@rt2x00.serialmonkey.com, linux-wireless@vger.kernel.org [-- Attachment #1: Type: text/plain, Size: 1477 bytes --] Michael Maier wrote: > Hello! > > I'm using the following configuration on CentOS 6.5 w/ lt-kernel > (3.10.37) - or any other kernel version. > > brctl addbr br0 > brctl addif br0 eth0 > > ip li add vxlan0 type vxlan id 1 group 239.1.1.1 ttl 1 dev ra0 > > brctl addif br0 vxlan0 > > This is one end of a vxlan tunnel via WLAN. > > At the moment the first package arrives the bridge, the 64 bit-kernel > crashes (32 bit kernel works perfectly). What could be the reason for > the crash w/ 64 bit kernel? Btw: there isn't any problem even w/ 64 > bit kernel as long as the bridge code isn't involved. The rt5572sta driver (DPO_RT5572_LinuxSTA_2.6.1.3_20121022) isn't completely 64 bit stable. The attached patch makes rt5572sta working with 64bit kernels even when used with a bridge like mentioned above. The patch is derived from https://github.com/ashaffer/rt3573sta/commit/2654eaee416f238a6651465c88a804ee251afe74 - there it was applied to rt3573 driver from Ralink / Mediatek. I applied and tested it for rt5572sta (which is the newer one and supports a lot more chips, amongst others rt3573) and kernel 3.13.6 / 64 bit. I suppose it to work with 3.10.x, too. I detected, that bridging does not work with 3.14.x - but there is no crash - it just doesn't work (packages came in in eth0, go through the bridge and vxlan, are remotely answered, but the sent response can only be seen in the vxlan and br0 device - but it can't be seen in eth0 - strange). Michael [-- Attachment #2: ralink-64bit-1.diff --] [-- Type: text/x-patch, Size: 1736 bytes --] diff --git a/include/os/rt_linux.h b/include/os/rt_linux.h index 1612e34..c3a7792 100644 --- a/include/os/rt_linux.h +++ b/include/os/rt_linux.h @@ -858,9 +858,14 @@ void linux_pci_unmap_single(void *handle, ra_dma_addr_t dma_addr, size_t size, i #define GET_OS_PKT_DATATAIL(_pkt) \ (RTPKT_TO_OSPKT(_pkt)->tail) +#ifdef NET_SKBUFF_DATA_USES_OFFSET +#define SET_OS_PKT_DATATAIL(_pkt, _start, _len) \ + ((RTPKT_TO_OSPKT(_pkt))->tail) = (PUCHAR)(RTPKT_TO_OSPKT(_pkt)->data-(RTPKT_TO_OSPKT(_pkt)->head) + (_len)) +#else #define SET_OS_PKT_DATATAIL(_pkt, _start, _len) \ ((RTPKT_TO_OSPKT(_pkt))->tail) = (PUCHAR)((_start) + (_len)) - +#endif + #define GET_OS_PKT_HEAD(_pkt) \ (RTPKT_TO_OSPKT(_pkt)->head) diff --git a/os/linux/rt_linux.c b/os/linux/rt_linux.c index f5b5e19..817bca8 100644 --- a/os/linux/rt_linux.c +++ b/os/linux/rt_linux.c @@ -505,9 +505,15 @@ PNDIS_PACKET duplicate_pkt( MEM_DBG_PKT_ALLOC_INC(skb); skb_reserve(skb, 2); +#ifdef NET_SKBUFF_DATA_USES_OFFSET + NdisMoveMemory(skb->data+skb->tail, pHeader802_3, HdrLen); + skb_put(skb, HdrLen); + NdisMoveMemory(skb->data+skb->tail, pData, DataSize); +#else NdisMoveMemory(skb->tail, pHeader802_3, HdrLen); skb_put(skb, HdrLen); NdisMoveMemory(skb->tail, pData, DataSize); +#endif skb_put(skb, DataSize); skb->dev = pNetDev; /*get_netdev_from_bssid(pAd, FromWhichBSSID); */ pPacket = OSPKT_TO_RTPKT(skb); @@ -705,7 +711,11 @@ void wlan_802_11_to_802_3_packet( pOSPkt->dev = pNetDev; pOSPkt->data = pData; pOSPkt->len = DataSize; +#ifdef NET_SKBUFF_DATA_USES_OFFSET + pOSPkt->tail = (pOSPkt->data-pOSPkt->head)+pOSPkt->len; +#else pOSPkt->tail = pOSPkt->data + pOSPkt->len; +#endif /* */ /* copy 802.3 header */ [-- Attachment #3: ralink-64bit-2.diff --] [-- Type: text/x-patch, Size: 715 bytes --] diff --git a/include/os/rt_linux.h b/include/os/rt_linux.h index c3a7792..f5975a1 100644 --- a/include/os/rt_linux.h +++ b/include/os/rt_linux.h @@ -860,7 +860,7 @@ void linux_pci_unmap_single(void *handle, ra_dma_addr_t dma_addr, size_t size, i (RTPKT_TO_OSPKT(_pkt)->tail) #ifdef NET_SKBUFF_DATA_USES_OFFSET #define SET_OS_PKT_DATATAIL(_pkt, _start, _len) \ - ((RTPKT_TO_OSPKT(_pkt))->tail) = (PUCHAR)(RTPKT_TO_OSPKT(_pkt)->data-(RTPKT_TO_OSPKT(_pkt)->head) + (_len)) + ((RTPKT_TO_OSPKT(_pkt))->tail) = (ULONG)RTPKT_TO_OSPKT(_pkt)->data - (ULONG)(RTPKT_TO_OSPKT(_pkt)->head) + (_len) #else #define SET_OS_PKT_DATATAIL(_pkt, _start, _len) \ ((RTPKT_TO_OSPKT(_pkt))->tail) = (PUCHAR)((_start) + (_len)) ^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: Kernel crash in bridge module: unable to handle kernel paging request @ 2014-04-18 18:10 ` Michael Maier 0 siblings, 0 replies; 3+ messages in thread From: Michael Maier @ 2014-04-18 18:10 UTC (permalink / raw) To: netdev-u79uwXL29TY76Z2rM5mHXA, users-poMEt7QlJxcwIE2E9O76wjtx2kNaKg5H@public.gmane.org, linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [-- Attachment #1: Type: text/plain, Size: 1477 bytes --] Michael Maier wrote: > Hello! > > I'm using the following configuration on CentOS 6.5 w/ lt-kernel > (3.10.37) - or any other kernel version. > > brctl addbr br0 > brctl addif br0 eth0 > > ip li add vxlan0 type vxlan id 1 group 239.1.1.1 ttl 1 dev ra0 > > brctl addif br0 vxlan0 > > This is one end of a vxlan tunnel via WLAN. > > At the moment the first package arrives the bridge, the 64 bit-kernel > crashes (32 bit kernel works perfectly). What could be the reason for > the crash w/ 64 bit kernel? Btw: there isn't any problem even w/ 64 > bit kernel as long as the bridge code isn't involved. The rt5572sta driver (DPO_RT5572_LinuxSTA_2.6.1.3_20121022) isn't completely 64 bit stable. The attached patch makes rt5572sta working with 64bit kernels even when used with a bridge like mentioned above. The patch is derived from https://github.com/ashaffer/rt3573sta/commit/2654eaee416f238a6651465c88a804ee251afe74 - there it was applied to rt3573 driver from Ralink / Mediatek. I applied and tested it for rt5572sta (which is the newer one and supports a lot more chips, amongst others rt3573) and kernel 3.13.6 / 64 bit. I suppose it to work with 3.10.x, too. I detected, that bridging does not work with 3.14.x - but there is no crash - it just doesn't work (packages came in in eth0, go through the bridge and vxlan, are remotely answered, but the sent response can only be seen in the vxlan and br0 device - but it can't be seen in eth0 - strange). Michael [-- Attachment #2: ralink-64bit-1.diff --] [-- Type: text/x-patch, Size: 1736 bytes --] diff --git a/include/os/rt_linux.h b/include/os/rt_linux.h index 1612e34..c3a7792 100644 --- a/include/os/rt_linux.h +++ b/include/os/rt_linux.h @@ -858,9 +858,14 @@ void linux_pci_unmap_single(void *handle, ra_dma_addr_t dma_addr, size_t size, i #define GET_OS_PKT_DATATAIL(_pkt) \ (RTPKT_TO_OSPKT(_pkt)->tail) +#ifdef NET_SKBUFF_DATA_USES_OFFSET +#define SET_OS_PKT_DATATAIL(_pkt, _start, _len) \ + ((RTPKT_TO_OSPKT(_pkt))->tail) = (PUCHAR)(RTPKT_TO_OSPKT(_pkt)->data-(RTPKT_TO_OSPKT(_pkt)->head) + (_len)) +#else #define SET_OS_PKT_DATATAIL(_pkt, _start, _len) \ ((RTPKT_TO_OSPKT(_pkt))->tail) = (PUCHAR)((_start) + (_len)) - +#endif + #define GET_OS_PKT_HEAD(_pkt) \ (RTPKT_TO_OSPKT(_pkt)->head) diff --git a/os/linux/rt_linux.c b/os/linux/rt_linux.c index f5b5e19..817bca8 100644 --- a/os/linux/rt_linux.c +++ b/os/linux/rt_linux.c @@ -505,9 +505,15 @@ PNDIS_PACKET duplicate_pkt( MEM_DBG_PKT_ALLOC_INC(skb); skb_reserve(skb, 2); +#ifdef NET_SKBUFF_DATA_USES_OFFSET + NdisMoveMemory(skb->data+skb->tail, pHeader802_3, HdrLen); + skb_put(skb, HdrLen); + NdisMoveMemory(skb->data+skb->tail, pData, DataSize); +#else NdisMoveMemory(skb->tail, pHeader802_3, HdrLen); skb_put(skb, HdrLen); NdisMoveMemory(skb->tail, pData, DataSize); +#endif skb_put(skb, DataSize); skb->dev = pNetDev; /*get_netdev_from_bssid(pAd, FromWhichBSSID); */ pPacket = OSPKT_TO_RTPKT(skb); @@ -705,7 +711,11 @@ void wlan_802_11_to_802_3_packet( pOSPkt->dev = pNetDev; pOSPkt->data = pData; pOSPkt->len = DataSize; +#ifdef NET_SKBUFF_DATA_USES_OFFSET + pOSPkt->tail = (pOSPkt->data-pOSPkt->head)+pOSPkt->len; +#else pOSPkt->tail = pOSPkt->data + pOSPkt->len; +#endif /* */ /* copy 802.3 header */ [-- Attachment #3: ralink-64bit-2.diff --] [-- Type: text/x-patch, Size: 715 bytes --] diff --git a/include/os/rt_linux.h b/include/os/rt_linux.h index c3a7792..f5975a1 100644 --- a/include/os/rt_linux.h +++ b/include/os/rt_linux.h @@ -860,7 +860,7 @@ void linux_pci_unmap_single(void *handle, ra_dma_addr_t dma_addr, size_t size, i (RTPKT_TO_OSPKT(_pkt)->tail) #ifdef NET_SKBUFF_DATA_USES_OFFSET #define SET_OS_PKT_DATATAIL(_pkt, _start, _len) \ - ((RTPKT_TO_OSPKT(_pkt))->tail) = (PUCHAR)(RTPKT_TO_OSPKT(_pkt)->data-(RTPKT_TO_OSPKT(_pkt)->head) + (_len)) + ((RTPKT_TO_OSPKT(_pkt))->tail) = (ULONG)RTPKT_TO_OSPKT(_pkt)->data - (ULONG)(RTPKT_TO_OSPKT(_pkt)->head) + (_len) #else #define SET_OS_PKT_DATATAIL(_pkt, _start, _len) \ ((RTPKT_TO_OSPKT(_pkt))->tail) = (PUCHAR)((_start) + (_len)) [-- Attachment #4: Type: text/plain, Size: 201 bytes --] _______________________________________________ users mailing list users-poMEt7QlJxcwIE2E9O76wjtx2kNaKg5H@public.gmane.org http://rt2x00.serialmonkey.com/mailman/listinfo/users_rt2x00.serialmonkey.com ^ permalink raw reply related [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-04-18 18:30 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-04-17 9:00 Kernel crash in bridge module: unable to handle kernel paging request Michael Maier 2014-04-18 18:10 ` Michael Maier 2014-04-18 18:10 ` Michael Maier
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.