**** BEGIN LOGGING AT Fri Sep 13 02:59:58 2013 Sep 13 03:12:49 build #311 of ar71xx is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx/builds/311 Sep 13 03:29:21 build #36 of imx23 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/imx23/builds/36 Sep 13 03:32:43 build #329 of xburst is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/xburst/builds/329 Sep 13 04:35:30 build #324 of ixp4xx is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/ixp4xx/builds/324 **** BEGIN LOGGING AT Fri Sep 13 07:16:32 2013 Sep 13 13:25:25 jow r37961 trunk/package/system/rpcd/Makefile * rpcd: update to git head Sep 13 13:25:35 jow r37962 trunk/package/network/services/uhttpd/Makefile * uhttpd: udpat to git head Sep 13 13:26:03 being able to type straight would be nice... Sep 13 13:29:51 :D Sep 13 13:30:42 you could have used copy&paste from the commit before ;) Sep 13 13:30:56 or actualy review and amend :) Sep 13 13:31:06 or that... Sep 13 13:34:49 nitpick: I really hate those "update to git head" commit subjects, because they have no usable information at all about what has changed and why it was updated ;p Sep 13 13:35:27 the description is in the commit message Sep 13 13:36:07 its usually far too long for the subject anyway Sep 13 13:36:26 even a summary of changes would in the end read like "various stuff changed" Sep 13 13:39:42 usually you have a reason for updating to git head, IMHO that should be part of the subject (e.g. r37961 could have been "rpcd: enhance session handling" or something like that) Sep 13 13:40:38 but it's just a nickpick, not a "please don't do that" ;) Sep 13 13:41:44 I just like to be able to tell from the subject whether a certain commit might or might not have fixed/introduced a certain issue I am seeing whenever possible Sep 13 14:46:42 good morning :) Sep 13 15:02:29 juhosg r37963 trunk/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c * ar71xx: add wireless bgn led support for dir-825-c1 Sep 13 15:29:39 juhosg r37964 trunk/target/linux/ar71xx/image/Makefile * ar71xx: add support for TL-MR3040 v2 Sep 13 15:31:55 Hauke: hey Sep 13 15:32:02 zajec: hey Sep 13 15:32:28 Hauke: i was looking at shared code... to see if some special init is needed for BCM5357* Sep 13 15:32:34 but didn't find anything interesting :| Sep 13 15:33:19 Hauke: i found some BCM5357* specific code in do_router_coma... do you know what is that? Sep 13 15:33:21 that comma? Sep 13 15:33:24 *coma Sep 13 15:35:11 zajec: no never heard of that function Sep 13 15:35:30 it's hndmips.c Sep 13 15:36:54 Hauke: did you boot your BCM5356? Sep 13 15:39:28 juhosg r37965 trunk/target/linux/cns21xx/config-3.8 * cns21xx: enable XZ_DEC_ARM and XZ_DEC_BCJ kernel options Sep 13 15:39:29 juhosg r37966 trunk/target/linux/cns21xx/base-files/etc/uci-defaults/01_leds * cns21xx: fix broken case statement in led defaults file Sep 13 15:39:30 juhosg r37967 trunk/target/linux/cns21xx/config-3.8 * cns21xx: disable legacy PTY devices Sep 13 15:39:31 juhosg r37968 trunk/target/linux/ cns21xx/profiles/00-default.mk cns21xx/modules.mk cns21xx/patches-3.8/104-cns21xx-usb-ehci-support.patch * cns21xx: make cns21xx-ehci a separate driver Sep 13 15:40:24 Hauke good afternoon :) Sep 13 15:47:49 zajec: no, but I have some time later on any will try Sep 13 15:48:03 s/any/and/ Sep 13 15:48:18 does anyone have suggestions for how to go about hunting down my kernel memory leak? https://iris.personaltelco.net/graphs/graph.php?action=zoom&local_graph_id=1530&rra_id=4&view_type=&graph_start=1346034051&graph_end=1379087235 Sep 13 15:53:01 KanjiMonster: ping Sep 13 15:54:46 Hauke: thanks, any ideas are more than welcome Sep 13 15:56:01 * Devastator hopes the bootlog was correct Sep 13 15:57:24 hauke r37969 trunk/target/linux/brcm47xx/patches-3.10/260-MIPS-BCM47XX-add-board-detection.patch * brcm47xx: detect WRT310NV1 Sep 13 16:01:34 Hauke, hello, if you can add maybe this router would be awesome.. https://dev.openwrt.org/ticket/14151 thanks! Sep 13 16:01:41 hauke r37970 trunk/package/kernel/broadcom-diag/src/diag.c Sep 13 16:01:41 brcm47xx: do not use GPIO configuration of WRT54G for every unknown Linksys device Sep 13 16:02:58 dape: I will have a look at it later Sep 13 16:03:26 thanks a lot, no rush, if any info needed i have it powered up Sep 13 16:08:04 Hauke: this dape's router doesn't have anything nice in the nvram, and doesn't use trx :| Sep 13 16:08:11 Hauke: someone really hacked CFE Sep 13 16:08:51 Hauke: Sep 13 16:08:52 [ 2.920000] 0x000000000000-0x000000ff0000 : "boot" Sep 13 16:08:54 [ 2.928000] 0x000000ff0000-0x000001000000 : "nvram" Sep 13 16:08:56 zajec: then we have to do detection by boardtype, boardnum and boardrev Sep 13 16:11:08 :| Sep 13 16:12:38 zajec: yes some vendors like to hacking some parts Sep 13 16:13:55 crazy chinese hackers :) Sep 13 16:22:16 Hauke ping Sep 13 16:39:45 Hauke: pong Sep 13 16:40:22 juhosg r37971 trunk/target/linux/ (20 files in 2 dirs) * cns21xx: add support for 3.10 Sep 13 16:40:23 juhosg r37972 trunk/target/linux/cns21xx/Makefile * cns21xx: switch to 3.10 Sep 13 16:40:25 juhosg r37973 trunk/target/linux/ cns21xx/patches-3.8 cns21xx/config-3.8 * cns21xx: remove 3.8 support Sep 13 16:43:10 dape: i was trying to find H218N on http://www.ztedevices.com/support/selectproduct.html?type=software but couldn't Sep 13 16:43:27 dape: did you see firmware for your router somehwere on the ZTE website? Sep 13 16:44:01 http://enterprise.zte.com.cn/en/products/network_lnfrastructure/cpe/201212/t20121210_373320.html says "No document" for "Software Downloads" Sep 13 16:47:46 zajec, they provide it directly to the isp... Sep 13 16:48:01 http://wwwen.zte.com.cn/en/products/access/cpe/201111/t20111110_352102.html Sep 13 16:51:13 and... ISP doesn't share it? ;) Sep 13 16:51:33 nope, i just got it via serial, its non public Sep 13 16:52:08 too bad, we need at least a sample firmware (that can be installed using CFE) to find out the firmware image format Sep 13 16:53:43 i can ask, should look at first bytes, right? Sep 13 16:54:52 dape: full firmware image would be nicer Sep 13 16:55:07 dape: in case there is more magic between kernel and the rootfs Sep 13 16:55:15 header will be the most important ofc Sep 13 16:55:36 but in case they are using some unknown header... we will have to ask for the tools for generating the header Sep 13 16:55:43 (and the whole image) Sep 13 16:55:47 * zajec afk for some time Sep 13 17:06:25 The_Lizard: ping Sep 13 17:25:20 juhosg r37974 trunk/target/linux/ (24 files) * generic/3.10: rename mtd patches Sep 13 17:27:30 KanjiMonster: there is no phy at address 0x1e on Devastators wrt310n, only at 0x1, but we have to access the registers at 0x1e Sep 13 17:30:03 juhosg r37975 trunk/target/linux/ generic/patches-3.10/008-hso-Fix-stack-corruption-on-some-architectures.patch generic/patches-3.10/063-arm-fix-fiq-vivt.patch generic/patches-3.10/007-hso-Earlier-catch-of-error-condition.patch * generic/3.10: refresh patches Sep 13 17:30:04 juhosg r37976 trunk/target/linux/ar71xx/patches-3.10/ 407-mtd-m25p80-allow-to-pass-probe-types-via-platform-data.patch 412-mtd-m25p80-zero-partition-parser-data.patch 406-mtd-m25p80-allow-to-specify-max-read-size.patch * ar71xx: refresh patches Sep 13 17:53:58 Hauke: I don't quite follow; the phy driver should still attach to 0x1e (there's a phy_fixup that assigns the 0x0's phyid to the "phy" at 0x1e, so that b53 can then "match") Sep 13 17:55:56 KanjiMonster: I do not get that ;-) Sep 13 17:56:11 how does this phy fixup work Sep 13 17:56:27 Hauke: it is run after scan but before probe Sep 13 17:57:20 Hauke: https://dev.openwrt.org/browser/trunk/target/linux/generic/files/drivers/net/phy/b53/b53_phy_fixup.c Sep 13 17:59:51 KanjiMonster: so it should scan at, 0x1e, it will find nothing, this fixup will be called, which does a scan at 0x1 instead and writes the phyid to the struct? Sep 13 18:01:40 Hauke: not quite. The basic mdio bus code will scan the bus (read out the phyids of all 32 phys), then run all fixups for all phyids; this one should then run if 0x1e is fixed up. After that the actual phy drivers are matched and then ->probe()d Sep 13 18:03:54 so there is no nothing found -> fixup step, it's just always fixups Sep 13 18:07:08 KanjiMonster: the fixup is just run for phy addresses where a phy is connected to, is that correct? So I assume this is just the case for 0x1 Sep 13 18:07:19 no Sep 13 18:07:26 it is run for all phys Sep 13 18:07:46 all phy addresses Sep 13 18:08:00 because if you can see the phy without a fixup, then you wouldn't need a fixup ;) Sep 13 18:10:43 KanjiMonster: I just see phy_scan_fixups() being called in phy_device_register(), which is only called if get_phy_device() returned a valid phydev Sep 13 18:10:59 which call path an I missing? Sep 13 18:12:04 I have flashed my own rom to my device, however, masquerading/nat is not working for any lan-based devices.. did i miss a kernel config or something? Sep 13 18:15:20 we can't tell from the information given Sep 13 18:15:41 hmm.. what options hsould be there? Sep 13 18:15:46 do i need conntrac? Sep 13 18:15:51 yes Sep 13 18:15:58 :/ oops Sep 13 18:16:11 basically all that are enabled already Sep 13 18:16:23 the default config already disables most uneeded stuff Sep 13 18:16:28 I thought this wouldn't have been a problem as I never unchecked conntract Sep 13 18:19:01 conntrac-tools is not what i need Sep 13 18:19:19 it's not a kernel config, and there's no kernel config for this Sep 13 18:19:28 put the output of ./scripts/diffconfig.sh Sep 13 18:19:32 ... into pastebin Sep 13 18:20:17 http://pastebin.com/nJNnrrkQ Sep 13 18:22:12 did you change anything in kernel_menuconfig ? Sep 13 18:23:13 Hauke: hm, I have definitely seen the fixup work on bcm63xx, but I see what you mean (the problem is that it won't create phy_devices if the phy_id is all 0xf) Sep 13 18:29:52 KanjiMonster: at 0x1e there was no phy created not even the generic phy driver was used, so I assume it returned null Sep 13 18:31:14 Hauke: and the only phy address where a phy is visible is 1, and not 0-4? Sep 13 18:31:44 KanjiMonster: I haven't tested let me write a patch for Devastator Sep 13 18:41:01 Hauke: if there is one at 0, maybe you can do something like "if (boardflags & BFL_ROBO) && phyaddr == 0x1e) phyaddr = 0; /* allow b53 to attach at 0 */" Sep 13 18:42:10 jow_laptop: mmm can't remember? is there a diffing tool for that? Sep 13 18:47:01 * russell-- remembers kmemleak Sep 13 18:47:43 froek: it will show up as a changed target/linux//config-* (or ...///config-*) Sep 13 18:47:50 *modified Sep 13 18:47:54 in svn/git Sep 13 18:52:50 KanjiMonster: this is my 3.10: http://pastebin.com/Rz95eWJi Sep 13 18:54:23 froek: that doesn't help; you need to check with git/svn status if they are listed as modified files Sep 13 18:55:01 KanjiMonster: oh sorry hold on Sep 13 19:10:23 KanjiMonster: no modifications Sep 13 19:10:26 svn stat returns nothing Sep 13 19:15:11 KanjiMonster: how does the fail-safe indication message send over udp work with b53? I thought it should work without some custom scripts, but it did not work, but I can connect when the device is in failsafe and the switch is deactivated (not forwarding packages between ports) Sep 13 19:17:12 compat-drivers will be the death of me Sep 13 19:23:16 Hauke should I git pull master before applying the patch? Sep 13 19:23:36 Devastator: yes Sep 13 19:23:45 ok Sep 13 19:24:13 Devastator: and make sure no other additional patches are applied Sep 13 19:24:46 ok Sep 13 19:24:57 hauke r37977 trunk/ target/linux/brcm47xx/patches-3.10/260-MIPS-BCM47XX-add-board-detection.patch package/kernel/broadcom-diag/src/diag.c * brcm47xx: board detection, GPIO for Linksys E1000 V2.1 Sep 13 19:31:15 Hauke thanks for your patience Sep 13 19:55:33 build #349 of rb532 is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/349 Sep 13 19:58:56 build #349 of ppc44x is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/349 Sep 13 20:01:12 zajec: now I know why my BCM5356 device was cheep, it just has 16MB ram Sep 13 20:02:55 Hauke: hehe :D Sep 13 20:03:03 i've to check mine ;) Sep 13 20:03:08 didn't even check Sep 13 20:03:27 gotta love hardware mods :) Sep 13 20:03:31 32MiB Sep 13 20:03:37 (Linksys E900) Sep 13 20:04:05 I will try to enable usb ports on WRT310N, it will be similar to WRT610N v1 Sep 13 20:04:19 Hauke: did OpenWrt boot fine? Sep 13 20:05:01 it booted and then the oomem killer killed some processes Sep 13 20:05:24 Ohh Sep 13 20:05:33 Is that because of 16MiB of RAM? Sep 13 20:05:35 Tooooo bad Sep 13 20:05:54 yes, but that was network boot Sep 13 20:06:09 well, installing the firmware should be safe Sep 13 20:06:22 now we find out how to make CFE write firmware :) Sep 13 20:06:31 but this device just costs 20,89 euro include shipping and 3 years warranty, which I already voided ;-) Sep 13 20:06:37 :P Sep 13 20:06:54 did you have to solder the PINs for serial console? Sep 13 20:10:47 Hauke: i did'nt know 16MiB of RAM is such a problem Sep 13 20:10:54 I expected lower performance Sep 13 20:11:04 No way of running... I dont know, torrent client ;) Sep 13 20:11:09 zajec: no there are already some pins for serial on the board Sep 13 20:11:14 no soldering needed Sep 13 20:11:17 Hauke: you lucky :) Sep 13 20:11:26 Linksys removed pins in E900 ;/ Sep 13 20:11:47 does anyone know how to remove the black thing where the chip model is printed? Sep 13 20:11:56 I haven't seen such pins on recent devices, expect on some high end asus devices Sep 13 20:12:03 I don't know the keyword for that to search Sep 13 20:12:21 I thought the vendors are trying to save the costs for the serial pins ;-) Sep 13 20:12:29 Devastator: uhm, you talking about the case on some chip? Sep 13 20:12:36 Devastator: that's a bad idea, and likely to destroy it Sep 13 20:13:13 Hauke: :D Sep 13 20:13:16 Hauke: or soldering :D Sep 13 20:13:46 had to solder my pins in :X Sep 13 20:13:46 zinx: something like this: http://img227.imageshack.us/img227/3647/sdc11476.jpg Sep 13 20:14:11 Devastator: yeah, removing that case will likely destroy the chip Sep 13 20:14:17 Devastator: most methods involve dissolving the case Sep 13 20:14:42 zinx I like hardware mods :( Sep 13 20:14:51 Devastator: wtf?! Sep 13 20:14:54 Devastator: there's nothing you can do with the case off one of those Sep 13 20:14:58 Devastator: what has happened to that chip?D Sep 13 20:15:13 Devastator: the components are far too small Sep 13 20:15:23 zajec that guy is enabling usb on wrt54gl Sep 13 20:15:24 Devastator: i.e., you need a fairly powerful microscope to even see them Sep 13 20:15:30 Devastator: omg :D Sep 13 20:16:20 zinx actually, you have to search the pins Sep 13 20:16:46 Devastator: you don't need to remove the chip's case to check pins :X Sep 13 20:17:02 (desoldering the chip is actually safer than removing the case...) Sep 13 20:17:53 I don't feel comfortable removing smd chips like this one, I remember I tried to do bga reballing on a via chip and.. well, you know Sep 13 20:18:12 well, then definitely don't mess w/ the chip's casing :P Sep 13 20:18:18 Devastator: you could also build your own routers, there are some people from china selling such chips in low quantities Sep 13 20:18:29 there are routers that actually come with USB on them Sep 13 20:18:36 i know it's hard to believe Sep 13 20:23:23 zajec: how do I show the flash partitions and their offsets in cfe? Sep 13 20:24:53 show devices Sep 13 20:24:54 probably Sep 13 20:27:15 too bad show just supports clocks ;-) Sep 13 20:27:27 build #367 of ppc40x is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/ppc40x/builds/367 Sep 13 20:28:16 build #369 of cobalt is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/369 Sep 13 20:28:19 Hauke: the switch should be configured to simple forwarding between ports; with port vlans used for port isolation Sep 13 20:29:12 Hauke: how is "e" in your name pronounced? ;) "e" like in "eagle" or "e" like in "egg"? ;) Sep 13 20:36:14 zajec: hmm I can not tell, I am very bad at this pronouncing stuff ;-) Sep 13 20:36:36 zajec: it's likely a schwa Sep 13 20:36:38 build #401 of brcm63xx is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/brcm63xx/builds/401 Sep 13 20:37:39 Hauke: I think you "broke" the build with your ssb/bcma update ;) -^ Sep 13 20:38:49 Support for BCMA in a SoC (BCMA_HOST_SOC) [N/y/?] (NEW) aborted! :) Sep 13 20:40:19 hauke r37978 trunk/package/kernel/linux/modules/other.mk * kernel: add missing config option Sep 13 20:40:27 KanjiMonster: should be fixed Sep 13 20:40:58 build #330 of sibyte is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/330 Sep 13 20:43:19 zajec: I just flashed OpenWrt on the device Sep 13 20:45:53 KanjiMonster: ahh.. found it: http://pastebin.com/Yy1RD4SF Sep 13 20:48:46 froek: so you did modify your kernel config? Also I have no idea what the original question/problem was, so you should probably tell that whoever was asking you whether your config was changed :p Sep 13 20:49:41 build #370 of lantiq is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/lantiq/builds/370 Sep 13 20:49:42 KanjiMonster: origially I didn't modify it. My original question was why I have no internet behind my router, and I haven't changed a configuration in /etc/config/network or anything Sep 13 20:49:50 build #381 of orion is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/381 Sep 13 20:50:14 I had thought I screwed up by missing a rule that would enable IP masq or soemthing.. but I could be wrong Sep 13 20:52:16 zinx I know, but it's fun to modify cheap hardware heheh Sep 13 20:59:39 KanjiMonster: I'm sure I'll figure it out.. i reflashed an image from the trunk snapshots, and internet is back.. so I figure something's amiss! Sep 13 21:02:27 build #352 of x86 is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/x86/builds/352 Sep 13 21:27:01 Hauke ping Sep 13 21:27:08 Devastator: pong Sep 13 21:27:55 Hauke unfortunately, I still get the same message: no phy devices Sep 13 21:28:16 more strange than that, no debugging is showed Sep 13 21:29:45 Hauke http://codepad.org/ValRtZNS Sep 13 21:31:46 Devastator: strange Sep 13 21:33:21 I even removed my .config and selected bcm947xx, tg3 + wl proprietary, saved, applied your latest patch then make Sep 13 21:33:41 KanjiMonster: have you looked at powersaving in b53? Sep 13 21:33:52 Hauke: not yet. Sep 13 21:34:42 do you know if that chould be needed to make the switch work at all? Sep 13 21:35:02 it shouldn't Sep 13 21:35:12 hmm this code is commented out for cfe, so it should not Sep 13 21:36:05 shouldn't I be seeing at least this? printk("b53_switch_reset_gpio wth gpio %i\n", gpio); Sep 13 21:37:03 yes Sep 13 21:37:21 meh.. Sep 13 21:37:48 verifying the files manually, all the changes are there Sep 13 21:39:52 Devastator: have you removed the old kernel source code before building with "make target/linux/clean" ? Sep 13 21:40:04 hum, no Sep 13 21:40:07 that could be it Sep 13 21:40:11 this does not look like the out put of the patch I gave you Sep 13 21:43:48 attempt #2 Sep 13 21:51:24 luka r37979 trunk/target/linux/imx6/base-files/etc/uci-defaults/02_network * imx6: add network defaults for GW5400-A Sep 13 21:59:19 build #379 of atheros is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/atheros/builds/379 Sep 13 22:14:44 Hauke now I have what you want Sep 13 22:15:59 Hauke http://codepad.org/uyR8O73M Sep 13 22:35:48 KanjiMonster what shows in my pastebin is not good news, right? Sep 13 22:38:44 Devastator: partially good, partially bad. I see that attaching to phyaddr 30 should normally work without any additional code (which is good). Also it shows that it enabling the switch does not work yet (which is bad, but hopefully fixable). Sep 13 22:40:34 KanjiMonster according to what you and Hauke discovered, my switch wants to attach to phyaddr 1, right? Sep 13 22:40:57 Devastator: no; that was just the tg3 code that always wanted to attach to phyaddr 1 Sep 13 22:41:57 that phy id is so unknown that even google can't find something Sep 13 22:43:46 #define BCM5395_VENDOR_ID 0x0143 #define BCM5395_DEVICE_ID 0xbcf0 Sep 13 22:45:30 anyway, you shouldn't worry about the phyid Sep 13 22:46:04 that you get the "failed to enable the switch" message means the driver did attach and it successfully identified the switch chip Sep 13 22:49:29 I see.. Sep 13 22:49:38 half way there then Sep 13 22:49:53 KanjiMonster do you think that hard work will benefit other routers? Sep 13 22:50:27 build #362 of uml is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/362 Sep 13 22:51:12 eh, that's one of the lesser reasons for me. My main criteria usually is "is it fun to solve?" ;-) Sep 13 22:51:57 KanjiMonster hahah, is it being fun for you then? Sep 13 22:52:08 yes Sep 13 22:52:14 great Sep 13 22:52:28 though I'm lacking the time to really look into it Sep 13 22:53:02 you need some vacation, again Sep 13 22:53:24 days just need more than 24 hours :P Sep 13 22:54:15 [RFC][PATCH] Implement Earth spin lock Sep 13 23:01:06 Devastator: could you add a msleep(500); after b53_write8(dev, B53_CTRL_PAGE, B53_SOFTRESET, 0x83); in target/linux/generic/files/drivers/net/phy/b53/b53_common.c Sep 13 23:01:22 Hauke sure! Sep 13 23:02:19 build #340 of avr32 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/340 Sep 13 23:03:10 Hauke just add and recompile, right? Sep 13 23:03:46 Devastator: use this to copy the modified file to your build dir: Sep 13 23:03:48 cp target/linux/generic/files/drivers/net/phy/b53/* build_dir/target-mipsel_uClibc-0.9.33.2/linux-brcm47xx/linux-3.10.10/drivers/net/phy/b53/ Sep 13 23:05:09 recompiling.. Sep 13 23:06:03 build #287 of iop32x is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/iop32x/builds/287 Sep 13 23:06:11 I'm in need of a Core i5 at least.. Sep 13 23:10:15 Devastator: when you are modifying stuff in the kernel, a "make target/linux/install" should be enough to rebuild the kernel and generate a new image without going through all the other stuff (and therefore a lot faster) Sep 13 23:10:55 thanks for the tip Sep 13 23:10:56 (modifying stuff in build_dir/target-*/linux-*/ that is compiled into the kernel and not a module) Sep 13 23:10:57 noted! Sep 13 23:15:25 Hauke same thing, should I give you a pastebin? Sep 13 23:15:51 Devastator: you still have "b53_common: Failed to enable switch!" Sep 13 23:16:00 Hauke yes Sep 13 23:25:20 Hauke do you think lspci output could help? Sep 13 23:36:40 Devastator: could you add "printk("found switch id: 0x%x\n", dev->chip_id);" after the msleep(500); and replace msleep(500); with mdelay(500); Sep 13 23:36:54 sure! Sep 13 23:45:56 good damn it, I forgot to make clean! Sep 13 23:55:14 god, not good, meh Sep 13 23:55:36 one day I will get it right the first time.. Sep 14 00:05:51 Hauke I'm trying my best but it doesn't show the printk Sep 14 00:07:02 Devastator: could you add it before b53_switch_reset_gpio(dev); Sep 14 00:08:31 Devastator: when you edit it in target/linux/generic/files/drivers/net/phy/b53/ you have to copy the files to the build dir before Sep 14 00:08:43 cp target/linux/generic/files/drivers/net/phy/b53/* build_dir/target-mipsel_uClibc-0.9.33.2/linux-brcm47xx/linux-3.10.10/drivers/net/phy/b53/ Sep 14 00:09:27 Hauke yes, when I do that, I don't need to make target/linux/clean, correct? Sep 14 00:09:36 yes Sep 14 00:09:40 should I keep mdelay(500);? Sep 14 00:09:46 yes Sep 14 00:19:40 Hauke switch id 0x65 Sep 14 00:35:06 probably something when accessing the phy goes wrong, you should not have a 5365 Sep 14 00:35:16 I will go to sleep now Sep 14 00:36:01 Hauke ok! Sep 14 00:36:44 yep.. 65 is definitely wrong.. Sep 14 00:37:15 afaik it should be 5395 Sep 14 00:39:21 well, no pinctrl driver to test, no switch working Sep 14 00:39:29 boring weekend ahead.. Sep 14 01:40:26 build #387 of brcm47xx is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx/builds/387 Sep 14 01:41:10 build #348 of ar7 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/ar7/builds/348 Sep 14 01:48:18 KanjiMonster do you have a theory why I'm getting 65 instead of 95? 5395, that is Sep 14 02:04:05 build #322 of kirkwood is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/kirkwood/builds/322 Sep 14 02:37:16 build #288 of ep93xx is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/ep93xx/builds/288 **** ENDING LOGGING AT Sat Sep 14 02:59:59 2013