**** BEGIN LOGGING AT Sun Dec 13 02:59:57 2009 Dec 13 12:46:12 florian * r18769 /packages/utils/schedtools/ (. Makefile): [package] add schedtools (#6342) Dec 13 12:46:15 florian * r18770 /packages/libs/libdmapsharing/Makefile: [package] update libdmapsharing to 1.9.0.15 (#6350) Dec 13 12:46:17 florian * r18771 /packages/net/dmapd/Makefile: [package] update dmapd to 0.0.19 (#6349) Dec 13 12:52:41 florian * r18772 /packages/net/xl2tpd/Makefile: [package] add missing xl2tpd libpcap dependency (#6351) Dec 13 19:12:29 hmm is there anyone that could help me with ar8316 support? Dec 13 19:13:21 russo: how ar8316-specific are your questions? Dec 13 19:13:46 well its not supported by swconfig yet :) Dec 13 19:14:00 and the question is, how portable is the ar8216 implementation Dec 13 19:14:23 russo: do you have datasheets? Dec 13 19:15:33 i wish ;) Dec 13 19:15:41 i wouldn't be complaining if i did Dec 13 19:15:46 i would get to it :D Dec 13 19:20:15 russo: do you have a link for the ar8216 driver? Dec 13 19:22:23 https://dev.openwrt.org/browser/trunk/target/linux/generic-2.6/files/drivers/net/phy/ar8216.c Dec 13 19:22:38 that and the header obviously Dec 13 19:25:32 rtz: what do you think? Dec 13 19:25:41 i emailed atheros... still waiting though Dec 13 19:27:17 russo: I doubt you can easily port it Dec 13 19:27:44 i doubt i can port it without the datasheet :/ Dec 13 19:27:47 russo: the ar8316 semms to support gbit Dec 13 19:27:50 yeah Dec 13 19:28:03 but there are patches to get one port running Dec 13 19:28:13 just not the switch Dec 13 19:28:30 russo: you could ask nbd how he menaged to write the first driver Dec 13 19:28:49 yeah... nbd is hard to catch on irc :) Dec 13 19:29:00 russo: do both have the same number of ports? Dec 13 19:29:08 yup Dec 13 19:29:31 the 8316 really is the "gigabit version" of the 8216 Dec 13 19:29:40 i got a datasheet for ar8216 under nda with explicit permission to release the driver under gpl Dec 13 19:29:44 i mean i can imagine the implementation is not that different :) Dec 13 19:29:53 oh hi btw nbd :) Dec 13 19:29:54 unfortunately i haven't been able to obtain one for ar8316 yet Dec 13 19:29:57 hi there Dec 13 19:30:06 hmm Dec 13 19:30:15 but i know that the register values for ar8316 looks very similar Dec 13 19:30:40 how do you know that? what kind of debugging have you done so far? Dec 13 19:30:58 i'm setting up a tftp right now to play with Dec 13 19:31:03 i've checked the initialization that the routerstation pro boot loader does Dec 13 19:31:11 oh okay Dec 13 19:31:17 unfortunately, ubnt hasn't released sources to it Dec 13 19:31:20 which is a gpl violation Dec 13 19:31:33 so maybe you should try contacting them to ask for the sources Dec 13 19:31:44 thats actually what i was planning to do Dec 13 19:31:56 do they release their sources on trunk? Dec 13 19:32:06 ? Dec 13 19:32:12 sorry Dec 13 19:32:14 i meant to say Dec 13 19:32:21 do they have a repo for their sources? Dec 13 19:32:35 they occasionally release some code drops Dec 13 19:32:47 but their openwrt based firmware does not reinit the switch Dec 13 19:32:55 yeah i heard Dec 13 19:33:21 it bridges eth1 into a regular switch, doesn't it? Dec 13 19:36:31 crap, usb is broken :/ Dec 13 19:36:43 well, I have to go for now Dec 13 19:43:07 nbd: could you please check this patch and it's below result here: http://openwrt.pastebin.com/m82d2314 Dec 13 19:43:24 the question is why I always get the same old partition map? Dec 13 19:46:16 solca: maybe the mtd map is not even used? kann you post the full dmesg? Dec 13 19:46:37 solca: iirc you need to specify board=wrt160nl in the boot args Dec 13 19:46:47 nbd: i had one more question when you have a moment, namely, your git mirror, how often does it get updated? Dec 13 19:47:04 russo: every few minutes Dec 13 19:47:19 is it just a cron script? Dec 13 19:47:26 yes Dec 13 19:47:29 nice :) Dec 13 19:47:37 i might talk to the guys at work Dec 13 19:47:43 we all use openwrt Dec 13 19:47:58 maybe we'll host something like that too (since we don't pay for bandwidth) Dec 13 19:48:15 ;) Dec 13 19:48:22 bbl Dec 13 19:48:29 right, cu Dec 13 19:50:00 xMff: hi! Dec 13 19:50:05 xMff: http://openwrt.pastebin.com/m5c4808a2 Dec 13 19:53:12 xMff: btw those partitions are always protected, can't write to them yet Dec 13 19:53:58 solca: maybe it misdetects the board, another idea; can you compare the u-boot bootargs from the working and the non working devices? Dec 13 19:54:15 solca: Iirc you need this in u-boot: setenv bootargs 'board=WRT160NL' Dec 13 19:55:34 ah no, you have it already set Dec 13 19:55:58 if you check the dmesg command line is ok and dmesg said: MIPS: machine is Linksys WRT160NL Dec 13 19:56:21 so I pressume is ok, but will check u-boot with 'printenv' Dec 13 19:57:41 xMff: bootargs=console=ttyS0,115200 root=31:04 rootfstype=squashfs init=/sbin/init mtdparts=ar7100-nor0:256k(u-boot),7808k(linux),64k(nvram),64k(ART),64k(filesystem) bootver=1.1.5 Dec 13 19:57:51 that part is not set Dec 13 19:58:39 solca: I think the openwrt kernel has the commandline embedded Dec 13 19:58:56 because it clearly shows another one as passed by uboot Dec 13 19:59:08 ahh ok, in that case this one is ignored Dec 13 19:59:28 yea, because dmesg shows other command line Dec 13 19:59:36 makes sense also otherwise one would have to modify the bootloader in order to install openwrt Dec 13 20:00:01 but why my new mappings doesn't show up? Dec 13 20:00:11 I have no idea Dec 13 20:00:30 how did your recompiler after chaning this? Dec 13 20:01:03 I did a `make target/linux/clean world` Dec 13 20:01:18 hmm should be okay then Dec 13 20:01:20 and I verify in the buildir and the code is there Dec 13 20:01:43 even I verify with strings the vmlinux file and at least solcatest is there too Dec 13 20:01:52 very weird Dec 13 20:02:16 yeah, that's why your suggestion about removing the mask is not working Dec 13 20:02:26 dunno why Dec 13 20:02:55 ah wait Dec 13 20:03:05 maybe the partition table you edited is just a fallback Dec 13 20:03:30 --> keep talking! --> keep talking! --> Dec 13 20:04:46 "6 wrt160nl partitions found on MTD device spi0.0" Dec 13 20:05:20 maybe it searches the uboot environment or so to get the partition layout and the one you edited is only used if the environment is empty Dec 13 20:06:59 xMff: does this patch have anything to do with this: Dec 13 20:07:02 target/linux/ar71xx/patches-2.6.30/109-mtd-wrt160nl-trx-parser.patch Dec 13 20:07:38 likely Dec 13 20:12:30 solca: yes, seems like it uses a real partition parser instead of the hardcoded map, so maybe the offsets for nvram and art are just wrong after all Dec 13 20:12:52 target/linux/ar71xx/files/drivers/mtd/wrt160nl_part.c Dec 13 20:13:07 this is the partition parser registered by the patch mentioned above Dec 13 20:15:02 and the offsets for art and nvram are defined as flashsize - 2 * erasesize and flashsize - erasesize Dec 13 20:15:27 now it would be interesting to know whether this matches the actual physical flash locations Dec 13 20:16:01 both sizes are 64KB Dec 13 20:16:48 solca: I'd suggest to edit target/linux/ar71xx/patches-2.6.30/109-mtd-wrt160nl-trx-parser.patch , add a new partition that spans the entire flash (0 to master->size) Dec 13 20:17:00 and then use that partition to dump the whole flash Dec 13 20:17:12 and examine it offline Dec 13 20:17:30 *off-device whatever Dec 13 20:18:20 I already examine (via your vbindiff tool) u-boot, nvram and art partitions Dec 13 20:18:42 I must say you were right, that's a very nice tool! Dec 13 20:18:50 and look whether the stuff at (size-128k) looks like art and the stuff at (size-64k) like nvram Dec 13 20:19:55 I just find another way to flash: from u-boot Dec 13 20:20:04 with the cp command Dec 13 20:20:29 to me it looks like the information about the flash partitioning is encoded within the image itself Dec 13 20:20:38 in the try header Dec 13 20:20:42 *trx header Dec 13 20:21:04 yeah, probably Dec 13 20:21:44 the thing with u-boot is that I don't know where to put for example the nvram in what offset in ram? Dec 13 20:22:13 I think the offset doesn't really matter expect when executing a kernel Dec 13 20:22:19 *except Dec 13 20:22:43 i have a patch for olsrd from upstream that fixes (or makes vastly better at a minimum) the memory leak i discovered recently Dec 13 20:23:34 xMff: I read this example: https://forum.openwrt.org/viewtopic.php?pid=81962#p81962 Dec 13 20:23:57 russell_: oh your mysterious memleak way caused by olsrd? Dec 13 20:24:03 yeah Dec 13 20:24:16 show me the patch Dec 13 20:24:18 procps ftw! Dec 13 20:24:26 one sec Dec 13 20:24:38 i wish trac supported git Dec 13 20:24:45 i mean Dec 13 20:24:49 really supported git :P Dec 13 20:24:54 and everyone would migrate to git Dec 13 20:25:02 then writing patches would be so much easier Dec 13 20:28:09 xMff, drop this into packages/net/olsrd/patches: http://iris.personaltelco.net/~russell/200-mid_memory_cleanup.patch Dec 13 20:30:13 russell_: looks nasty, does it happen with many ifup/ifdown cycles or during normal operation too? Dec 13 20:30:23 normal operation Dec 13 20:30:37 on our network it grows about 700k/day Dec 13 20:31:16 olsrd 0.5.6-r7 ? Dec 13 20:31:21 yeah Dec 13 20:31:29 grr Dec 13 20:31:51 * xMff wonders when there's a really stable version Dec 13 20:31:53 grr Dec 13 20:31:57 8 is ever so much a nicer number Dec 13 20:32:01 i finally isntalled oepnwrt on my rb450g Dec 13 20:32:16 eth0 is down if the routerboard booted from nand and not from tftp Dec 13 20:33:53 russell_: thanks, I'll take care of it. Do you have a git url or sth.? Dec 13 20:35:20 hang on Dec 13 20:36:30 the strange thing is, I use olsrd 0.5.6-r7 as well and I see no memory leaks Dec 13 20:36:37 but I don't have httpinfo loaded Dec 13 20:39:24 * russell_ neither Dec 13 20:40:02 hmm Dec 13 20:40:35 i can't find a git web thingie, but i generated the patch from a: git clone git://olsr.org/olsrd.git -b stable ; git diff HEAD~ HEAD Dec 13 20:41:10 commit c9134a38bec7cefc3ca2e0e5faeb0f8d1b4c8bc7 Dec 13 20:45:16 i do use txtinfo plugin though Dec 13 20:46:10 me too :-/ Dec 13 20:46:36 jow * r18773 /trunk/feeds.conf.default: [packages] add a src-link example to feeds.conf.default Dec 13 20:46:59 xMff, how big is your network? Dec 13 20:47:12 russell_: ~250 nodes Dec 13 20:47:17 hmm Dec 13 20:47:29 most of them with a way older olsrd Dec 13 20:47:33 0.5.5 Dec 13 20:48:47 our olsrd.conf is here: http://personaltelco.net/~russell/grank-olsrd.conf Dec 13 20:48:49 fwiw Dec 13 20:49:08 almost the same as ours Dec 13 20:52:43 jow * r18774 /packages/net/olsrd/ (Makefile patches/200-mid_memory_cleanup.patch): [packages] olsrd: fix multiple memleaks in tc and mid handling and the httpinfo plugin - thanks russell Dec 13 20:57:28 nbd: when you get back, for what its worth, i did get the latest linux patch that mikrotik had recently. You can take a look at it here: http://nedos.net/stuff/linux-2.6.27.39.patch.gz and: http://nedos.net/stuff/mips.config Dec 13 21:01:05 nbd: also the patch contains some microsd delcarations, how far is openwrt's microsd support? Dec 13 21:02:56 nbd: anyway if you don't mind, pm me what you think, i'll probably go off in a bit, but i'll get any pms. I also wrote ubiquiti and mikrotik (again). Hopefully, someone responds. Dec 13 21:07:28 russell_: the memleak patch seems to clean only memory on exit, how can it clear runtime memory? Or is that memory left behind by forked childs? Dec 13 21:08:31 russell_: oh, mails on this topic just hit the list... going to update my stuff too Dec 13 21:19:57 xMff: I finally was able to restore nvram and art partitions! Dec 13 21:20:14 but from those the one needed for wifi operation is the art partition Dec 13 21:20:25 :-/ Dec 13 21:20:29 without it ath9k will not work Dec 13 21:20:54 xMff: which list? Dec 13 21:21:59 russell_: freifunk Dec 13 21:22:22 xMff: you are a great hacker!!! thank you for helping me!!! Dec 13 21:22:47 solca: np but it would be very interesting to know why art is missing in the first place Dec 13 21:23:45 solca: if it really contains hardware specific calibration data and if it gets erased somehow on install then this would be a rather big issue Dec 13 21:24:24 xMff: it seems everything except u-boot was erased when upgrading from original firmware on unused WRT160NL to latest Linksys firmware Dec 13 21:24:40 on those that I skip the upgrade to latest nvram and art was not erased Dec 13 21:25:03 so it must be a original or latest linksys firmware bug Dec 13 21:25:14 yeah, a big issue IMO Dec 13 21:25:49 hmm but if the latest linksys firmware just erases it then it can't be so important after all - at least not hardware specific Dec 13 21:25:58 unless it relocates the data to another place Dec 13 21:26:41 well, on those devices with erased ART wifi doesn't work neither with original Linksys firmwares Dec 13 21:26:47 so IT IS important Dec 13 21:27:27 xMff: how important is calibration data? Dec 13 21:27:44 solca: well I think it can hurt wifi performance badly Dec 13 21:27:50 but maybe it is just an urban legend Dec 13 21:29:02 hmm that's scary... Dec 13 21:33:16 xMff: better I'll ask in #madwifi if ath9k needs some firmware or calibration data to successfully load Dec 13 21:33:23 maybe they can help me Dec 13 21:34:54 solca: good idea, tell me what you found out Dec 13 21:35:55 xMff: ok! Dec 13 21:36:57 solca: does the restoring of art also fixes the mac issue? Dec 13 21:37:30 xMff: nope, but restoring nvram fix both eth0 & eth1 MAC addresses Dec 13 21:37:35 ok Dec 13 21:37:54 obviously you'll end up with the same mac on each device then unless you change it Dec 13 21:38:48 can you try whether the "nvram" tool works on the wrt160nl ? Dec 13 21:38:48 xMff: yea, I modify the nvram package Makefile and I modify it with it (btw: et0macaddr, lan_hwaddr, wan_hwaddr & wl0_hwaddr) Dec 13 21:39:24 yeah, it works every other run, weird... Dec 13 21:40:11 so you need to try multiple times? Dec 13 21:40:43 yeah Dec 13 21:40:52 weird Dec 13 21:41:00 what's the error? Dec 13 21:41:02 will strace it... let me check Dec 13 21:41:52 xMff: error: http://openwrt.pastebin.com/m46232c62 Dec 13 21:43:05 is there "nvram" in /proc/mtd ? Dec 13 21:44:23 yes Dec 13 21:45:31 hmm Dec 13 21:45:41 xMff: strace: http://openwrt.pastebin.com/ma3dec63 Dec 13 21:45:57 just the last lines, I couldn't find the problem though Dec 13 21:46:19 must be a pure coding bug IMHO Dec 13 21:46:27 likely ;) Dec 13 21:46:29 but I haven't check the source code Dec 13 21:49:16 ah, invalid magic Dec 13 21:50:17 xMff: where to? Dec 13 21:50:58 in the nvram header Dec 13 21:51:43 is the wrt160nl low or big endian? Dec 13 21:51:53 mips ... big Dec 13 21:53:12 probably an endianess issue Dec 13 21:53:45 how can I check if it is little or big endian? Dec 13 21:54:32 the weird thing is that sometimes it works others not Dec 13 21:54:48 on your host "file" on some mips binary Dec 13 21:55:09 ok, let me check Dec 13 21:55:10 yeah someone needs to debug it some time, I don't have the hardware around for it Dec 13 21:56:35 nvram: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1, dynamically linked (uses shared libs), with unknown capability 0x41000000 = 0xf676e75, not stripped Dec 13 21:57:55 big endian Dec 13 21:59:10 same as the broadcom boards like WRT54GL? Dec 13 21:59:22 nope gls are low endian Dec 13 22:00:16 good to know Dec 13 22:00:17 solca: if you do "nvram set foo=bar" and "nvram show" does it work then? Dec 13 22:01:57 yeah, that works so far Dec 13 22:02:07 nasty Dec 13 22:02:25 I'm not getting now the error when 'show' Dec 13 22:02:34 yes, the explaination is simple Dec 13 22:02:48 ? Dec 13 22:02:50 if you do something that writes, it copies the mtd contents to a staging file in /tmp Dec 13 22:02:57 and operates on that Dec 13 22:03:12 if you do something read only, it operates on the mtd device Dec 13 22:03:19 /tmp/.nvram Dec 13 22:03:21 yes Dec 13 22:03:29 hmm I see Dec 13 22:03:36 if you rm that and run nvram show, you should get the error again Dec 13 22:03:51 yeah it fails Dec 13 22:04:09 the file in /tmp is written back to flash if you execute "nvram commit" Dec 13 22:05:09 but don't ask me why it works with the staging file :D Dec 13 22:05:24 its contents should be exactly the same as those in mtd Dec 13 22:05:38 yeah, `rm -f /tmp/.nvram; nvram show` sometimes works now Dec 13 22:06:10 maybe some mmap foo Dec 13 22:06:28 weird, setting 'nvram set foo=bar' always succeeds Dec 13 22:07:22 I think the code is not really endian safe, it is more or less a sraight copy of the broadcom code Dec 13 22:07:37 with a cli tacked on Dec 13 22:07:55 but who knows Dec 13 22:08:35 or mmap have a strange behavior on mips be? Dec 13 22:08:43 s/be/big endian/ Dec 13 22:08:53 can't imagine Dec 13 22:08:58 that would break a lot of stuff Dec 13 22:09:10 yeah, unprobable Dec 13 22:43:55 nbd: you added a patch to packages/net/olsrd/patches last April. the olsrd dudes are wondering if they should be integrating that (and the other one from July) upstream. Dec 13 22:47:44 russell_: yes, the olsrd duded should make the proc poking configurable Dec 13 22:47:48 *dudes Dec 13 22:48:33 the patch (if i'm remembering) just #if 0's it out Dec 13 22:49:04 yes because the init script takes care of it Dec 13 22:49:39 but some users just start the binary with some config file, in this case it would be annoying to fiddle with proc I think Dec 13 22:51:15 i'm not clued in sufficiently to make a valuable suggestion on this, maybe you should suggest something appropriate directly to the olsrd dudes? Dec 13 22:51:43 maybe Dec 13 22:52:32 interesting, another mtd failure. i had another one recently. Dec 13 22:52:48 solar wind Dec 13 22:52:56 maybe it's panic/rebooting before it finishes flashing Dec 13 22:54:04 i did set kernel.panic_on_oops=1 Dec 13 22:55:15 i can see why a running system might consider having its flash written out from under it somewhat rude and be upset about it. Dec 13 23:21:05 it actually works okay as long as no services are poking the storage Dec 13 23:21:53 but if some cronjob etc. runs during mtd write it'll result in lzma read errors that will make the kernel panic **** ENDING LOGGING AT Mon Dec 14 02:59:56 2009