**** BEGIN LOGGING AT Tue Mar 16 02:59:56 2010 Mar 16 03:04:31 any opinions on having a separate /etc from /overlay for the usbroot ? This would allow for a read-only / I think, and, more importantly, if you use a separate /home partition means all the data is on a different partition than the binaries (thus allowing wiping the binaries and reloading them to be a safer operation) Mar 16 04:04:25 ping xMff Mar 16 06:14:11 morning Mar 16 06:14:38 anyone know what this patch actually is for? https://dev.openwrt.org/browser/trunk/target/linux/generic-2.6/patches-2.6.31/940-wireless_mesh_header.patch?rev=17351 Mar 16 08:15:50 acoul * r20236 /trunk/target/linux/generic-2.6/patches-2.6.33/ (150-netfilter_imq.patch 940-wireless_mesh_header.patch): generic-2.6: sync patches to 2.6.33.1 Mar 16 08:16:54 acoul: do you know of tc has been fixed? Mar 16 08:23:04 acoul * r20237 /trunk/target/linux/rb532/ (10 files in 3 dirs): rb532: sync patches. Use 2.6.33.1 kernel Mar 16 08:26:52 acoul * r20238 /trunk/target/linux/rb532/base-files/etc/config/network: rb532: don't use bridge by default Mar 16 08:28:14 tc? Mar 16 08:28:40 traffic control Mar 16 08:28:48 for qos Mar 16 08:28:53 not using it :( Mar 16 08:29:41 ah, I saw the netfilter_imq patch and thought you might know Mar 16 08:30:36 just syncing the patches that's all Mar 16 08:32:02 but I do basic test on actual hw before committing Mar 16 10:39:40 markus * r20239 /trunk/target/linux/brcm47xx/ (2 files in 2 dirs): (log message trimmed) Mar 16 10:39:40 fix PCI resouce allocation for SSB PCI host bridge Mar 16 10:39:40 The defined offset is wrong and the fixup-code overrides it Mar 16 10:39:40 later on so that it never gets used for most PCI devices. Mar 16 10:39:40 Unfortunately the yenta-socket allocates its own resources Mar 16 10:39:40 and crashes because of the wrong mem_offset. Mar 16 10:39:41 It seems that the offset and fixup code came from 2.4 where Mar 16 10:41:28 markus * r20240 /trunk/target/linux/brcm47xx/ (2 files in 2 dirs): Mar 16 10:41:29 fix yenta_socket driver Mar 16 10:41:29 Disable some calls the WRT54G3G implementation does not like Mar 16 10:41:29 and enable interrupts to allow hotplugging. Mar 16 11:21:39 build #32 of ep93xx is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/ep93xx/builds/32 Mar 16 11:38:15 build #29 of gemini is complete: Success [build successful] Build details are at http://tksite.gotdns.org:8010/builders/gemini/builds/29 Mar 16 11:47:43 Hi all, is there someone with concrete experience on MPC8377 ? Mar 16 11:48:31 I am investigating this platform. Freescale said me that OpenWRT is supported, but they do not know what release/trunk .... Mar 16 11:48:54 They seems a bit confused :-( Mar 16 11:49:38 kaloz is working partially on this Mar 16 11:50:52 acoul1: thanks, so it's better I ask him directly .... Mar 16 11:51:56 you can check here: https://dev.openwrt.org/browser/trunk/target/linux/mpc83xx Mar 16 11:52:24 I think rb600 is working (never tested) Mar 16 12:00:37 ok thanks. I'll make some check with kaloz Mar 16 12:55:15 hi all, I'm developing an app on OpenWRT kamikaze. My app is multi-threaded when i run my app i got too many processes in "ps -ef" output. I think there is one entry for every thread, it is ok but i have 5 thread and there are 7 entries. Why is that, any suggestions ? Mar 16 12:55:43 " I think there is one entry for each thred" Mar 16 12:56:24 augurel: openwrts uclibc uses the linuxthreads-old implementation on all platforms except x86, this impl. is known to spawn more threads than created by the program, the additional ones are management threads Mar 16 12:58:13 oh i see. After some time, my threads gets killed. May it be a linuxthreads-old implementation bug? Mar 16 12:58:31 maybe, or oom Mar 16 12:58:43 Just 1 pid stays, other ones killed Mar 16 12:59:56 did u faced problems like that ? Mar 16 13:01:33 no, I never worked with pthreads Mar 16 13:02:30 actually, the main problem is i couldn't find how to identify the problem Mar 16 13:02:55 is there a way that i can dump the process data? Mar 16 13:04:06 markus * r20241 /trunk/include/kernel-version.mk: Mar 16 13:04:07 new kernel checksums: Mar 16 13:04:07 2.6.32.10 Mar 16 13:04:07 2.6.33.1 Mar 16 13:06:36 augurel: ulimit -c unlimited; echo /tmp/core > /proc/sys/kernel/core_pattern; ./your_executable; ...; kill -ABRT your_pid Mar 16 13:06:41 augurel: this should work Mar 16 13:07:34 thank u so much, immediately trying Mar 16 13:13:37 when i type "ldd /sbin/test" it says libpthread.so.0 => /lib/libpthread.so.0 (0x2aabe000) Mar 16 13:13:47 ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x2aaa8000) Mar 16 13:14:28 is it using threads from ucLibc or pthread?? i got confused Mar 16 13:18:19 : binary is not stopped when i send -ABRT signal Mar 16 13:30:11 augurel: i'm also interested in this topic Mar 16 13:30:19 " is it using threads from ucLibc or pthread?? i got confused" Mar 16 13:30:33 i think the only threads implementation available in openwrt comes from ucLibc Mar 16 13:31:01 and if your target is NOT x86 you are using that old linuxthreads-old implementation Mar 16 13:31:13 what do you mean from "ucLibc or phtread"? Mar 16 13:36:51 Oh, it is about my toolchain right? Mar 16 13:42:54 augurel: check /lib/libpthread.so.x.y.z Mar 16 13:43:10 if it has the same version number as uClibc.so.x.y.z, then it is part of uClibc Mar 16 13:44:12 yes it is the same version with ucLibc Mar 16 13:44:31 how could i update the pthread? Mar 16 13:44:37 you can't Mar 16 13:44:53 libpthread.so and libuClibc.so are built from the same sources Mar 16 13:45:05 which version of uclibc is that? Mar 16 13:45:06 but you can try to change the uclibc config Mar 16 13:45:17 to use ntpl Mar 16 13:45:19 ld-uClibc-0.9.30.1.so Mar 16 13:45:48 mmm Mar 16 13:46:12 openwrt is going to migrate to ntpl? Mar 16 13:46:16 yes Mar 16 13:46:22 at least we plan to Mar 16 13:46:51 I see Mar 16 13:47:23 but augurel why do you think the current threads implementation in openwrt does not work for you? Mar 16 13:48:11 Lallino: bacause his applications threads disappear after some time Mar 16 13:48:18 *because Mar 16 13:49:30 okay but if i've understood he should be using threads in a very unique and special way Mar 16 13:49:47 otherwise everyone using multithreads application should experience similar issues or? Mar 16 13:50:04 currently openwrt uses this? http://en.wikipedia.org/wiki/LinuxThreads Mar 16 13:50:30 actually, i'm not using in special way Mar 16 13:50:48 i'm sorry for my newbies questions, i'm not fond on threads byt nowadays applications do a heavy usage of applications Mar 16 13:50:56 sorry for my english also Mar 16 13:51:34 augurel: do you suspect a bug in the threads implementation? Mar 16 13:52:10 actually i'm working on my applications' bugs. Mar 16 13:52:29 if any, i just asked for are there any one faced similar problem Mar 16 13:52:32 but do you think the current thread implementation is not doing the job right for you? Mar 16 13:52:44 ah okay :) Mar 16 13:53:08 btw, i couldn't success on core dumps Mar 16 13:53:31 my processes do not create dump files Mar 16 13:53:33 augurel: have you started your application from the same shell instance where you did the ulimit? Mar 16 13:53:48 augurel: and have you checked /tmp/ for the dump? Mar 16 13:53:55 is you application setuid or something? Mar 16 13:54:09 i have connected via serial Mar 16 13:56:18 cshore: can you look at https://dev.openwrt.org/ticket/6852 Mar 16 13:57:21 : i tried again, set ulimit -c unlimited and start my app Mar 16 13:57:31 after that i killed with kill -9 pid Mar 16 13:57:48 not kill -9 Mar 16 13:58:03 you need to send a signal which produces a coredump Mar 16 13:58:11 sigfpe, sigsegv, sigabrt Mar 16 13:58:16 something like that Mar 16 13:58:47 when i use "kill -ABRT pid" it doesn't kill my process Mar 16 13:59:04 which is the number of ABRT? Mar 16 14:00:30 i send 6(SIGABRT) but result is same Mar 16 14:00:57 maybe your program is masking that signal Mar 16 14:00:58 try sigsev Mar 16 14:01:16 sigsegv is more fun ^_^ Mar 16 14:01:18 http://docs.google.com/viewer?a=v&q=cache:86q6AsDrOe8J:www.kernel.org/doc/ols/2006/ols2006v1-pages-409-420.pdf+nptl+uclibc&hl=en&pid=bl&srcid=ADGEEShaE7V7mtQUco7ewQ_NhUmN5rgU3rNsqfyn7_WYXqjKw4zKN5y5DuXRAdIf-etq25mHBXHgv0lhtkQp8sGRarBTUNLZegeARd3tFeq5NX4KVgPkZkspiuV-dzwiLm_fMbvU2huC&sig=AHIEtbRkh1CU2on_1JWd0W6Dsz6hQbzIgw Mar 16 14:01:27 ah sorry for the paste Mar 16 14:01:40 i was just wondering, is it possible to also have glibc under openwrt? Mar 16 14:02:12 according to this paper the different in size is not too much between glibc and uclibc about 5 megs vs 3 megs Mar 16 14:02:14 http://www.kernel.org/doc/ols/2006/ols2006v1-pages-409-420.pdf Mar 16 14:02:30 I'm not sure that space is still so expensive on todays flash memories Mar 16 14:02:34 juhosg * r20242 /trunk/target/linux/ar71xx/files/arch/mips/ar71xx/gpio.c: ar71xx: optimize GPIO code Mar 16 14:02:54 Lallino: they still introduce routers with 4MB flash :-/ Mar 16 14:03:10 this limitation will be around for quite some time Mar 16 14:03:18 ah sorry i did not know Mar 16 14:03:32 they really want to save on every little bit! :) Mar 16 14:05:10 so we'll probably have NPTL with uclibc in openwrt Mar 16 14:05:27 but we are not going to have NPTL with glibc in openwrt Mar 16 14:05:31 is this vision correct? Mar 16 14:05:36 yes Mar 16 14:05:39 thx Mar 16 14:11:01 jow_laptop : my process is forks immediately it starts, is it cause not to creating core dumps Mar 16 14:12:16 augurel: ah Mar 16 14:12:33 augurel: well give it an option to not fork :) Mar 16 14:12:46 augurel: or add the ulimit call to the forked child Mar 16 14:13:23 ok, trying to not to fork Mar 16 14:16:02 acoul * r20243 /trunk/target/linux/adm5120/Makefile: adm5120: use 2.6.33.1 kernel Mar 16 14:41:01 acoul * r20244 /trunk/target/linux/adm5120/Makefile: revert last commit Mar 16 14:42:26 acoul * r20245 /trunk/target/linux/adm5120/Makefile: adm5120: use 2.6.32.10 kernel Mar 16 14:51:53 jow_laptop i've seen that Mar 16 14:51:58 with some targets Mar 16 14:52:09 and recent revisions of openwrt Mar 16 14:52:21 under advanced configuration Mar 16 14:52:31 Toolchain options Mar 16 14:52:42 it's possible to choose C library implementation Mar 16 14:52:50 there is uclibc-nptl branch available Mar 16 14:52:53 and also eglibc Mar 16 14:52:55 and glibc Mar 16 14:53:06 could you please clarify ? Mar 16 14:53:25 I understood that these options were not available Mar 16 14:53:35 (target is a MPC83xx powerpc) Mar 16 15:01:40 clarify what? Mar 16 15:04:13 i mean Mar 16 15:04:22 why do i see the possibility in make menuconfig Mar 16 15:04:29 1) to have uclibc with nptl Mar 16 15:04:34 2) to have glibc instead of uclibc Mar 16 15:04:57 i thought from what you told me that in openwrt now there is only uclibc with linuxthreads Mar 16 15:05:16 just when you think you think you've fixed something, something pops up further Mar 16 15:05:29 jow_laptop have you understood my doubt? Mar 16 15:05:55 Lallino: I didn't they there is only this, it just happens to be the default Mar 16 15:06:02 *didn't say Mar 16 15:06:09 ah sorry i misunderstood Mar 16 15:06:23 therefore openwrt already supports glibc as C library Mar 16 15:07:10 good to know Mar 16 17:49:45 blogic * r20246 /trunk/target/linux/ifxmips/patches-2.6.30/ (3 files): ifxmips - adds cf0001 swizzel patch, by/signed off Veli-Matti Valtonen (maligor) Mar 16 17:50:01 maligor: done Mar 16 17:50:18 now other people can attempt to poke it into submission :P Mar 16 17:51:00 hehe Mar 16 17:51:06 i'll have a look later Mar 16 17:51:08 ahhh Mar 16 17:51:11 I guess I'll have to find a mips assembler manual somewhere Mar 16 17:51:14 is it 64k or 128k block ? Mar 16 17:51:26 128k Mar 16 17:51:27 there is a book called "see mips run" Mar 16 17:51:32 the images are 64k :) Mar 16 17:51:38 i have a patch for 128 images Mar 16 17:51:41 let me mail it to you Mar 16 17:51:42 oh.. ok Mar 16 17:51:43 ok ? Mar 16 17:51:54 sure Mar 16 17:51:56 gimme 20 minutes i am on the train with crppy 3g Mar 16 18:08:56 maligor: https://lists.openwrt.org/pipermail/openwrt-devel/2010-March/006278.html Mar 16 18:09:07 maligor: i will merge it later today Mar 16 19:29:12 build #33 of ep93xx is complete: Failure [failed compile_6] Build details are at http://tksite.gotdns.org:8010/builders/ep93xx/builds/33 Mar 16 19:53:29 juhosg * r20247 /trunk/target/linux/ar71xx/files/arch/mips/ar71xx/gpio.c: Mar 16 19:53:29 ar71xx: fix semantics error in the __ar71xx_gpio_get_value function. Mar 16 19:53:29 * Thanks to Pascal Dornier Mar 16 20:11:25 xMff: ping Mar 16 21:00:01 [florian]: about my brcm63xx device we talked about yesterday. what was the source file again i'd have to change in order for the wirless device to properly work? Mar 16 22:22:30 ping thepeople Mar 16 22:23:39 ping xMff Mar 16 22:23:45 pong Mar 16 22:24:00 xMff: did you see my email about LuCI? Mar 16 22:24:09 yes, go ahead Mar 16 22:24:17 xMff: ok Mar 16 22:24:54 xMff: are you mostly just doing bug fixes for now? Mar 16 22:25:03 yes, in luci-0.9 Mar 16 22:25:37 xMff: what is that going to have vs trunk? Mar 16 22:26:10 a working state Mar 16 22:26:38 xMff: ok, so will it be trunk fixed, or will there be things that are in trunk that aren't in 0.9? Mar 16 22:26:55 I usually fix the stuff in trunk and merge it afterwards Mar 16 22:27:02 unless the differences are too big Mar 16 22:27:03 xMff: ok Mar 16 22:27:39 xMff: should I send you the diff when I edit trunk then? Mar 16 22:27:53 no, just go ahead Mar 16 22:28:03 I'll clean it up if something breaks Mar 16 22:28:09 you should have commit access Mar 16 22:28:31 yep Mar 16 22:29:01 I meant so you know what I've changed (i.e. if you want to merge it) Mar 16 22:29:27 my bot will notify me and I look up the changes in trac anyway Mar 16 22:29:32 ok Mar 16 22:30:02 xMff: does the bot mail to the LuCI mailing list? I'd like to see commit messages too, if possible Mar 16 22:30:11 no Mar 16 22:30:42 you can subscibe to the trac rss, that is what the bot does as well Mar 16 22:30:53 ok Mar 16 22:31:11 http://luci.subsignal.org/trac/timeline?ticket=on&changeset=on&milestone=on&wiki=on&max=50&daysback=90&format=rss Mar 16 22:43:31 got it Mar 16 23:12:40 build #27 of ixp4xx is complete: Failure [failed compile_6] Build details are at http://tksite.gotdns.org:8010/builders/ixp4xx/builds/27 Mar 16 23:15:23 lars * r20248 /trunk/target/linux/xburst/ (patches-2.6.32/103-lcm.patch qi_lb60/config-2.6.32): Mar 16 23:15:23 [xburst] The lcm driver currently does not use any of the backlight api, so Mar 16 23:15:23 remove CONFIG_BACKLIGHT_CLASS_DEVICE as a dependecy and from the config. Fixes #6871 Mar 16 23:27:19 acinonyx * r20249 /packages/net/ (quagga/Makefile quagga-unstable/Makefile): [packages] quagga{,-unstable}: Install config files with proper permissions Mar 16 23:27:24 acinonyx * r20250 /packages/net/ (quagga/Makefile quagga-unstable/Makefile): [packages] quagga{,-unstable}: Add conffiles sections to prevent overwritting of config files Mar 16 23:33:33 cshore: pong Mar 16 23:34:59 thepeople: comments on the bug you pointed out. Can't apply the patch as-is Mar 16 23:36:24 cshore: that is ok, I just wanted you to take a look at it as I have no way of testing Mar 16 23:36:33 cshore: can I assign it to you? Mar 16 23:42:39 ok Mar 16 23:43:19 cshore: I am working on getting tickets taken care of Mar 16 23:43:36 so you will likely hear more from me :-) Mar 16 23:50:50 gnight all Mar 16 23:52:52 lars * r20251 /packages/lang/python/patches/110-enable-zlib.patch: [packages] python: Don't add host paths when compiling the zlib module. Fixes #6856 Mar 17 00:24:17 build #27 of kirkwood is complete: Failure [failed compile_6] Build details are at http://tksite.gotdns.org:8010/builders/kirkwood/builds/27 Mar 17 00:51:20 cshore: what is the status on https://dev.openwrt.org/ticket/6078 ? Mar 17 02:09:10 build #27 of s3c24xx is complete: Failure [failed compile_6] Build details are at http://tksite.gotdns.org:8010/builders/s3c24xx/builds/27 Mar 17 02:39:05 thepeople ticket #6078 is bogus...I just didn't wait long enough...ifup -a just takes a really long time (just tested it again and watched the serial console) Mar 17 02:39:46 cshore: closed :-) **** ENDING LOGGING AT Wed Mar 17 02:59:57 2010