**** BEGIN LOGGING AT Tue Oct 19 02:59:57 2010 Oct 19 05:21:54 yes, so can we revert r22663? Oct 19 05:22:08 since it broke things? Oct 19 05:23:02 or at least, commit something the unbreaks those things? Oct 19 05:23:13 russell_: you need to talk to Hauke Oct 19 05:23:22 he's in charge of that Oct 19 05:23:57 i got the impression he'd kind of thrown up his arms on the subject Oct 19 05:24:34 it is still the nvram return value stuff? Oct 19 05:25:22 yeah, if i revert that commit and apply my patch (from the mailing list), wgt634u boots again and broadcom-diag detects the board Oct 19 05:25:24 dumb question: does PPP have a UCI interface, or does it need to be configured manually? Oct 19 05:25:42 philipp64|laptop: uci Oct 19 05:25:50 xMff: get a chance to look at the PPP version bump? Oct 19 05:26:06 it's not in /etc/config/network by default. Oct 19 05:26:37 no not yet, my openwrt timeslice is basically over for now and I need to get luci back in shape... Oct 19 05:26:44 http://wiki.openwrt.org/doc/uci/network#protocol.ppp.ppp.over.modem Oct 19 05:26:51 is it really acceptable to commit stuff that breaks long-supported devices, i guess is my underlying question. Oct 19 05:27:38 russell_: no it is not, but on the other hand the devs do not like to mess with each others target Oct 19 05:29:00 philipp64|laptop: I'll have more time to look into "enhancements" if the release phase is over Oct 19 05:30:36 hmm... interesting Oct 19 05:30:48 flash crashed and took thunderbird and firefox with it Oct 19 05:30:50 wtf Oct 19 05:37:11 russell_: so you traced down the failure to 23529 ? Oct 19 05:37:57 r22663 is what makes the console disappear (and goodness knows what else) Oct 19 05:38:06 (since it's invisible) Oct 19 05:38:37 hmm Oct 19 05:38:45 revertig it will break other for sure Oct 19 05:38:54 +n +s Oct 19 05:39:20 "i was here first!" ;-) Oct 19 05:41:21 hm Oct 19 05:41:34 the code used to have some swap serial workaround which relied on cfe_getenv Oct 19 05:41:47 where is that? Oct 19 05:42:02 arch/mips/bcm47xx/setup.c Oct 19 05:43:23 hmm Oct 19 05:43:48 maybe it'll be enough to swap nvram_getenv and cfe_getenv Oct 19 05:44:01 since nvram_getenv will always suceed Oct 19 05:44:16 maybe nvram_get won't find anything by sdram_ndcl on a wgt Oct 19 05:44:45 problem is that it unconditionally returns 1 Oct 19 05:44:51 so it allways suceeds Oct 19 05:45:48 what is the point of the test, then? that seems crazy. Oct 19 05:46:07 the test is fine Oct 19 05:46:24 until 23592 breaks the sematics of nvram_get Oct 19 05:47:19 i'm not even rev'd up that far Oct 19 05:47:19 or actually restores it, but other stuff was changed so that the former correct behaviour is now broken Oct 19 05:47:38 i've been testing r23482 Oct 19 05:49:14 which kernel? Oct 19 05:49:21 2.6.34.7 Oct 19 05:49:32 https://dev.openwrt.org/changeset/22768/trunk/target/linux/brcm47xx/patches-2.6.34 Oct 19 05:49:54 note the hunk in 400-arch-brcm47xx.patch Oct 19 05:50:08 oh nvm Oct 19 05:50:14 its just a context change Oct 19 05:50:40 my git pull just got me as far as r23528, where is this 23592? Oct 19 05:51:31 oh nvm that rev Oct 19 05:51:41 I copied the wrong number from the backlog Oct 19 05:51:50 ah ok Oct 19 05:51:50 and even managed to swap the last two digits Oct 19 05:51:56 yeah, i wondered Oct 19 05:52:27 I'm going back and forth in https://dev.openwrt.org/changeset/22663/trunk/target/linux/brcm47xx/patches-2.6.34 Oct 19 05:52:37 and try to understand the changes Oct 19 05:53:02 hope I someday get to be a committer... I got patches stacking up 3 and 4 deep... Oct 19 05:53:18 but do they break anything??? Oct 19 05:53:58 22424 Oct 19 05:54:33 it introduces the nvram_get || cfe_get Oct 19 05:54:47 later nvram_get is changed (back) to always return 1 Oct 19 05:54:53 "fix return codes of nvram_getenv. Now it behaves like cfe_getenv" Oct 19 05:54:53 which breaks the serial fixup check Oct 19 05:57:07 https://dev.openwrt.org/changeset?new=23516%40trunk%2Ftarget%2Flinux%2Fbrcm47xx%2Fpatches-2.6.34&old=22296%40trunk%2Ftarget%2Flinux%2Fbrcm47xx%2Fpatches-2.6.34 Oct 19 05:57:12 this one is easier to review :) Oct 19 05:57:55 when ignoring all the style changes it still leaves the changed setrial fixup Oct 19 06:02:22 I wonder what'd happen if you swap cfe_getenv and nvram_getenv Oct 19 06:03:13 ok, what am I missing? http://pastebin.ca/1966593 Oct 19 06:04:17 russell_: http://paste.openwrt.org/d602d124f Oct 19 06:04:39 I'm looking at /etc/ppp/options* and there is no "options.wan" file, or other signs of it taking effect. Oct 19 06:04:48 xMff: will try ... Oct 19 06:05:42 philipp64|laptop: cat /proc/`pidof pppd`/cmdline ? Oct 19 06:06:46 no pppd running. Oct 19 06:07:00 k, you might also this atm-bridge thing Oct 19 06:07:03 +need Oct 19 06:08:16 and an option ifname like atm0 or naws0 Oct 19 06:08:18 nas0 Oct 19 06:08:53 I have CONFIG_PACKAGE_ppp-mod-pppoa=y in my .config... Oct 19 06:09:30 br2486ctl is only used by pppoe. it's not required for pppoa. Oct 19 06:10:34 don't you still some sort of ifname to point pppd to? Oct 19 06:10:38 +need Oct 19 06:11:22 an yeah, its constructed from vc etc. Oct 19 06:11:49 xMff: what rev is that patch against? Oct 19 06:12:02 russell_: whatever I have here Oct 19 06:12:04 oh nm, /me learns to read Oct 19 06:13:01 philipp64|laptop: starting of pppd is done in /lib/network/pppoa.sh Oct 19 06:13:19 hmm, ok, missing "auto 1" Oct 19 06:13:52 hm no, pppoa needs a coldplug_interface_pppoa() procedure Oct 19 06:14:18 since it does not reference any traditional interface the ifup -a on boot will miss it Oct 19 06:16:06 philipp64|laptop: http://paste.openwrt.org/d50216223 Oct 19 06:16:07 found two bugs in the pppoa parsing: (1) you can't specify the interface on a multi-DSL box (i.e. 1.0.32 for 0/32 on the second interface), and (2) ifname should *not* be required. Oct 19 06:16:13 that will make it start on boot Oct 19 06:16:28 it is not required Oct 19 06:16:34 ifname is nowhere used Oct 19 06:16:44 its just passed in Oct 19 06:16:59 because all other protos use it Oct 19 06:18:26 as for the interface Oct 19 06:18:32 you can reuse the unused device option Oct 19 06:18:45 actually, from the wiki: "This option may be empty or missing if only a wireless interface references this network or if the protocol type is pptp or 6in4" Oct 19 06:18:59 well then let me add pppoa Oct 19 06:20:35 fixed Oct 19 06:21:18 http://paste.openwrt.org/d4cf7a9c2 Oct 19 06:23:20 at least that would be my suggestion Oct 19 06:23:31 option device 0 for DSL adapter #1 Oct 19 06:23:35 option device 1 for DSL adapter #2 Oct 19 06:24:04 its unused atm so it would be suitable Oct 19 06:24:30 3g / ppp used device for the device node (/dev/tty...) Oct 19 06:26:32 ok. btw, do we really need an mtu? If the DSLAM wants to negotiate a 4096 byte MTU, who am I to say no? Oct 19 06:27:29 I suggest to change the default to something reasonable then Oct 19 06:27:33 I'd rather not default it if omitted, and just let the DSLAM set it to the largest it will support. Oct 19 06:27:44 sure, would work too Oct 19 06:28:13 http://paste.openwrt.org/d446f8a93 Oct 19 06:29:29 as you might have noticed the pppoe, pppoa and 3g scripts inherit from ppp.sh and some code was just copy-pasted along the way Oct 19 06:30:42 yup I had the same idea for the diffs as you did. Oct 19 06:30:52 ditto for the device. Oct 19 06:31:33 ok, then I'll commit it Oct 19 06:32:14 wait a minute... Oct 19 06:32:36 "payload" doesn't actually get used. Oct 19 06:33:16 is there some corresponding pppd option or is it atm bridge specific stuff? Oct 19 06:34:31 it's an argument to br2684ctl (which is only used in pppoe). Oct 19 06:34:50 so you can strip it from your config and the network doc needs fixes Oct 19 06:35:00 yup. Oct 19 06:35:36 you said "auto" doesn't get used, right? Oct 19 06:35:46 not quite Oct 19 06:36:12 auto has only an effect if interface coldpluging is implemented Oct 19 06:36:17 and it defaults to 1 Oct 19 06:36:24 so there's no need to specify it Oct 19 06:36:37 usually you need it only to disable interface launch on boot Oct 19 06:38:00 http://paste.openwrt.org/d7789b17d Oct 19 06:38:57 line 18, 23. 24 and 25 are redundant Oct 19 06:39:09 errr ignore lines 23-25. Oct 19 06:40:41 what was on line 32 ... you can also write this as : ${mtu:=1500} Oct 19 06:40:57 in case anyone cares. Oct 19 06:41:05 hmm. r23528 doesn't build for me ... Oct 19 06:41:09 Applying patch platform/900-bcm47xx_wdt-noprescale.patch Oct 19 06:41:09 patching file drivers/watchdog/bcm47xx_wdt.c Oct 19 06:41:09 Hunk #1 FAILED at 31. Oct 19 06:41:23 philipp64|laptop: well I think ommitting it if no mtu was given is the best choice Oct 19 06:41:55 ping [florian] Oct 19 06:42:00 sure, of course. I was just pointing some bash trivia. Oct 19 06:42:23 apparently ":" causes substitutions to be evaluated, and the result to be discarded. Oct 19 06:42:38 you mean :- ? Oct 19 06:43:30 try the following: Oct 19 06:43:50 : ${nosuch:=5} Oct 19 06:43:52 echo $nosuch Oct 19 06:44:04 ah, yes Oct 19 06:44:41 so my patch is basically the same as yours but with ${device:+$device.} just before the vpi/vci stuff. Oct 19 06:45:45 jow * r23530 /trunk/package/ppp/ (Makefile files/pppoa.sh): Oct 19 06:45:45 [package] ppp: Oct 19 06:45:45 - implement coldplugging for pppoa interfaces Oct 19 06:45:45 - honour device option to select the DSL adapter Oct 19 06:45:45 - don't set any default mtu, rely on pppd to negotiate it Oct 19 06:45:45 - bump pkg revision Oct 19 06:49:21 would be great if you could check whether /etc/hotplug.d/atm/20-atm-modem interferes now Oct 19 06:49:45 it was/is intended for usb adsl modems which pop up some time after init Oct 19 06:53:24 how to be sure if it does or not? Oct 19 06:53:51 well if you see in logread that pppd gets terminated and then restarts for example Oct 19 06:54:05 after a reboot Oct 19 06:54:26 build complete Oct 19 06:54:29 about to flash Oct 19 06:54:33 btw, quick question.... I know that you don't have time to review the entire diff I sent you.. it's lengthy... just want to make a quick simplification though. Oct 19 06:55:36 when gcc gets run on the files, it gets passed a lot of -I flags, most of them are superfluous. Oct 19 06:57:04 where do the -I flags get passed in? I really only need -I$(STAGING_DIR)/usr/include Oct 19 06:57:22 xMff, that got the console back, yay! Oct 19 06:57:25 http://paste.openwrt.org/d680cdba1 Oct 19 06:57:28 they're inherited Oct 19 06:58:10 btw, you can run "make package/ppp/refresh" to rebase all those patches Oct 19 06:58:20 to get rid of the fuzz Oct 19 06:59:07 what does that do? Oct 19 06:59:17 it refreshes all patches using quilt Oct 19 06:59:22 so that they fir properly Oct 19 06:59:31 without fuzzy offsets and stuff Oct 19 07:00:38 ah. Oct 19 07:01:06 ok, so about the -I flags? what do you mean they're inherited? from where? Oct 19 07:02:07 and I just rebuilt package/ppp ... now how to build a new image (squashfs)? Oct 19 07:02:11 they're in TARGET_CFLAGS which is used by the default Package/Build template Oct 19 07:02:30 passed as $(MAKE) ... CFLAGS="$(TARGET_CFLAGS)" Oct 19 07:02:38 see include/package-defaults.mk Oct 19 07:02:41 * russell_ applying my broadcom-diag patch on top and trying that Oct 19 07:03:45 lol Oct 19 07:03:49 no network! Oct 19 07:04:01 -_- Oct 19 07:04:45 jow * r23531 /trunk/package/ppp/files/etc/hotplug.d/atm/20-atm-modem: [package] ppp: honour option auto in atm hotplug Oct 19 07:05:02 diag: Router model not detected. Oct 19 07:05:02 roboswitch: Probing device eth0: No such device Oct 19 07:05:02 roboswitch: Probing device eth1: No such device Oct 19 07:05:02 from inside package/ppp/Makefile if I do $(info TARGET_CFLAGS=$(TARGET_CFLAGS)) I get: Oct 19 07:05:03 TARGET_CFLAGS=-Os -pipe -march=k6-2 -fno-align-functions -fno-align-loops -fno-align-jumps -fno-align-labels -fhonour-copts Oct 19 07:05:29 maybe my broadcom-diag patch will fix that? Oct 19 07:05:42 russell_: possibly Oct 19 07:05:50 <[florian]> xMff: pong Oct 19 07:06:33 * russell_ recovers via tftp so he can reflash via mtd Oct 19 07:06:33 [florian]: russell_ had an issue with 900-bcm47xx_wdt-noprescale.patch but I think it was pebkac (?) Oct 19 07:06:52 maybe Oct 19 07:06:57 but ... i didn't do nuthin Oct 19 07:07:09 so it still does not apply against .34 ? Oct 19 07:07:25 it seemed to already have been applied Oct 19 07:07:25 <[florian]> xMff: I have double applied it without noticing acoul already had done so Oct 19 07:07:33 ah ok Oct 19 07:07:39 * russell_ vindicated! Oct 19 07:07:52 <[florian]> what I do not understand is why the build did not fail with a patch already applied Oct 19 07:07:56 <[florian]> that's just weird Oct 19 07:08:05 it failed for me Oct 19 07:08:15 <[florian]> ah Oct 19 07:08:19 <[florian]> well, let me revert my change Oct 19 07:08:24 [florian]: maybe because you used a quilt series Oct 19 07:08:33 <[florian]> xMff: I used patch actually Oct 19 07:08:38 hm ok Oct 19 07:08:45 <[florian]> xMff: and then did a make target/linux/{clean,prepare} Oct 19 07:08:46 heisenbug Oct 19 07:08:54 <[florian]> or my stupidity :) Oct 19 07:09:20 florian * r23532 /trunk/package/opkg/patches/009-remove-upgrade-all.patch: Oct 19 07:09:20 Merge branch 'master' of git://nbd.name/openwrt Oct 19 07:09:20 Conflicts: Oct 19 07:09:20 package/opkg/patches/009-remove-upgrade-all.patch Oct 19 07:09:26 <[florian]> damn it Oct 19 07:09:29 hehe Oct 19 07:09:37 <[florian]> maybe I should keep using svn after all Oct 19 07:10:09 never use git pull when using git-svn Oct 19 07:10:17 florian * r23533 /trunk/target/linux/brcm47xx/ (3 files in 3 dirs): Oct 19 07:10:17 Revert "[brcm47xx] Add support for cores with slow WDT clock (bcm5354)" Oct 19 07:10:17 This reverts commit 7467fdab387f451082c15d17ce9ae4d91d74b6ca. Oct 19 07:10:50 philipp64|laptop: can you throw your current package/ppp/Makefile into pastebin? Oct 19 07:11:16 [florian]: revert commit with no explanation as to why the change was reverted? Oct 19 07:13:03 <[florian]> oh you are right Oct 19 07:13:08 * russell_ has network again, reflashing Oct 19 07:14:28 nope, roboswitch is still hosed Oct 19 07:14:37 crap Oct 19 07:14:39 [florian]: so why did you revert it? Oct 19 07:14:50 nbd: because it was applied twice Oct 19 07:14:59 ah Oct 19 07:16:54 nbd: does roboswitch nvram probes to find memory locations and stuff? Oct 19 07:17:18 package/switch/src/switch-robo.c Oct 19 07:17:30 xMff: working on it. Oct 19 07:17:37 #define getvar(str) (nvram_get(str)?:"") Oct 19 07:17:51 hm ok, this is fubared too then Oct 19 07:17:55 yeah Oct 19 07:18:18 /* WAN port LED, except for Netgear WGT634U */ Oct 19 07:18:18 if (strcmp(getvar("nvram_type"), "cfe") != 0) Oct 19 07:18:26 xMff: http://paste.openwrt.org/d1882366d Oct 19 07:18:27 that's easy Oct 19 07:18:32 looks like you can port your diag change 1:1 Oct 19 07:18:39 yeah Oct 19 07:18:53 crappy though it is, ought to work Oct 19 07:20:06 philipp64|laptop: hm, CFLAGS is the wrong var Oct 19 07:20:15 you need TA$RGET_CFLAGS Oct 19 07:21:32 check include/package-defaults.mk, line 119 Oct 19 07:26:06 nbd: working on it. Oct 19 07:28:48 * russell_ reflashing again with fixed roboswitch Oct 19 07:30:14 gha Oct 19 07:30:22 no workie Oct 19 07:33:04 when it works, it says: "roboswitch: Probing device eth0: found a 5325!" Oct 19 07:35:37 are you sure the wgt war got applied? Oct 19 07:35:51 whut? Oct 19 07:36:08 the condition you modified, is it actually reached? Oct 19 07:37:21 oh, no idea. /me starts sprinkling printk's Oct 19 07:40:39 shouldn't all this board detection crap be centralized somehow? Oct 19 07:41:10 so each thing doesn't have to invent its own probing mechanisms? Oct 19 07:42:03 swalker * r23534 /packages/ipv6/miredo/Makefile: [packages] miredo: replace dead upstream url Oct 19 07:42:55 yep, it should Oct 19 07:47:25 what was the command to resquash the filesystem again? Oct 19 07:47:44 swalker * r23535 /packages/net/click/Makefile: [packages] click: store the git hash in the PKG_REV variable, add PKG_RELEASE, remove redundant PKG_CAT and PKG_BUILD_DIR Oct 19 07:48:16 make target/linux/install Oct 19 07:53:27 interesting Oct 19 07:53:33 my printk's didn't fire Oct 19 07:57:15 dev_get_by_name(&init_net, devname) must be returning NULL Oct 19 07:59:23 swalker * r23536 /packages/sound/mt-daapd/Makefile: [packages] mt-daapd: replace dead upstream url Oct 19 07:59:38 * russell_ wonders where init_net comes from Oct 19 08:01:26 global kernel struct Oct 19 08:01:57 I think your issue may be with b44 and not roboswitch Oct 19 08:02:32 if dev_get_by_name files you don't even have an eth0 to attach to Oct 19 08:02:41 *fails Oct 19 08:02:51 that makes sense Oct 19 08:04:06 b44: probe of ssb0:0 failed with error -22 Oct 19 08:05:26 this is interesting ... target/linux/brcm47xx/patches-2.6.34/001-backport.patch Oct 19 08:08:04 but not too interesting Oct 19 08:09:15 https://dev.openwrt.org/changeset/22296/trunk/target/linux/brcm47xx/patches-2.6.34/210-b44_phy_fix.patch Oct 19 08:09:32 yeah, i'm looking at that right now Oct 19 08:09:34 another nvram always succeeds thing Oct 19 08:09:56 acoul * r23537 /packages/net/usbip/patches/000-upstream_svn_152.patch: net/usbip: cosmetic fix of r23514 Oct 19 08:10:13 if (nvram_getenv("boardnum", buf, sizeof(buf)) > 0) Oct 19 08:10:13 return; Oct 19 08:10:15 hello Oct 19 08:10:18 that looks like a typo to me Oct 19 08:10:38 the previous variant checked for a not existing var so the condition should read < 0 Oct 19 08:10:47 or <= 0 Oct 19 08:12:47 same further down Oct 19 08:12:58 yeah there are three > 0's Oct 19 08:16:06 I have to got to work now, wille be back shortly Oct 19 08:16:10 k Oct 19 08:16:15 thanks Oct 19 08:52:48 xMff /me has to go to sleep now Oct 19 08:53:44 * russell_ could try a patch if you come up with one Oct 19 08:53:58 in 8 hours or somethin Oct 19 08:54:00 g Oct 19 11:00:30 mb * r23538 /packages/libs/intltool/Makefile: intltool: Check for Perl XML prereq Oct 19 12:38:21 moin Oct 19 12:38:33 'lo Oct 19 12:38:40 i have a patch pending to make the zoneinfo package compile on mac os x Oct 19 12:38:57 do i insert it into a trac issue or send a patch to the ml? Oct 19 12:39:15 i'm also not quite sure if you will accept a patch for the zoneinfo sources Oct 19 12:39:35 or if i should submit it somewhere else (upstream?) Oct 19 12:39:55 i'm still somewhat newish to openwrt Oct 19 12:40:09 and zoneinfo looks like it's not part of the core package(s) Oct 19 12:40:35 well I guess I'm the guy responsbile for it Oct 19 12:40:52 create a ticket at dev.openwrt.org, attach your patch and assign it to jow Oct 19 12:41:27 your wish is my command :) Oct 19 12:52:25 jow_laptop: the component for that ticket would be luci? Oct 19 12:52:33 DonDiego: yes Oct 19 13:24:51 jow_laptop: https://dev.openwrt.org/ticket/8100 Oct 19 13:25:12 jow_laptop: it seems i cannot assign the issue to anybody Oct 19 13:25:31 i'm here to discuss the issue if you want Oct 19 13:25:51 the patch i proposed is more of a workaround since it exposes tzsetwall() unconditionally Oct 19 13:26:02 not sure if this is acceptable.. Oct 19 13:26:15 but of course there are multiple alternatives Oct 19 13:26:43 I'll check when I'm back home Oct 19 13:26:51 thx Oct 19 14:22:42 btw, is there a particular reason why the serial console defaults to 57600 bauds instead of 115200? Oct 19 14:23:08 from my naive perspective the faster default seems more useful.. Oct 19 14:24:32 we usually stick to the defaults of the bootloader Oct 19 14:24:44 principle of least surprise Oct 19 14:25:32 well, that's kinda why i'm asking - my bootloader uses 115200 and the openwrt kernel defaults to 57600 Oct 19 14:37:39 (SMCWBR11S-N and SMCWBR11S-3GN routers) Oct 19 14:41:51 what architecture is that? Oct 19 14:42:18 ralink rt3050F Oct 19 14:44:08 ah ok Oct 19 14:44:32 well I suppose the eval boards juhosg had access to used 57600 Oct 19 14:45:13 could be that a solution like in target/linux/x86 is used where the baudrate is selected depending on the choosen model Oct 19 14:45:30 s/is used/is needed/ Oct 19 15:22:43 build #9 of ubicom32 is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/ubicom32/builds/9 Oct 19 15:25:54 I've noticed an option in the original firmware from my board bcm63xx has this option: Inventel Workarounds ---> [*] Softirq round-robin (as in Linux 2.4) Oct 19 15:26:05 but openwrt doesnt have it Oct 19 15:26:58 can it be the origin of my problem on the board having low performance? Oct 19 15:30:36 build #12 of at91 is complete: Failure [failed compile_4] Build details are at http://tksite.gotdns.org:8010/builders/at91/builds/12 Oct 19 15:52:15 how should the PKG_VERSION and PKG_RELEASE be used? Oct 19 15:52:31 I noticed one of them was incremented for several packages at the same time Oct 19 15:53:02 PKG_RELEASE is incremented if a patch was applied to the packaged software or if some support script was changed Oct 19 15:53:22 PKG_VERSION alwas relates to the version of the packaged software Oct 19 15:53:35 if PKG_VERSION is incremented, PKG_RELEASE is reset to 1 Oct 19 15:55:47 so why were a lot of PKG_RELEASE changed to 2 a few months ago? Oct 19 15:56:42 because something in the packages was changed / patched and the committer who did that forgot to bump the pkg rev Oct 19 16:01:28 xMff: thanks Oct 19 16:03:38 the pkg_revision is basically interesting for opkg, so it can detect updates Oct 19 16:03:57 v1.2.3-1 vs. v1.2.3-2 Oct 19 16:04:09 think of it as a patch level Oct 19 18:39:29 isn't there any mechanism to convert a UCI list to a shell array? Oct 19 18:45:17 no since there are no shell arrays to begin with Oct 19 18:45:49 http://wiki.openwrt.org/doc/devel/config-scripting#reading.lists Oct 19 18:46:27 only in bash? Oct 19 18:48:04 oups...I was planning to use it, looks it's not sh compatible... Oct 19 21:51:37 hi, does someone know what can be if my openwode (working for first target release) detect usb peripheral (wifi or ethernet) and load the driver but then the interface is down and doesn't work? The drive is correct for the hardware. Oct 19 21:52:56 nbd * r23539 /trunk/package/mac80211/patches/404-ath_regd_optional.patch: ath9k: make the regulatory override less intrusive - allow it to parse CTLs Oct 19 22:14:33 nbd * r23540 /trunk/package/mac80211/ (22 files in 2 dirs): mac80211: update to wireless-testing 2010-10-19 Oct 19 22:43:51 nbd: ping Oct 19 22:43:56 pong Oct 19 22:44:24 curious why a ubiquiti picostation M 2HP shows 20dbm and not 27dbm for signal Oct 19 22:44:45 is there a hard limit or something ? Oct 19 22:45:14 20dBm is the regulatory limit, iirc Oct 19 22:45:19 nbd: does someone know what can be if my openwode (working for first target release) detect usb peripheral (wifi or ethernet) and load the driver but then the interface is down and doesn't work? The drive is correct for the hardware. USB Works fine, because if I attach an usb hd it is correctly mounted... Oct 19 22:45:22 for US ? Oct 19 22:45:54 OutBackDingo: yes Oct 19 22:45:56 Alicemirror1: no idea Oct 19 22:46:00 odd Oct 19 22:46:24 no, wait Oct 19 22:46:27 27 is the limit Oct 19 22:46:31 hm Oct 19 22:46:46 nbd: Argh ;( Oct 19 22:46:47 probably related to stintel's issue in #openwrt Oct 19 22:46:51 maybe the same issue as m4t in #openwrt :) Oct 19 22:46:58 OutBackDingo: scroll up a bit :) Oct 19 22:47:00 yeah Oct 19 22:47:05 in #openwrt not -devel Oct 19 22:48:00 OutBackDingo: running backfire on the picostation ? Oct 19 22:49:36 stintel: and trunk Oct 19 22:50:05 ic, well in backfire the easy workaround would be to remove package/mac80211/patches/540-.. Oct 19 22:50:26 and you should be able to use >20dBm with country=US again, according to what m4t said Oct 19 22:50:48 in trunk, well that patch is already upstream so a little more difficult Oct 19 22:53:02 ah, the channel maximum power is initialized to 20dBm by the driver Oct 19 22:53:25 if it worked without that patch, then that's probably random corruption Oct 19 22:53:46 since even without that patch, i see no place in the code where that limit is changed based on hw capabilities Oct 19 22:53:47 nbd: looks like the ar8236 replaced the ar8216; stumbled upon two devices having it (biggest chance I saw is that the 36 seems to have a 4k vlan table like the 8316) Oct 19 22:54:09 interesting Oct 19 22:55:16 stintel: soooo Oct 19 22:55:32 My pet project, if this is interesting for anyone: http://code.google.com/p/octodb/ Oct 19 22:57:07 stintel: i have an idea on how to fix this properly Oct 19 22:59:48 nbd: ok. I'll be happy to test any other patch :) Oct 19 23:02:00 i'll let you know when i have one Oct 19 23:02:05 working on it right now Oct 19 23:04:13 stintel: so will i :) Oct 19 23:06:48 I'll postpone going to be for a bit longer then ;-) Oct 19 23:10:14 going to bed * Oct 19 23:16:00 heh and windows is just great, it doesn't even show the channel or frequency used by a wifi connection Oct 19 23:25:24 signal: 33 dBm Oct 19 23:25:29 that seems wrong :P Oct 20 00:11:30 nbd * r23541 /trunk/package/mac80211/patches/ (3 files): ath9k: fix tx power display Oct 20 00:11:45 stintel, m4t, OutBackDingo: there you go Oct 20 00:11:54 this should also fix txpower > 20 dBm issues Oct 20 00:11:59 forgot to mention that Oct 20 00:12:47 nbd: any chance to backport to backfire ? Oct 20 00:13:30 i will do some more testing with trunk mac80211 soon Oct 20 00:13:37 if it proves stable, it will be backported as a whole Oct 20 00:14:04 cool Oct 20 00:14:09 too many fixes between backfire and trunk to keep track of Oct 20 00:14:13 thanks nbd Oct 20 00:14:22 not just my patches, but also other upstream fixes Oct 20 00:14:40 nbd: nice, thanks Oct 20 00:14:54 my card here only has power levels below 20 dBm, so i couldn't test for your specific issue Oct 20 00:15:08 however with my patch, it shows levels below 20dBm for the per-channel values now Oct 20 00:15:13 instead of the hardcoded vlaues Oct 20 00:15:17 so i assume it should work Oct 20 00:16:43 I'm able to test it Oct 20 00:20:52 flashing, bbiab :) Oct 20 00:27:40 nbd: http://paste.pocoo.org/show/277748/ Oct 20 00:29:33 what kind of device is this? Oct 20 00:29:41 channel flags seem ok but the txpowers are still off Oct 20 00:29:42 sec Oct 20 00:29:53 ieee80211 phy0: Atheros AR9160 MAC/BB Rev:0 AR5133 RF Rev:b0 mem=0xb0000000, irq=48 Oct 20 00:29:57 i mean device Oct 20 00:29:59