**** BEGIN LOGGING AT Wed Nov 17 02:59:57 2010 Nov 17 03:50:07 nbd * r24017 /trunk/package/mac80211/ (19 files in 2 dirs): mac80211: update to wireless-testing 2010-11-16 Nov 17 06:05:24 nbd: last commit makes acx-mac80211 not build anymore, with 2.6.32 Nov 17 07:42:05 [florian]: well, the gpio reset thing from the gpl tarball did not do the trick Nov 17 09:19:35 dottedmag: Absolutely Nov 17 09:20:49 Ad the upstream not being active: it is not active because I do not have any outstanding feature requests and no bug reports. I hope I haven't missed any, I have hopefully set email notification on just about everything :) Nov 17 09:21:39 dottedmag: (And sorry for late reply, I am currently at GMT+0) Nov 17 09:32:46 hello Nov 17 09:32:54 hi Nov 17 12:16:30 mirko * r24018 /packages/utils/triggerhappy/ (6 files in 2 dirs): Nov 17 12:16:30 Triggerhappy is a lightweight hotkey daemon that Nov 17 12:16:30 can launch arbitrary commands on input events. Nov 17 12:16:30 It supports the hotplugging of devices and the Nov 17 12:16:30 processing of key combinations. Nov 17 12:16:31 Thanks to Stefan Tomanek! Nov 17 12:58:54 [florian]: ping Nov 17 12:58:58 <[florian]> KanjiMonster: pong Nov 17 13:00:25 [florian]: I finally made 2.6.37 to compile (and runtested it) with all generic and platform patches (as far as they weren't already comitted to mainline), should I prepare a patch which adds support for 2.6.37(-rc2) for bcm63xx? Nov 17 13:01:54 <[florian]> KanjiMonster: what's in that patch Nov 17 13:04:11 [florian]: creating a config-3.6.37 and patches-2.6.37/ with all patches that still apply (one or two are partially applied to 2.6.37, so I had to remove some parts) Nov 17 13:04:29 so nothing really new, just grunt work ;) Nov 17 13:06:25 hi, is there a rough ETA for the next openwrt release? or are releases made strictly "when ready"? Nov 17 13:06:34 when ready Nov 17 13:07:00 k, thx Nov 17 13:33:16 iSteve: see the last 4 commits in http://git.iplinux.org/hotplug2.git/ Nov 17 13:34:16 iSteve: three bugfixes and one new small feature. Nov 17 13:43:58 on first glance, all four look good Nov 17 13:44:29 I'm in the office now, but I think I'll merge all of them without changes when I get home Nov 17 14:15:35 ja, net gekregen van Adrien, om als template voor Best documentatie te gebruiken Nov 17 14:23:25 <[florian]> MarkV: please stick to english on that channel Nov 17 14:23:59 Oops. wasn't even targeted at this channel.. Please ignore :-( Nov 17 14:24:10 <[florian]> no problem Nov 17 14:30:05 mmmmh. that 'port 5 is magic, it has trunked as default, and * means 'default' information was what i missed Nov 17 14:31:34 any why is luci on my Backfire broken when it comes to vlans? or is trunking simply not implemented? Nov 17 14:32:03 build #27 of ps3 is complete: Failure [failed compile_3] Build details are at http://tksite.gotdns.org:8010/builders/ps3/builds/27 Nov 17 14:32:51 hansenet is evil. they run a dhcp on their modem l2 (where you do pppoe) which gives out ips but no dns and doesnt work Nov 17 14:32:57 roh: * means "treat all untagged frames on this port as belonging to this vlan" Nov 17 14:33:19 roh: right trunking is not implemented on luci 0.9 Nov 17 14:34:15 ah. how do i get uci to 'load' the newly set vlan switch hw config? Nov 17 14:34:26 rebooting helps, but that can't be it Nov 17 14:34:45 on brcm? only reboot. Nov 17 14:34:53 sigh. Nov 17 14:35:04 well.. it works now. thats whats important. Nov 17 14:35:07 build #29 of ubicom32 is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/ubicom32/builds/29 Nov 17 14:49:28 nbd: r24017 makes acx-mac80211 not build anymore, with 2.6.32 Nov 17 14:52:02 build #29 of pxcab is complete: Failure [failed compile_3] Build details are at http://tksite.gotdns.org:8010/builders/pxcab/builds/29 Nov 17 15:03:51 iSteve: great, thanks Nov 17 15:09:11 nbd * r24019 /trunk/package/acx-mac80211/Makefile: acx-mac80211: fix compile errors with the new compat-wireless Nov 17 15:11:06 <[florian]> nbd: thanks ^ Nov 17 17:18:39 iSteve: I have found another problem with hotplug2 - in forked mode environment variables set by event processing leak into the following event Nov 17 17:19:19 iSteve: which makes rules like FILEMODE is unset { setenv FILEMODE 0644 } kind of useless Nov 17 17:19:47 interesting Nov 17 17:19:51 I thought I fixed that Nov 17 17:19:54 which version are you running? Nov 17 17:22:20 [florian]: i've been trying to replace the 97x patches with something more workable, but i'm not getting the switch to probe. what am i doing wrong? Nov 17 17:23:18 iSteve: svn from google code + patches from openwrt Nov 17 17:24:14 <[florian]> sn9: if I could see you r patches maybe I could answer you ;) Nov 17 17:24:22 i'll dcc Nov 17 17:24:44 <[florian]> no, pastebin it please Nov 17 17:26:16 i could. what's wrong with dcc, though? Nov 17 17:26:40 dottedmag: (still in office) That's weird. The worker merely runs action_perform (workers/worker_fork.c:97), which in turn does unsetenv() when it finishes (action.c:54) on all registered events Nov 17 17:27:16 dottedmag: And the setenv command does appear to register the environment variable (rules/command.c:213 onwards) Nov 17 17:29:13 iSteve: got it. it is directly related to my patch which fixes segfault Nov 17 17:29:46 <[florian]> sn9: I do not like using dcc that's not convenient for me Nov 17 17:29:53 iSteve: I will investigate further -- looks like event->env_vars[i] is corrupted, but I don't know why. Nov 17 17:30:22 http://openwrt.pastebin.com/BR4s7pfF Nov 17 17:30:31 That is, without my patch event->env_vars[i] is corrupted and with it applied envvars aren't properly cleaned up. Nov 17 17:31:31 Ah, I know Nov 17 17:32:15 iSteve: see, env[i] is allocated at the beginning of the function, so if ruleset_execute() increases event->env_vars_c, then for at the end of function freees env[i] which is beyond the end of array. Nov 17 17:32:21 *env is allocated Nov 17 17:33:43 <[florian]> sn9: gpio 17 is your switch reset gpio ? Nov 17 17:34:02 according to the gpl sources it is Nov 17 17:34:41 <[florian]> ok Nov 17 17:34:53 <[florian]> there are no breaks in your loop on external_mii, why? Nov 17 17:35:18 line 141 of the patch Nov 17 17:35:40 dottedmag: I'm sorry -- allocated at the beginning of which function? Nov 17 17:35:47 iSteve: action_perform Nov 17 17:35:51 <[florian]> oh right Nov 17 17:36:20 dottedmag: Oh, in your patch. I see. Nov 17 17:36:54 iSteve: I will retire the dup/free patch and provide proper one. Nov 17 17:37:37 Cool. When (if:]) I get home today, I'll submit the three short ones then. BTW, when I'm not available, nbd should have commit access to the repo, too. Nov 17 17:41:20 <[florian]> sn9: so far this looks pretty good Nov 17 17:41:32 doesn't work Nov 17 17:41:45 i'll try an experiment, hang on Nov 17 17:41:51 <[florian]> sn9: what's wrong with the current patches btw? Nov 17 17:42:07 they are known to break everything Nov 17 17:42:28 <[florian]> sn9: like? Nov 17 17:44:24 makes both fixed phy and switch not work Nov 17 17:47:36 <[florian]> certainly they do not because I tested them on 3 different boards which have all 3 the different layout Nov 17 17:47:51 <[florian]> and the patches work, it's just your switch which does not work with Nov 17 17:48:20 there is an open ticket for 88e6060 and another open ticket for adm6996, all with the same issues Nov 17 17:48:36 <[florian]> let me explain you a little bit more why Nov 17 17:48:46 <[florian]> adm6996 switch are being configured using kind of SPI-like interface Nov 17 17:48:53 <[florian]> so basically you are writing settings in the flash Nov 17 17:48:58 <[florian]> and reset the switch with them Nov 17 17:49:24 <[florian]> that's how it's configured right now, since I have no idea what are the gpios the switch is connected to, in general, we just see the PHY id to match an ADM6996 Nov 17 17:49:37 <[florian]> but that PHY driver does not have any switch functionnality Nov 17 17:50:02 <[florian]> for m88e6060, we need to support hooking into the rx/tx path of the ethernet mac to send frames to the outside world Nov 17 17:50:15 <[florian]> and your case shows that there should be a model-specific switch reset sequence Nov 17 17:50:26 <[florian]> for me that's the actual situation Nov 17 17:50:45 <[florian]> all other cases/devices that I have tested, ip175a switches, adm6996 switches and fixed phy work Nov 17 17:52:56 well, there appear to be multiple reports otherwise, and not just with marvell Nov 17 17:53:36 <[florian]> which ones exactly? Nov 17 17:53:59 i just said adm6996 (not to mention fixed phy) Nov 17 17:54:26 <[florian]> well, adm6996 is properly detected, though not correctly driven Nov 17 17:54:46 [florian]: what did you think of my x86 patches to fix the cache-line size? Nov 17 17:54:59 still in the category of "doesn't work" though Nov 17 17:55:00 <[florian]> philipp64|laptop: they look good, let me get back home to get them committed Nov 17 17:55:49 <[florian]> sn9: if you want to call it like that, then yes Nov 17 17:56:32 Wipster: hi Nov 17 17:56:46 sn9, hi Nov 17 17:57:24 <[florian]> sn9: if you have more insights on which gpios adm6996 switches are usually connected to, I take it Nov 17 17:57:35 <[florian]> sn9: it would then be quite trival to port kmod-switch to using them Nov 17 17:57:40 all in due time Nov 17 17:57:55 <[florian]> let's make your switch work first :) Nov 17 17:58:00 exactly Nov 17 17:59:13 fun stuff I see Nov 17 18:01:48 back in a sec, flashing Nov 17 18:23:43 Wipster: i've been trying to replace the 97x patches with something more workable, but i'm not getting the switch to probe. what am i doing wrong? Nov 17 18:23:51 http://openwrt.pastebin.com/BR4s7pfF Nov 17 18:30:03 lets see, so when you scan the mdio bus the kernel doesn't see it and load in its driver? Nov 17 18:30:13 correct Nov 17 18:30:32 that's why i put in the second scan, but still nothing Nov 17 18:30:41 [florian]: which of the two patches do you prefer? Nov 17 18:34:52 Wipster: ideas? Nov 17 18:36:24 sn9, well it should popup on the mdio scan regardless of MII reg and disabling EPHY, from what I can tell anyway, but try setting mii and ephy before it does the first mdio scan? Nov 17 18:37:05 tried it Nov 17 18:37:31 the switch was detected only with your patchset, not mine Nov 17 18:37:48 sn9, which change in that stopped it detecting? Nov 17 18:38:03 replacing your patches with mine Nov 17 18:38:34 i can't really see what's essentially different that makes it not detect Nov 17 18:39:53 wait a sec... are the offset thingies needed for detection too, not just for operation? Nov 17 18:40:20 not for operation, thats just to handle the extra 2 bytes the switch handles Nov 17 18:40:29 sory not for detection Nov 17 18:40:58 not something like mvswitch not in your config? Nov 17 18:41:06 it's in there Nov 17 18:44:51 is anything coming out in the mask at 16 onwards once its probed? Nov 17 18:45:20 what do you mean by 16? Nov 17 18:45:48 sorry, bit 16 ... fingers not keeping up with brain it seems Nov 17 18:46:01 bit 16 of what? Nov 17 18:46:25 phy_mask? Nov 17 18:47:29 the mask variable after the reset Nov 17 18:47:45 when its been read that is Nov 17 18:47:49 after which reset? Nov 17 18:48:45 reset(cpmac_mii) line 1282 area Nov 17 18:51:17 i will check Nov 17 18:51:31 that will tell you if the switch is giving you some phy_ids to work with... Nov 17 18:55:22 are there any ar7 ohios which connect the inbuilt phy to the outside world? or can we assume they will all have switches, reason for saying it with the ephy on and no mii reg set the switch detects so it thinks things are fine but it deadlocks the after a second or two Nov 17 18:56:15 i am currently connected to the outside world via a speedport w501v which i believe to be such a device Nov 17 18:56:49 it has only a single ethernet port (hence no switch) and an ohio Nov 17 18:59:09 ahhhhh well botheration ok, ok well how about we use the phy_ids in conjunction with has_high_cpmac, so from the id it detects a switch (more then one id reported, I think) then it checks for ohio then disables the ephy etc, if it only detects one phy_id the internal one it doesn't disable Nov 17 18:59:48 that should catch ohios without switch.... Nov 17 19:01:38 i thought that was what i was trying to do Nov 17 19:02:19 btw, after reset, the mask is 0xffff0000 Nov 17 19:04:27 well I was thinking it might need to happen before the mdio register. so it is responding hmmm Nov 17 19:05:39 do the most significant 16 bits mean something? Nov 17 19:06:28 thats the switch giving back its phy_ids, if I recall Nov 17 19:06:52 i thought that was least significant bits Nov 17 19:07:41 bit 16 up I thought, could be mistaken Nov 17 19:08:11 then, what do the least significant bits mean? Nov 17 19:09:35 no phy id's I guess, another of my switches report 1 from the lsb all the way up Nov 17 19:10:55 as you can see I'm no netdev just an enthusiastic hacker trying to get to grips with it Nov 17 19:18:36 jow * r24020 /trunk/package/base-files/ (3 files in 3 dirs): [package] base-file: add metric option for static and dhcp protos, this simplifies the management of multiple default routes Nov 17 19:19:15 jow * r24021 /trunk/package/6to4/ (Makefile files/6to4.sh): [package] 6to4: implement metric option Nov 17 19:19:57 jow * r24022 /trunk/package/6in4/ (Makefile files/6in4.sh): [package] 6in4: implement metric option Nov 17 19:24:32 jow * r24023 /branches/backfire/package/6to4/ (. Makefile files/6to4.sh): [backfire] merge r23996, r23997, r23998 and r24021 Nov 17 19:25:49 jow * r24024 /branches/backfire/package/base-files/ (3 files in 3 dirs): [backfire] merge r24020 Nov 17 19:26:45 jow * r24025 /branches/backfire/package/6in4/ (Makefile files/6in4.sh): [backfire] merge r24022 Nov 17 19:34:02 Wipster: the mask was the issue Nov 17 19:48:36 sn9, ah nice gratz Nov 17 19:48:48 maybe i'm doing this backwards Nov 17 19:49:22 maybe instead of trying internal phy and then external, i should reverse that Nov 17 19:50:21 there is only one internal phy, right? is that only on ohio? what about sangam or titan? Nov 17 19:54:16 This I am not sure about, I think sangam also has internal which can be configured as external and an external only. I can check the product briefs Nov 17 19:54:25 no idea about titans though Nov 17 19:54:56 from the code I have seen I would say two interfaces both and be internal or external, but thats pure speculation Nov 17 19:55:05 *can Nov 17 19:59:29 i have an idea; will try now Nov 17 21:45:46 Wipster, [florian]: i got the switch working, sort of. ethernet ports 1 and 2 are eth0.2 and eth0.1, but 3 and 4 are missing in action Nov 17 21:46:32 sn9, nice! how did you get swconfig to connect... I'm having failed to connect Nov 17 21:46:40 no Nov 17 21:46:51 i have to reboot to reconfig the switch Nov 17 21:47:10 swconfig fails Nov 17 21:47:27 only /etc/config/network can control it Nov 17 21:47:49 yeh I was seeing that, odd Nov 17 21:48:15 i need to know how cpmac can tell whether the detected switch is marvell or not, because the offset is definitely needed, but should be conditional Nov 17 21:48:43 ptk_align Nov 17 21:48:50 what about it? Nov 17 21:49:14 its exposed but only mvswitch will set it so you can offset += pkt_align Nov 17 21:49:32 but initial value of offset is 2 Nov 17 21:49:45 wouldn't it be zero for non-marvell? Nov 17 21:50:07 no pkt_align will be 0 for non marvell Nov 17 21:50:33 then where does the initial value of 2 come from? Nov 17 21:50:36 for offset Nov 17 21:51:01 so the IP header is on a cache boundry Nov 17 21:52:10 so for non-marvell, the offset should be 2, and for marvell, a bigger offset? Nov 17 21:52:26 for marvell it should be 4 or 0... Nov 17 21:52:50 how can it be 0 if it starts as 2 and gets added? Nov 17 21:53:29 because the switch adds 2 bytes (doing the offset for you so to speak), well it could be zero theoreticaly as it wont need to be offset but adding Nov 17 21:54:23 but wasn't it already zero without your enable patch? Nov 17 21:54:52 no because its padding by 2 as standard Nov 17 21:56:09 so why did the patch need to specifically do "offset = 2;" ? Nov 17 21:57:27 so you need the ip header on a 4byte boundry, in normal cases you offset by 2 to IP align it. Nov 17 21:57:45 without the patch its still doing reserve(skb, 2) Nov 17 21:58:21 or NET_IP_ALIGN if you prefer Nov 17 21:59:11 so the initial value for the var is added to pkt_align as a _replacement_ for the 2 in "reserve(skb, 2)" ? Nov 17 21:59:47 so with the switch adding two bytes you either dont need to offset it by anything, or you offset by 4. Yeh Nov 17 21:59:55 ok Nov 17 22:00:20 now, do you have any ideas how to access ethernet ports 3 & 4? Nov 17 22:00:57 i tried eth0.[0-8] Nov 17 22:01:31 have you set the initial vlans to that? Nov 17 22:01:34 you probably have to setup a vlan with the port (and the cpu port) as a member, first Nov 17 22:01:53 no, i just replaced eth0 in the bridge conf Nov 17 22:02:31 thats why then the standard vlans .1 is the lan and .2 is the wan Nov 17 22:02:33 found that port 1 is eth0.2 and port 2 is eth0.1 Nov 17 22:03:02 these are supposed to be four lan ports Nov 17 22:03:19 the wan would be nas0 Nov 17 22:03:21 and there is nothing specified for the others, thats why we couldn't get data.... you switch is connected totally differently Nov 17 22:03:50 wait a sec Nov 17 22:03:57 the initial vlan in mvswitch port 0-3 are lan port 4 is wan 5 is cpu, right? Nov 17 22:06:21 silly me, eth0.1 is ports 2, 3, and 4 Nov 17 22:06:50 and i am going by the numbers printed on the case Nov 17 22:07:33 yeh on the switch that should be 0 1 2 3 , so one of those is not connected to the outside world Nov 17 22:07:53 gotta find which ones connected to which ;) Nov 17 22:08:47 my first guess would be that 1 on the case is 4, 2 is 3, 3 is 2, and 4 is 1 Nov 17 22:09:10 is the cpu one right, do you get packets? Nov 17 22:09:48 whatever is in the initial vlan lets me ping over ethernet Nov 17 22:11:45 sweet sorted Nov 17 22:15:49 heres a question if you probe the mdio bus to get the phy_id's and you have say two external phy's how can you tell which phy is connected to which interface? Nov 17 22:17:02 I am using backfire-rc3 and I enabled support for HWMON and LM87 but openwrt never builds hwmon-core Nov 17 22:17:10 I get satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-hwmon-lm87: * kmod-hwmon-core * Nov 17 22:28:34 Wipster: just have to know it per model, i guess Nov 17 22:30:55 well could check the router model in platform and load a predefined vlan map perhaps for routers which differ electrically Nov 17 22:31:05 maybe Nov 17 22:31:18 brcm47xx does that Nov 17 22:31:49 now, who might have an idea why vlynq doesn't work? Nov 17 22:32:36 it reports the device id as zero Nov 17 22:48:04 nbd * r24026 /trunk/target/linux/x86/ (4 files in 4 dirs): x86: refresh config, enable pci express support Nov 17 22:49:58 nbd: how 'bout you? Nov 17 22:50:52 ? Nov 17 22:51:07 [Wed 2010-11-17 02:25:04 PM PST] now, who might have an idea why vlynq doesn't work? Nov 17 22:51:07 [Wed 2010-11-17 02:25:51 PM PST] it reports the device id as zero Nov 17 22:51:39 no idea Nov 17 22:51:49 i think it's been more than 4 years since last time i looked at vlynq Nov 17 22:52:21 so it's been all [florian] since? Nov 17 22:53:16 nbd * r24027 /branches/backfire/target/linux/x86/ (generic/config-default olpc/config-default): x86: enable pci express support (backport of r24026) Nov 17 22:57:26 [florian]: you asleep? Nov 18 01:44:39 does the 88E6060 work with swconfig on other targets? Nov 18 01:45:35 i.e. atheros Nov 18 02:08:57 build #34 of brcm63xx is complete: Failure [failed compile_7] Build details are at http://tksite.gotdns.org:8010/builders/brcm63xx/builds/34 Nov 18 02:50:47 build #32 of at91 is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/at91/builds/32 **** ENDING LOGGING AT Thu Nov 18 02:59:58 2010