**** BEGIN LOGGING AT Thu Sep 12 02:59:59 2013 Sep 12 06:01:42 build #276 of gemini is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/gemini/builds/276 Sep 12 07:56:23 has anyone else been seeing kernel memory leaks since 3.6.x? Sep 12 07:57:34 i had a theory it had to do with nocatauth and thrashing iptables rules, but i'm not sure that holds up in the face of our data. Sep 12 07:59:35 e.g. http://iris.personaltelco.net/graphs/graph.php?action=zoom&local_graph_id=1530&rra_id=4&view_type=&graph_start=1345919534&graph_end=1378972718 Sep 12 07:59:48 oops Sep 12 08:00:19 try https://iris.personaltelco.net/graphs/graph.php?action=zoom&local_graph_id=1530&rra_id=4&view_type=&graph_start=1345919534&graph_end=1378972718 Sep 12 08:00:33 (don't mind the self-signed cert) Sep 12 08:00:55 that was kernel version 3.8.0 Sep 12 08:05:02 also: https://iris.personaltelco.net/graphs/graph.php?action=zoom&local_graph_id=208&rra_id=4&view_type=&graph_start=1345919822&graph_end=1378973006 Sep 12 08:05:18 currently 3.7.4 Sep 12 08:06:40 prior to jan 27, it was running r18781 (jodie is an alix2) Sep 12 08:07:16 currently r35318 Sep 12 08:49:48 ls -al /proc/net/ Sep 12 10:41:02 Hauke ping Sep 12 10:41:10 Devastator: pong Sep 12 10:41:57 Hauke I just received your email, the only modified file is the one from the patch, I'm using git btw Sep 12 11:00:49 Hauke a reboot fixed nvram, I have the habit to erase nvram when flashing new firmware, let me pastebin it Sep 12 11:03:23 http://codepad.org/Iqo6rd2d Sep 12 11:12:09 Devastator: it looks like Linksys' OEM did not configure the switch reset GPIO to nvram, but hard coded it into the source code. Sep 12 11:21:31 Hauke: using the phyaddr from nvram ("et0phyaddr=30") should make it unnecessary to allow attaching to phyaddr 1) Sep 12 11:22:48 KanjiMonster: allowing tg3 to use a different phy addr then 1 is a big task Sep 12 11:23:06 it is hard coded everywhere Sep 12 11:30:19 Hauke: on a quick glance at only one place: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/broadcom/tg3.c#n1493 Sep 12 11:32:08 okay, and the phy mask Sep 12 11:33:53 Hauke: doesn't look like that a big task replacing those hardcoded values with tg->phy_addr (except for the regression testing part ;) Sep 12 11:37:50 KanjiMonster: have you seen the references to TG3_PHY_MII_ADDR Sep 12 11:38:36 yeah, but they aren't hat many, and replacing them with tg->phy_addr should make the code work the same, but allow tg->phy_addr be something != 1 Sep 12 11:40:29 KanjiMonster: ok I will try that Sep 12 11:41:22 I am wondering how this code works now with phy_addr != TG3_PHY_MII_ADDR Sep 12 11:45:01 Hauke: 5717_PLUS does not have the USE_PHYLIB flag set, and since this is the only one where tg->phy_addr != 1, there is currently no harm in hardcoding it everywhere Sep 12 11:45:07 Hauke I see the switch being reset in the CFE with gpio 8 Sep 12 11:45:22 Devastator: but your nvram says it's gpio 7 ;) Sep 12 11:45:59 the reset_gpio is the poweroff gpio Sep 12 11:46:04 ah, okay Sep 12 11:47:19 some dump engineer added the reset code into the source code with a hard coded gpio, probably copied from the robo driver instead if setting the nvram var Sep 12 11:50:21 Hauke should I revert your previous patch and apply the one you emailed me? Sep 12 11:50:52 Devastator: yes Sep 12 11:50:56 ok Sep 12 11:53:19 patch -p1 < patchfile is a blessing.. Sep 12 11:58:26 Hauke: I'd say expand b53_switch_get_reset_gpio() with a if (!strcmp(get_nvram("boot_hw_model"),"WRT310N") return 8; (+ error checking and comment) Sep 12 11:58:26 Hauke I've built it, but I cannot test it until tonight, which means in 12 hours :( Sep 12 11:58:51 Devastator: no problem Sep 12 12:00:02 a pipe broked on monday, my house was floated until yesterday.. 3 days at home, my boss, which is also my dad, is not really happy.. Sep 12 12:04:31 Is the MIPS /dev/random issue worth issuing a CVE? Sep 12 12:06:28 Ralf: just do it as it got some media coverage Sep 12 12:06:59 Ralf: I'm not sure; as all places using the cycles don't use it for entropy Sep 12 12:07:40 Hauke: i'm here in case you have any other ideas to discuss on irc :) Sep 12 12:07:48 zajec: ;-) Sep 12 12:08:07 Hauke: that BCM5357* is killing me '/ Sep 12 12:08:46 KanjiMonster: I added such a check to b53_switch_get_reset_gpio() Sep 12 12:09:03 Hauke I was fast enough and here is the bootlog: http://codepad.org/BMqpInR9 Sep 12 12:09:04 Hauke: can't you use detection code from bcm47xx? Sep 12 12:09:48 zajec: yes I used that Sep 12 12:10:13 Hauke I applied your patch and make, should I have done anything els? Sep 12 12:10:16 else Sep 12 12:10:44 KanjiMonster: i386, i486 don't have a cycle counter and many other Linux architectures also just return 0. Sep 12 12:11:28 KanjiMonster: do you know why there is a "Unhandled kernel unaligned access" in mdio_lock() ? Sep 12 12:12:05 Hello everyone, is there any uci provisioning solution for openwrt? Sep 12 12:12:34 Ralf: that was my draft response, but I didn't dare to send it yet because I fear of emberrassment if I talk rubbish: http://pastebin.com/Sd92EBvD Sep 12 12:14:45 <_rmk_> KanjiMonster: ARM has a similar problem too (not everything has a cycle counter) Sep 12 12:14:59 Hauke: I would assume a bad/uninitialized pointer Sep 12 12:15:28 <_rmk_> we implemented it as: #define get_cycles() ({ cycles_t c; read_current_timer(&c) ? 0 : c; }) Sep 12 12:16:48 _rmk_: yeah, I know. The biggest problem is that I have to trust the code/comments, but at least for me it looks like having the counter return zero isn't that big of a problem as everyone thinks, as all places using it are careful to not use it for entropy (or no place adding entropy uses the counter value) Sep 12 12:18:14 <_rmk_> KanjiMonster: I think you're right that it doesn't matter Sep 12 12:19:54 <_rmk_> my understanding is that the entropy comes from the "noise" and if something has no "noise" then it doesn't count. Sep 12 12:20:02 right Sep 12 12:21:41 Devastator: could you add some debugging to mdiobus_register() in build_dir/target-mipsel_uClibc-0.9.33.2/linux-brcm47xx/linux-3.10.10/drivers/net/phy/mdio_bus.c and print the pointer of bus and then also a printk to b53_mdio_op() in build_dir/target-mipsel_uClibc-0.9.33.2/linux-brcm47xx/linux-3.10.10/drivers/net/phy/b53/b53_common.c with the pointer of bus Sep 12 12:23:32 <_rmk_> KanjiMonster: the only difference I can see it making is the amount of "noise" available to the random pool Sep 12 12:24:31 Could anyone tell me who maintains x86 target? Sep 12 12:26:36 strasidlo: I'm not sure there is an actual maintainer. Sep 12 12:28:32 zajec: do the mac addresses of your output match the expected ones? Sep 12 12:30:32 Hauke: of course not :( Sep 12 12:50:56 zajec: I wonder if all the 5357 conditional code is also in the upstream bgmac code Sep 12 12:51:22 KanjiMonster: i'm not sure what do you mean Sep 12 12:51:31 KanjiMonster: upsteam code? Sep 12 12:51:35 KanjiMonster: do you mean Linus's tree? Sep 12 12:51:43 KanjiMonster: I'm using OpenWrt's kernel Sep 12 12:51:57 Not directly Linus's tree Sep 12 12:52:29 zajec: yes, and I mean if all special 5357 handling in the broadcom et driver is also in bcma/openwrt's bgmac driver Sep 12 12:53:06 KanjiMonster: So I suppose any issues with x86 will not be resolved soon.. Sep 12 12:53:13 ah, I didn't realize what that you mean et by "upstream bgmac" :P Sep 12 12:53:24 ah Sep 12 12:53:25 wait Sep 12 12:53:29 ok, i understand you now :P Sep 12 12:53:30 ;) Sep 12 12:53:40 <[florian]> that should be downstream then no? Sep 12 12:53:49 KanjiMonster: I checked bgmac vs. et few times alreeady Sep 12 12:53:52 okay Sep 12 12:54:05 KanjiMonster: maybe there is something generic in the init lacking... Sep 12 12:54:07 that's possible Sep 12 12:54:22 it's just pretty huge amount of code to check Sep 12 12:54:59 zajec: btw. still interested in me reviewing the bgmac code for performance issues? Sep 12 12:57:34 nbd: i dropped that for now Sep 12 12:57:40 nbd: did you see my cft thread? Sep 12 12:57:45 yes Sep 12 12:58:00 it appears that it's that magic ctf.ko that boost the network perofmrance for Broadcom firmware Sep 12 12:58:10 nbd: do you know what cft does? Sep 12 12:58:31 cyrus r37951 trunk/package/network/ipv6/odhcp6c/Makefile * odhcp6c: Timing workaround for buggy servers Sep 12 12:58:46 removing ctf.ko reduces network performance to ~100Mb/s, similarly to the OpenWrt perofmrance Sep 12 12:58:47 zajec: I see 00 08 04 which looks like the ethertype 0800 (ipv4) and then ipv4 header Sep 12 12:58:51 Hauke: it's a big ugly cross-layer hack to bypass large parts of the network stack and netfilter Sep 12 12:59:09 not sure if there's also hardware acceleration involved Sep 12 12:59:10 nbd: any chance to re-implement that in a open source way? Sep 12 12:59:13 a bit cleaner maybe too? Sep 12 12:59:22 cyrus r37952 branches/attitude_adjustment/package/odhcp6c/Makefile * AA: odhcp6c: work around buggy server timeouts Sep 12 12:59:25 nbd: that switches don't have hw acceleration Sep 12 12:59:39 Hauke: let me see that... Sep 12 12:59:40 i'm more interested in figuring out what the performance issues in the existing layers are Sep 12 12:59:46 than to implement such hackery Sep 12 12:59:57 nbd: i assumed it's a CPU limit we hit Sep 12 13:00:02 and we can't improve that further... Sep 12 13:00:21 Hauke: hm Sep 12 13:00:30 before we implement anything, we should replace assumptions with data and sane interpretations of said data ;) Sep 12 13:00:32 Hauke: that may look like a packet type indeed Sep 12 13:00:54 nbd: ok, i'll back work on that, just a bit later Sep 12 13:00:55 and that requires more measurements, experiments, code review Sep 12 13:01:02 nbd: i focused on that BCM5357 not working at all ;) Sep 12 13:05:07 zajec: when working on that I was sending broadcast packages monitored then with wireshark at the sender and was searching for them in bgmac's received frames Sep 12 13:07:08 let me check my MACs again... Sep 12 13:08:04 Hauke: my MAC is E8:11:32:CD:E2:xx (is that really important to protect my MAC?) Sep 12 13:08:14 I don't see anything matching in in the dump... Sep 12 13:08:26 Hauke you mean bus->name? Sep 12 13:08:43 it should be placed right before the 00 08 04 Sep 12 13:08:47 right? Sep 12 13:09:02 C is not my strong point Sep 12 13:09:11 Devastator: no the pointer bus something like printk("function bus: %p\n", bus); Sep 12 13:09:23 oh, ok Sep 12 13:10:03 zajec: yes it should be before 0080, if there is no vlan tag Sep 12 13:10:44 well, you see my log... there isn't ;) Sep 12 13:11:04 and I can't see anything like "00 08 04" in the dumps with enable_vlan 0 Sep 12 13:11:05 interesting Sep 12 13:12:35 Hauke there is no b53_mdio_op function in b53_common.c, at least search returns nothing Sep 12 13:12:39 zajec: is E8:11:32:CD:E2:xx the mac of the device you are debugging or of your pc you do tests with? Sep 12 13:12:54 Devastator: I meant b53_mdio.c Sep 12 13:14:08 Hauke: E8:11:32:CD:E2:xx is my notebook MAC Sep 12 13:14:20 so it should be visible for both devices Sep 12 13:14:26 E900 and that no-name board Sep 12 13:14:41 zajec: have you checked that you send broadcast packages so you do not have to worry about switches forwarding the packages Sep 12 13:16:18 I hope I did it correctly, I don't know C much hehe Sep 12 13:17:03 Devastator: then it will probably not compile Sep 12 13:26:25 Hauke: please see my e-mail Sep 12 13:26:27 and attachment mainly Sep 12 13:26:34 you can steal my MAC now ;) Sep 12 13:26:41 posted full dump Sep 12 13:27:56 Hauke pointer of b53_mdio_op is dev, correct? Sep 12 13:28:01 opss Sep 12 13:28:18 Hauke pointer of bus in b53_mdio_op is dev, correct? Sep 12 13:28:38 and they are the same? Sep 12 13:29:43 in mdio_bus I have bus pointer, in b53_mdio_op, there is no bus pointer declared, the only I see pointer is dev Sep 12 13:31:08 Devastator: bus is decalred there, there is struct mii_bus *bus = dev->priv; in b53_mdio_op() Sep 12 13:33:23 zajec: you receive something after you send a package, so you are able to connect the sending of a package and receiving something in bgmac? Sep 12 13:34:23 Hauke here is the b53_mdio_op() I'm seeing: http://codepad.org/62lX1ca5 Sep 12 13:35:00 dvthere is one of my older patches applied Sep 12 13:35:12 only applied the last one Sep 12 13:35:14 Devastator: Sep 12 13:36:57 Hauke the last one applied is from the email Sep 12 13:37:37 if I revert I get a clean git status Sep 12 13:38:32 Devastator: are you sure that you haven't committed anything? Sep 12 13:38:54 Hauke: i just did Sep 12 13:39:06 Hauke: i compared what I sent and what I received Sep 12 13:39:15 Hauke positive, let me revert and show git status Sep 12 13:39:17 at least I hope so... I hope I didn't do any mistake Sep 12 13:39:54 zajec: is the length matching? Sep 12 13:41:39 Hauke: "Frame 64: 362 bytes on wire (2896 bits), 362 bytes captured (2896 bits) on interface 0" vs. "[RX] len:148" Sep 12 13:41:43 I guess not? Sep 12 13:41:48 The first message is from Wireshark Sep 12 13:42:41 zajec: could it be that dma is not working and you are fetching some randoo Sep 12 13:42:45 random data Sep 12 13:43:29 yeah Sep 12 13:43:31 makes sense Sep 12 13:43:40 but not sure how to debug that further Sep 12 13:43:43 and fix... Sep 12 13:45:28 luka r37953 packages/libs/glib2/Makefile * [packages] glib2: update to 2.37.7 Sep 12 13:45:29 luka r37954 packages/utils/lirc/Makefile * [packages] lirc: add more lirctools Sep 12 13:45:44 zajec: look into all the rx buffers and search for your mac address Sep 12 13:47:14 Hauke the only file that is not reverted is b53_priv.h, I'm gonna git checkout -- it Sep 12 13:47:31 Hauke: huh... that will require some further hacking Sep 12 13:47:38 to dump all buffers Sep 12 13:49:49 Devastator: just to a "git checkout origin/master -f" Sep 12 13:49:59 and then apply the patch I send in the last mail Sep 12 13:50:25 and then do "make target/linux/clean && make" Sep 12 13:51:34 zajec: I have a new device with a BCM5356, but I haven't tested it, will do that tonight or tomorrow Sep 12 13:52:53 Hauke: gr8! Sep 12 13:52:55 Hauke: thx Sep 12 13:54:14 luka r37955 packages/utils/lirc/Makefile * [packages] lirc: partially revert r37954 Sep 12 14:08:26 Hauke I don't know why but I get this error after reverting to master and applying your patch: http://codepad.org/avUQP69z Sep 12 14:10:18 Hauke I did "git checkout origin/master -f", then "git checkout wrt310nv1_support", then add the printk to target/linux/generic/files/drivers/net/phy/b53/b53_mdio.c and typed make Sep 12 14:11:51 remove the file target/linux/brcm47xx/patches-3.10/260-MIPS-BCM47XX-add-board-detection.patch.orig Sep 12 14:12:21 what does your branch wrt310nv1_support contain? Sep 12 14:12:26 Devastator: Sep 12 14:14:30 Hauke contains master basically master, I try to divide in branches to keep master untouched Sep 12 14:14:44 contains basically master, that is Sep 12 14:21:33 finally! Sep 12 14:24:04 luka ping Sep 12 14:24:39 pong Sep 12 14:25:21 luka sorry to disturb you, I'm just checking if you saw my patch in patchwork and if it's the way you wanted Sep 12 14:26:37 i missed it... link please Sep 12 14:27:23 luka http://patchwork.openwrt.org/patch/4037/ Sep 12 14:29:17 Devastator: that looks great ;) Sep 12 14:29:35 did you test it on latest trunk? Sep 12 14:29:58 luka yes sir, I refreshed like you told me and it applies cleanly Sep 12 14:30:33 pretty trivial patch I think hehe Sep 12 14:32:45 Hauke another error: http://codepad.org/LVaCAynT Sep 12 14:35:33 I also saw that on my device Sep 12 14:35:45 Devastator: could you try the patch I send you per mail Sep 12 14:35:54 plaase use that on top of Sep 12 14:36:40 Devastator: please use that without any other patches, so create a new branch or use a clean master Sep 12 14:37:13 Hauke ok, I will revert everything and apply the patch you just sent! Sep 12 14:37:16 thank you! Sep 12 14:39:36 luka r37956 trunk/target/linux/generic/patches-3.10/009-mtd_m25p80_add_support_for_esmt_f25l32pa.patch * kernel: add support for ESMT F25L32PA with upstream submission Sep 12 14:39:41 Devastator: ^^ Sep 12 14:39:53 holy moly! Sep 12 14:39:55 thanks! Sep 12 14:40:49 luka I want to thank you, Jonas, Russell and others for the help and knowledge to do this Sep 12 14:41:24 Devastator: np, so next time you can explain to someone what to do ;) Sep 12 14:41:52 i just changed the nuber to 009 because 063 was taken (after you proposed your patch) Sep 12 14:41:57 I can't wait to see it in kernel upstream, one day I can tell that to my grandsons :) Sep 12 14:42:55 luka thanks! Sep 12 14:43:32 np Sep 12 14:44:17 blogic sir, just to inform you can build trunk with your pinctrl driver whenever you have time and I will test it with honour :) Sep 12 14:44:30 luka btw, which target you maintain? Sep 12 14:45:39 imx6 Sep 12 14:46:44 humm, that's new, I will get a board to see how it is, suggestions? Sep 12 14:47:09 wandboard is nice Sep 12 14:47:28 but all the interesting stuff are not working yet Sep 12 14:50:15 sounds like someone needs a tester :P Sep 12 14:55:19 Devastator: hehe Sep 12 17:34:42 blogic: have you managed to make an image of the VGV7519 board yet? Sep 12 17:34:57 not yet Sep 12 17:35:03 i was busy with a different board Sep 12 17:35:14 ok, no problem Sep 12 17:37:42 we need to find out what the pin is really Sep 12 17:41:21 pin! Sep 12 17:41:26 the pin codes, of course, I was wondering if there would be different pins for each board, or possibly a different one in a different version of the software... Sep 12 17:43:09 easy to find out Sep 12 17:43:21 i will dump my flash these dazs and then we check what sha1 there is Sep 12 17:43:38 ok, you can send it to my e-mail if you like Sep 12 17:43:39 if it is the same we should just spent some time to figure out how the gpu instance in ec2 work Sep 12 17:43:45 sure Sep 12 17:44:00 what tools do you use Sep 12 17:44:04 ... to extract it ? Sep 12 17:44:14 I extracted it using openOCD Sep 12 17:44:21 no i mean the sha1 Sep 12 17:44:24 objdump ? Sep 12 17:44:31 or ida Sep 12 17:44:32 ah, combination of hex dumps and ida pro Sep 12 17:44:53 ok Sep 12 17:45:24 the best thing is that I know 'a good amount' of the functions, so it is pretty readable here ;) Sep 12 17:45:32 * Devastator thanks God his device doesn't have so many flashing barriers :) Sep 12 17:45:49 ;) Sep 12 17:45:51 nice Sep 12 17:46:08 so, imho we should try to build a uboot hat the brnloader starts Sep 12 17:46:13 and then do the rest from uboot Sep 12 17:46:31 also i noticed on this other arcadyan board i have that i cannot find the board config sector Sep 12 17:47:20 If I remember correctly it is reported in the flash layout... Sep 12 17:47:29 yes Sep 12 17:47:36 but the content seems crypted Sep 12 17:47:44 i cannot find the mac in it Sep 12 17:48:06 wait a sec, let me take a look Sep 12 17:48:54 can you show me the 64kb of the config sector ? Sep 12 17:49:12 becasue we need it to make wifi work Sep 12 17:49:39 why is that? because the wifi password is in there Sep 12 17:49:43 no Sep 12 17:49:52 the calibration data Sep 12 17:50:08 it starts with this: BRN-BOOT Æ<Ä=§J229112404 01 v3.00.06 BRN-BOOT Sep 12 17:50:25 then there is the wifi password (in plain text) Sep 12 17:50:35 is there 0x63 0x30 in it ? Sep 12 17:50:41 is there 0x62 0x30 in it ? Sep 12 17:50:55 the wifi data is 0x200 bytes and starts with 0x6230 Sep 12 17:51:18 0x30 0x62 maybe >_< Sep 12 17:51:22 ok Sep 12 17:51:26 starting at 0x400 it starts with 0x12345678 Sep 12 17:51:42 zinx: in general the wifi eep of ralink is endianess swapped Sep 12 17:51:58 zinx: 5350 has 5053 Sep 12 17:52:08 3052 has 5230 Sep 12 17:52:10 ;) Sep 12 17:52:12 yup, I discovered it the hard way Sep 12 17:52:23 just before 0x1400 it ends with 0x87654321 Sep 12 17:52:28 hehe Sep 12 17:52:31 well Sep 12 17:52:31 so I guess it is packed with something... Sep 12 17:52:56 hmmm Sep 12 17:53:14 where is the bootloader itself packed with? Sep 12 17:53:34 the 12345678 sequence is used to construct the brn-image as well Sep 12 17:53:41 yes Sep 12 17:56:02 5350 seems to be a good chip.. Sep 12 17:56:32 I will see if I can enable USB on my router after fixing remaining things.. Sep 12 17:56:37 Devastator: cheap Sep 12 17:56:48 really really cheap Sep 12 17:57:10 it costs around 30EU, and costed me nothing hehe Sep 12 17:57:37 but as a travel router, might be enough Sep 12 17:58:22 funny though, I know more about openwrt development than using/configuring it Sep 12 18:01:11 blogic is it possible for you to give me something to test on friday or so? I have nothing planned for the weekend, it would be boring without something to test, work on :P Sep 12 18:03:06 hehe Sep 12 18:03:06 ok Sep 12 18:04:07 routers can ruin marriages, but thankfully I'm not married Sep 12 18:04:53 I just married 3 weeks weeks ago ;) Sep 12 18:05:11 The_Lizard: grats Sep 12 18:05:16 thanks Sep 12 18:06:28 The_Lizard be careful then.. Sep 12 18:06:39 playing with routers is addicting Sep 12 18:06:53 I know, for me, it is a big puzzle... Sep 12 18:07:14 the only problem is that I'm unable to solve it by myself :S Sep 12 18:07:19 some day you WILL choose your router against sex Sep 12 18:07:35 women doesn't get it :) Sep 12 18:07:39 Devastator: i doubt it Sep 12 18:07:46 I doubt it as well Sep 12 18:07:51 hahah Sep 12 18:08:35 I have done it, but she was ugly, does it count? Sep 12 18:09:13 it is up to you if it counts... Sep 12 18:09:58 what a bizarre conversation Sep 12 18:10:03 yeah, doesn't count :P Sep 12 18:12:05 one day, xvideos will have a routers section Sep 12 18:12:12 or even routers genre Sep 12 18:12:24 xvideos? Sep 12 18:13:00 yeah, for those who got in love by their router and decided to have sex with it, then upload the video Sep 12 18:13:21 there is something wrong with you :P Sep 12 18:13:26 hahah Sep 12 18:13:27 get a girl this weekend :P Sep 12 18:13:33 not really Sep 12 18:13:51 maybe I will, after testing pinctrl driver Sep 12 18:29:04 Devastator: follow The_Lizard advice Sep 12 18:29:10 ;) Sep 12 18:31:17 Pteridium I will, but pinctrl comes first hahah Sep 12 18:31:24 blogic: i'm astonished; in a couple of days you have put owrt in the livebox 2.1. Really astonished... Sep 12 18:31:50 Pteridium: and then i killed the board ;) Sep 12 18:31:58 hahaha Sep 12 18:31:59 Mr Crispim in a router support spree :) Sep 12 18:32:08 i ordered 2 more liveboxes todaz Sep 12 18:33:28 in seguridadwireless forum somebody said that would be good idea to send you a couple Sep 12 18:33:51 yes i know Sep 12 18:33:53 and it's a good idea Sep 12 18:33:53 esteban Sep 12 18:33:56 is it the lzma that requires the 0x12345678? Sep 12 18:34:14 no, other Sep 12 18:34:17 zorrua Sep 12 18:34:19 ok Sep 12 18:34:25 well i received that unit ;) Sep 12 18:34:35 and broke it 2 minutes after making it work ;) Sep 12 18:34:47 :D Sep 12 18:34:54 by making a shortcut whihc burned the nor flash Sep 12 18:34:58 :) Sep 12 18:35:32 nor flash should be cheap to replace, no? Sep 12 18:35:37 shortcutting is a way to learn... Sep 12 18:36:53 i suppose that the xwave300 will not be supported Sep 12 18:37:02 Pteridium: it should very easily Sep 12 18:37:09 the rpoblem is you need a firmware blob Sep 12 18:37:13 and that is not public Sep 12 18:37:39 i supposed it Sep 12 18:37:56 minor problem Sep 12 18:38:31 can I ask another dumb question? Sep 12 18:38:57 yes? Sep 12 18:39:39 how openwrt made broadcom wl proprietary driver, kernel version independent? Sep 12 18:40:22 I see there is wl glue, which I thought is something to make it possible?! Sep 12 18:40:49 AFAIK the binary file was made by broadcom specifically for owrt Sep 12 18:41:25 yes, that what I've read too Sep 12 18:42:34 why can't they do the same thing for their dsl driver? Sep 12 18:43:34 why you need dsl? it consumes some resources. Sep 12 18:44:07 I'm not a fan of modem+router combo Sep 12 18:44:12 the 63xx series Sep 12 18:44:56 if I can, I setup bridge and my router does the routing Sep 12 18:45:15 why have an extra box? Sep 12 18:45:27 Devastator: me too ;) Sep 12 18:47:00 DonkeyHotei it was that way of thinking that created 56k softmodems which would hog your cpu to its knees :) Sep 12 18:47:20 dedicated cpu is always best imho Sep 12 18:47:42 the dsp is dedicated either way Sep 12 18:47:56 DonkeyHotei: my experience tells that an ar7 based modem + owrt flashed router is the best option Sep 12 18:48:18 ar7 can take owrt Sep 12 18:48:32 Devastator: you are right Sep 12 18:49:20 yes, but the vast majority of the ar7 routers have 16MB ram Sep 12 18:50:41 the actiontec pk5000 has 32 flash, 64 ram Sep 12 18:50:49 iirc Sep 12 18:52:03 the big problem with ar7 is no 1350A wifi drivdr¨ Sep 12 18:52:07 *driver Sep 12 18:52:53 I understand your point, lots of boxes, more power expended and space Sep 12 18:53:01 DonkeyHotei: i have a Zyxel 660HW-D1 configured as a bridge and an arv4518 as the router, and that was the best option for me Sep 12 18:53:59 the zyxel adsl syncro is the best for my li ne Sep 12 18:54:05 line* Sep 12 18:55:33 I use a sagecom as modem, it was provided by my isp Sep 12 18:55:38 yes, the acx111 driver is a bit limited, but the developers made its best effort Sep 12 18:56:13 it is also wireless router, but I take my chances with asus RT-N16 Sep 12 18:56:20 b43 driver has some limitations too Sep 12 18:56:44 Pteridium: why not just use the arv4518's modem? Sep 12 18:58:03 DonkeyHotei: ar7=3'3Mb downstream while lantiq=2'7Mb Sep 12 18:58:41 and this is adsl2+? Sep 12 18:58:41 i have 55dB downstream attenuation Sep 12 18:58:56 no, adsl Sep 12 18:59:11 :P Sep 12 19:00:49 mine is vdsl Sep 12 19:00:50 the other reason was that the lantiq dsl driver consumes a good amount of ram Sep 12 19:01:17 does anyone know ikanos chipset? Sep 12 19:01:33 i have not yet tried lantiq on my line, because owrt currently can't boot on the netgear dgn3500 Sep 12 19:03:11 where i live there is only adsl; vdsl, fiber and other advanced technologies only near the dslams Sep 12 19:03:50 and you're far? Sep 12 19:04:06 more or less 5 Km Sep 12 19:04:24 the city is Vigo, in Spain Sep 12 19:04:52 i'm at 3km Sep 12 19:05:03 this is my modem/router: http://wiki.openwrt.org/toh/sagem/fast2764 Sep 12 19:05:58 Devastator: are you sure you want to fight with ikanos chips? Sep 12 19:06:22 it is a pain, huh?! I can imagine Sep 12 19:06:34 128 ram... Sep 12 19:07:10 DonkeyHotei: maybe in your country the infrastructure is better than here Sep 12 19:07:23 Pteridium who deals with that soc? blogic? Sep 12 19:08:02 AFAIK he is the lantiq maintainer Sep 12 19:08:13 i don't think owrt knows about ikanos Sep 12 19:08:39 i think it knows, just don't have the necessary files to support it Sep 12 19:09:43 in this country, almost all dsl hardware is brcm 63xx Sep 12 19:09:51 afaik, no one could reverse engineer dsl drivers with perfection.. let's put this ways Sep 12 19:11:03 the ikanos kernel and drivers can be found easily for the Fusiv Vx180, but owrt people have enough work with the actual platforms Sep 12 19:11:32 indeed Sep 12 19:12:18 is there source for the ikanos drivers? Sep 12 19:12:20 I try to give enough information for the devs to have less work, but they do all the thinking Sep 12 19:12:42 or just binary blobs? Sep 12 19:33:42 DonkeyHotei: i was wrong; only a ethernet driver: http://gpl.back2roots.org/source/fritzbox/7390_5.50/GPL-release_kernel/linux/drivers/net/avm_cpmac/ Sep 12 19:35:33 can't wait to get home and test my last build Sep 12 19:35:44 :D Sep 12 19:35:57 3 hours remaining :/ Sep 12 19:36:35 blogic: enjoy the livebox. Sep 12 19:54:01 build #348 of rb532 is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/348 Sep 12 19:56:00 build #348 of ppc44x is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/348 Sep 12 20:27:02 what is the default make config for the openwrt image located in trunk? Sep 12 20:27:21 if I do make menuconfig, is it already at the settings to which openwrt builds trunk snapshots? Sep 12 20:27:44 froek: yes Sep 12 20:27:51 blogic: thank you :) Sep 12 20:28:22 I just wanted to make sure before I flash my device with the image in case I forgot to add a kernel item and end up bricking my device for some reason Sep 12 20:42:10 build #369 of ramips is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/ramips/builds/369 Sep 12 20:46:01 build #400 of brcm63xx is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/brcm63xx/builds/400 Sep 12 20:46:14 build #396 of at91 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/at91/builds/396 Sep 12 20:47:29 build #329 of sibyte is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/329 Sep 12 21:05:01 build #369 of lantiq is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/lantiq/builds/369 Sep 12 21:11:13 build #361 of uml is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/361 Sep 12 21:13:15 Does anyone have any ideas on adding startup scripts with procd? Sep 12 21:13:34 I have a script that needs to be called early and I used to do that with rcS... Sep 12 21:15:06 build #380 of orion is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/380 Sep 12 21:25:45 build #339 of avr32 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/339 Sep 12 21:38:01 build #347 of ar7 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/ar7/builds/347 Sep 12 21:57:00 i selected BCM47xx/53XX with ARM on make menuconfig, however it only made a bin/bcm53xx image Sep 12 21:57:11 am i doing something wrong? I was expecting brcm47xx/ Sep 12 21:58:20 froek: thats correct it creates an image in bin/bcm53xx Sep 12 21:58:39 are you sure you have a bcm4708? Sep 12 21:58:53 Broadcom BCM4716 (Linksys WRT610N V2) Sep 12 21:59:08 i have been using trunk images from here: http://downloads.openwrt.org/snapshots/trunk/brcm47xx/ Sep 12 21:59:11 that's with mips cpu Sep 12 21:59:18 ooo 8| Sep 12 21:59:30 you have to select bcm947xx.. Sep 12 21:59:39 i c.. thank you very much Sep 12 22:00:04 which target profile should I choose? Sep 12 22:00:53 i'm not sure I see one that matches my linksys 610n Sep 12 22:04:34 hauke r37957 trunk/target/linux/ (21 files in 7 dirs) * kernel: update bcma and ssb to wireless-testing master-2013-09-09 Sep 12 22:04:51 froek: use the generic target Sep 12 22:05:00 Hauke: thx Sep 12 22:05:43 hauke r37958 trunk/target/linux/brcm47xx/config-3.10 * brcm47xx: add default config for new kernel config option Sep 12 22:08:01 hauke r37959 trunk/target/linux/ brcm47xx/config-3.8 brcm47xx/Makefile brcm47xx/patches-3.8 brcm47xx/profiles/PS-1208MFG.mk * brcm47xx: remove support for kernel 3.8 Sep 12 22:34:22 build #312 of au1000 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/au1000/builds/312 Sep 12 22:36:41 hm.. can't seem to find 'generic image' in make menuconfig anymore.. Sep 12 22:37:23 build #286 of iop32x is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/iop32x/builds/286 Sep 12 22:38:01 build #321 of kirkwood is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/kirkwood/builds/321 Sep 12 22:40:43 froek: for the wrt610n v2 this should fit: Broadcom SoC, bgmac Ethernet, BCM43xx WiFi (b43) Sep 12 22:43:49 awesome Sep 12 23:04:16 build #366 of ppc40x is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/ppc40x/builds/366 Sep 12 23:09:29 build #378 of atheros is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/atheros/builds/378 Sep 12 23:09:48 build #386 of brcm47xx is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx/builds/386 Sep 12 23:16:17 build #368 of cobalt is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/368 Sep 12 23:39:42 luka r37960 trunk/package/kernel/linux/modules/hwmon.mk * kernel: gsc depends on kmod-i2c-core Sep 12 23:58:35 build #287 of ep93xx is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/ep93xx/builds/287 Sep 13 00:53:38 build #267 of mpc52xx is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/mpc52xx/builds/267 Sep 13 01:17:56 build #99 of mpc85xx is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/mpc85xx/builds/99 Sep 13 01:20:57 build #277 of gemini is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/gemini/builds/277 Sep 13 01:23:27 build #285 of adm5120 is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/adm5120/builds/285 Sep 13 01:49:54 build #252 of octeon is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/octeon/builds/252 Sep 13 01:59:02 build #351 of x86 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/x86/builds/351 Sep 13 02:18:54 build #283 of mcs814x is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/mcs814x/builds/283 **** ENDING LOGGING AT Fri Sep 13 02:59:58 2013