**** BEGIN LOGGING AT Tue Jan 19 02:59:57 2010
Jan 19 11:53:58 <CIA-88> kaloz * r19224 /trunk/ (5 files in 5 dirs): update to latest kernel versions
Jan 19 12:53:38 <CIA-88> kaloz * r19225 /trunk/target/linux/generic-2.6/patches-2.6.31/980-vm_exports.patch: refresh patch
Jan 19 13:12:46 <cshore> anyone else run into the MASQ rules not being created in the firewall yet?
Jan 19 13:24:00 <CIA-88> nico * r19226 /trunk/toolchain/binutils/patches/2.18/500-avr32.patch: [toolchain] binutils: remove unrelated hunk in 2.18 avr32 support patch
Jan 19 13:26:05 <CIA-88> nico * r19227 /trunk/toolchain/gcc/ (Config.in Config.version): [toolchain] gcc: use coherent version selector between binutils & gcc
Jan 19 13:39:05 <cshore> ping xMff
Jan 19 13:39:18 <jow_laptop> pong cshore
Jan 19 13:40:03 <cshore> I've run into the MASQ entries not being created in the firewall...is it useful to debug that, or how long will it be until the new firewall is ready?
Jan 19 13:40:32 <jow_laptop> it is useful to debug that
Jan 19 13:40:53 <jow_laptop> apart from that; what are the details of the problem?
Jan 19 13:46:40 <cshore> I have a brcm63xx-based router that I've configured with VLANs.  wan is eth1.0, lan is eth1.2 (on br-lan), and master is eth1.1.  I'm not using lan yet, but concentrating on master.  When I allow master->wan, and use the default wan configuration (forwarding, mtu_fix), outgoing ping reports destination unreachable, and incoming ssh says connection refused (with redirect and firewall ACCEPT rules).  I looked into it, and when I added 
Jan 19 13:48:07 <jow_laptop> your post was truncated after "when I added"
Jan 19 13:48:23 <cshore> when I added a static route, on the outside host, that tells how to go through the router to master, and remove the MASQ, and make the forward default to ACCEPT, the packets are accepted.  Before I do that I checked iptables -nv -L and there are no masquerade rules
Jan 19 13:49:07 <jow_laptop> so you added a forwarding section src:master dest:wan and kept the default wane zone definition with masq:1
Jan 19 13:49:08 <jow_laptop> ?
Jan 19 13:49:32 <cshore> I did that, but that was insufficient
Jan 19 13:50:48 <cshore> iptables -nv -L doesn't display any masquerade rules, but on my other router it does, so I think the rule isn't being added
Jan 19 13:51:11 <cshore> (other router = older revision)
Jan 19 13:51:25 <jow_laptop> masquerading rules are found in the nat table
Jan 19 13:51:30 <jow_laptop> iptables *-t nat* -nvL
Jan 19 13:56:44 <cshore> config 'zone'
Jan 19 13:56:44 <cshore>         option 'name' 'wan'
Jan 19 13:56:44 <cshore>         option 'input' 'REJECT'
Jan 19 13:56:44 <cshore>         option 'output' 'ACCEPT'
Jan 19 13:56:44 <cshore>         option 'forward' 'REJECT'
Jan 19 13:56:45 <cshore>         option 'mtu_fix' '1'
Jan 19 13:56:47 <cshore>         option 'masq' '1'
Jan 19 13:56:49 <cshore> and
Jan 19 13:56:51 <cshore> config 'forwarding'
Jan 19 13:56:53 <cshore>         option 'src' 'master'
Jan 19 13:56:55 <cshore>         option 'dest' 'wan'
Jan 19 13:56:57 <cshore> results in no MASQ rules
Jan 19 13:57:04 <cshore> iptables -t nat -nv -L | grep MASQUERADE
Jan 19 13:57:08 <cshore> no results
Jan 19 14:02:47 <Lalloso> hello
Jan 19 14:02:56 <Lalloso> how does the boot system of openwrt work?
Jan 19 14:03:04 <Lalloso>  /bin/sh /etc/rc.common /etc/rc.d/S90freeswitch boot
Jan 19 14:03:09 <Lalloso> i mean the init scripts
Jan 19 14:03:22 <cshore> ?
Jan 19 14:03:23 <jow_laptop> kernel calls /etc/preinit, /etc/preinit does failsafe preparation and spwans /sbin/init
Jan 19 14:03:46 <jow_laptop>  /sbin/init launches /etc/rc.d/* one by one
Jan 19 14:03:59 <cshore> with boot (not start)
Jan 19 14:04:04 <Lalloso> so if i don't want
Jan 19 14:04:05 <jow_laptop> exactly
Jan 19 14:04:12 <Lalloso> a process to start at boot
Jan 19 14:04:23 <jow_laptop> then you do /etc/init.d/scriptname disable
Jan 19 14:04:28 <Lalloso> i have to remove the script from rc.d
Jan 19 14:04:33 <Lalloso> ah wonderful
Jan 19 14:04:35 <Lalloso> let me try
Jan 19 14:04:48 <jow_laptop> disable removes the symlink, enable installs it again
Jan 19 14:04:53 <jow_laptop> no need to do manual work in rc.d
Jan 19 14:05:22 <Lalloso> thanks a lot jow_laptop
Jan 19 14:05:27 <Lalloso> it works like a charm
Jan 19 14:05:32 <Lalloso> how is this system called?
Jan 19 14:05:41 <Lalloso> i'm used to BSD style scripts such the ones in slackware
Jan 19 14:05:46 <jow_laptop> it has no name
Jan 19 14:05:55 <jow_laptop> all the magic is implemented in /etc/rc.common
Jan 19 14:06:02 <jow_laptop> which is sourced by each init script
Jan 19 14:06:10 <jow_laptop> (#!/bin/sh /etc/rc.common)
Jan 19 14:06:37 <cshore> Lalloso: hey, you know anyone who knows DSP stuff...we're looking at seeing about DSP for our board for FreeSwitch
Jan 19 14:06:48 <Lalloso> i am :-D
Jan 19 14:07:04 <Lalloso> i'm joking cshore
Jan 19 14:07:16 <Lalloso> the best man i know is coppice on #freeswitch aka steve underwood
Jan 19 14:07:22 <Lalloso> you can get him at consulting@freeswitch.org
Jan 19 14:07:24 <Lalloso> i think
Jan 19 14:07:34 <Lalloso> jow_laptop: thanks a lot so it's a specific system of openwrt
Jan 19 14:07:40 <Lalloso> is it documented somewhere onthe wiki?
Jan 19 14:08:36 <cshore> Lalloso: what DSP are you going to be using with FS?  Ours is a DSPG Voicepump VP101x
Jan 19 14:09:19 <cshore> we've already got a SLIC driver that [florian] did
Jan 19 14:09:38 <jow_laptop> Lalloso: in the forum, wait a moment
Jan 19 14:10:01 <jow_laptop> Lalloso: https://forum.openwrt.org/viewtopic.php?id=11301
Jan 19 14:12:49 <cshore> xMff:  config 'zone'
Jan 19 14:12:49 <cshore>          option 'name' 'wan'
Jan 19 14:12:49 <cshore>          option 'input' 'REJECT'
Jan 19 14:12:49 <cshore>          option 'output' 'ACCEPT'
Jan 19 14:12:49 <cshore>          option 'forward' 'REJECT'
Jan 19 14:12:50 <cshore>          option 'mtu_fix' '1'
Jan 19 14:12:52 <cshore>          option 'masq' '1'
Jan 19 14:12:54 <cshore>  and
Jan 19 14:12:56 <cshore>  config 'forwarding'
Jan 19 14:12:58 <cshore>          option 'src' 'master'
Jan 19 14:13:00 <cshore>          option 'dest' 'wan'
Jan 19 14:13:02 <cshore> results in no MASQ rules
Jan 19 14:13:04 <cshore> iptables -t nat -nv -L | grep MASQUERADE
Jan 19 14:13:06 <cshore> no results
Jan 19 14:13:07 <jow_laptop> in -t nat ?
Jan 19 14:13:13 <cshore> that's right
Jan 19 14:13:28 <cshore> I've also noticed that there are other rules missing
Jan 19 14:13:30 <jow_laptop> throw the full output of -t filter and -t nat into pastebin
Jan 19 14:13:40 <cshore> it appears to be a bunch of stuff in addif is missing
Jan 19 14:13:48 <jow_laptop> and check whether the rules are created after an additonal "ifup master"
Jan 19 14:14:15 <Lalloso> cshore ours is audiocodes i think
Jan 19 14:16:25 <cshore> Lalloso: the DSPG is an audiocodes DSP
Jan 19 14:17:45 <cshore> Lalloso: my boss is interested in finding others to work with for FS on brcm63xx and in particular our chip
Jan 19 14:21:36 <cshore> xMff: http://openwrt.pastebin.com/m593d60f
Jan 19 14:21:56 <cshore> and ifup does add it; I'll post that in a sec
Jan 19 14:22:55 <jow_laptop> cshore: then you should focus your debugging efforts on ifup -a, hotplug and /etc/init.d/network
Jan 19 14:23:27 <jow_laptop> could be a race condition since the initial bringup of network interfaces checks against /proc/net/dev
Jan 19 14:23:43 <cshore> probably because it's vlan
Jan 19 14:23:49 <jow_laptop> if the switch is initialized later the ethX.Y devices are not there yet and thus the corresponding networks are not brought up
Jan 19 14:26:02 <cshore> maybe we just need a sleep to give the switch time to be configured (since ifup doesn't happen until after switch_setup (or is it setup_switch))
Jan 19 14:26:34 <cshore> nevermind I was thinking of start
Jan 19 14:26:37 <jow_laptop> probably, however I do not like the idea of arbitary sleeps
Jan 19 14:27:11 <jow_laptop> the switch config itself should trigger the subsequent setup steps after it is finished
Jan 19 14:27:17 <cshore> probably the firewall is happening before the device is hotplugged
Jan 19 14:27:34 <jow_laptop> the actual addif() in the firewall is triggered by hotplug already
Jan 19 14:27:39 <cshore> hmmm....
Jan 19 14:27:44 <jow_laptop> it should be timining agnostic
Jan 19 14:27:48 <cshore> right
Jan 19 14:27:59 <jow_laptop> firewall start just constructs common chains and rules
Jan 19 14:31:57 <cshore> hmmm....maybe the problem is hotplug isn't happening...the iface is created but no hotplug event is generated
Jan 19 14:33:29 <rtz> cshore: I would rather think the hotplug event is not handled correctly
Jan 19 14:33:50 <cshore> hmmm....
Jan 19 14:34:04 <rtz> cshore: take a look at /etc/hotplugs2.rules
Jan 19 14:37:16 <Lalloso> cshore are you doing the development in freeswitch in order to use the DSP instead of software library spandsp?
Jan 19 14:37:41 <cshore> Lalloso: that's the plan
Jan 19 14:38:04 <Lalloso> are you using the DSP just for the transcoding stuff
Jan 19 14:38:09 <Lalloso> plus DTMF recognition
Jan 19 14:38:23 <cshore> yes
Jan 19 14:38:26 <Lalloso> or also in place of mod_conference (i.e. conferencing stuff) ?
Jan 19 14:38:42 <cshore> hmmm...I'd have to ask about that
Jan 19 14:38:50 <cshore> I'm not sure what the chip is capable of
Jan 19 14:39:11 <Lalloso> do you already know which files you have to modify for freeswitch?
Jan 19 14:39:15 <cshore> we're looking at a channel driver and enpoint
Jan 19 14:39:26 <Lalloso> mmm
Jan 19 14:39:29 <cshore> Lalloso: no
Jan 19 14:39:42 <Lalloso> i've spoken with a couple of guys who are also expert in that
Jan 19 14:39:52 <Lalloso> but if you have budget to spend
Jan 19 14:40:08 <Lalloso> the best way is to ask for a professional service at freeswitch consulting
Jan 19 14:40:15 <cshore> right
Jan 19 14:40:33 <Lalloso> we are still finalizing our budget here I also would like to hire some of those guys
Jan 19 14:40:54 <cshore> Lalloso: I don't think we have a big budget...but if we could share costs it would help
Jan 19 14:41:50 <Lalloso> indeed
Jan 19 14:58:20 <Lalloso> lol I think i've erased the whole mtdblock2
Jan 19 14:58:40 <Lalloso> all the uboot environment is now gone
Jan 19 14:58:52 <Lalloso> I still have a lot to learn on embedded
Jan 19 16:08:13 <CIA-88> lars * r19228 /packages/Xorg/xorg/lib/libXtst/Makefile: [packages] libXtst install headers.
Jan 19 16:11:54 <Lalloso> jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found
Jan 19 16:12:22 <rtz> Lalloso: your image is messed up
Jan 19 16:12:30 <Lalloso> doh
Jan 19 16:12:32 <rtz> Lalloso: it's not aligned corretly
Jan 19 16:12:40 <Lalloso> any hint on where to look?
Jan 19 16:12:45 <Lalloso> I have an mtdblock2
Jan 19 16:12:48 <Lalloso> and u-boot
Jan 19 16:12:56 <Lalloso> it's my first day with u-boot
Jan 19 16:14:18 <rtz> Lalloso: either it's a problem with the script creating the image, or you flashed to the wrong place
Jan 19 16:14:24 <rtz> is your device supported?
Jan 19 16:14:49 <rtz> Lalloso: or are you trying to add support for it
Jan 19 16:14:52 <Lalloso> i'm not sure if it's supported
Jan 19 16:15:03 <Lalloso> i'm not the main developer
Jan 19 16:15:08 <rtz> Lalloso: what is it?
Jan 19 16:15:26 <Lalloso> it's an infineon smthing
Jan 19 16:16:06 <Lalloso> Old JFFS2 bitmask found at 0x006b2eb4 You cannot use older JFFS2 filesystems with newer kernels
Jan 19 16:16:44 <Lalloso> the kernel loads into ram from a tftpserver with bootm
Jan 19 16:16:58 <Lalloso> then it seems it plays with the filesystem and breaks something on the flash
Jan 19 16:17:51 <rtz> Lalloso: you can't use the jffs2 or squahsfs image if you boot from ram
Jan 19 16:18:06 <rtz> Lalloso: try the initrd one
Jan 19 16:18:16 <rtz> Lalloso: (or write it to flash)
Jan 19 16:19:21 <Lalloso> the kernel is in lzma
Jan 19 16:19:24 <Lalloso> and it boots properly
Jan 19 16:19:33 <Lalloso> the problem is that the rootfs is on flash
Jan 19 16:19:41 <Lalloso> and on flash mtdblock2 there are:
Jan 19 16:19:49 <Lalloso> rootfs,kernel,data,environment
Jan 19 16:19:51 <Lalloso> in this order
Jan 19 16:20:15 <Lalloso> it seems that the jffs2 support in the kernel does not like something on the flash and break it here and there
Jan 19 16:20:20 <rtz> that's kinda messed up
Jan 19 16:20:28 <jow_laptop> just erase the jffs2
Jan 19 16:20:53 <jow_laptop> it probably finds old signatures on the flash
Jan 19 16:21:02 <Lalloso> i've reflashed it a lot of times
Jan 19 16:21:16 <jow_laptop> reflashing does not erase thar part of the flash
Jan 19 16:21:27 <rtz> erasing it won't work, you will have to add the correct signatures
Jan 19 16:21:46 <jow_laptop> ti will work to avoid this: "Old JFFS2 bitmask found at 0x006b2eb4 You cannot use older JFFS2 filesystems with newer kernels"
Jan 19 16:22:07 <Lalloso> let me check if with ro it changes anything
Jan 19 16:24:17 <Lalloso> mkimage -A MIPS -O Linux -C none -T filesystem -e 0x00 -a 0x00 -n "MY_NAME_OPENWRT" -d $(KDIR)/root.$(1).swap  $(KDIR)/rootfs_jffs2.img
Jan 19 16:24:45 <Lalloso> but is u-boot a default boot loader with openwrt or it's just me ?
Jan 19 16:28:30 <rtz> Lalloso: did you try to flash the image?
Jan 19 16:29:07 <Lalloso> i'm trying
Jan 19 16:35:12 <Lalloso> jffs2 does not work with an mtblock2 which contains other things besides root filesystem
Jan 19 16:36:30 <Lalloso> is there a way to specify a subsegment of mtdblock2
Jan 19 16:37:14 <rtz> Lalloso: it does work
Jan 19 16:37:26 <rtz> or wait
Jan 19 16:37:34 <rtz> Lalloso: what's in mtdblock2?
Jan 19 16:38:18 <Lalloso> rootfs, kernel,data,environment
Jan 19 16:38:24 <Lalloso> environment are the uboot variables
Jan 19 16:38:41 <Lalloso> kernel is a kernel not loaded into ram but used just for a CRC check at boot
Jan 19 16:39:39 <rtz> Lalloso: I admit, I don't have a very good idea how uboot loads a kernel
Jan 19 16:40:17 <Lalloso> okay
Jan 19 16:40:18 <Lalloso> np
Jan 19 16:40:20 <rtz> Lalloso: but usually, the jff2 partition starts directly after data and goes to the end of the partition
Jan 19 16:40:20 <Lalloso> thx for your hints
Jan 19 16:40:34 <Lalloso> what's in data usually?
Jan 19 16:40:57 <rtz> the partition table should be somewhere in the platform setup code of the kernel, not sure if the uboot table matters at all
Jan 19 16:41:11 <rtz> not sure
Jan 19 16:41:15 <rtz> how big is it?
Jan 19 16:41:29 <Lalloso> i don't know but not too big
Jan 19 16:41:38 <rtz> the jffs2 partition should be called rootfs_data
Jan 19 16:42:27 <Lalloso> mmm okay we'll see
Jan 19 16:42:30 <rtz> Lalloso: if it's only a few kb, then probably config data or something
Jan 19 16:42:37 <rtz> like nvram
Jan 19 16:46:18 <rtz> Lalloso: do you have a link to the partition table setup code handy?
Jan 19 16:49:16 <Lalloso> no
Jan 19 16:49:31 <Lalloso> but squashfs is always ro right?
Jan 19 16:49:36 <rtz> yes
Jan 19 16:49:46 <Lalloso> so i need jffs2
Jan 19 16:50:03 <rtz> the squashfs image uses a jffs2 overaly
Jan 19 16:50:24 <rtz> and I strongly suggest to look at this code, because that's where the problem most likely is
Jan 19 16:52:42 <Lalloso> UnionFS
Jan 19 16:53:20 <rtz> Lalloso: openwrt uses mini_fo
Jan 19 16:54:15 <Lalloso> thx i'll have to look deeper into this tomorrow
Jan 19 16:54:18 <Lalloso> i go
Jan 19 18:23:09 <CIA-88> nbd * r19229 /trunk/package/hostapd/Makefile: hostapd: remove all object files on config changes
Jan 19 18:28:00 <CIA-88> juhosg * r19230 /trunk/target/linux/ar71xx/image/Makefile: ar71xx: fix image generation for TL-WR741ND/TL-WR841ND-v5
Jan 19 18:38:59 <thepeople> notify list
Jan 19 18:39:04 <thepeople> builder: notify list
Jan 19 18:39:05 <builder> The following events are being notified: []
Jan 19 18:40:32 <thepeople> builder: notify on
Jan 19 18:40:32 <builder> The following events are being notified: ['started', 'finished']
Jan 19 18:41:41 <thepeople> builder: status brcm-2.4
Jan 19 18:41:41 <builder> no such builder 'brcm-2.4'
Jan 19 18:41:56 <Bartman007> builder: status brcm-2.4-trunk
Jan 19 18:41:56 <builder> no such builder 'brcm-2.4-trunk'
Jan 19 18:42:11 <thepeople> fail :-P
Jan 19 18:42:39 <rtz> builder: help
Jan 19 18:42:39 <Bartman007> oh right, you have it named funky.
Jan 19 18:42:39 <builder> Get help on what? (try 'help <foo>', or 'commands' for a command list)
Jan 19 18:42:43 <Bartman007> builder: status brcm2.4-trunk
Jan 19 18:42:43 <builder> brcm2.4-trunk: idle, last build 33h18m06s ago: build successful
Jan 19 18:43:10 <rtz> builder: help commands
Jan 19 18:43:10 <builder> Usage: commands - List available commands
Jan 19 18:43:23 <thepeople> build status all
Jan 19 18:43:28 <thepeople> builder: status all
Jan 19 18:43:33 <Bartman007> haha.
Jan 19 18:43:33 <thepeople> LOL
Jan 19 18:43:33 <rtz> builder: commands
Jan 19 18:43:34 <builder> buildbot commands: commands, dance, destroy, excited, force, hello, help, join, last, leave, list, notify, source, status, stop, version, watch
Jan 19 18:43:42 <Bartman007> builder: dance
Jan 19 18:43:43 <builder> 0-<
Jan 19 18:43:45 <builder> 0-/
Jan 19 18:43:46 <builder> 0-\
Jan 19 18:44:06 <rtz> builder: excited
Jan 19 18:44:06 <thepeople> builder: hello
Jan 19 18:44:06 <builder> What you say!
Jan 19 18:44:06 <builder> yes?
Jan 19 18:44:14 <rtz> ?!?
Jan 19 18:44:24 <rtz> builder: help excited
Jan 19 18:44:24 <builder> No usage info for 'excited'
Jan 19 18:44:34 <rtz> builder: help hello
Jan 19 18:44:34 <builder> No usage info for 'hello'
Jan 19 18:44:52 <rtz> builder: help destroy
Jan 19 18:44:52 <builder> No usage info for 'destroy'
Jan 19 18:44:58 <rtz> bahhh
Jan 19 18:45:32 <rtz> builder: status
Jan 19 18:45:41 <rtz> :/
Jan 19 18:45:50 <cshore> builder: help
Jan 19 18:45:50 <builder> Get help on what? (try 'help <foo>', or 'commands' for a command list)
Jan 19 18:45:56 <cshore> builder: commands
Jan 19 18:45:56 <builder> buildbot commands: commands, dance, destroy, excited, force, hello, help, join, last, leave, list, notify, source, status, stop, version, watch
Jan 19 18:46:12 <cshore> builder: help status
Jan 19 18:46:12 <builder> Usage: status [<which>] - List status of a builder (or all builders)
Jan 19 18:46:36 <nbd> builder: list
Jan 19 18:46:37 <builder> try 'list builders'
Jan 19 18:46:41 <nbd> builder: list builders
Jan 19 18:46:41 <builder> Configured builders: amcc-ppc40x-trunk amcc-trunk ar7-trunk ar71xx-trunk atheros-trunk au1000-trunk avr-trunk brcm2.4-trunk brcm47xx-trunk brcm63xx-trunk cobalt-trunk etrax-trunk gemini-trunk ifxmips-trunk infineon-trunk iop32x-trunk ixp4xx-trunk octeon-trunk orion-trunk ps3-trunk rb532-trunk rdc321x-trunk s3c24xx-trunk uml-trunk x86-trunk
Jan 19 18:47:04 <cshore> builder: status brcm63xx-trunk
Jan 19 18:47:04 <builder> brcm63xx-trunk: idle, last build 4h47m30s ago: exception failed slave lost compile_15
Jan 19 18:48:00 <Bartman007> that slave was probably lost due to the blackout this morning.
Jan 19 18:48:16 <cshore> ah, fun stuff
Jan 19 18:48:37 <cshore> builder: status x86-trunk
Jan 19 18:48:37 <builder> x86-trunk: idle, last build 41h33m20s ago: build successful
Jan 19 18:50:26 <rtz> builder: ifxmips-trunk
Jan 19 18:50:36 <rtz> builder: status ifxmips-trunk
Jan 19 18:50:36 <builder> ifxmips-trunk: idle, last build 9h07m23s ago: build successful
Jan 19 18:51:13 <rtz> builder: destroy
Jan 19 18:51:13 * builder readies phasers
Jan 19 18:51:40 <rtz> builder: version
Jan 19 18:51:40 <builder> buildbot-0.7.11p3 at your service
Jan 19 18:51:46 <cshore> I see that someone was having fun
Jan 19 18:51:56 <rtz> who the heck wrote this thing?!?
Jan 19 18:52:08 <rtz> builder: destroy cshore
Jan 19 18:52:08 * builder readies phasers
Jan 19 18:52:11 <rtz> :)
Jan 19 18:52:18 <cshore> heh
Jan 19 18:52:34 <rtz> this could have been way funnier
Jan 19 18:52:39 <Bartman007> djmitche wrote it. I guess he was having fun.
Jan 19 18:52:58 <glp> as fun as elisa
Jan 19 18:53:14 <rtz> elisa?
Jan 19 18:53:47 <rtz> builder: watch
Jan 19 18:53:47 <builder> try 'watch <builder>'
Jan 19 18:53:58 <glp> the psych thingie hidden in some versions of emacs
Jan 19 18:54:07 <rtz> builder: help watch
Jan 19 18:54:07 <builder> Usage: watch <which> - announce the completion of an active build
Jan 19 18:56:33 <glp> http://www-ai.ijs.si/eliza/eliza.html
Jan 19 18:56:52 <rtz> thanks
Jan 19 18:57:08 <Bartman007> glp: I preferred the AI that tried to emulate a schizophrenic personality.
Jan 19 18:59:33 <glp> Bartman007: also a good one
Jan 19 20:11:29 <thepeople> builder: notify list
Jan 19 20:11:29 <builder> The following events are being notified: ['exception', 'successToFailure', 'failureToSuccess']
Jan 19 20:12:39 <[Fate]> nbd: ping
Jan 19 20:18:38 <nbd> [Fate]: pong
Jan 19 20:19:20 <[Fate]> nbd: can you give me a brief summary of what 065-rootfs_split.patch is used for?
Jan 19 20:20:22 <[Fate]> I can't trace back the original version / commit commentary in the svn log
Jan 19 20:20:42 <[Fate]> and it's causing me trouble in conjunction with sw-raid
Jan 19 20:21:02 <rtz> [Fate]: it dynamically creates the rootfs_data partition for jffs2
Jan 19 20:22:46 <nbd> trouble with sw-raid? are you using block2mtd on sw-raid?
Jan 19 20:25:32 <[Fate]> no, I run a sw-raid on some hard disks. normally the kernel in init/do_mounts_md.c:md_run_setup() creates "/dev/md0" (apparantly on the root device) and uses it to trigger raid autodetection via an ioctl in init/do_mounts_md.c:autodetect_raid() later
Jan 19 20:26:16 <[Fate]> this worked in r17695. in r17900 (and possibly already since r17803, the upgrade to 2.6.30) autodetect worked, but mounting rootfs didn't. juhosg fixed this in r18007
Jan 19 20:26:43 <[Fate]> but since then raid autodetection doesn't work any longer. the create_dev() for "/dev/md0" returns with -ENOENT
Jan 19 20:28:07 <[Fate]> I can use mdadm to assemble the array later without problems, mdadm can create /dev/md0 just fine, but I'm stuck as to why the kernel-level autodetect suddenly fails
Jan 19 20:28:43 <[Fate]> I differed 065-rootfs_split.patch between r17695 and trunk but couldn't find anything obvious :(
Jan 19 20:28:46 <[Fate]> *diffed
Jan 19 20:33:31 <[Fate]> in the patch, I notice that "index" is no longer passed to split_rootfs_data(), but I guess that's by intent
Jan 19 20:34:57 <rtz> [Fate]: are you sure it's that patch?
Jan 19 20:35:41 <[Fate]> not yet, but it's about the only relevant change I could find in the logs between r17695 and r18007
Jan 19 20:41:36 <nbd> i don't consider the rootfs split patch 'relevant' in this case
Jan 19 20:41:43 <nbd> i don't see any connection to mtd
Jan 19 20:41:49 <nbd> erm, to md
Jan 19 20:41:50 <nbd> ;)
Jan 19 20:41:57 <nbd> except for the name similarity ;)
Jan 19 20:42:10 <[Fate]> but isn't the patch responsible for setting up "the root partition"?
Jan 19 20:42:26 <nbd> only if it finds one
Jan 19 20:43:44 <nbd> if you don't have an mtd partition called 'rootfs', it shouldn't do anything at all
Jan 19 20:45:28 <[Fate]> I have (it's x86, grub boots openwrt from a compactflash medium)
Jan 19 20:46:00 <[Fate]> but let me double check when rootfs mounting actually happens
Jan 19 20:46:52 <nbd> ah, ok. so it currently tries to boot from the block2mtd device, but you want it to boot from the software raid?
Jan 19 20:48:09 <[Fate]> no. it boots from block2mtd just fine. but kernel-level autodetection of the sw-raid (which is mounted later for storage) worked in r17695-r18006
Jan 19 20:53:56 <[Fate]> and seeing that the kernel in init/do_mounts_md.c:md_run_setup() tries to create /dev/md0 so it can ioctl() on it, and this create_dev() call fails with ENOENT, there seems to be something wrong with the rootfs
Jan 19 20:54:16 <nbd> odd
Jan 19 20:57:08 <[Fate]> see here http://pastebin.ca/1757973
Jan 19 20:59:33 <rtz> missing rootfs?
Jan 19 20:59:48 <rtz> I'm not sure when you can write to it
Jan 19 21:00:15 <[Fate]> that's the problem. how can I do a kernel-level "ls"? :)
Jan 19 21:01:54 <rtz> no idea
Jan 19 21:02:05 <[Fate]> maybe the timepoint when it gets writeable changed between 2.6.28 and 2.6.31
Jan 19 21:02:08 <rtz> [Fate]: did you try to use the old version of this patch?
Jan 19 21:02:48 <[Fate]> gonna try that next
Jan 19 21:03:05 <[Fate]> I suffer from the dell latitude "where's my performance" problem :/
Jan 19 21:03:47 <rtz> [Fate]: let met tell you, the inspiron has the same problem :/
Jan 19 21:04:09 <[Fate]> I have to look into delivering the build work to a different machine
Jan 19 21:05:48 <rtz> I don't have a different machine
Jan 19 21:05:50 <rtz> :(
Jan 19 21:08:13 <[Fate]> old version doesn't apply cleanly of course, let's see
Jan 19 21:28:24 <CIA-88> jow * r19231 /trunk/package/mtd/ (Makefile src/fis.c): [package] mtd: treat failure to open FIS partition as fatal when a fis_layout is given, aborts mtd write if reformat is needed and FIS table not available
Jan 19 21:41:07 <[Fate]> mh shouldn't I have a ~/.ccache directory if I enable the "use ccache" option in "make menuconfig"?
Jan 19 22:30:03 <rtz> [florian]: ping
Jan 19 22:30:29 <xMff> you should try it earlier, rtz
Jan 19 22:30:59 <xMff> or via email :)
Jan 19 22:31:20 <rtz> during dezember, I didn't have any luck before midnight :/
Jan 19 22:32:06 <cshore> xMff: I found the bug in the firewall
Jan 19 22:32:23 <xMff> cshore: explain
Jan 19 22:33:58 <cshore> xMff: it seems that the addif function was check the UCI up status of an interface, but it the config_load network it was basing it was from elsewhere and too old to pick up the hotplugged values.  I corrected it by doing a config_load network in the addif function
Jan 19 22:34:30 <xMff> hmm
Jan 19 22:35:39 <cshore> there's a config_load network in the part near the call to add if (in fw_init), but it is in a subshell
Jan 19 22:35:49 <cshore> so the values are lost
Jan 19 22:35:50 <xMff> hmm
Jan 19 22:36:07 <xMff> maybe this bug was introduced while the code refactoring for hush compatibility
Jan 19 22:36:20 <xMff> s/while/during/
Jan 19 22:36:25 <cshore> possibily
Jan 19 22:36:39 <xMff> can you check svn blame ?
Jan 19 22:36:44 <xMff> :)
Jan 19 22:36:47 <cshore> how does that work?
Jan 19 22:36:54 <xMff> svn blame blah/file
Jan 19 22:37:07 <xMff> shows last changed rev + author for each line
Jan 19 22:38:20 <cshore> nbd in 18716
Jan 19 22:39:31 <xMff> hm yeah, hush compat
Jan 19 22:41:31 <xMff> maybe we should add a force flag for addif
Jan 19 22:41:43 <cshore> sorry fw_addif
Jan 19 22:41:53 <xMff> adding config_load back in would kinda reverse what nbd intended to prevent
Jan 19 22:42:10 <cshore> what was that?
Jan 19 22:42:17 <xMff> recursinve includes
Jan 19 22:42:22 <cshore> ah
Jan 19 22:43:59 <xMff> ne even better
Jan 19 22:44:11 <cshore> ?
Jan 19 22:44:17 <xMff> fw_addif is a wrap around fw_event with an additional check for .up
Jan 19 22:44:26 <cshore> yes
Jan 19 22:44:44 <xMff> what about just calling  fw_event ifup "$x"  instead of fw_addif
Jan 19 22:44:47 <cshore> it's the up check that failes
Jan 19 22:45:34 <cshore> what happens if the iface is down?
Jan 19 22:45:42 <xMff> good question
Jan 19 22:45:46 <xMff> nothing I assume
Jan 19 22:46:08 <xMff> the uci firewall never uses ip addresses from interfaces, so I see nothing that would break
Jan 19 22:46:11 <cshore> does iptables throws errors in that case?
Jan 19 22:46:32 <cshore> if the interface doesn't exist yet, for example
Jan 19 22:46:48 <xMff> hm. point
Jan 19 22:47:37 <cshore> can we check if the interface is up with ifconfig instead?
Jan 19 22:48:18 <cshore> I assume the /sys/ stuff might not work with 2.4
Jan 19 22:48:52 <cshore> or use uci without the wrapper layer?
Jan 19 22:49:42 <xMff> http://openwrt.pastebin.com/m7ea8aeb1
Jan 19 22:49:59 <xMff> forgot something
Jan 19 22:50:38 <xMff> http://openwrt.pastebin.com/m345bb1d8
Jan 19 22:51:36 <cshore> that makes sense to me...I'll try it
Jan 19 22:51:56 <cshore> basically move the up check into the subshell
Jan 19 22:52:04 <xMff> yes
Jan 19 22:53:24 <xMff> ugly as hell
Jan 19 22:53:28 <xMff> but if it works
Jan 19 22:56:09 <cshore> just a sec I'll got to my serial console and see that /etc/init.d/firewal restart does, and then a reboot
Jan 19 22:59:15 <cshore> it works
Jan 19 22:59:31 <xMff> ok
Jan 19 22:59:49 <xMff> so what was the issue again? Interface not addif'd on boot?
Jan 19 23:01:04 <cshore> well the interfaces were added before the firewall was started by /etc/init.d/firewall, and fw_init wasn't fw_addif'ing the interfaces because up was not set to up when the last config_load was done
Jan 19 23:01:12 <cshore> i.e. up was blank
Jan 19 23:01:50 <cshore> so no addif rules were getting added
Jan 19 23:02:13 <CIA-88> jow * r19232 /trunk/package/firewall/ (Makefile files/uci_firewall.sh): [package] firewall: fix a race condition preventing interfaces from being added to the firewall on boot
Jan 19 23:02:48 <xMff> thanks ;)
Jan 19 23:03:21 <cshore> np
Jan 19 23:03:45 <cshore> There's a ticket that might be because of this...just a sec
Jan 19 23:03:57 <xMff> the one with webif reachable on wan?
Jan 19 23:04:07 <cshore> yes
Jan 19 23:04:24 <xMff> #6505
Jan 19 23:04:29 <cshore> yes
Jan 19 23:05:20 <xMff> nuked.
Jan 20 01:45:46 <cshore> ping nbd
Jan 20 02:25:56 <CIA-88> nbd * r19233 /trunk/package/mac80211/patches/570-ath9k_bcnslot_leak.patch: ath9k: fix a beacon buffer leak on interface up/down
Jan 20 02:26:02 <CIA-88> nbd * r19234 /trunk/package/hostapd/ (5 files in 2 dirs): hostapd: upgrade to latest git version, add patches to fix multi-bss support with a single hostapd instance
Jan 20 02:26:06 <CIA-88> nbd * r19235 /trunk/package/ (hostapd/files/hostapd.sh mac80211/files/lib/wifi/mac80211.sh):
Jan 20 02:26:06 <CIA-88> mac80211: restructure /lib/wifi/mac80211.sh
Jan 20 02:26:06 <CIA-88> use the new multi-bss single instance hostapd mode
Jan 20 02:26:06 <CIA-88> move mac80211 specific bits out of /lib/wifi/hostapd.sh
Jan 20 02:26:08 <CIA-88> add a new option 'htmode' for switching between HT20 and HT40+,HT40-
Jan 20 02:26:16 <cshore> ping nbd
**** ENDING LOGGING AT Wed Jan 20 02:59:57 2010