**** BEGIN LOGGING AT Fri Feb 10 02:59:57 2012 Feb 10 05:47:02 jow_laptop: so i just traced the instability underload of my shitastic wrt54gs back to /sbin/watchdog loosing to [irq/4-b43], [rcu_kthread], [ksoftirqd/0], etc Feb 10 05:47:20 service_start /bin/nice -n -15 /sbin/watchdog -t 5 /dev/watchdog Feb 10 05:47:23 kthx Feb 10 06:41:15 build #96 of rdc is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/rdc/builds/96 Feb 10 07:00:14 jow_laptop: how would I make a profile that has to set kernel options ala http://dpaste.com/700775/ ? **** BEGIN LOGGING AT Fri Feb 10 07:28:11 2012 Feb 10 07:50:13 philipp64|laptop: pong Feb 10 08:49:28 juhosg * r30401 /trunk/ (5 files in 5 dirs): kernel: update linux 3.2 to 3.2.5 Feb 10 08:49:30 juhosg * r30402 /trunk/target/linux/ (2 files in 2 dirs): ar71xx: refresh 3.2 patches Feb 10 08:49:31 juhosg * r30403 /trunk/target/linux/ar71xx/Makefile: ar71xx: switch to 3.2.5 Feb 10 08:49:33 juhosg * r30404 /trunk/target/linux/ar71xx/ (config-2.6.39 files-2.6.39/ patches-2.6.39/): ar71xx: nuke 2.6.39 support Feb 10 08:49:35 juhosg * r30405 /trunk/target/linux/ar71xx/ (81 files in 6 dirs): ar71xx: merge files-3.2 to files Feb 10 08:49:37 juhosg * r30406 /trunk/target/linux/ar71xx/ (18 files in 5 dirs): ar71xx: merge 3.2 fixes Feb 10 10:29:23 uhm, guys, just did a svn update for tp-link wr703n, is linux 3.2.5 enabled by default now? Feb 10 10:29:30 i see its started to download it Feb 10 10:31:55 wow, same for wr740n Feb 10 10:32:37 dape: yes Feb 10 10:33:34 you guys are the awesome then Feb 10 11:30:35 this is weird, was messing around with make kernel_menuconfig as usual but for tp-link wr703n, disabled all the debugging and unneeded support for this device and suddenly atheros ethernet support dissapeared from ethernet devices section Feb 10 11:31:30 didnt touch anything special in regard to what i did to old 2.6.39.4 Feb 10 11:44:32 hmm, PCI=n, i never touched this for 703n.. Feb 10 11:48:08 ok, here it is, having disabled every machine i dont compile for and keeping only ATH79_MACH_TL_WR703N=y it seems that PCI support dissapears.. Feb 10 11:48:27 thus preventing me to further choose atheros ethernet driver support Feb 10 11:48:37 could this be a bug in menuconfig ? Feb 10 11:52:06 HW_HAS_PCI seems no but im pretty sure tp-link wr703n has a pci a bus and uses that ag71xx ethernet part Feb 10 11:52:31 the ethernet is in the soc, not on the pci bus Feb 10 11:53:59 aight, but i still cant see atheros ethernet support in menuconfig Feb 10 11:56:27 CONFIG_NET_VENDOR_ATHEROS Depends on: NETDEVICES [=y] && ETHERNET [=y] && PCI [=y] but seems like having only ATH79_MACH_TL_WR703N=y in the device list unselects PCI Feb 10 12:05:00 ok, reading in 610-MIPS-ath79-openwrt-machines.patch i see wr741 selects SOC_AR724X and wr703n selects SOC_AR933X so then i dont need atheros ethernet support anymore (that unselects for my wr703n in menuconfig) ? Feb 10 12:05:25 i dont have serial on the little router so.. Feb 10 12:16:14 juhosg * r30407 /trunk/target/linux/ar71xx/patches-3.2/420-net-ar71xx_mac_driver.patch: ar71xx: allow to build ag71xx w/o PCI support enabled Feb 10 12:16:36 nbd * r30408 /trunk/target/linux/ar71xx/base-files/lib/ar71xx.sh: ar71xx: fix db120 board detection Feb 10 12:16:41 nbd * r30409 /trunk/target/linux/ar71xx/patches-3.2/710-ar934x_no_ddr_flush.patch: ar71xx: disable DDR flush for ethernet on AR934x, it is no longer necessary Feb 10 12:16:52 thanks! Feb 10 12:17:06 * dape bows Feb 10 12:24:02 juhosg * r30410 /trunk/target/linux/ar71xx/ (99 files in 3 dirs): ar71xx: add preliminary support for 3.3 Feb 10 13:16:40 meh, bricked it, now i gotta figure out how to solder serial without damaging those tiny pads Feb 10 13:17:30 build #94 of mpc52xx is complete: Failure [failed compile_10] Build details are at http://buildbot.openwrt.org:8010/builders/mpc52xx/builds/94 Feb 10 13:38:00 dingo * r30411 /packages/utils/ (3 files in 3 dirs): [patchteam] usb-modeswitch-data: update to 20120120 / usb-modeswitch: update to 1.2.3 - Signed-off-by: Cezary Jackiewicz Feb 10 13:42:12 dape: :V Feb 10 13:42:16 nice Feb 10 13:46:24 meh, gotta convince the ol' man to fine-solder me the serial with a stereo plug, it will be hard to do it Feb 10 13:46:52 juhosg * r30412 /trunk/package/kernel/modules/usb.mk: package/kernel: nuke CONFIG_USB_{O,E}HCI_AR71XX symbols Feb 10 13:46:53 juhosg * r30413 /trunk/package/mac80211/ (Makefile patches/201-ath5k-WAR-for-AR71xx-PCI-bug.patch): package/mac80211: apply AR71XX PCI workaround on ATH79 as well Feb 10 13:46:54 juhosg * r30414 /trunk/package/madwifi/ (3 files in 2 dirs): package/madwifi: apply AR71XX PCI workaround on ATH79 as well Feb 10 13:51:58 build #96 of adm5120 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/adm5120/builds/96 Feb 10 13:55:19 dingo * r30415 /packages/net/mosquitto/Makefile: [patchteam] upgrade mosquitto MQTT tools from 0.13 to 0.14.4 - Signed-off-by: Karl Palsson Feb 10 14:28:33 i wonder where is gcc 4.5.X or a 4.6.x without linaro patches ? Feb 10 14:29:15 also bumping into a really old issue again -> http://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg11849.html Feb 10 14:29:30 pthread_rwlock_tryrdlock.c:52: Error: bad register name `%sil' Feb 10 14:32:48 looks like the same as 12 months ago for my x86 targetted builds -> https://dev.openwrt.org/ticket/9483 Feb 10 14:46:57 build #135 of at91 is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/at91/builds/135 Feb 10 14:51:26 build #133 of ubicom32 is complete: Failure [failed compile_1] Build details are at http://buildbot.openwrt.org:8010/builders/ubicom32/builds/133 Feb 10 15:26:49 juhosg * r30416 /trunk/target/linux/ar71xx/patches-3.2/903-add-dummy-BQF-helpers.patch: ar71xx: add dummy DQL helper functions for 3.2 Feb 10 15:26:52 juhosg * r30417 /trunk/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c: Feb 10 15:26:52 ar71xx: ag71xx: add BQL support Feb 10 15:26:52 It will be usable only from linux-3.3. Feb 10 15:26:52 Based on a patch by Dave Taht Feb 10 15:42:30 anybody knows about x86 hardware running OpenWrt having an FXO port? Feb 10 15:43:27 mirko: hmm i do remeber from asteriks some pci cards for that Feb 10 15:43:42 uff Feb 10 15:44:01 http://www.aliexpress.com/fm-store/603951/210932255-434103093/AEX410-with-2FXO-2FXS-Asterisk-card-PCI-express-card-AXE410-for-IP-PBX-elastix-trixbox.html Feb 10 15:44:32 good question Feb 10 15:44:56 mirko: but if they run openwrt i doubt it.. we did run asteriks from gentoo linux Feb 10 15:45:04 using those cards Feb 10 15:45:21 hw with that onboard no clue guess none.. Feb 10 15:45:25 yeah, it's not very embedded anymore.. ;) Feb 10 15:45:27 thanks Feb 10 15:51:46 build #91 of octeon is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/octeon/builds/91 Feb 10 15:51:48 juhosg * r30418 /trunk/target/linux/generic/patches-3.3/507-yaffs2-3.3_fix.patch: generic: fix yaffs2 build warnings on 3.3 Feb 10 15:54:58 hmm any reason to not maintain glibc+baseutils+gcc till current stable versions ? Feb 10 15:55:19 for gcc this will be downgrading back to gcc 4.5 Feb 10 15:55:35 <- wanna continue with his x86 non embedded builds. Feb 10 15:57:56 juhosg * r30419 /trunk/target/linux/ar71xx/Makefile: ar71xx: fix platform description Feb 10 15:59:13 why downgrade gcc Feb 10 15:59:15 doesn't make sense to me Feb 10 16:09:14 nbd: since mosth distro's do it that way .. Feb 10 16:09:29 nbd: make something stable before push new issues in the soup Feb 10 16:09:54 for us the linaro-gcc is the most tested version Feb 10 16:09:58 so it makes sense to stick with that Feb 10 16:10:09 i do understand that the newer unsupported gcc releases have some pro's for embedded devices but also brake stuff for generic x86 glibc builds i belive. Feb 10 16:10:17 because testing is heavily dependent on the environment Feb 10 16:10:31 and in our environment linaro-gcc works fine Feb 10 16:10:47 nbd: yes for uclibc builds.. Feb 10 16:11:04 it doesn't matter if uclibc or glibc Feb 10 16:12:13 so if you say that you believe our compiler version breaks something for generic x86, i'd like to see some evidence before i'm willing to consider that as a valid point ;) Feb 10 16:12:31 8 months ago i bumped into these issues and it looks like i have to redo a lot work since i have no note about what package failed with the asm stuff Feb 10 16:12:36 http://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg11849.html Feb 10 16:13:09 i do remember it had something todo with enable nls/ntpl/threading.. but like i said this is 8 months ago for me.. Feb 10 16:14:00 so i'll start from ticked #9483 again and build up back to where i stalled Feb 10 16:14:01 https://dev.openwrt.org/ticket/9483 Feb 10 16:14:20 when i look for this error with google, i find it showing up with lots of different compiler versions in various scenarios Feb 10 16:14:33 nbd: true Feb 10 16:14:55 but it has been fixed also i do notice glibc is ancient Feb 10 16:15:40 so upgrade that to atleast 2.10/2.11 and try again where it fails.. also theire was something with grub to be fixed Feb 10 16:16:03 but i have been idle for months and looks like the x86 parts of openwrt have been untouched :( Feb 10 16:16:27 yeah, feel free to try upgrading glibc Feb 10 16:16:42 though i think using eglibc makes much more sense than using glibc Feb 10 16:16:44 all this is for including collectd current ;-) Feb 10 16:16:53 i have been trying that.. Feb 10 16:17:03 but that did not fix a thing for my threading issues :( Feb 10 16:17:06 glibc did Feb 10 16:19:24 nbd: accepting/supporting glibc like eglibc for debug/test builds used as virtualized guests will not be a weird idea to me.. Feb 10 16:20:08 nbd: personal i never understanded why glibc has been avoided and people keep adding workaround patches to uclibc for adding glibc features that are not included by default on uclib.. Feb 10 16:20:37 those patches brake with glibc when they are included always and not if uclibc ;-) Feb 10 16:20:47 one of the reasons why i stopped back then Feb 10 16:20:48 eglibc is preferred over glibc because it cross-compiles better and it's binary-compatible to glibc Feb 10 16:21:15 nbd: possible but collectd is not working with eglibc nor crosscompiling if your using the latest svn release.. Feb 10 16:21:43 uclibc is obviously the most maintained libc, because using (e)glibc on small-scale embedded stuff is stupid Feb 10 16:21:47 and the old ancient collectd is a nogo full with memleaks :( Feb 10 16:22:13 when was the last time you tried collectd with eglibc? Feb 10 16:22:19 yes you think small but i think universal there whe do think diffrent :S Feb 10 16:22:35 well, what can be used on small stuff can also be used on big stuff Feb 10 16:22:44 but what can be used on big stuff can be too big for small stuff ;) Feb 10 16:22:49 sad but yes without threading it can Feb 10 16:22:59 ? Feb 10 16:23:09 but i bumped into 1001 issues at a single plan back then. Feb 10 16:23:30 all that helped me into ignoring evrything else then glibc Feb 10 16:23:41 what's 'back then'? Feb 10 16:23:47 8/9 months back.. Feb 10 16:23:54 maybe you should try again Feb 10 16:23:55 that guy peter on the forum was still active here Feb 10 16:24:01 things change, bugs tend to get fixed Feb 10 16:24:19 i have tryed a rebuild last month using arch linux as toolchain will work but still have to do something with grub Feb 10 16:24:42 today done a fresh build from svn using the wrt building his own toolchain and bumped in the %sil errors. Feb 10 16:25:11 try eglibc 2.13 Feb 10 16:25:14 grub is a 8 month old issue and the %sil was part of the patches in ticket #9483 Feb 10 16:25:20 or try updating to a new glibc Feb 10 16:25:30 i think playing with old versions of glibc is pointless Feb 10 16:25:36 nbd: also the buildbots can they share resources ? Feb 10 16:25:47 no idea what that means Feb 10 16:25:52 nbd: yes old glibc is breaking a lot Feb 10 16:26:23 nbd: svn/git/buidbot-master at home but these builds take a while on my amd x2 Feb 10 16:26:35 like one run per day max. Feb 10 16:26:47 if can compile without errors maby 3 runs per day Feb 10 16:27:52 i can speedup by using the stock toolchain from my distro over the option wrt build his own toolchain. but then i do also loose all support and will be forced to redo it anyway for reproducing errors :( Feb 10 16:29:32 short story all options are long roads .. Feb 10 16:30:02 and will stuff be included upstream if it get fixed or will this be an issue that keep comming back every 12 months when i wanna upgrade.. :( Feb 10 16:31:40 nbd: anyway glibc has not been updated while theire where patches delivered.. Feb 10 16:32:14 as i remember for glibc till 2.15 Feb 10 16:33:13 also about gcc 4.5 without linaro.. without linaro i'm able to build gcc as part of my gcc target image.. via that way it was easyer building collectd without cross compiling it.. Feb 10 16:33:35 this also reminds me at the point why i do it this way.. i wanted i686 code.. no cross-compilation needed. Feb 10 16:33:52 part of these issues are not needed .. Feb 10 16:35:51 openwrt always does cross-compile to ensure reproducible builds free from dependencies on host binaries Feb 10 16:35:56 i think this makes sense even for x86 Feb 10 16:36:19 true but costh time :( Feb 10 16:36:28 i care more about reproducible builds than about time Feb 10 16:36:29 ;) Feb 10 16:36:46 also, it costs more in the short term Feb 10 16:36:50 hmm can you understand that i want more then use 10% of my router features :) Feb 10 16:36:51 but it might save some debugging work in the long term Feb 10 16:37:01 because sudden distro upgrades or changes might break stuff in subtle ways Feb 10 16:37:12 and then without segfaults that i simply can not debug easyly :) Feb 10 16:37:50 yeah, but you do realize that you have to put in the extra effort, since you want to do something that's different from the normal openwrt use case Feb 10 16:37:52 hmm my point about the combination baseutils+glibc+gcc is based on looking at debian/gentoo/fedora/arch linux and theire toolchain versions.. Feb 10 16:38:21 nbd: yes i do understand that i try to open a completly other way of using openwrt yes Feb 10 16:38:23 yeah, and my point is about understanding what's going on instead of just repeating what other people do Feb 10 16:38:51 i was close to a working build with everything included.. Feb 10 16:38:57 but never fully debugged Feb 10 16:39:04 so, if there are patches out there to support glibc 2.15, how about you try those and report back to me afterwards? Feb 10 16:39:08 if they Feb 10 16:39:11 make things work Feb 10 16:39:18 atleast it did solve my segfault horrors Feb 10 16:39:20 i'll make sure they get included Feb 10 16:39:29 part was in collectd itself and part in the base stuff. Feb 10 16:39:30 you just have to point me to the exact patch that you're using Feb 10 16:39:30 ok Feb 10 16:40:26 i still have those patches on my backups so must not be to hard to get them Feb 10 16:40:45 nbd: i stick some time in glibc and report results in a ticket.. Feb 10 16:41:24 ok, then send me a link in the channel afterwards Feb 10 16:41:29 so i notice it Feb 10 16:41:50 ok also will be tonight or tomorrow.. unsure but i think about continueing tonight anyway.. Feb 10 16:42:15 without this router i have to delay other work so it has to be done :) Feb 10 16:43:43 nbd * r30420 /trunk/package/zlib/Makefile: zlib: parallel build has been reported to break this package, disable it (#10948) Feb 10 17:26:09 loswillios: I noticed that linux-igd2 never made it into OpenWRT... any reason to hold it back? looks interesting. Feb 10 17:37:19 hauke * r30421 /trunk/package/broadcom-wl/patches/009-fix_compile_3_2.patch: broadcom-wl: fix compile with kernel 3.2 Feb 10 17:41:23 hauke * r30422 /trunk/package/broadcom-wl/patches/912-pci-bus-nvram-hack.patch: (log message trimmed) Feb 10 17:41:23 broadcom-wl: fix reading fallback sprom for pci devices. Feb 10 17:41:23 When using the Broadcom SDK the SSB bus is emulated as an PCI bus so Feb 10 17:41:23 the PCI bus number of the first real pci bus is increased by one. The Feb 10 17:41:23 variable names in the nvram are created with that structure in mind. To Feb 10 17:41:24 fix this we have ti increases the pci bus number by one. This was also Feb 10 17:41:25 done for ssb some time ago. Feb 10 17:52:31 hauke * r30423 /trunk/target/linux/brcm47xx/patches-3.2/220-bcm5354.patch: brcm47xx: update bcm5354 support patch Feb 10 18:03:47 philipp64|laptop: didn't know about it. Since miniupnpd was added I haven't looked at linux-igd either Feb 10 18:04:36 really? the gitorious feed has your name on the packaging... it must have been cut&pasted. Feb 10 18:06:28 I think I added it Feb 10 18:07:14 so no reason it shouldn't be in feeds/packages/net/ then? Feb 10 18:07:34 linux-igd2? Feb 10 18:07:40 yeah. Feb 10 18:08:50 juhosg * r30424 /trunk/target/linux/ramips/files/arch/mips/ralink/common/prom.c: ramips: fix compiler warning in prom.c Feb 10 18:09:00 ah now I see. yeah, copy/paste Feb 10 18:09:47 should be good Feb 10 18:11:58 I can try building it later. Feb 10 19:51:26 swalker * r30425 /packages/ipv6/dibbler/ (6 files in 3 dirs): Feb 10 19:51:26 [packages] dibbler: update to 0.8.1 Feb 10 19:51:26 * switch to uclibcxx Feb 10 19:51:26 * add requestor package, init scripts & conffiles Feb 10 19:51:26 * drop obsolete patches Feb 10 20:17:26 swalker * r30426 /packages/utils/lmbench/Makefile: [packages] lmbench: fix md5sum Feb 10 20:26:09 do we support packages that don't come from tarballs but from from GIT trees instead? Feb 10 20:33:52 plenty of packages are cloned from git, support is another matter... Feb 10 20:36:40 also, if you have two mutually exclusive packages, how is that indicated in the DEPENDS field? Feb 10 20:48:27 philipp64|laptop: yes, there are several packages using git as the source, and no, conflicts aren't properly handled currently (and there's no real way of expressing them) Feb 10 20:49:12 juhosg * r30427 /trunk/target/linux/ar71xx/ (2 files in 2 dirs): Feb 10 20:49:12 ar71xx: zero partition parser data in m25p80 Feb 10 20:49:12 Ths fixes parsing of RedBoot partitions. Feb 10 20:50:44 You'd think that you could have: a/Makefile: DEPENDS:= ... +!b Feb 10 20:51:01 and vice versa: b/Makefile: DEPENDS:= ... +!a Feb 10 20:51:10 where's JoW to work his magic? Feb 10 21:01:03 philipp64|laptop: you can, but these don't get properly evaluated (or they don't work recursively or something broken like that), at least the last time I tried that Feb 10 21:11:28 so they serve mostly as a comment? Feb 10 23:12:48 hauke * r30428 /trunk/target/linux/brcm47xx/patches-3.2/ (2 files): brcm47xx: print the chip id and rev found by ssb and bcma Feb 10 23:38:40 swalker * r30429 /packages/net/tor-alpha/ (Makefile patches/002-add-tor-socket-t-header.patch): [packages] tor-alpha: update to 0.2.3.11-alpha Feb 10 23:39:38 swalker * r30430 /packages/net/obfsproxy/ (. Makefile patches/ patches/001-no-werror.patch): [packages] obfsproxy: add obfsproxy (#10947) Feb 11 01:13:24 hello Feb 11 01:16:43 found a bug in the fstab init script Feb 11 01:17:38 https://dev.openwrt.org/ticket/10953 Feb 11 01:18:08 i could create a patch but since it's just one line change there is probably no point Feb 11 01:53:06 jow_laptop: is #10337 fixed? Feb 11 02:40:08 build #136 of s3c24xx is complete: Failure [failed compile_10] Build details are at http://buildbot.openwrt.org:8010/builders/s3c24xx/builds/136 **** ENDING LOGGING AT Sat Feb 11 02:59:57 2012