**** BEGIN LOGGING AT Mon Apr 08 02:59:58 2013 Apr 08 03:03:28 build #215 of ppc44x is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/215 Apr 08 07:12:22 juhosg r36268 trunk/target/linux/ramips/dts/TEW-692GR.dts * ramips: TEW-692GR.dts fixes Apr 08 08:25:35 juhosg r36269 trunk/target/linux/ramips/patches-3.8/0125-MIPS-ralink-process-PCI-pinmux-group.patch * ramips: avoid invalid pointer dereference in pinmux code Apr 08 08:25:36 juhosg r36270 trunk/target/linux/ramips/dts/OMNI-EMB-HPM.dts * ramips: fix console speed for OMNI-EMB-HPM Apr 08 08:44:48 [ 96.388000] kmemleak: 3 new suspected memory leaks (see /sys/kernel/debug/kmemleak) Apr 08 08:44:51 [ 96.536000] br-pub: port 1(wlan0) entered forwarding state Apr 08 08:44:53 [ 794.756000] kmemleak: 139 new suspected memory leaks (see /sys/kernel/debug/kmemleak) Apr 08 09:00:15 build #205 of sibyte is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/205 Apr 08 09:02:43 something to do with insmod? Apr 08 09:03:07 the other notable thing is that the loadavg climbs quite high Apr 08 09:16:11 hmm, i'm not sure how to read /sys/kernel/debug/kmemleak, but they seem to be predominantlyl related to insmod's Apr 08 09:16:32 like, maybe something is firing them off at a high rate Apr 08 09:34:51 hmm, it does seem to quiet down after boot Apr 08 09:35:20 * russell-- disabled a bunch of larger daemons, which makes things slightly happier Apr 08 09:39:01 # cat /sys/kernel/debug/kmemleak | grep size | tr '()' ' ' | awk '{ Apr 08 09:39:01 a += $5 ; n++ } END { print n,a }' Apr 08 09:39:01 143 145984 Apr 08 09:39:29 total size of unreferenced objects is not huge Apr 08 10:01:22 build #210 of xburst is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/xburst/builds/210 Apr 08 10:18:43 build #242 of orion is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/242 Apr 08 11:12:46 juhosg r36271 trunk/target/linux/ramips/patches-3.8/0132-NET-ramips-fix-mdio-bus-support.patch * ramips: fix MDIO/PHY handling Apr 08 11:12:47 juhosg r36272 trunk/target/linux/ramips/dts/rt3883.dtsi * ramips: add mdio-bus node to rt3883.dtsi Apr 08 11:12:48 juhosg r36273 trunk/target/linux/ramips/dts/OMNI-EMB-HPM.dts * ramips: OMNI-EMB-HPM.dts fixes Apr 08 11:12:49 juhosg r36274 trunk/target/linux/ramips/rt3883/profiles/omnima.mk * ramips: add profile for the Omnima EMB-HPM board Apr 08 11:13:58 KanjiMonster: that atheros buttons problem I was talking about, it works out of the box in trunk and backfire, just not not in AA. Apr 08 11:18:34 karlp: ah I see. in that case a patch fixing it in AA is okay ;) Apr 08 11:20:32 kinda unexpected though, possibly related to the gpiodev getting pulled from BB, or some conflict there Apr 08 11:20:53 didn't need to add the button-hotplug-gpio modules directly in menuconfig either. **** BEGIN LOGGING AT Mon Apr 08 11:28:15 2013 **** BEGIN LOGGING AT Mon Apr 08 11:59:37 2013 Apr 08 12:35:00 juhosg r36275 trunk/target/linux/ramips/rt3883/config-3.8 * ramips: rt3883: enable the AR8216 driver Apr 08 12:35:02 juhosg r36276 trunk/target/linux/ramips/dts/TEW-691GR.dts * ramips: TEW-691GR.dts fixes Apr 08 12:57:52 build #184 of iop32x is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/iop32x/builds/184 Apr 08 13:32:44 KanjiMonster: Kevin Cernekee who added support for bmips multicores, is a guy from Broadcom Corp. ? Apr 08 13:33:18 danitool: yes Apr 08 13:36:28 danitool: https://github.com/KanjiMonster/bcm63xx/commit/d992b18c8a93f770104512e7e88f5bc396f48428.patch https://github.com/KanjiMonster/bcm63xx/commit/506aa50d8fc3391a5d9b163f75835eeb741c8846.patch https://github.com/KanjiMonster/bcm63xx/commit/898498f136ecee0bb2af2c18d5aad5050591cf4e.patch will make the second core come up and be available for userspace Apr 08 13:39:38 KanjiMonster: thanks, btw how to use it from userspace, does it mean we can run an application (i.e wget) manually in the second core? Apr 08 13:40:35 danitool: you don't need to, the kernel will schedule it automatically Apr 08 13:43:04 danitool: only userspace means that all irqs will be handled by cpu0, so e.g. network performance won't be as fast as it could be Apr 08 13:43:23 ah, ok Apr 08 13:44:12 also there are changes that there will be concurrency problems in the bcm63xx code that only show in real SMP Apr 08 13:48:35 https://github.com/KanjiMonster/bcm63xx/blob/master/arch/mips/Kconfig#L1494, doesn't select CONFIG_SMP, do we need to select it manually? Apr 08 13:48:56 I guess, yes we do Apr 08 13:52:03 hmm, what could be the reason that strace doesn't work in failsafe mode? I am trying to trace /sbin/init, but it just hangs forever without any output. Apr 08 13:56:23 proc or so not mounted ? Apr 08 13:56:59 blogic: /proc is mounted Apr 08 13:58:48 blogic: any other idea? Apr 08 13:59:12 wbx: if strace uses stderr then that would be the reason; iirc stderr is disabled/doesn't work in failsafe Apr 08 14:00:59 <_rmk_> no, pid 1 is special, it never receives signals that it doesn't have a handler installed for, and that includes the stop/trap signals Apr 08 14:04:11 _rmk_: he is in failsafe afaic ... Apr 08 14:04:31 wbx: is this the new procdinit ? Apr 08 14:04:54 blogic: no the old style Apr 08 14:08:57 ok Apr 08 14:09:13 init will do an exec very early i think Apr 08 14:09:38 wbx: try adding 2>&1 at the end of your strace call Apr 08 14:10:14 just tested, on failsafe stderr is redirected to /dev/null or something like that, and strace uses stderr for its output Apr 08 14:11:02 <_rmk_> blogic: so? init doesn't like running except as pid1, and it's the kernel which enforces "no signals unless pid1 has a handler" Apr 08 14:11:05 (but I did not test strace on failsafe, so there might be further issues; just that stderr is not working in failsafe, and that strace in normal uses stderr) Apr 08 14:11:30 strace ls 2>&1 Apr 08 14:11:35 hangs still. Apr 08 14:11:56 <_rmk_> kanjimonster: check stderr with this: echo "foo" >&2 Apr 08 14:12:02 <_rmk_> if you get output, your stderr is fine Apr 08 14:12:25 _rmk_: no output in failsafe Apr 08 14:12:54 <_rmk_> what does ls -al /proc/self/fd report for '2' ? Apr 08 14:12:56 _rmk_: my test was "cd blubb" => no output; "cd blubb 2>&1" => ash: cd: can't cd to blubb Apr 08 14:14:03 <_rmk_> redirecting stderr to /dev/null is pretty silly for an interactive shell, more so in a "failsafe" environment Apr 08 14:23:05 wbx: for the stderr problem: menuconfig -> Image configuration -> Preinit configuration options -> Suppress stderr messages during preinit Apr 08 14:23:34 (after that you need to issue make package/base-files/clean, else it won't have any effect) Apr 08 14:23:34 _rmk_: 2 -> /dev/console Apr 08 14:25:01 KanjiMonster: i am trying... Apr 08 14:25:18 <_rmk_> okay, so stderr should appear on the system console Apr 08 14:25:51 <_rmk_> and if "1 -> /dev/console" then it'll be the same place as stdout Apr 08 14:29:13 _rmk_: 90_init_console initialized with "exec <$M0 >$M1 2>&0", which isn't reflected in /proc/self Apr 08 14:29:43 <_rmk_> ROTFL Apr 08 14:30:18 (unless you have pi_suppress_stderr disabled, then its exec <$M0 >$M1 2>$M2) Apr 08 14:30:28 <_rmk_> <$M0 - so that takes stdin from whatever $M0 is, opening it in O_RDONLY mode Apr 08 14:30:52 <_rmk_> 2>&0 ... so you want to direct output to a fd that was originally opened in read only mode? really? Apr 08 14:33:06 KanjiMonster: the data cache is shared by both bcm63xx cores, or are they splitted like the instruction cache?, or is this feature unknown? Apr 08 14:33:29 but it isn't the reason strace doesn't work. -o log or KanjiMonster tip doesn't work either. Apr 08 14:33:43 <_rmk_> this is what happens in bash with that kind of stuff: Apr 08 14:33:43 <_rmk_> open("/dev/stdin", O_RDONLY|O_LARGEFILE) = 3 Apr 08 14:33:49 <_rmk_> ... Apr 08 14:33:49 <_rmk_> dup2(3, 0) = 0 Apr 08 14:33:56 <_rmk_> dup2(0, 1) = 1 Apr 08 14:34:01 <_rmk_> write(1, "foo\n", 4) = -1 EBADF (Bad file descriptor) Apr 08 14:34:23 * KanjiMonster slaps _rmk_ with a large trout Apr 08 14:34:25 <_rmk_> you _can't_ write to a descriptor opened in read only mode, even one which has been dup'd Apr 08 14:34:48 <_rmk_> running any command with &0 will make stderr unwritable Apr 08 14:35:01 (for pasting several lines) Apr 08 14:35:02 <_rmk_> 2>&0 is just plain fscked in the head Apr 08 14:35:31 <_rmk_> KanjiMonster: what? that was individually selected? want the full thing? it's about 20 lines in total. Apr 08 14:35:40 build #200 of ar71xx is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx/builds/200 Apr 08 14:35:45 <_rmk_> KanjiMonster: I only pasted what was required to get you to understand Apr 08 14:36:01 <_rmk_> the absolute minimum Apr 08 14:36:15 _rmk_: yaya. But we have to maintain a facade! Apr 08 14:36:25 ;) Apr 08 14:36:47 _rmk_: but it seems to do what is intended (prevent stderr to spill into the bootlog) Apr 08 14:38:34 <_rmk_> that depends... 2>&0 is offensive technically. 2>/dev/null would've been much better. Apr 08 14:38:55 <_rmk_> and much more obvious that you don't want stderr output Apr 08 14:39:36 <_rmk_> not to mention the standard unix way to get rid of stderr output Apr 08 14:44:06 <_rmk_> you know, it's exactly this kind of programming mentality which leads to the kind of crap that gets produced from companies like draytek where things just don't work correctly. Apr 08 14:58:35 _rmk_: while I see your point, I also see that there are bigger issues than ugly code (also it looks like the code is basically obsolete anyway; the procd as init code does not seem to have it anymore) Apr 08 15:00:13 KanjiMonster: I was wrong about the gpio buttons on ahteros being AA only, I had the wrong image loaded, it's broken in AA and trunk, I've sent in the patch for trunk Apr 08 15:01:07 karlp: cool. Apr 08 15:01:52 wbx: a "strace ls" worked for me on bcm63xx with preinit suppress stderr disabled (haven't checked with it enabled) Apr 08 15:02:13 <_rmk_> I wouldn't describe it as "ugly code" at all. It's just plain technically broken. Apr 08 15:02:49 KanjiMonster: oh. then it is qemu specific. trying to find out why the new mips64 port doesn't boot Apr 08 15:05:00 KanjiMonster: may be strace 4.7 is broken on mips64 I remember sth like this. trying strace 4.5.2 Apr 08 15:06:13 _rmk_: to me it does exactly what was intended (i.e. "disable" stderr) and doesn't seem to cause any visible failures, so the incentive to fix it is quite low (especially if the code is going away eventually anyway) Apr 08 15:15:25 KanjiMonster: http://wiki.openwrt.org/doc/howto/hardware.button#preliminary.steps says you need to remove the ̂ from in front of button, but that doesn't seem to be true. Do you know the reasoning behind that piece in the wiki? Apr 08 15:16:44 <_rmk_> kanjimonster: turning the power off also disables stderr too :) Apr 08 15:17:41 karlp: no idea Apr 08 15:19:10 _rmk_: with all the time and effort you used to complain about the code you could have already created a patch and sent it in for us to ignore :P Apr 08 15:59:40 <_rmk_> KanjiMonster: probably not, because that implies that I know (a) where it is in which repository, (b) that I'm able to test it, and (c) I'd know who to email it to. Apr 08 15:59:46 <_rmk_> none of that applies. Apr 08 16:03:44 I was assuming this knowledge since this is #openwrt-*devel*, but if you don't have it, then you are forgiven :) Apr 08 16:09:05 back to poking at kirkwood ... Apr 08 17:12:11 blogic: a little question. Does the Danube use the spi bus to control the slics? Apr 08 17:14:49 my old nick was Pteridium, but changed it to evade ps2chiper (Jason Duhamell) Apr 08 17:23:03 the ALM slics dont need spi Apr 08 17:23:13 what does ps2cipher want from you ? Apr 08 17:25:18 if i know somebody to develop a a driver for the RTL8188RE Apr 08 17:26:30 Christian Lamparter told me that is better evade Jason Apr 08 17:27:38 he asked for the driver developer because this post: https://forum.openwrt.org/viewtopic.php?pid=197574 Apr 08 17:28:24 a lot of thanks for the info Apr 08 19:10:37 build #167 of octeon is complete: Failure [failed shell_12] Build details are at http://buildbot.openwrt.org:8010/builders/octeon/builds/167 Apr 08 21:43:48 KanjiMonster: for the smp patches you told to danitool, additional flags to GCC must be passed or a certain gcc version is needed? Apr 08 21:44:00 Ginkgo: no Apr 08 21:44:38 ok, thanks. Time to play... :) Apr 08 21:44:55 and time to learn, of course **** ENDING LOGGING AT Tue Apr 09 02:59:58 2013