Hacking on the rtl8366S
Dave Taht
dave.taht at gmail.com
Fri Jun 3 23:54:16 EDT 2011
If anyone cares, a copy of this build is at:
http://huchra.bufferbloat.net/~cerowrt/cerowrt-wndr3700-dbg/
and the kernel is at:
http://huchra.bufferbloat.net/~cerowrt/vmlinux
On Fri, Jun 3, 2011 at 9:49 PM, Dave Taht <dave.taht at gmail.com> wrote:
> So I built a fresh build of openwrt from git head, patched in my
> preliminary patch to the switch, compiled it with oprofile support, and
> turned on -O2 rather than -Os, in my usual approach to all-up testing that
> makes it hard to track down what's really going on without backtracking.
>
> The net result with iperf was better than before,
> with iptables and qos turned entirely off, no nat, etc.
> pings stayed very flat and well below 8ms, down from 100ms.
>
> elara: [ 3] 0.0-60.0 sec 435 MBytes 60.7 Mbits/sec
> io: [ 3] 0.0-60.0 sec 495 MBytes 69.2 Mbits/sec
> leda: [ 3] 0.0-60.9 sec 226 MBytes 31.1 Mbits/sec
> thebe: [ 3] 0.0-60.0 sec 105 MBytes 14.7 Mbits/sec
>
> (how all this stuff is routed is beyond the scope of this, but only
> partially explains the discrepancies above)
>
> Oprofiling a later run, we're spending a lot of time in an unaligned trap,
> and I have no idea why iptables and conntrack even register.
>
> I am not sure at the moment how to track down the source of the alignment
> fault, I assume I can look at the performance counter somehow, and backtrack
> that to a given function or functions. It's late...
>
> samples cum. samples % cum. % app name symbol
> name
> 14992 14992 22.7158 22.7158 vmlinux do_ade
> 10054 25046 15.2338 37.9496 ip_tables
> /ip_tables
> 7257 32303 10.9958 48.9454 nf_conntrack
> /nf_conntrack
> 3398 35701 5.1486 54.0941 vmlinux
> handle_adel_int
> 2613 38314 3.9592 58.0533 vmlinux ip_rcv
> 2356 40670 3.5698 61.6231 vmlinux
> nf_iterate
> 1869 42539 2.8319 64.4550 iptable_nat
> /iptable_nat
> 1626 44165 2.4637 66.9187 vmlinux
> r4k_dma_cache_inv
> 1544 45709 2.3395 69.2582 nf_conntrack_ipv4
> /nf_conntrack_ipv4
> 1331 47040 2.0167 71.2749 vmlinux
> ag71xx_poll
> 1011 48051 1.5319 72.8068 vmlinux
> ip_route_input_common
> 988 49039 1.4970 74.3038 vmlinux
> ret_from_exception
>
>
>
> asmlinkage void do_ade(struct pt_regs *regs)
> {
> unsigned int __user *pc;
> mm_segment_t seg;
>
> perf_sw_event(PERF_COUNT_SW_ALIGNMENT_FAULTS,
> 1, 0, regs, regs->cp0_badvaddr);
> /*
> * Did we catch a fault trying to load an instruction?
> * Or are we running in MIPS16 mode?
> */
> if ((regs->cp0_badvaddr == regs->cp0_epc) || (regs->cp0_epc & 0x1))
> goto sigbus;
>
> pc = (unsigned int __user *) exception_epc(regs);
> if (user_mode(regs) && !test_thread_flag(TIF_FIXADE))
> goto sigbus;
> if (unaligned_action == UNALIGNED_ACTION_SIGNAL)
> goto sigbus;
> else if (unaligned_action == UNALIGNED_ACTION_SHOW)
> show_registers(regs);
>
> /*
> * Do branch emulation only if we didn't forward the exception.
> * This is all so but ugly ...
> */
> seg = get_fs();
> if (!user_mode(regs))
> set_fs(KERNEL_DS);
> emulate_load_store_insn(regs, (void __user *)regs->cp0_badvaddr,
> pc);
> set_fs(seg);
>
> return;
>
>
>
> --
> Dave Täht
> SKYPE: davetaht
> US Tel: 1-239-829-5608
> http://the-edge.blogspot.com
>
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat-devel/attachments/20110603/21a92ca4/attachment-0002.html>
More information about the Bloat-devel
mailing list