**** BEGIN LOGGING AT Sat Aug 13 02:59:57 2011 Aug 13 08:35:24 philipp64|laptop: it's also un-de-selectable, so it's clearly selected because of a dependency on it - deselecting kmod-gpio-buttons unselects it, as well as reselecting it selects kmod-input-core again, so it's working as intended for me Aug 13 08:43:00 KanjiMonster: it's not selected for me. don't know why. Aug 13 08:43:40 philipp64|laptop: try deleting tmp so the .config-packages.in get's fully regenerated Aug 13 08:44:11 did that. Aug 13 08:53:10 philipp64|laptop: can you paste the kmod-input-core and any kmod that depends on -core sections from tmp/.config-packages.in ? Aug 13 09:16:52 here's the file: ftp://ftp.redfish-solutions.com/pub/.config-package.in Aug 13 09:17:00 wasn't sure which parts you wanted out of it. Aug 13 09:20:19 philipp64|laptop: hm, are you sure you have the patch applied? Aug 13 09:20:52 hmm can gcc 4.4.6 not be generic instaid of depending on (avr32 || ubicom32) Aug 13 09:21:36 also hope that it will not be removed on the next 5 months before the newer gcc problems are pinned down. Aug 13 09:22:33 philipp64|laptop: it should look like this -> http://pastebin.com/icniqkt9 Aug 13 09:35:58 philipp64|laptop: do you have by chance any local patches applied that might affect this? Aug 13 09:38:43 hmm chocky's last glibc patch was not his own but eglibc patch from mirko and not really tested on glibc (since there is/was no line 479 in that makefile thats about 50% shorter). Aug 13 09:45:17 hmm fixed/moved the parameter to the toolchain makefile. (glibc) instaid of hacky patch the makefile from tarball.. Aug 13 09:45:38 https://dev.openwrt.org/attachment/ticket/9483/glibc.patch Aug 13 09:45:38 https://dev.openwrt.org/browser/trunk/toolchain/eglibc/patches/2.13/200-add-dl-search-paths.patch?rev=27216 Aug 13 09:46:02 patch can be replaced by define it in the configure part of toolchain/glibc/Makefile Aug 13 09:46:08 or eglibc* Aug 13 09:46:36 <- bbl coffee and wakeup.. Aug 13 11:21:25 build #46 of mpc52xx is complete: Failure [failed compile_10] Build details are at http://buildbot.openwrt.org:8010/builders/mpc52xx/builds/46 Aug 13 13:27:20 build #71 of at91 is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/at91/builds/71 Aug 13 13:42:12 build #69 of ubicom32 is complete: Failure [failed compile_3] Build details are at http://buildbot.openwrt.org:8010/builders/ubicom32/builds/69 Aug 13 14:09:05 nbd * r27970 /trunk/package/crda/Makefile: crda: update regulatory database to 2011-04-28, adds fixes for NL (#9931) Aug 13 14:11:08 nbd * r27971 /branches/backfire/package/crda/Makefile: crda: update regulatory database to 2011-04-28, adds fixes for NL (#9931), backport of r27970 Aug 13 14:19:13 nbd: I'm getting WARNING when trying out latest ar71xx image :S Aug 13 14:21:20 http://paste.pocoo.org/show/457744/ Aug 13 14:24:10 yeah, that one's not a problem Aug 13 14:31:25 why? Aug 13 14:32:14 it's just a warning in a piece of code that is only relevant for setting up ASPM power saving, and that doesn't even apply to that kind of embedded hw Aug 13 14:32:27 heh, ok Aug 13 16:27:22 nbd * r27972 /trunk/package/mac80211/patches/ (7 files): ath9k: merge a few more pending fixes, including a fix for the bogus WARN_ON in pci.c and fixes for Rx DMA stop issues Aug 13 16:28:26 plaes: now the warning is gone Aug 13 16:29:02 \o/ Aug 13 19:05:05 I'm trying to package figlet for openwrt, but it doesn't seem to like the PKG_NAME variable. Can anyone see what the problem is? http://pastebin.com/7WaFhMa7 Aug 13 19:07:04 Nvm. Left out an "=" sign. Aug 13 19:44:51 KanjiMonster: local patches yes, but I don't think any of them would affect it. Aug 13 19:51:07 figlet? I'm not sure if I should applaud or slap Aug 13 21:26:43 hmmm... which versions of the wifi ledtrigger stuff support 'tpt' ? Aug 13 21:29:18 mac80211 has a built-in trigger that does tpt Aug 13 21:33:44 running 2.6.39.3: [none] timer default-on netdev phy0rx phy0tx phy0assoc phy0radio gpio heartbeat Aug 13 21:34:05 that's from building last night's trunk... Aug 13 21:34:27 (cat of /sys/class/leds/geos:2/trigger ) Aug 13 21:34:43 what kind of wifi driver? Aug 13 21:35:41 ath9k on a tplink 300N I think... Aug 13 21:36:03 odd, i have a current trunk on my device with ath9k and the tpt trigger shows up there Aug 13 21:36:14 lspci says: Wistron NeWeb Corp. CM9 Wireless a/b/g MiniPCI Adapter Aug 13 21:36:20 ah, that's ath5k Aug 13 21:36:33 maybe ath5k needs to enable this trigger then Aug 13 21:36:49 it's part of the core, but i think the driver needs to supply a throughput-to-blinkrate table Aug 13 21:37:17 let me try it here... Ubiquiti Networks, Inc. SR71-A 802.11abgn Wireless Mini PCI Adapter Aug 13 21:43:36 nbd: if you have a patch to enable it, I can test it. Aug 13 21:43:50 i don't, and i'm currently busy with other stuff Aug 13 21:43:58 it should be easy to locate, do you want to give it a shot? Aug 13 21:51:52 nbd * r27973 /trunk/target/linux/ar71xx/files/drivers/net/ag71xx/ag71xx_main.c: ar71xx: on ar724x only reset the link status in the restart handler, the fast reset takes care of DMA stuck issues Aug 13 21:52:36 I can try... Aug 13 21:52:37 nbd * r27974 /branches/backfire/target/linux/ar71xx/files/drivers/net/ag71xx/ag71xx_main.c: ar71xx: on ar724x only reset the link status in the restart handler, the fast reset takes care of DMA stuck issues, backport of r27973 Aug 13 21:53:27 do any of our platforms use Coreboot other than the Geos and Alix boards? Aug 13 22:05:49 say, what's needed to support a soft reset switch other than the gpio-keys support, etc? who actually reads the key and does something with it? Aug 13 22:09:19 I suppose there's either a kernelspace listener or a daemon (hotplug2) waiting for dispatched events to trigger userspace actions Aug 13 22:18:59 do I need to do anything particular per-platform? Aug 13 22:19:23 I don't think so Aug 13 22:19:28 linux-3.1 contains support for the alix.c platform driver, to which I've just submitted the following patch: Aug 13 22:19:45 http://fpaste.org/t1BS/ Aug 13 22:19:51 I mean apart from making the gpio stuff avauilable in the first place Aug 13 22:19:55 the rest should be generic Aug 13 22:20:08 unavailable how? Aug 13 22:20:49 I basically mean what you did in your patch Aug 13 22:21:05 ah, ok. so it looks complete? Aug 13 22:24:04 it looks reasonable at least Aug 13 22:24:14 ok. thanks. Aug 13 22:29:56 I cannot figure out that kmod-input-core dependency thing. I don't see the same behavior as Jonas when I apply Hauke's patch. Aug 13 22:32:09 two patches inbound. Aug 13 22:32:21 nbd * r27975 /trunk/target/linux/ar71xx/files/ (4 files in 3 dirs): ar71xx: add some code to detect DMA stuck conditions on ar7240 Aug 13 22:46:54 say where did gpio-buttons come from, and how is it different from gpio-keys? Aug 13 22:51:03 nbd: looking ieee80211_led_names() but only seeing 4 names, not five. Aug 13 22:58:05 jow * r27976 /trunk/package/mac80211/files/lib/wifi/mac80211.sh: [package] mac80211: use first available channel from current phy if channel is set to "auto" Aug 13 23:01:25 ath5k doesn't seem to call ieee80211_create_tpt_led_trigger Aug 13 23:02:16 yep, as i expected Aug 13 23:08:07 nbd: so you are closing it just because I haven't supplied a fix yet? Aug 13 23:08:18 it's nice that you jump on that one, and not my glibc stuff. sigh Aug 13 23:13:09 Chocky: no updated info in the ticket, no usable proposal for fixing it properly, no time on my side to come up with one Aug 13 23:13:36 i think changing the makefile by hand to a specific profile is an acceptable workaround Aug 13 23:14:51 I don't. Was there something wrong with my suggesting of allowing the sub target in the profile? I just find it very odd that of all the tickets I've commented on/created, on this particular one gets any attention. I wish I had solutions to all the openwrt problems I find, but alas, I do not Aug 13 23:15:15 we already have targets > subtargets > profiles Aug 13 23:15:43 so, is the idea of creating a custom set of packages in a profile with a different name name to a subarch wrong? Aug 13 23:16:14 it doesn't really belong in a profile Aug 13 23:16:36 profiles are meant to be device specific preselections, hence in this case the profile is also tied to reducing the number of images Aug 13 23:16:45 perhaps not, from a design view point. but nevertheless, as it is, profiles contain exactly a list of packages for a subtarget. Aug 13 23:17:10 don't confuse subtarget with device / image set Aug 13 23:17:23 ar71xx has only two subtargets Aug 13 23:17:27 generic and nand Aug 13 23:17:50 I meant to say subarch. I don't know if that's the terminology you generally use in Wrt Aug 13 23:18:19 right now we don't have a level of indirection for what you're hinting at Aug 13 23:18:56 and i'd like to avoid adding one for this special case Aug 13 23:19:36 sure, the image builder could use some improvement Aug 13 23:19:45 but i'd like to fix the issue properly instead of adding more hacks Aug 13 23:20:04 sure Aug 13 23:20:04 one way to fix this would be to make more use of config files for package selection in the image builder Aug 13 23:20:14 that would require quite a bit of rework though Aug 13 23:20:23 how are the blink times calculated? Aug 13 23:20:26 but it would allow people to use scripts/env to manage different device configurations Aug 13 23:20:32 philipp64|laptop: there's a throughput table Aug 13 23:20:43 philipp64|laptop: with a default in mac80211 Aug 13 23:21:02 I'm looking at it... and trying to figure out what's the relationship of throughput to blink time. Aug 13 23:21:26 so I can set the appropriate blink times for the ath5k Aug 13 23:22:09 jow * r27977 /branches/backfire/package/base-files/ (Makefile files/sbin/ifdown files/sbin/ifup): [backfire] backport r27720 Aug 13 23:22:41 nbd: to be honest, it's the least of my worries, and my present work around doesn't involve any make file hacks. My frustration is more from lack of movement on other issues. today I have a serious issue with flash access deadlocking Aug 13 23:22:51 jow * r27978 /branches/backfire/package/mac80211/files/lib/wifi/mac80211.sh: [backfire] merge r27976 Aug 13 23:22:59 on what device? Aug 13 23:23:13 and triggered by what? Aug 13 23:23:24 made a post, just a sec Aug 13 23:23:34 ah, found it Aug 13 23:24:19 you can find out where tasks are stuck by using /proc/sysrq-trigger Aug 13 23:24:38 ok Aug 13 23:24:40 hm Aug 13 23:25:06 assuming I have that in this kernel, which I don't Aug 13 23:25:07 echo t > /proc/sysrq-trigger Aug 13 23:25:15 it's enabled by default on ar71xx Aug 13 23:25:17 iirc Aug 13 23:25:32 oh, wait Aug 13 23:25:39 it's enabled by a toplevel .config option Aug 13 23:25:48 enable CONFIG_KERNEL_MAGIC_SYSRQ Aug 13 23:25:57 it's under 'Global build settings' Aug 13 23:26:02 then rebuild Aug 13 23:26:10 * Chocky tries Aug 13 23:26:56 but have you seen anything like this? Aug 13 23:26:59 no Aug 13 23:27:33 * Chocky blames glibc as a scapegoat Aug 13 23:28:26 well, if the kernel is blocking on stuff, then it can't be glibc's fault Aug 13 23:28:55 would a process stuck in a system call be killable with ctrl-c? Aug 13 23:29:19 depends Aug 13 23:29:31 it looks very much like a kernel problem to me too, but you never know Aug 13 23:29:54 do you have a serial console connected? Aug 13 23:30:10 yes. no complaints from the kernel about anything Aug 13 23:30:26 you'll need it to properly capture the sysrq output Aug 13 23:30:33 because often it's too much for the normal logging buffer Aug 13 23:32:06 this is major deja-vu for me. I've seen different kinds of flash problems on many many systems. Aug 13 23:35:40 let's gather some more data before we jump to conclusions Aug 13 23:36:09 I promise you I haven't jumped anywhere :p I deal with people jumping to conclusions all the time. i know what it's like. Aug 13 23:36:31 ok Aug 13 23:37:46 will take me 20 mins to reproduce Aug 13 23:44:27 anyone feeling like doing some commits? Aug 13 23:44:55 what would I need to do to make a wget version that linked with static libssl? Aug 13 23:45:02 * Chocky pokes as its configure Aug 13 23:45:24 could delete libssl.so :p Aug 13 23:51:59 crap. it's all numbers. I guess I need a kernel that isn't stripped Aug 13 23:54:24 nbd: well, I'll cobble up some numbers and you can tweak them as you see fit. Aug 14 00:22:25 nbd: the end function is unmask_mips_irq Aug 14 00:22:31 making a function trace now Aug 14 00:27:57 jow_laptop: by the way, how do I test that the gpio button actually works? can I read its state in sysfs? Aug 14 00:34:15 nbd: see mailing list post just now Aug 14 00:35:35 jow * r27979 /trunk/package/firewall/ (Makefile files/firewall.config files/reflection.hotplug): [package] firewall: further tune ICMPv6 default rules according to RFC4890 (#9893) Aug 14 00:36:10 jow * r27980 /branches/backfire/package/firewall/ (Makefile files/firewall.config files/reflection.hotplug): [backfire] merge r27979 Aug 14 00:39:35 Chocky: that does not look like a normal deadlock Aug 14 00:39:45 Chocky: did you check for things like running out of ram or out of flash space? Aug 14 00:40:25 also, you don't need to copy functions from System.map if you enable CONFIG_KERNEL_KALLSYMS Aug 14 00:45:27 indeed Aug 14 00:45:29 thanks Aug 14 00:45:46 but it was quicker (slightly :-() than doing a complete rebuild Aug 14 00:46:14 lots of RAM, lots of flash free Aug 14 00:46:34 flash is only 5% full. RAM is mostly buffers Aug 14 00:47:53 what now? Aug 14 00:51:46 try doing another one to see if stops at the same place Aug 14 01:32:08 philipp64|laptop: if you want to test that you've got the right gpio, use sysfs to export an in gpio , and check what happens when you press the button. If that's right, then try using hotplug-buttons and and a script under /etc/hotplug.d/buttons that uses logger -t testbutton "$ACTION $BUTTON" or some such. If the everthings working you'll see pressed and released events Aug 14 01:58:23 nbd: looks different, maybe. I can see other stuff waiting on/through jffs2 Aug 14 02:25:39 Chocky: in that new trace there's one process erasing and one writing. the erase apparently got preempted by the write Aug 14 02:25:59 maybe the chip doesn't like interrupting the erase command Aug 14 02:26:11 you could try to modify the chip driver to not do that anymore Aug 14 02:26:33 for that, edit drivers/mtd/chips/cfi_cmdset_0002.c Aug 14 02:26:38 go to the get_chip() function Aug 14 02:26:48 and #if 0 everything under case FL_ERASING Aug 14 02:27:06 it's just a wild guess, but maybe it could help Aug 14 02:27:55 or maybe it's just the beer talking, dunno ;) Aug 14 02:33:24 build #71 of s3c24xx is complete: Failure [failed compile_10] Build details are at http://buildbot.openwrt.org:8010/builders/s3c24xx/builds/71 Aug 14 02:40:47 will try Aug 14 02:41:19 in the meantime, I'm going to try some shell locking to copy the file Aug 14 02:41:51 i don't think that'll be of much use Aug 14 02:42:28 since a lot of the flash write/erase stuff happens in the background Aug 14 02:52:30 hm, ok Aug 14 02:54:35 I will probably still use it for other reasons; to retain the integrity of the db during a copy. Aug 14 02:54:51 since it does stuff with a journal file, etc Aug 14 02:55:14 makes sense **** ENDING LOGGING AT Sun Aug 14 02:59:57 2011