On Sunday 04 September 2011 22:44:08 Luka Perkov wrote: > On Sun, Sep 04, 2011 at 08:47:46PM +0200, Michael Büsch wrote: > > On Sun, 4 Sep 2011 01:06:02 +0200 > > > > Luka Perkov <open...@lukaperkov.net> wrote: > > > > What are you actually trying to fix with enabling preemption? I > > > > didn't really get it by reading your mail. > > > > > > Kernel oops that I described. > > > > Yeah. And that is completely unacceptable. > > See the patch attached. > > > > CONFIG_PREEMPT must be enabled; don't know what more I can do. > > > > No. You must provide a full OOPS message. > > An unaligned access is easy to fix (or at least work around properly) > > with proper debugging information. > > 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 > > If you want to debug say so and I'll send you vmlinux file. I'm not going > to debug this further.
Then just post the oops along with the problem description the netfilter/netdev mailing-list and get the upstream networking people resolve this bug for you. They certainly will ask you to test for some patches, which sounds like an acceptable trade to me. Please at least agree that enabling preemption is a workaround and not a fix. > > > > --- a/net/ipv4/netfilter/nf_nat_core.c > > > +++ b/net/ipv4/netfilter/nf_nat_core.c > > > > This doesn't seem to fix any alignment issues, does it? > > No. > > Users can now choose which preemption mode they want. Is this ok? > > Luka > > Index: Config.in > =================================================================== > --- Config.in (revision 28166) > +++ Config.in (working copy) > @@ -231,6 +231,33 @@ > bool "Compile the kernel with SysRq support" > default n > > + choice > + prompt "Compile the kernel with selected preemption model" > + default KERNEL_PREEMPT_NONE > + help > + Select the preemption model you wish to use. > + > + config KERNEL_PREEMPT_NONE > + bool "No Forced Preemption (Server)" > + help > + Select this option if you are building a kernel for a server or > + scientific/computation system, or if you want to > maximize the > + raw processing power of the kernel, irrespective of scheduling > + latencies. > + > + config KERNEL_PREEMPT_VOLUNTARY > + bool "Voluntary Kernel Preemption (Desktop)" > + help > + Select this if you are building a kernel for a > desktop system. > + > + config KERNEL_PREEMPT > + bool "Preemptible Kernel (Low-Latency Desktop)" > + help > + Select this if you are building a kernel for a > desktop or > + embedded system with latency requirements in the milliseconds > + range. > + endchoice > + > comment "Package build options" Now this looks better, I am not opposed at all in us exposing such a kernel configuration option to users through OpenWrt's menuconfig. -- Florian _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
