**** BEGIN LOGGING AT Mon Oct 29 02:59:56 2007
Oct 29 10:03:17 <CIA-23> florian * r9458 /trunk/target/linux/rb532/ (config-2.6.22 files/arch/mips/rb500/devices.c): Resync kernel config, put back yellow led registration (#2607)
Oct 29 10:09:48 <CIA-23> florian * r9459 /trunk/target/linux/x86/mediacenter/profiles/s100.mk: Update S100 profile (#2587)
Oct 29 10:31:18 <CIA-23> florian * r9460 /trunk/package/iptables/files/firewall.init: Only masquerade non routable addresses (#2535)
Oct 29 10:59:13 <farnz_> [florian]: You wouldn't happen to know the intended relationship between $WAN and $WANDEV in the firewall scripts, would you?
Oct 29 10:59:55 <nbd> farnz: wandev is currently only relevant for pptp
Oct 29 11:00:13 <nbd> because on pptp you need firewalling both for the ip on the interface itself and for the ip on the ppp device
Oct 29 11:00:31 <farnz> nbd: So (for PPPoA), I expect $WAN to be the PPP device, not the underlying ATM device?
Oct 29 11:00:35 <CIA-23> florian * r9461 /trunk/package/iptables/files/firewall.init: Only masquerade LAN, other settings need manual tweaking
Oct 29 11:00:39 <nbd> farnz: yes
Oct 29 11:01:04 <farnz> Thanks. That's the information I need to bug-hunt.
Oct 29 11:01:15 <nbd> enjoy the hunt
Oct 29 11:07:11 <farnz> Rest of the script made sense; it's just that bit that didn't.
Oct 29 11:15:51 <farnz> And it's a PEBKAC error.
Oct 29 12:10:32 <slapin_nb> hi, all!
Oct 29 12:10:42 <slapin_nb> ejka, ping
Oct 29 15:09:15 <nabcore> anyone any ideas on this? https://dev.openwrt.org/ticket/2555
Oct 29 15:12:00 <farnz> nabcore: Decode the call trace, and I can go looking for you.
Oct 29 15:13:49 <nab-core> farnz; can you suggest any reading materials for "decoding the call trace" so that I can give you the optimum information
Oct 29 15:14:02 <cardone> compile with -g
Oct 29 15:14:32 <nab-core> ok
Oct 29 15:14:39 <farnz> Or look in System.map
Oct 29 15:15:08 <farnz> You're aiming to turn all the addresses in the call trace into function line numbers.
Oct 29 15:15:29 <nab-core> ok; Should I run make kernel_menuconfig and turn on some debugging options?
Oct 29 15:16:22 <farnz> I just want a fighting chance at working out which NULL pointer mac80211 has jumped through.
Oct 29 15:16:43 <farnz> http://ds9a.nl/symoops.html
Oct 29 15:17:08 <nab-core> ah ok; thanks I'll have a read of that now. Thanks
Oct 29 15:22:32 <nab-core> ok; compiling now
Oct 29 15:48:36 <nabcore> I can't seem to trigger trigger the crash on the debugging symbols kernel...
Oct 29 16:18:04 <nabcore> farnz; having compiled with Kernel hacking -->{Kernel Debugging, Compile the kernel with debug info}, I still get a very similar output on Oops as in the ticket: http://pastebin.ca/753832
Oct 29 16:20:03 <farnz> nabcore: http://ds9a.nl/symoops.html tells you how to turn the trace into line numbers.
Oct 29 16:22:18 <farnz> In particular, which line of which file is your pastebin's line 29 referring to.
Oct 29 16:34:39 <nabcore> ok
Oct 29 16:56:10 <dhr> how can I find a committer for a 1 line patch?  It is simple, it fixes a real problem, it has been sitting in trac for about a month.  See the last message in https://dev.openwrt.org/ticket/1936
Oct 29 17:07:37 <nabcore> farnz; within the build directory; /scratch/openwrt/trunk/toolchain_build_mipsel/gdb-6.3/gdb/gdb vmlinux
Oct 29 17:07:51 <nabcore> (gdb) list *(ieee80211_hw_config+0x20/0x9c)
Oct 29 17:08:01 <nabcore> No symbol "ieee80211_hw_config" in current context.
Oct 29 17:08:29 <nabcore> Do I need to somehow tell gdb about a module that the kernel will load at some point in future?
Oct 29 17:09:05 <farnz> nabcore: Look in that webpage, under "The quick way"
Oct 29 17:09:15 <farnz> nabcore: It's in the mac80211 module.
Oct 29 17:11:11 <farnz> I *think* that gdb openwrt/build_dir/linux-ar7/mac80211/mac80211/ieee80211.o will open the right file, then "list ieee80211_hw_config+0x20/0x9c"
Oct 29 17:11:29 <farnz> If that doesn't work, try "list ieee80211_hw_config+0x20" and "list ieee80211_hw_config+0x9c"
Oct 29 17:11:32 <nabcore> ok
Oct 29 17:13:43 <nabcore> http://pastebin.ca/753901
Oct 29 17:14:40 <farnz> Try "list ieee80211_hw_config+0x20" and "list ieee80211_hw_config+0x9c"
Oct 29 17:15:25 <nabcore> http://pastebin.ca/753904
Oct 29 17:16:09 <farnz> OK, my foul-up there. Try "list *(ieee80211_hw_config+0x20)" and "list *(ieee80211_hw_config+0x9c)"
Oct 29 17:16:27 <nabcore> ok
Oct 29 17:17:46 <nabcore> http://pastebin.ca/753909
Oct 29 17:19:00 <farnz> Gah. Still not finding anything useful (MIPS has imprecise exceptions, hence the two numbers).
Oct 29 17:19:16 <nabcore> ok :(
Oct 29 17:24:35 <nabcore> ah, well. Thanks for all your guidance on getting me that far anyway farnz.
Oct 29 17:25:42 <farnz> Might be worth trying GDB on the mac80211.ko file.
Oct 29 17:27:46 <nabcore> same result
Oct 29 17:29:54 <farnz> How good's your C? The function ieee80211_hw_config is at line 486 of ieee80211.c, so you could put printks in to find out what's NULL.
Oct 29 17:33:59 <nabcore> so; I'd be looking for a null pointer somewhere in the struct ieee80211_local *local
Oct 29 17:34:24 <farnz> Or for local being NULL.
Oct 29 17:34:38 <nabcore> ok
Oct 29 17:34:52 <farnz> The exception tells us that somewhere in that function body, a NULL pointer is dereferenced.
Oct 29 17:37:03 <farnz> If you can work out which function pointer, you're on your way to working out what acx-mac80211 doesn't implement but should.
Oct 29 17:37:09 <farnz> s/function//
Oct 29 17:37:43 <nabcore> ok
Oct 29 17:38:27 <nabcore> I'm not sure if this would work; http://pastebin.ca/753940
Oct 29 17:39:13 <farnz> One of those for each pointer dereference should work nicely.
Oct 29 17:42:25 <cardone> aurevoir à tous le monde!
Oct 29 17:43:37 <nabcore> and the other being?
Oct 29 17:47:05 <farnz> If you look down, after the if(local->sta_scanning) block, chan, mode, local->ops and local->ops->config all get dereferenced.
Oct 29 17:50:17 <nabcore> ok
Oct 29 17:55:19 <dhr> another way would be to look at the assembly code and try to map it to the C code.  Sometimes optimization makes that hard.
Oct 29 17:56:51 <nabcore> ok; this is it so far: http://pastebin.ca/753965
Oct 29 17:58:01 <farnz> Looks reasonable.
Oct 29 17:58:58 <nabcore> thanks; just got set that compiling and pop out to Tesco
Oct 29 19:18:52 <slapin_nb> rehi, all!
Oct 29 19:18:57 <slapin_nb> ejka, ping
Oct 29 19:26:35 <nabcore> farnz; http://pastebin.ca/754070
Oct 29 20:33:33 <farnz> nabcore: It's clearly a bug in acx-mac80211; when the scan for your IBSS completes, it doesn't update its state to indicate where your IBSS is running.
Oct 29 20:39:29 <nabcore> ok
Oct 29 20:46:42 <farnz> Actually, could be mac80211. Can we get someone to try with a different radio?
Oct 29 20:47:57 <nabcore> not sure; the bug is not easily triggered
Oct 29 20:48:43 <nabcore> I just keep setting the essid with iwconfig; that generally does it, but it's not a foolproof testcase
Oct 29 20:49:02 <farnz> Race condition, from the sound of it.
Oct 29 20:49:14 <farnz> Could well be in mac80211; I know they're cleaning up races in there.
Oct 29 20:49:57 <nabcore> thing is; I'm not totally sure of the version of mac80211 in the openwrt tree.
Oct 29 20:54:16 <nabcore> it's also unclear who actually is developing it http://acx100.sourceforge.net/wiki/Acx-mac80211
Oct 29 21:20:42 <farnz> mac80211 is developed by Mr Linville, so if it's in there, not in acx-mac80211, it'll get fixed.
Oct 29 21:21:25 <farnz> I think Matteo Croce is working hard on acx-mac80211.
Oct 29 21:23:30 <nabcore> ok
Oct 29 22:05:25 <CIA-23> nbd * r9462 /trunk/rules.mk: fix empty download dir error
Oct 30 00:48:02 <nabcore> ejka; any joy with that "tx dma ring full" bug?
**** ENDING LOGGING AT Tue Oct 30 02:59:56 2007