On 2011-09-05 3:25 PM, Michael Büsch wrote:
On Sun, 4 Sep 2011 22:44:08 +0200
Luka Perkov<open...@lukaperkov.net> wrote:
Unhandled kernel unaligned access[#1]:
Cpu 0
$ 0 : 00000000 00000000 00000006 00000011
$ 4 : d5bf9da3 80dbb548 00000006 0000c010
$ 8 : 0000c578 00000000 6e617332 6e617332
$12 : 00000000 00000000 00000000 00000000
$16 : 6fbb5ff7 80d05618 8028fab0 00000000
$20 : 8028fa28 80cba248 8028fabc 8028fabe
$24 : 00000000 80d85a50
$28 : 8028e000 8028f9f0 81043d14 80cb8708
Hi : 00000235
Lo : 02922c00
epc : 80cb8968 nf_nat_setup_info+0x2e0/0x6e8 [nf_nat]
Tainted: P
ra : 80cb8708 nf_nat_setup_info+0x80/0x6e8 [nf_nat]
Status: 1100fc03 KERNEL EXL IE
Cause : 00800010
BadVA : 6fbb600f
PrId : 00019641 (MIPS 24Kc)
Modules linked in: gpio_keys_polled dwc_otg ath_pci ath_hal(P) lantiq_atm
drv_dsl_cpe_api lantiq_mei ipt_MASQUERADE iptable_nat nf_nat xt_conntrack
xt_NOTRACK iptable_raw xt_state nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack
pppoe pppox ipt_REJECT xt_TCPMSS ipt_LOG xt_comment xt_multiport xt_mac
xt_limit iptable_mangle iptable_filter ip_tables xt_tcpudp x_tables ppp_async
ppp_generic slhc br2684 atm drv_vmmc usbcore drv_tapi crc_ccitt drv_ifxos arc4
aes_generic crypto_algapi
Process swapper (pid: 0, threadinfo=8028e000, task=80291bc0, tls=00000000)
Stack : 81722280 8019bfa0 801c686c 80f4f800 c0a801c7 00000000 00000000 00000000
c5780002 6ea9cbd9 00000000 00000000 00000000 a6a90600 d5bf9da3 00000000
6ea9cbd9 00000000 00000000 00000000 a6a90002 c0a801c7 00000000 00000000
00000000 c5780601 80cb9fd0 80cb8b0c 00000001 d5bf9da3 00000000 00000000
c0a801c7 8028fae4 80fd8840 80d05618 8028fae8 d8263338 813ca98c 80fd8840
...
Call Trace:
[<80cb8968>] nf_nat_setup_info+0x2e0/0x6e8 [nf_nat]
[<80d1e158>] masquerade_tg+0xc0/0xe8 [ipt_MASQUERADE]
[<80c646a8>] ipt_do_table+0x3e0/0x484 [ip_tables]
[<80dee0c0>] nf_nat_rule_find+0x28/0x9c [iptable_nat]
[<80dee290>] nf_nat_fn+0x120/0x1a0 [iptable_nat]
[<801baa34>] nf_iterate+0x8c/0xfc
[<801bab34>] nf_hook_slow+0x90/0x17c
[<801c76c8>] ip_output+0xd8/0x104
[<8019a224>] __netif_receive_skb+0x4d4/0x578
[<80210128>] br_handle_frame+0x280/0x2b8
[<80199f9c>] __netif_receive_skb+0x24c/0x578
[<8019a370>] process_backlog+0xa8/0x188
[<8019a778>] net_rx_action+0x8c/0x1b8
[<800215f0>] __do_softirq+0xa8/0x154
[<800217f0>] do_softirq+0x48/0x68
[<800031c0>] plat_irq_dispatch+0xf4/0x164
[<800059ec>] ret_from_irq+0x0/0x4
[<80005be0>] r4k_wait+0x20/0x40
[<80007690>] cpu_idle+0x28/0x4c
[<802a58d0>] start_kernel+0x35c/0x378
thanks.
I am still wondering how enabling preempt could possibly workaround/hide
an alignment bug. sounds strange to me. Does somebody have an idea?
I didn't look too closely at the function yet, though.
Look at "BadVA : 6fbb600f" - it's not an alignment bug, the address is
completely bogus. It just happens to trip on the unhandled unaligned
access first because of the lowest bits.
This looks like a nasty memory corruption bug, and hiding it with
CONFIG_PREEMPT probably eventually makes it show up somewhere else instead.
- Felix
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
