**** BEGIN LOGGING AT Thu Jan 21 02:59:56 2010 Jan 21 03:49:16 Anyone know what qemu guests other than x86 are supported by OpenWRT? Jan 21 03:51:21 I'd like to be able to test generic stuff on a few arch's, if possible (like the preinit stuff I'm working, which will affect everyone) Jan 21 03:51:54 although the only thing that will need to change is /etc/preinit.arch will move to the new system Jan 21 04:29:25 cshore: what do you plan to do? Jan 21 04:30:38 I'm making preinit modular...it allows for drop in packages for usbroot and enhanced failsafe, or in our cases, a service provider provisioning and recovery system Jan 21 04:31:08 also mounting the rootfs and firstboot Jan 21 04:31:45 cshore: could I take a look at it? Jan 21 04:33:04 sure...I'm just doing final testing on brcm63xx (my devel platform) and will make sure it works on x86 tonight as well. The docs I've written are at http://cshore.is-a-geek.com/openwrt/preinit_mount.html, and I'll pastebin the patch in a sec Jan 21 04:34:44 http://openwrt.pastebin.com/m30f48178 Jan 21 04:35:46 I haven't written the updated version of the usbroot (I had a previous version based on a previous version of this concept), or the failsafe (ditto), yet Jan 21 04:42:59 it works perfectly for brcm63xx squashfs and jffs2. Now I'm making sure the same is true of x86 VM Jan 21 04:46:41 should sysctl be passed -e considering r19214 added 3 more unknown keys to the syslog? Jan 21 04:47:11 cshore: I could test it on rdc Jan 21 04:47:21 cshore: and I may have a few suggestions Jan 21 04:48:30 cool...just let me check out your preinit.arch...I've found it...there'll be a minor patch for moving it to the new format Jan 21 04:50:06 cshore: ohh, and one thing first Jan 21 04:50:13 what's that? Jan 21 04:50:33 cshore: could you add an option to disable the broadcast message completely? Jan 21 04:50:54 cshore: imho this thing is rather useless Jan 21 04:50:57 sure, just don't define an iface Jan 21 04:51:23 it checks if there is one defined and if not ignores it Jan 21 04:52:37 hmm, ok Jan 21 04:53:00 it's more of a you have to turn it on if you want it Jan 21 05:01:48 btw what sorts of routers are the rdc? Jan 21 05:06:08 ok new patch http://openwrt.pastebin.com/m807332b Jan 21 05:06:17 basically just move preinit.arch Jan 21 05:06:27 and rename it Jan 21 05:06:56 and instead of /etc/functions.sh we use /lib/functions/boot.sh (for the find mtd) Jan 21 05:07:41 I've done a full patch that should just be directly applicable Jan 21 05:08:04 rtz: ping? Jan 21 05:08:21 cshore: yes Jan 21 05:08:30 one moment Jan 21 05:08:35 rtz2: just making sure you got the messages Jan 21 05:09:18 cshore: I have some other problems at the moment, give me half an hour Jan 21 05:09:44 sure, not a problem....write the pastebin down somewhere is a good idea though Jan 21 05:18:46 swalker * r19251 /packages/net/tor/Makefile: [packages] tor: update to 0.2.1.22 Jan 21 05:50:25 argh Jan 21 05:50:35 cshore: I can't get my wdt working Jan 21 05:50:45 cshore: your patch will have to wait till tomorrw Jan 21 05:50:46 o Jan 21 05:51:35 rtz: sorry to hear it Jan 21 05:52:03 rtz: good luck getting this working Jan 21 07:18:17 cshore: still there? Jan 21 07:56:55 rtz: yep Jan 21 07:57:38 rtz: you still here since it's been 30 min since your query? Jan 21 08:05:31 ping rtz2 (just in case your client goes by exact name when alerting you) Jan 21 08:27:16 cshore: ok, back Jan 21 08:27:25 cshore: you still there :) Jan 21 08:27:26 ? Jan 21 08:27:33 rtz2: I'm here Jan 21 08:28:05 rtz2: I'm just as crazy about sleep schedule as you Jan 21 08:28:22 rtz2: assuming your in NA Jan 21 08:28:48 cshore: I'm in germany Jan 21 08:28:53 ;) Jan 21 08:29:00 anyway Jan 21 08:29:12 rtz2: oh well, then I'm just the strange one :)....do you want to resend the patch Jan 21 08:29:41 I didn't change anything with it yet Jan 21 08:30:19 hmmm Jan 21 08:30:28 how to explain this ... Jan 21 08:30:32 give me a minute Jan 21 08:32:08 ok Jan 21 08:32:23 yes? Jan 21 08:32:33 there are a few problems with your patch as far as I can see Jan 21 08:32:37 ok Jan 21 08:32:49 but there is a far more general problem Jan 21 08:32:58 is it really worth it? Jan 21 08:33:13 why don't you use normal init scripts? Jan 21 08:33:42 I need to modify the behaviour before we get to init...e.g. replace the mount_root stuff, and the failsafe stuff Jan 21 08:34:16 preferably with packages, so that it's optional changes Jan 21 08:34:38 and doesn't require changing the tree Jan 21 08:35:23 the point is, you are recreating a system fairly similiar to the init scripts Jan 21 08:36:09 so you mean move preinit into init? Jan 21 08:36:22 I'm not sure about dependencies of preinit? Jan 21 08:36:32 like init for initramfs Jan 21 08:37:23 I have to admit, I'm not completly sure, why the preinit system was created in the first place Jan 21 08:37:38 I was interested in changing only one section of the boot process...there's a lot more to change if you do that Jan 21 08:39:03 The problem is that the multiple archs do things differently Jan 21 08:39:16 and ramdisk vs cpio vs squashfs Jan 21 08:39:24 vs ext2 Jan 21 08:40:39 While this change looks big, for most devs it won't mean anything except a minor change to preinit.arch (to new files) Jan 21 08:41:21 A change to all init scripts would require a more major architecture meeting Jan 21 08:43:59 it'd probably be the better way to go in the long run, but I'm not sure it's of enough interest to enough people Jan 21 08:47:17 hmmm Jan 21 08:47:34 next question is, how things should work ... Jan 21 08:47:39 ok Jan 21 08:47:46 there are lot's of problems in the details Jan 21 08:47:56 I basically moved the current system into the new one Jan 21 08:48:03 anyway, back to your patch Jan 21 08:48:58 cshore: why do you do the stuff with boot_hook_add and don't execute the scripts directly? Jan 21 08:49:37 because this way I can add files with a higher sort order, and they can replace the functions before they are executed Jan 21 08:50:00 and add new ones in between and so on Jan 21 08:50:18 cshore: and that's useful because ...? Jan 21 08:50:45 oh Jan 21 08:50:53 right, I think I understand Jan 21 08:50:56 drop in package...e.g. usb root will replace mount_root functionality, but it's not something that should be for everyone Jan 21 08:51:09 hmmm Jan 21 08:51:18 swalker * r19252 /packages/utils/pciutils/ (3 files in 2 dirs): [packages] pciutils: update to 3.1.5, remove the gzip-only mirror, switch to using the compressed ID file Jan 21 08:51:23 or adding new funky failsafe stuff Jan 21 08:51:38 but only optionally Jan 21 08:51:54 and without having bug the devs to get a change comitted Jan 21 08:53:57 also for e.g. third party development Jan 21 08:54:55 agb * r19253 /trunk/package/carl9170/Makefile: [package] carl1970: fix download url. Closes #6542. Thanks swalker Jan 21 08:55:14 I give an absolutely trivial example in the Customization section of the docs Jan 21 09:06:28 cshore: another question Jan 21 09:06:33 yes? Jan 21 09:06:41 cshore: did you measure the boot time with this patch? Jan 21 09:07:59 no, I haven't. To be honest on my platform getting to the - preinit - prompt is the lengthy part of the boot process Jan 21 09:08:32 i.e. the CFE and kernel Jan 21 09:08:48 for me it's probably the init stage Jan 21 09:09:02 but it takes quite some time :/ Jan 21 09:09:41 there is a 2 second delay to give the user a chance to enter failsafe Jan 21 09:10:28 on the brcm63xx platform the preinit stuff doesn't take long, but getting to preinit, and the rsS init takes a while Jan 21 09:10:47 starting daemons and such takes a while Jan 21 09:10:57 that hasn't changed, as I haven't changed it Jan 21 09:11:21 rcS I man Jan 21 09:11:29 mean Jan 21 09:12:33 on the x86 VM I'm running boot is practically instantaneous, with a second or so delay for the rcS init Jan 21 09:12:39 after grub Jan 21 09:12:45 and kernel Jan 21 09:15:06 I think besides the 2s delay the longest part is mount_root Jan 21 09:25:10 cshore: ok, maybe I don't get it, but how does the overwriting work? Jan 21 09:25:35 cshore: say, if you want to insert a custum root mount command? Jan 21 09:26:05 the files are all sourced, so if you source the second file after the functions is first defined, and you redefine it, the system uses the second function definition Jan 21 09:26:29 the hooks execute the last function of a given name that was defined Jan 21 09:27:06 ahh, right Jan 21 09:27:45 cshore: another thing Jan 21 09:27:53 file1: Jan 21 09:27:53 func1() { Jan 21 09:27:53 echo "1" Jan 21 09:27:53 } Jan 21 09:27:53 func2() { Jan 21 09:27:54 echo "2" Jan 21 09:27:55 the fs_wait_for_key function? Jan 21 09:27:56 } Jan 21 09:27:58 boot_hook_add some_hook func1 Jan 21 09:28:00 boot_hook_add some_hook func2 Jan 21 09:28:02 file2: Jan 21 09:28:15 That's because Ctrl-C doesn't work on brcm63xx Jan 21 09:28:37 so I wait for f for failsafe Jan 21 09:28:50 with a timeout Jan 21 09:30:02 for x86 I redefine that function to not use it because it doesn't make sense...failsafe is entered via GRUB Jan 21 09:30:19 but if you've got a serial console it helps Jan 21 09:30:32 cshore: did you figure out where exactly the problem is? Jan 21 09:31:58 The truth is I don't understand how Ctrl-C would work in the first place...my understanding was that /dev/console doesn't support job control (CTRL-C -> SIGINT), but if it works elsewhere then I have no clue Jan 21 09:33:53 the jobcontrol is probably done by init Jan 21 09:34:16 I remember it being in issue on x86 too, way back when I was doing boot floppies Jan 21 09:34:36 so I just assumed that it never actually worked Jan 21 09:34:52 does it work on rdc? Jan 21 09:35:15 no Jan 21 09:35:41 does it work in failsafe? or is only during startup broken? Jan 21 09:36:26 only before multiuser ... /dev/console doesn't do Ctrl-C, but /dev/tty does (so after /sbin/init launches ash on a tty it's okay Jan 21 09:36:54 What I read is that /dev/console simply doesn't support that function Jan 21 09:37:43 you need the tty (or pty for network etc) or ttyS Jan 21 09:37:53 <{Nico}> /win 16 Jan 21 09:38:16 {Nico}: ? Jan 21 09:39:01 <{Nico}> cshore: just waking up :) Jan 21 09:39:08 heh Jan 21 09:39:31 rtz: My guess is that Ctrl-C doesn't work anywhere for preinit for failsafe Jan 21 09:39:46 this channel is getting a second youth Jan 21 09:40:00 i love the smell of openwrt in the mornings ^_^ Jan 21 09:40:55 Lalloso: so do I, but I think my morning is different than your morning because it's still dark and I haven't been to bed yet Jan 21 09:45:57 you work too hard Jan 21 09:46:23 when i'll be your boss i won't let you do so ;-) Jan 21 09:46:39 http://lists.busybox.net/pipermail/busybox/2002-June/040486.html Jan 21 09:46:44 Lalloso :) Jan 21 09:46:48 build #24 of amcc-ppc40x-trunk is complete: Failure [failed compile_6] Build details are at http://tksite.gotdns.org:8010/builders/amcc-ppc40x-trunk/builds/24 Jan 21 09:49:47 or another link on Ctrl-C: http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/archive/2006/03/msg00149.html Jan 21 09:50:21 Basically Ctrl-C can't work with busybox and it'd be broken to hack it to make it do so (on /dev/console I mean) Jan 21 09:51:00 The solution if you really want Ctrl-C it to get a tty device Jan 21 10:37:27 hmmm, can no longer compile pciutils it seems. running make V=99 now Jan 21 10:39:54 http://openwrt.pastebin.ca/1760022 Jan 21 11:08:03 stintel: wrap the postinst inside an if [ -z "$${IPKG_INSTROOT}" ]; ... then and rebuild? Jan 21 11:20:49 swalker: Jan 21 11:20:54 -$${IPKG_INSTROOT}/usr/sbin/update-pciids Jan 21 11:20:54 +[ -z "$${IPKG_INSTROOT}" ] && $${IPKG_INSTROOT}/usr/sbin/update-pciids Jan 21 11:20:55 ? Jan 21 11:21:18 or do I really need to use if; then? Jan 21 11:21:54 erm wouldn't that say no IPKG_INSTROOT AND use IPKG_INSTROOT? Jan 21 11:22:21 it seems strange to me as well Jan 21 11:23:21 is IPKG_INSTROOT non-empty for opkg targets other than default (e.g. if you do -d usb, will this break?) Jan 21 11:23:54 can you pastebin the postinit? Jan 21 11:24:02 postinst I mean Jan 21 11:26:56 cshore: the pciutils.postinst is defined here: https://dev.openwrt.org/browser/packages/utils/pciutils/Makefile?rev=19252#L35 Jan 21 11:28:41 I think you need: Jan 21 11:28:41 ( cd $${IPKG_INSTROOT} && usr/sbin/update-pciids ) Jan 21 11:29:19 unless update-pciids hardcods the leading slash Jan 21 11:29:26 in which case you need to patch it Jan 21 11:29:27 cshore: well before it was: (cd $${IPKG_INSTROOT}/usr/share; $${IPKG_INSTROOT}/usr/sbin/update-pciids.sh) Jan 21 11:29:38 er right Jan 21 11:29:52 then you need to patch update-pciids Jan 21 11:30:23 it's hard-coding the absolute location, which isn't what you want anyway) Jan 21 11:30:38 opkg can install other than to / Jan 21 11:31:03 the test for PKG_INSTROOT is also used to differentiate between install at compile time and manual opkg install Jan 21 11:31:34 PKG vs IPKG ? Jan 21 11:31:45 the proble is that during compile time it tries to access my pciids file from my desktop's distribution Jan 21 11:32:14 then you need to protect the install routine Jan 21 11:33:04 jow: does that mean non-root destinations are all broken? (wouldn't IPKG_INSTROOT be non empty for them as well?) Jan 21 11:33:42 cshore: maybe, I don't know right now but we used that if instroot thing a lot for luci packages Jan 21 11:34:19 ok, so I think the answer is yes :-/ Jan 21 11:35:17 yes, maybe the openwrt buildroot should provide an additional environment variable, like $SDK=1 or similar Jan 21 11:36:34 or maybe we should just switch to uci-defaults Jan 21 11:37:06 hmm, update-pciids.sh in 3.1.4 and 3.1.5 are identical, so this problem has been introduced in r19252, afaict. I am just going to revert back to the postinst from < r19252 Jan 21 11:37:14 is there a way to stop uci-defaults from overriding $ROOTDIR/files? Jan 21 11:37:32 i.e. so you can have actual default that stay default Jan 21 11:37:50 rather than overridden by package defaults Jan 21 11:40:09 I don't know what you mean Jan 21 11:40:51 doesn't uci-defaults override settings that are in /etc/config at flash time (i.e. on first boot)? Jan 21 11:41:05 yes, and you can't really prevent that Jan 21 11:41:20 I could just add a custom package with an init script that changes stuff Jan 21 11:41:35 ick Jan 21 11:41:43 you need to rely on the cooperation of the shipped uci-defaults Jan 21 11:42:25 I knew there was a reason I didn't like uci-defaults Jan 21 11:42:47 well it is the same as run once on windows Jan 21 11:42:55 and it is useful imo Jan 21 11:42:56 yes, well windows sucks Jan 21 11:43:22 you could disable uci-defaults Jan 21 11:43:22 wouldn't it be better to have a mechanism for modify the target rootfs at build time Jan 21 11:43:27 in the init system Jan 21 11:43:36 not really Jan 21 11:44:00 some scripts need environment info like mac address, device type, dhcp information etc. Jan 21 11:44:07 hmmm Jan 21 11:44:19 not everything can be done at build time Jan 21 11:45:00 Is there any way to control who's last in uci-defaults? Jan 21 11:47:40 jow: the preinit patch, which now works on x86 and brcm63xx, for certain, is here: http://openwrt.pastebin.com/m78e7309b Jan 21 11:48:29 I'm going to do a test build applying the patch to a fresh checkout to make sure I haven't missed anything Jan 21 11:49:48 oh and the latest docs are at http://cshore.is-a-geek.com/openwrt/preinit_mount.html Jan 21 11:50:31 I tested with ramdisk, jffs2, squashfs, and ext2 Jan 21 11:54:09 cshore: I believe the uci-defaults are executed in alphabetical order Jan 21 11:55:25 jow: have I screwed up the patch or does patch not automatically create directories as needed? Jan 21 11:56:31 patch will only create directories with content Jan 21 11:56:47 it has no concept of empty directories Jan 21 11:56:53 hmmm...ok, I've screwed something up Jan 21 11:59:15 hmmm....is it because I svn mv'd a file and then modified it? Jan 21 11:59:23 maybe Jan 21 11:59:44 should appear as one delete + one add in patch Jan 21 11:59:52 +the Jan 21 12:05:03 yep, it did it for the other one I did that way too...hmmm...doesn't seem to generate it correctly Jan 21 12:11:59 http://openwrt.pastebin.com/m57f6920c has the patch that applies correctly Jan 21 12:13:45 juhosg * r19254 /trunk/target/linux/ar71xx/files/drivers/net/phy/rtl8366_smi.c: rtl8366_smi: rename switch attribute handlers Jan 21 12:15:08 ok, building away, we'll see what happen in 20 minutes or so Jan 21 12:22:52 patch applied okay with minimal fuzz Jan 21 12:22:59 building a vm iamge right now Jan 21 12:55:29 It works here Jan 21 12:57:34 pls let me know how yours does Jan 21 12:58:35 swalker * r19255 /packages/utils/pciutils/ (4 files in 2 dirs): [packages] pciutils: Revert r19252's postinst changes, make $DEST a relative path Jan 21 13:18:17 build #26 of ar71xx-trunk is complete: Failure [failed compile_15] Build details are at http://tksite.gotdns.org:8010/builders/ar71xx-trunk/builds/26 Jan 21 13:39:03 cshore it seems no one is interrested in upgrading this plattform Jan 21 13:40:56 which one? Jan 21 13:43:33 puchu: not my skillset Jan 21 13:43:50 jow_laptop brcm47xx Jan 21 13:43:55 2.6.32 Jan 21 13:44:14 i ported the old patches but there i a insmod error when booting from usb disk Jan 21 13:44:47 well as you noticed, there are breakages that must be sorted out before bumping to >= 2.6.32 Jan 21 13:44:58 cryptodev created a kernel oops but it works when i dont boot from usb disk Jan 21 13:45:10 jow_laptop: i know but i cant find the relevant parts Jan 21 13:46:51 well, have you booted a kernel with debug symbols already? What's in the oops ? Jan 21 13:52:06 cshore: to make CTRL+C working, you have to enable CONFIG_FEATURE_INIT_SCTTY in busybox Jan 21 13:54:51 tmonjalo: hmmm....what are the consequences of that? My understanding is that's a 'not recommended' feature Jan 21 13:55:22 and it would only be for preinit, so I'm not sure that it's worth it Jan 21 13:56:26 cshore: it allows you to use /dev/console as a controlling tty Jan 21 13:56:51 by prepending /bin/sh with a dash in inittab Jan 21 13:57:08 jow_laptop http://nopaste.info/4c2234de22.html Jan 21 13:57:32 jow_laptop i allready posted this on the mailing list some time ago Jan 21 13:57:38 but I think it should work if you use getty also Jan 21 13:57:40 tmonjalo: does that cause problems when the serial console becomes accessed by a ttyS device instead of /dev/console? Jan 21 13:57:49 yes Jan 21 13:58:05 then that's bad....the normal operation mode is to use /dev/ttyS Jan 21 13:58:11 CTRL+C works if you have a controlling TTY Jan 21 13:58:19 it is my understanding Jan 21 13:58:34 it *only* for preinit that it doesn't work Jan 21 13:58:43 jow_laptop it doesnt create /dev/crypto ... so the hardware crypto doesnt work when booting from usb disk ... without it it works without problems Jan 21 13:59:03 without it == when booting from flash Jan 21 13:59:06 so I think my solution (wait, with timeout, for f is better) Jan 21 13:59:13 cshore: so you have 2 ways of solving the problem I think : getty or sctty Jan 21 13:59:49 or don't do Ctrl-C in preinit - it works in normal operation so that doesn't need fixed Jan 21 14:00:06 or broken by fixing preinit, which is a minor part of the system Jan 21 14:00:32 cshore: I'm not sure of understanding the whole problem Jan 21 14:00:42 my advice is only for CTRL+C Jan 21 14:02:25 well what's happening is that, currently, there is a prompt during initial boot (preinit) to press Ctrl-C to enter failsafe mode, but it doesn't work because there is no controlling tty. *however* once init runs and spawns a shell on ttyS everthing is fine (and that's the normal operating mode) Jan 21 14:03:05 So fixing Ctrl-C in preinit would break the normal mode Jan 21 14:03:19 puchu: sorry, just seen your msg on the mailinglist now Jan 21 14:03:48 so we should just realize that Ctrl-C doesn't work *in preinit* and not try to use it Jan 21 14:03:52 jow_laptop np .. i played around with some patches but none of my changes worked Jan 21 14:04:44 puchu: so you poked around in the vfs layer already? Jan 21 14:04:58 apparently the "path_get" function has issues Jan 21 14:05:07 yeah but it was more like ... i dont know what i should change Jan 21 14:05:25 adding some debug printfs to trace the execution flow would be a good start Jan 21 14:05:37 in this particular function Jan 21 14:07:33 tmonjalo: but the thought is appreciated Jan 21 14:08:08 jow_laptop i thought maybe some of the patches in generic or brcm47 pachtes is causing this Jan 21 14:08:28 puchu: maybe, or it is a real bug :) Jan 21 14:08:58 okay Jan 21 14:09:14 i just did a make dirclean so i just started to create a new image Jan 21 14:10:05 cshore: I don't understand why fixing preinit would break normal mode Jan 21 14:10:53 Doesn't making /dev/console a controlling tty (which is on the serial console), break the using the the same serial console as /dev/ttyS0? Jan 21 14:11:27 cshore: no, I don't think so Jan 21 14:11:56 if not at the same time, of course Jan 21 14:12:11 jow_laptop: so putting some fprintfs in vfs_path_lookup would be the first thing you would recoment Jan 21 14:12:19 puchu: the offending function is defined in fs/namei.c ... http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=fs/namei.c;h=d11f404667e962ababa87f3678a52e78c50794dd;hb=refs/tags/v2.6.32#l360 Jan 21 14:12:51 maybe the passed path struct pointer is NULL or something Jan 21 14:13:40 find out whether mntget() or dget() fails, if you found out which one, proceed with that Jan 21 14:13:49 Ah, well /dev/console is still active when the /dev/ttyS0 thing is going... there are messages still going to stdout and stderr for instance, that are being sent to /dev/console, even though the shell is on /dev/ttyS0 Jan 21 14:14:22 jow_laptop okay ... can i just do a frpintf in the kernel source or do i need a special fprintf function to see the message in dmesg Jan 21 14:14:26 puchu: but apparently they're not called - at least they don't appear in the stacktrace, so maybe the "path->mnt" expression causes a null pointer dereferencing Jan 21 14:15:25 puchu: use printk() - it has similar semantics as printf() Jan 21 14:15:29 okay Jan 21 14:16:08 cshore: it's strange to try having 2 TTYs at the same time on the serial console Jan 21 14:16:18 so maybe putting some printk in vfs_path_lookup would be a good idea too Jan 21 14:16:33 puchu: e.g. kprint(KERN_INFO "path = %p\n", mnt); Jan 21 14:16:45 erm printk(), not kprint() Jan 21 14:16:45 cshore: use only one TTY Jan 21 14:16:57 okay Jan 21 14:16:57 tmonjalo: it's because init is spawned from /dev/console Jan 21 14:17:12 puchu: this will appear in dmesg then Jan 21 14:17:58 cshore: I'm beginning to understand Jan 21 14:18:08 tmonjalo: IIRC VT1 on x86 PC's does the same thing Jan 21 14:18:15 you are in a very standard case Jan 21 14:18:20 don't worry Jan 21 14:18:52 /dev/console and /dev/ttyS0 should be linked to the same instance in the driver Jan 21 14:19:08 there is no conflict Jan 21 14:19:23 (I think) Jan 21 14:19:28 just try Jan 21 14:19:32 tmonjalo: ah, but here's the catch, there isn't always a serial console Jan 21 14:20:04 so ? Jan 21 14:20:06 tmonjalo: which driver? Jan 21 14:20:13 the serial driver Jan 21 14:21:06 tmonjalo: hmmm.....I'm not that with the number of architectures that's possible Jan 21 14:21:47 it can be dependent of kernel configurations Jan 21 14:22:19 tmonjalo: hmmm...I'll have to see what the kernel devs think Jan 21 14:22:47 puchu: btw, the attempt to create /dev/crypto is what causes the oops Jan 21 14:23:13 i know so what would u recommend? Jan 21 14:23:52 no prints in path_get? Jan 21 14:24:02 well first some debugging to find the real cause, and then maybe check what's different in the usb case, maybe /dev is not available (not mounted, mounted too late) or read-only somehow? Jan 21 14:24:51 hmmm okay Jan 21 14:24:54 I could imagine that the error case of a not available /dev is not really handled in the driver Jan 21 14:25:05 drwxr-xr-x 4 root root 940 Jan 1 1970 dev Jan 21 14:25:18 i could do a ls -la / befor i load the module Jan 21 14:25:30 yes, and cat /proc/mtab Jan 21 14:25:37 okay Jan 21 14:25:41 or /proc/mounts Jan 21 14:26:00 okay i compile a new kernel with this printk Jan 21 14:26:15 print(KERN_INFO "path = %p\n mnt= %p\n", path,path->mnt); Jan 21 14:26:36 and put the rest into a file in /tmp Jan 21 14:26:39 change the third arg to: path ? path->mnt : NULL Jan 21 14:27:10 okay Jan 21 14:29:24 jow_laptop: but i think dev sould be there because i use the same preinit i used for 2.6.30 and there it worked without an error Jan 21 14:30:02 puchu: I see Jan 21 14:30:28 puchu: still, maybe the module load order hcanged or something Jan 21 14:54:44 jow_laptop: its mounted Jan 21 14:54:46 drwxrwxrwt 4 root root 900 Jan 1 01:00 dev Jan 21 14:54:51 tmpfs /dev tmpfs rw,relatime,size=512k 0 0 Jan 21 14:57:28 i also pivot_root to the usb disk .. so if there would be no dev at all this wouldnt be possible Jan 21 16:33:54 Lalloso: ping Jan 21 16:35:55 glp: pong Jan 21 16:36:06 wow noone ever pinged me before :) Jan 21 16:36:19 you talked about an ifx dev board? Jan 21 16:37:36 Lalloso: is that correct? Jan 21 16:38:09 could be Jan 21 16:43:55 hi I'm looking for some advice... Jan 21 16:44:29 I'm getting Kernel panic when trying to boot openwrt intramfs image for ar71xx paltform.. Jan 21 16:47:26 i got a kernel panic apparently cause the kernel couldn't find rootfs.. Jan 21 16:47:48 my image is loaded at 0x8100000... Jan 21 17:46:36 hey, seems sta mode with mac80211 is broken again because of the return at https://dev.openwrt.org/browser/trunk/package/mac80211/files/lib/wifi/mac80211.sh#L411 Jan 21 17:47:37 I replaced that line with an if, and put the new code in there, http://openwrt.pastebin.ca/1760429 Jan 21 17:47:41 does that look ok? Jan 21 19:14:47 hi... the "-a" and "-e" arguments passed to mkimage correpond to "Load Address" and "Entry Point" recpectively right?? Jan 21 19:52:18 stintel: hasn't the suggested patch the same effect as the return? Jan 21 19:52:56 stintel: the start_vif loop further down also skips non-ap networks Jan 21 20:52:20 jow * r19256 /trunk/package/broadcom-wl/ (files/lib/wifi/broadcom.sh src/wlc/wlc.c): [package] broadcom-wl: implement wepauth in wlc and support it in broadcom.sh, allows switching between open and shared authentication Jan 21 20:53:07 jow * r19257 /trunk/package/broadcom-wl/files/lib/wifi/broadcom.sh: [package] broadcom-wl: properly detach nas by using start-stop-daemon to launch it Jan 21 21:04:41 jow * r19258 /packages/net/gpsd/ (4 files in 2 dirs): [packages] gpsd: update to v2.90 Jan 21 21:08:12 jow * r19259 /packages/net/transmission/ (Makefile patches/001-debian_dont_build_libevent.patch): [packages] transmission: update to v1.80 (#6544) Jan 21 22:25:36 ping xMff Jan 21 22:25:55 pong cshore Jan 21 22:26:12 xMff: how did the build go for you? Jan 21 22:26:37 cshore: can't tell, I left office early, will check tomorrow Jan 21 22:26:44 xMff: ok Jan 21 22:27:50 xMff: it worked fine here, so it *ought* to be okay...I pulled from latest trunk Jan 21 22:27:57 good Jan 21 22:28:05 the patch looked very clean also Jan 21 22:28:19 unless there are logic errors I can't see why it wouldn't work Jan 21 22:28:25 just wanted to see it in action Jan 21 22:28:34 xMff: of course Jan 21 22:28:34 maybe we can get it included during the upcoming weekend Jan 21 22:32:22 That would be awesome Jan 21 23:38:51 nbd * r19260 /trunk/package/mac80211/patches/580-mac80211_rxdata_fix.patch: mac80211: fix multi-bss related rx handling bug Jan 21 23:40:08 <[Fate]> florian: ping Jan 21 23:41:31 <[Fate]> btw nbd / rtz2 I just fixed that md raid autodetection issue, a patch is in ticket 6548 :) Jan 21 23:41:39 cool Jan 21 23:42:57 <[Fate]> if you could have a quick look I could answer any remaining questions immediately :) Jan 21 23:43:21 no questions, fix looks good Jan 21 23:43:45 i'll commit it Jan 21 23:45:32 hi guys Jan 21 23:45:35 ./package/mtd/src/mtd.c:fprintf(stderr, "\nAppending jffs2 data to from %s to %s...", jffs2file, mtd); Jan 21 23:45:40 that's gotta be a typo Jan 21 23:46:24 nbd * r19261 /trunk/target/linux/x86/ (2 files in 2 dirs): x86: fix software raid autodetection on boot (patch from #6548 by Pieter "Fate" Hollants) Jan 21 23:47:16 Plouj: what specifically? Jan 21 23:47:45 nbd: the "to from" Jan 21 23:47:58 ah Jan 21 23:47:59 yes Jan 21 23:48:18 * nbd is blind to his own typos Jan 21 23:48:25 jow * r19262 /trunk/ (4 files in 4 dirs): [brcm-2.4] add support for OvisLink WL-1600GL Jan 21 23:48:55 nbd * r19263 /trunk/package/mtd/src/mtd.c: mtd: fix typo (thx, Plouj) Jan 21 23:49:20 thanks Jan 21 23:55:28 hey, for some reason, this firewall rule doesn't block access to that IP anymore: http://fpaste.org/1GXZ/ Jan 21 23:55:51 it used to work in some 8.09 release, but not in trunk Jan 21 23:56:23 Plouj: can you paste iptables -nvL ? Jan 22 00:00:13 http://fpaste.org/MRZT/ Jan 22 00:05:53 hmm yes the rule is never reached because it is inserted after the wildcard accept for wan Jan 22 00:06:11 have you tried it without dest ? Jan 22 00:06:19 only src required in the rule Jan 22 00:15:57 * Plouj tries Jan 22 00:16:11 nope, I can still ping that ip Jan 22 00:41:01 xMff: that's what I thought at first, but with that patch I don't have the error "mac80211: enable failed" (just written from memory, I dont have a device in client mode here atm). the problem is that I don't find where enable_mac80211() is executed, so I haven't found an explanation yet for why the problem happens Jan 22 00:41:20 maybe a return code issue? Jan 22 00:42:04 it could be possible, I'll have another look at it tomorrow Jan 22 00:42:42 it is called by wifi_ifupdown in /sbin/wifi Jan 22 00:42:57 eval "${1}_$iftype '$device'" || echo "$device($iftype): ${1} failed" Jan 22 00:43:13 $1 = enable; $iftype = mac80211 Jan 22 00:43:26 ah, I was just grepping for enable_mac80211 :-) Jan 22 00:45:35 http://openwrt.pastebin.com/m5772a369 Jan 22 00:46:03 looks a bit more sane than my patch Jan 22 00:46:06 :-) Jan 22 00:46:35 hmm, I could test if the error occurs even without antenna attached to my card Jan 22 00:47:21 with out value, return will pass the current value of $? Jan 22 00:47:23 *without argument Jan 22 00:47:44 ah Jan 22 00:47:49 the rm Jan 22 00:47:56 most likely Jan 22 00:47:56 the file doesn't exist so it's not 0 ? Jan 22 00:48:16 right Jan 22 00:48:39 interesting Jan 22 00:48:42 $ rm -f /does/not/exist || echo fail Jan 22 00:48:50 ok on my desktop and fail in ash Jan 22 00:49:47 hmm, gives nothing on both my openwrt and desktop Jan 22 00:49:51 *confused* Jan 22 00:50:26 erm you're right Jan 22 00:53:56 I need a quadcore :/ Jan 22 00:55:13 nbd * r19264 /trunk/package/mac80211/files/lib/wifi/mac80211.sh: mac80211: fix hostapd wmm setting for multiple bss interfaces Jan 22 00:56:07 yay, multiple ap mode interfaces finally works properly with ath9k Jan 22 00:56:32 time for a short client mode test? Jan 22 00:56:55 client mode needs to be reworked a bit anyway Jan 22 00:57:00 i think i'll do that tonight Jan 22 00:57:11 client mode with ath9k is really unstable :( Jan 22 00:57:14 stintel seems to get spurious "failed to enable interface" errors, I suspect it is caused the preliminary return Jan 22 00:57:24 stintel: are you using unencrypted or encrypted? Jan 22 00:57:24 http://openwrt.pastebin.com/m5772a369 Jan 22 00:57:40 feel free to commit that patch Jan 22 00:57:42 nbd: both Jan 22 00:58:08 stintel: what kind of hardware? Jan 22 00:58:13 sr71a Jan 22 00:58:24 ar9160? Jan 22 00:58:38 phy0: Atheros AR9160 MAC/BB Rev:0 AR5133 RF Rev:b0 mem=0xb0000000, irq=48 Jan 22 00:58:39 indeed Jan 22 00:58:47 yup, that chip is pretty crappy Jan 22 00:58:53 jow * r19265 /trunk/package/mac80211/files/lib/wifi/mac80211.sh: [package] mac80211: fix spurious error return codes in enable_mac80211() Jan 22 00:59:05 my guess is, not all hw bugs have been worked around in ath9k yet Jan 22 00:59:09 there are quite a few... Jan 22 00:59:09 it's working pretty well as AP with wpa2-psk + 802.11d Jan 22 00:59:38 what are the symptoms of the client mode instabilities? Jan 22 00:59:39 my x86 non-smp laptop hardlocks with ath9k Jan 22 01:00:06 ugh Jan 22 01:00:15 nbd: it loses the connection, need rmmod / insmod ath9k Jan 22 01:00:25 ouch Jan 22 01:00:27 to get it to connect again, sometimes even a reboot Jan 22 01:00:43 sounds like the early days of b43 :) Jan 22 01:00:51 tried it on your laptop or on openwrt? Jan 22 01:00:54 today I had even difficulties with iw dev wlan0 connect ... Jan 22 01:01:10 but with wpa_supplicant it then worked Jan 22 01:01:27 the hard locks are on laptop with another chip Jan 22 01:01:27 yes, client mode will probably always be unreliable without wpa_supplicant Jan 22 01:02:10 i will probably make my own hostapd+wpa_supplicant daemon soon that reads uci directly Jan 22 01:02:24 that'll save some space compared to having both hostapd and wpa_supplicant on the system Jan 22 01:02:25 oh, right, I noticed a problem when using wpa_supplicant as well. when executing wifi when wpa_supplicant is already running, it doesn't kill the old wpa_supp Jan 22 01:02:30 and it'll get rid of some of the nasty shell code Jan 22 01:02:56 \o/ Jan 22 01:02:58 that's problably a problem with one of my patches I added in trac Jan 22 01:03:04 now that we fixed wep :P Jan 22 01:04:00 so for the stability issues you suggest I try with wpa_supplicant Jan 22 01:04:12 yes Jan 22 01:04:19 will do Jan 22 01:04:36 I even disabled ht in ath9k/init.c Jan 22 01:05:08 I hope 2.6.33 will have a stable and useable ath9k at last Jan 22 01:06:08 nbd: is this a symptom of the DFS issue? http://pastebin.com/m7a185e7a -- 5GHz was working semi-ok in previous builds. Jan 22 01:07:00 what does 'iw reg get' show? Jan 22 01:07:13 and what's the output of 'iw phy0 info'? Jan 22 01:07:32 http://pastebin.com/m755fe32f <- iw reg get Jan 22 01:07:39 stintel: it probably won't be more usable that what we have in openwrt right now Jan 22 01:08:01 stintel: since openwrt is pretty much up to date with wireless-testing stuff, which is quite a bit ahead of linus' tree Jan 22 01:08:08 in terms of wireless support Jan 22 01:08:28 nbd: so I've noticed :-) been following linux-wireless and ath9k-devel pretty close lately, and trac log :-) Jan 22 01:08:47 n1x: PASSIVE-SCAN, NO-IBSS - those flags are set for all 5ghz channels Jan 22 01:08:54 that effectively disables ap mode support for these channels Jan 22 01:08:56 jow * r19266 /packages/lang/php5/ (Makefile patches/001-configure_cross.patch): (log message trimmed) Jan 22 01:08:56 [PATCH 1/4] packages/lang/php5: Update to version 5.3.1 Jan 22 01:08:56 The following patchset upgrades the php5 package to php's 5.3 stable branch. Jan 22 01:08:56 It removes the SPL build option as this is included in php's core henceforth, likewise Jan 22 01:08:58 for pcre module. On the other hand a new option for SysV IPC is added and a package Jan 22 01:09:00 for sqlite3 is introduced. Jan 22 01:09:02 As FastCGI support is now a core feature the php5-fastcgi package now depends Jan 22 01:09:12 i'm still considering whether i should just temporarily ignore those regulatory restrictions Jan 22 01:09:22 jow * r19267 /packages/lang/php5/patches/002-uts_domainname.patch: Jan 22 01:09:22 [PATCH 2/4] packages/lang/php5: Remove uts domain patch Jan 22 01:09:22 This patch removes the domain name patch for the new php version 5.3.1 as Jan 22 01:09:22 it doesn't apply anymore. Jan 22 01:09:22 Signed-off-by: Michael Heimpold Jan 22 01:09:29 our madwifi does so as well, after all ;) Jan 22 01:09:41 I also tried a build with compat-wireless-2010-01-20, and removed the patches you sent upstream to make it compile again, but that even had more difficulties, iw dev wlan0 connect did like nothing Jan 22 01:10:03 upstream doesn't have a workaround for the ack timeout issue yet Jan 22 01:10:15 still waiting for an answer from atheros Jan 22 01:10:58 yes but I only removed those who complained that it was already applied (during make V=99), iirc 550-ath9k_ack_timeout_workaround.patch wasm Jan 22 01:11:01 wasn Jan 22 01:11:05 ah, ok Jan 22 01:11:05 ehrm Jan 22 01:11:10 wasn't one of them* Jan 22 01:11:18 this means bedtime ;-) Jan 22 01:11:48 now that ap mode works much better, i think i'll turn my attention towards client mode soon Jan 22 01:11:51 I'll experiment a bit with wpa_supplicant to see if the stability improves, and I'll keep watching track Jan 22 01:11:57 trac* Jan 22 01:12:15 at some point i want to have working ap+sta mode as well Jan 22 01:12:17 and ap+ibss Jan 22 01:12:38 though ap+ibss will probably be easy as soon as ibss mode has been sorted out properly Jan 22 01:13:00 but other people are working on that already, so i guess i won't have to deal with that yet Jan 22 01:13:44 [63888.438268] ioctl32(grub:3507): Unknown cmd fd(3) cmd(00001261){t:12;sz:0} arg(00000000) on /home/stijn/Development/OpenWRT/trunk-x86/bin/x86/openwrt-x86-ext2.image Jan 22 01:13:58 is that something I should worry about ? Jan 22 01:13:59 seems like this issue came along with compat-wireless 2010-01-15 Jan 22 01:16:21 stintel: nope, should be fine Jan 22 01:16:51 nbd: ok, thanks Jan 22 01:20:16 jow * r19268 /packages/lang/php5/patches/ (002-uts_domainname.patch 005-APC.patch): Jan 22 01:20:16 [PATCH 3/4] packages/lang/php5: Upgrade APC patch Jan 22 01:20:16 This patch upgrades the APC module patch to version 3.1.3p1 with Jan 22 01:20:16 support for php 5.3 branch. Jan 22 01:20:16 Signed-off-by: Michael Heimpold Jan 22 01:21:13 jow * r19269 /packages/lang/php5/files/php.ini: Jan 22 01:21:13 [PATCH 4/4] packages/lang/php5: Cleanup php.ini Jan 22 01:21:13 Cleanup php.ini by removing dropped config items. Jan 22 01:21:13 Signed-off-by: Michael Heimpold Jan 22 01:30:18 now I get twice "/sbin/uci: Invalid argument" Jan 22 01:30:30 when doing what? Jan 22 01:30:38 executing wifi Jan 22 01:30:48 the actual command being executed "/sbin/uci -P /var/state set network.wan.ifname=wlan0" Jan 22 01:31:28 ah, there is no wan in /etc/config/network, that's problably the problem. forget what I said Jan 22 01:32:11 but the return 0 fixes the other problem I encountered Jan 22 01:32:21 great, thanks again for the help and tips guys Jan 22 01:32:31 have a good night / timezone all Jan 22 01:32:37 good night Jan 22 01:37:29 nbd: is it possible to force or remove those NO-IBSS flags on ath9k? Jan 22 01:38:32 you can enable the ATH_USER_REGD config option in openwrt and use the hacked regulatory database from http://nbd.name/regulatory.bin Jan 22 01:40:33 thanks **** ENDING LOGGING AT Fri Jan 22 02:59:57 2010