**** BEGIN LOGGING AT Sat Dec 12 02:59:57 2009 Dec 12 05:30:38 nbd: i think i figured out my "memory leak" i was bugging you about Dec 12 06:52:47 russell_: details please Dec 12 06:52:51 cshore1: sounds good Dec 12 06:54:44 nbd: it was olsrd, i'm pretty sure. busybox ps only shows VSZ, not RSS. VSZ wasn't growing very much, but RSS is. I'll be following up with the olsrd people. In the meantime, i'm just cronjob'ing a restart in the middle of the night. Dec 12 06:56:59 nbd: brcm2.6 handel N at all? Dec 12 06:57:27 there is a inode or dentry cache leak that was fixed recently (.32-ish?), but it supposedly isn't really significant because the memory will get reclaimed under memory pressure of with an echo 3 > /proc/sys/vm/drop_caches Dec 12 06:57:52 s/of/or/ Dec 12 06:59:59 Weedy: nope Dec 12 07:00:33 russell_: interesting Dec 12 07:01:27 so if i want to play with a netgear WNDR3300 i'm stuck on 2.4 or just plain stuck with b/g Dec 12 07:16:05 nbd: linux git commit 29f12ca32122db98481150be09d35bd72b68045e Dec 12 07:31:35 yeah, doesn't look like a big leak to me Dec 12 07:32:13 weirdly the missing memory doesn't show up in the caches total Dec 12 07:32:52 i got 100 meg visible again by the drop_caches on an alix after a few months run time Dec 12 07:34:34 https://personaltelco.net/graphs/graph_view.php?action=tree&tree_id=4&leaf_id=134&host_group_data=graph_template:13 Dec 12 07:36:18 *sigh* ... /me just researched these modems again Dec 12 07:37:03 the 4Euro dsl2+ ones...bcm6338 only dsl and one eth, serial on 3.3V on already soldered pinheader Dec 12 07:38:00 congster DSL-Box Zwei .. seems to have 4mbit of spi flash and only 2mbyte of ram. runs tiny bridge Dec 12 07:38:27 tcom speedport 200 seems to be the same (from exteriour pictures, placement of plugs etc) Dec 12 07:42:02 the pcb is kinda made for different types of ram it seems. i wonder which one is the 'biggest one' which fits the second pinout (+2pads on each row, makes 4 more pins Dec 12 07:49:55 so it seems any openwrt-attempts with that hardware are postponed to somebody finding the fun in soldering in different (bigger) ram Dec 12 10:54:09 <_trine> has anyone figured out why trunk will not boot anymore? Dec 12 12:39:34 _trine: it just booted for me Dec 12 12:40:36 r18763 on wgt634u Dec 12 12:43:09 <_trine> I am using a wrt160nl and the usb drivers Dec 12 12:43:43 <_trine> now my serial line seems not to be working properly Dec 12 12:43:58 <_trine> I will do a windows trick and reboot :( Dec 12 12:45:17 <_trine> hmm the serial is responding again maybe it was a delay because I am compiling Dec 12 12:48:10 <_trine> I think this problem is related to the code specific to the wrt160nl Dec 12 12:48:32 <_trine> I am now compiling and trying different options Dec 12 13:08:32 _trine: wrt160nl switch driver is b0rked atm Dec 12 13:09:40 <_trine> ah thankyou Dec 12 13:11:01 <_trine> I have been trying different things for the last 2 days :( Dec 12 13:12:14 <_trine> solca, do you know at which revision it got b0rked Dec 12 15:34:26 root@OpenWrt:~# opkg install openswan_2.6.23-1_brcm-2.4.ipk Dec 12 15:34:26 Collected errors: Dec 12 15:34:26 * Packages were found, but none compatible with the architectures configured Dec 12 15:34:26 root@OpenWrt:~# uname -a Dec 12 15:34:26 Linux OpenWrt 2.4.35.4 #9 Mon Sep 14 08:35:07 UTC 2009 mips unknown Dec 12 15:35:01 can anyone shed some light on that? I'm pretty sure I'm compiling for the right platform Dec 12 15:37:57 older opkg trying to use newer packages Dec 12 15:52:54 hmm it is supposed to be 8.09RC2 firmware? Dec 12 15:53:13 is that "old" compared to the git/svn i used for package building? Dec 12 15:53:42 KAMIKAZE (8.09.2-RC2, r17574) Dec 12 15:53:48 I thought that was pretty new :) Dec 12 15:58:13 LetoTo: yes it is old compared to trunk, was branched off half a year ago and is binary incompatible Dec 12 15:58:46 LetoTo: use a branches/8.09 buildroot to build packages for 8.09.x Dec 12 15:59:51 ah Dec 12 15:59:59 well i can also flash it with trunk Dec 12 17:06:17 xMff: thanks. now getting further: Linux Openswan U2.6.23/K(no kernel code presently loaded) Dec 12 17:06:34 now to fix the kernel for ubsec / ocf / klips Dec 12 17:17:04 florian * r18766 /trunk/target/linux/rdc/ (6 files in 4 dirs): [rdc] add preliminary support for the bifferboard, patch from bifferos Dec 12 18:47:36 _trine: rtl8306 (wrt160nl switch) got b0rked @ r18699, r18709 semi fix it. Dec 12 18:47:49 _trine: if you want a working switch revert both Dec 12 18:52:56 <_trine> solca, the non booting issue,, I have now tracked it down to between 19640 and 18700 Dec 12 18:56:55 <_trine> solca, have you any idea what caused the problem? Dec 12 18:58:06 <_trine> solca, and could you explain at bit about which revision got the b0rk it's not clear in your sentence was it at 18699? Dec 12 18:59:08 <_trine> if it was do you know what possibly caused it? Dec 12 19:04:51 _trine: I'm talking just about the switch driver, afaik all svn revisions I tried are bootable Dec 12 19:05:10 can you explain the non-booting issue? Dec 12 19:09:25 <_trine> solca, http://pastebin.com/m294221ff Dec 12 19:09:34 * solca looking... Dec 12 19:09:40 <_trine> http://pastebin.com/m73fe7e7d Dec 12 19:10:07 <_trine> http://pastebin.com/m3ddd9df1 Dec 12 19:10:42 <_trine> all different compiles taking out things like parts of the usb stuff but all failed Dec 12 19:10:57 <_trine> http://pastebin.com/m70aa75e6 Dec 12 19:11:25 <_trine> that last one was compile with no usb storage component Dec 12 19:11:48 <_trine> and this compile without any usb stuff at all Dec 12 19:11:52 <_trine> http://pastebin.com/m72203cd2 Dec 12 19:12:26 <_trine> 18670 compiles and boots ok Dec 12 19:12:33 are you able to enter failsafe? Dec 12 19:12:34 as far as I can tell you the OOM swconfig kill is caused by the above switch driver breakage Dec 12 19:12:51 <_trine> xMff, no Dec 12 19:13:17 doesn't react on Ctrl-C ? Dec 12 19:13:53 <_trine> xMff, it will go into failsafe but it then crashes Dec 12 19:14:18 _trine: same here, it's because the above commits Dec 12 19:14:25 so no usable interactive shell? Dec 12 19:14:35 <_trine> no Dec 12 19:14:53 try reverting r18699, r18708 and r18709 Dec 12 19:15:26 <_trine> actually if you press a key when it tells you you can get a shell for a very brief period Dec 12 19:16:02 _trine: actually you can prevent the crash, comment the switch section at network config Dec 12 19:16:31 the crash is caused by a swconfig mem leak receiving netlink messages Dec 12 19:16:35 <_trine> just reflashing now Dec 12 19:16:57 which in turn caused a out-of-memory (OOM) kill Dec 12 19:18:01 I'll try to digg more info today about that to help nbd fix the switch driver Dec 12 19:19:22 <_trine> 18698 is ok Dec 12 19:19:28 <_trine> just flashed it Dec 12 19:19:58 <_trine> so solca it looks like you are correct Dec 12 19:20:24 <_trine> what happened at 18699? Dec 12 19:20:36 <_trine> or 18700 Dec 12 19:20:58 what happend is that nbd was fixing the switch driver being attached to eth1 where it must be attached to eth0 Dec 12 19:21:11 <_trine> I see Dec 12 19:21:15 so r18699 fixes that but broke somthing Dec 12 19:22:19 <_trine> well we are now on the way to mending now we know where it's broken Dec 12 19:23:06 hmm those switches are messy, if nbd can't fix it... hard to say ;) Dec 12 19:23:38 <_trine> I didn't have any problems with eth1 being wan Dec 12 19:24:26 _trine: eth1 always will be wan, problem is that the switch was attached to eth1 and must be attached to eth0 Dec 12 19:24:41 https://dev.openwrt.org/changeset/18699 Dec 12 19:25:34 it was fixing this: https://dev.openwrt.org/ticket/6309 Dec 12 19:27:07 <_trine> I see Dec 12 19:30:56 xMff: do you know what purpose has the "art" partition on the WRT160NL? Dec 12 19:31:27 solca: nobe, maybe some rescue/vendor stuff Dec 12 19:32:05 <_trine> I have 2 wrt160nl's so I have one for testing with Dec 12 19:32:20 solca: did you hexdump it? Dec 12 19:32:39 rtz: I have one WRT160NL that ath9k doesn't work, the art and nvram partitions are full with 0xFF Dec 12 19:33:05 that's the only difference between the working and non working ones Dec 12 19:33:17 solca: well, not much to do with that :/ Dec 12 19:33:35 weird thing is that I can erase nvram Dec 12 19:33:51 `mtd erase nvram` doesn't work Dec 12 19:34:03 <_trine> solca, do you use a serial cable to flash them with Dec 12 19:34:23 _trine: yep Dec 12 19:34:31 solca: maybe some memory config or something got messed up Dec 12 19:35:18 in the WRT54G era you used to erase nvram that way, in the WRT160NL is not possible Dec 12 19:35:59 so I'm figuring how to "re-fill" the nvram and art partitions from a working device Dec 12 19:36:02 <_trine> solca, why would you need to erase nvram on the wrt160nl Dec 12 19:36:03 any hints? Dec 12 19:36:33 <_trine> should not the nvram be recreated on each new flash Dec 12 19:36:40 _trine: to force the original fw to refill it in my probably twisted logic :) Dec 12 19:37:34 I find an erase flash command the u-boot but don't know if that will erase the bootloader too Dec 12 19:38:15 <_trine> maybe mtd erase_rootfs Dec 12 19:38:59 that would erase just the filesystem area Dec 12 19:39:20 <_trine> what about firstboot Dec 12 19:39:39 firstboot? Dec 12 19:39:57 <_trine> yes you can issue the command firstboot from cli Dec 12 19:40:11 <_trine> it puts it back to factory Dec 12 19:40:31 <_trine> in our case to the state it was in when you first flashed it Dec 12 19:41:28 ahh, no that just revert the jffs to the original squashfs Dec 12 19:41:44 I need something to revert the nvram to original factory defaults Dec 12 19:42:07 reset in the original linksys doesn't refill the nvram which is weird IMO... Dec 12 19:43:14 <_trine> there's also mtd -r erase rootfs_data Dec 12 19:43:18 I do not know how uboot handles it but but on broadcom platforms the nvram has a header structure holding a crc8 value over the contents, if this header is invalidated, the cfe repopulates the nvram area with hardcoded defaults Dec 12 19:44:28 xMff: that would be nice on this platform too but I can confirm the complete nvram area is filled with 0xFF so the bootloader should repopulate it Dec 12 19:44:41 but it seems it didn't Dec 12 19:44:57 maybe is just a cfe feature not in u-boot Dec 12 19:45:50 on wrt54gl devices I noticed that only the upper half of the whole nvram area was filled with content, the rest was completely filled with 0xFF Dec 12 19:46:11 maybe the mtd partitioning is wrong or the kernel maps the wrong block in your case? Dec 12 19:47:12 hmm maybe "art" holds calibration data or something similar for the radio hardware? Dec 12 19:47:46 xMff: that would suck... Dec 12 19:48:29 have you examined the "art" contents from a working device? any strings in there indicating the content? Dec 12 19:49:22 and are working and non-working devices exactly the same hardware revision? Dec 12 19:49:40 do they have the same flash chip? Dec 12 19:49:59 yea I did check with strings but no human readable but definetly there is tons of values there Dec 12 19:50:22 xMff: actually that is weird because working devices have a different flash chip than non working Dec 12 19:50:47 solca: hmm so it could be a different physical memory layout after all? Dec 12 19:50:55 but from dmesg I have seen the en25p64 is working for others here Dec 12 19:51:19 <_trine> both my wrt160nl's have different flash chips Dec 12 19:51:41 working: m25p80 spi0.0: mx25l64 (8192 Kbytes) Dec 12 19:51:48 ok, ath9k seems to pull its eeprom stuff from platform data Dec 12 19:52:29 xMff: where does that eeprom is stored? Dec 12 19:52:29 solca: maybe add some printf to ath9k/ahb.c and let it hexdump the eeprom data to dmesg or something Dec 12 19:52:49 solca: check the platform support bits to where the data is pulled from Dec 12 19:53:03 xMff: I have checked Dec 12 19:53:10 maybe it is even preloaded by the bootloader (copied into a specific memory location) Dec 12 19:53:17 I'm no expert in this Dec 12 19:53:56 but from where it is pulled, from main flash? are other on-chip flashes for ethernet and ath9k? Dec 12 19:54:14 u-boot always report the good MAC for eth0 Dec 12 19:54:20 hm I think from main flash Dec 12 19:54:45 but when booting this bad devices the MAC bits for eth0 are random created Dec 12 19:55:13 I have 50 WRT160NL for a Uni project here Dec 12 19:55:26 48 have this 0xFF filled in both nvram and art partitions Dec 12 19:55:45 and those 48 are defunct? Dec 12 19:55:46 and wifi doesn't work, both eth0 and eth1 have weird MAC addresses Dec 12 19:56:03 nope, they work fine except for ath9k Dec 12 19:56:07 and the ethernet MACs Dec 12 19:56:14 MAC addresses Dec 12 19:56:25 ath9k ath9k: failed to initialize device Dec 12 19:56:25 ath9k: probe of ath9k failed with error -22 Dec 12 19:56:49 I tracked down that error to "EPROM" bad values Dec 12 19:57:10 I see Dec 12 19:57:16 not unexpected Dec 12 19:57:19 imo Dec 12 19:57:46 xMff: we open the boxes, flash to latest linksys fw version and then to openwrt Dec 12 19:58:10 then we figure this, the first 2 devices where we do testings works fine Dec 12 19:58:27 but on those first two we didn't flash to latest linksys Dec 12 19:58:41 we skip that step plus tons of openwrt flashings :) Dec 12 19:59:15 hmm, maybe the latest linksys fw reorganizes stuff? Dec 12 19:59:51 yea, I find the original linksys fw and revert to that without luck, nvram and art continue empty Dec 12 20:00:10 xMff: any idea how could I copy from a working device to this non-working? Dec 12 20:00:29 well art and nvram are marked writeable in the mtd partition setup Dec 12 20:00:39 you can just use dd Dec 12 20:00:44 yea but everything I tried with mtd end with this: Could not open mtd device: nvram Dec 12 20:00:48 to /dev/mtdblockx Dec 12 20:00:56 what's the content of /proc/mtd ? Dec 12 20:01:20 dev: size erasesize name Dec 12 20:01:20 mtd0: 00040000 00010000 "u-boot" Dec 12 20:01:20 mtd1: 00130000 00010000 "kernel" Dec 12 20:01:20 mtd2: 00670000 00010000 "rootfs" Dec 12 20:01:20 mtd3: 00010000 00010000 "nvram" Dec 12 20:01:22 mtd4: 00010000 00010000 "art" Dec 12 20:01:24 mtd5: 007a0000 00010000 "firmware" Dec 12 20:01:27 symbolic names are resolved to /dev/mtdblockx via /proc/mtd by the mtd util Dec 12 20:01:43 so nvram would be mtd3 Dec 12 20:02:20 there should be a /dev/mtdblock3 Dec 12 20:02:21 I didn;t try with dd Dec 12 20:03:18 xMff: yes, there is mtdblock3 Dec 12 20:03:53 erase size is 0x10000 so use 65536 byte blocks when writing with dd to avoid erase overhead Dec 12 20:04:11 bs=65k ? Dec 12 20:04:14 64 Dec 12 20:04:28 oops, that's right Dec 12 20:04:42 dd bs=65536 if=/tmp/dump.bin of=/dev/mtdblock3 Dec 12 20:05:16 same for reading Dec 12 20:05:27 could busybox dd read from stdin? Dec 12 20:05:30 with if and of swapped of course ;) Dec 12 20:05:32 yes Dec 12 20:05:41 just ommit if= and pipe into dd Dec 12 20:06:13 I already have a nvram and art but I get it with: cat /dev/mtd3ro >nvram.bin Dec 12 20:06:16 was that ok? Dec 12 20:07:55 is it 65535 byte? Dec 12 20:08:36 /dev/mtdX are char devices, /dev/mtdblockX are block devices Dec 12 20:08:48 not sure whether both result in the same data Dec 12 20:08:49 65536 Dec 12 20:08:58 erm yes, sounds okay Dec 12 20:09:26 hmm, better I will get it as you say, via the block devices Dec 12 20:10:31 cmp reports both are the same Dec 12 20:10:37 I think it is just a compat thing Dec 12 20:11:03 iirc the block is just one more indirection to access the flash like a blkdev Dec 12 20:11:59 ok, now to try flashing to the bad device Dec 12 20:12:05 * solca prays... Dec 12 20:12:25 * xMff is curious whether the nvram contents survive a reboot Dec 12 20:16:05 * _trine wants to know who solca is praying to Dec 12 20:16:08 <_trine> :P Dec 12 20:16:38 cisco? Dec 12 20:17:08 <_trine> abandon hope all ye who enter cisco land Dec 12 20:20:41 _trine: praying to xMff so he is right and dd works... Dec 12 20:20:47 hmm, can't transfer the image Dec 12 20:20:54 will have to flash pre r18699 Dec 12 20:21:08 type it in by hand :P Dec 12 20:21:19 cat is all you need Dec 12 20:21:54 that's why I was prying you so you would do it but it seems you are not that powerfull :( Dec 12 20:26:17 xMff: dd: writing '/dev/mtdblock3': Operation not permitted Dec 12 20:26:38 solca: strange Dec 12 20:27:10 can you strace it? Dec 12 20:27:19 does it happen at open or at write? Dec 12 20:27:47 hmm will have to compile strace Dec 12 20:27:52 give me a sec... Dec 12 20:28:01 can't you take the one from snapshots? Dec 12 20:28:16 xMff: from where? Dec 12 20:28:52 http://downloads.openwrt.org/snapshots/trunk/ar71xx/packages/strace_4.5.18-2_ar71xx.ipk Dec 12 20:30:02 hmm I generate this without ipkg :) Dec 12 20:30:18 how could I extract just the binary? Dec 12 20:30:24 tar -xzf Dec 12 20:30:35 it contains two more tgz Dec 12 20:30:45 data.tgz is holding the actual contents Dec 12 20:31:10 great! Dec 12 20:32:23 xMff: open("/dev/mtdblock3", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3 Dec 12 20:32:36 write(1, "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., 65535) = -1 EPERM (Operation not permitted) Dec 12 20:33:00 hm, have you looked at your dump? Dec 12 20:33:17 apart from the write problem, the dump seems to contain 0xFF as well Dec 12 20:33:43 strings shows everything is in there Dec 12 20:33:48 ok Dec 12 20:33:56 maybe the 0xFF are for the interleaving? Dec 12 20:34:10 I bet the first 32k are 0xFF Dec 12 20:34:22 hmm, thats seems pausible Dec 12 20:34:30 would be the same as on wrt54 then Dec 12 20:35:03 yea, the thing now is how could I write to that f*ing mtd partition? Dec 12 20:35:12 however, the permission denied is weird Dec 12 20:35:32 what's in dmesg regarding the mtd layout? Dec 12 20:35:44 size is 65536, maybe writing just 65535 bytes? Dec 12 20:35:54 nono Dec 12 20:36:00 65536 is okay Dec 12 20:36:14 I remember something about mtd devices being picky about page sizes or something Dec 12 20:36:22 erase block sizes Dec 12 20:36:26 0x10000 Dec 12 20:36:34 = 65536 Dec 12 20:37:23 ok Dec 12 20:37:55 u-boot have the 'upgrade code.bin' which writes via tftp the whole 'firmware' partition Dec 12 20:38:13 solca: ah mom Dec 12 20:38:15 will check if there is another option instead of code.bin Dec 12 20:39:16 upgrade- upgrade bootcode, code.bin, rom.bin and mfg.bin via using TFTP protocol Dec 12 20:39:24 solca: http://openwrt.pastebin.com/m46b3a45e Dec 12 20:39:31 upgrade Dec 12 20:39:32 the partition is write protected ;) Dec 12 20:39:41 I misinterpreted the code earlier Dec 12 20:40:01 xMff: I read too in the platform code that is WRITEABLE too! ?? Dec 12 20:40:09 no write is masked Dec 12 20:40:15 means it is forbidden Dec 12 20:40:43 ohhh Dec 12 20:40:47 that explains everything Dec 12 20:41:04 so if I remove those .mask_flags? Dec 12 20:41:13 for nvram and art partitions Dec 12 20:46:05 yes Dec 12 20:46:31 * solca compiling... Dec 12 20:47:33 is there a default place where the wdt module gets loaded? Dec 12 20:51:05 rtz: /etc/modules.d/ ? Dec 12 20:55:48 solca: what script parses this directory? Dec 12 20:56:14 grep -r modules.d /etc/init.d/* Dec 12 20:56:26 probably boot Dec 12 20:57:12 xMff, solca: right, thanks Dec 12 20:57:24 but something doesn't work :/ Dec 12 21:12:31 hmm, my 2 working wrt160nl's have different contents in "ART" partitions... Dec 12 21:13:11 solca: probably really eeprom stuff thenß Dec 12 21:13:11 ? Dec 12 21:14:24 xMff: yea, hopefully just MAC addresses would be different but who knows Dec 12 21:14:39 (calibration data scares me) Dec 12 21:20:14 solca: there's a nice tool, vbindiff to examine differences between two binary blobs Dec 12 21:23:48 somebody forgot an x :/ Dec 12 21:24:29 xMff: excellent! if restoring this nvram and art partitions works then I'll have to check for differences Dec 12 21:24:41 rtz: where? Dec 12 21:25:25 solca: in /etc/modules.d/50-rdc321x-wdt Dec 12 21:25:37 does anybody know, where this file comes from? Dec 12 21:26:38 rtz: is is generated by package/kernel/modules/other.mk Dec 12 21:26:56 in the $(call AutoLoad,idx,name) macro Dec 12 21:28:32 rtz: http://openwrt.pastebin.com/m153ac724 Dec 12 21:28:41 ? Dec 12 21:29:54 xMff: right Dec 12 21:30:04 if you could commit it to svn Dec 12 21:31:19 jow * r18767 /trunk/package/kernel/modules/other.mk: [package] kernel: fix typo that prevents autoloading of the rdc321x_wdt driver Dec 12 21:31:30 xMff: thanks :) Dec 12 21:32:06 np Dec 12 22:02:21 xMff: same -EPERM Dec 12 22:02:25 http://openwrt.pastebin.com/m72111590 Dec 12 22:02:46 you did make target/linux/clean afterwards? Dec 12 22:03:19 I did make distclean and then make again just to be sure Dec 12 22:03:49 strange Dec 12 22:04:28 will try again, I'm not completely sure I was in the correct trunk Dec 12 22:04:32 trunk dir Dec 12 22:49:25 is a gpio_chip supposed to appear somewhere in sys? Dec 13 00:02:31 florian * r18768 /trunk/target/linux/rdc/image/Makefile: [rdc] generate bifferboard images, patch from bifferos Dec 13 00:19:06 [florian]: ping **** ENDING LOGGING AT Sun Dec 13 02:59:57 2009