**** BEGIN LOGGING AT Tue Jul 23 02:59:59 2013
Jul 23 03:00:05 <DonkeyHotei> anyone have an rt5350 device?
Jul 23 03:00:25 <Devastator> me
Jul 23 03:04:21 <DonkeyHotei> does wifi work on it?
Jul 23 03:04:34 <Devastator> yes
Jul 23 03:05:01 <Devastator> but I couldn't configure proper mac address to the interface
Jul 23 03:05:09 <DonkeyHotei> hmm
Jul 23 03:05:16 <DonkeyHotei> which device?
Jul 23 03:05:36 <Devastator> D-Link DIR-610 A1
Jul 23 03:06:43 <DonkeyHotei> i got this thing today: http://www.rakuten.com/pr/product.aspx?sku=245965249
Jul 23 03:07:24 <DonkeyHotei> i thought it would be largely the same as the tp-link device (ar71xx)
Jul 23 03:31:49 <builder> build #310 of uml is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/310
Jul 23 05:30:03 <russell--> is /etc/init.d/log stop not supposed to stop logread?
Jul 23 05:30:14 <russell--> because it doesn't seem to
Jul 23 05:32:43 <russell--> maybe the designers of procd should fill-in the wiki page that describes it?  http://wiki.openwrt.org/doc/techref/procd
Jul 23 07:40:39 <russell_> blogic: pinging as requested
Jul 23 07:41:21 <blogic> yes
Jul 23 07:41:26 <blogic> i am not at work yet ;)
Jul 23 07:41:33 <russell_> okay, np
Jul 23 07:41:35 <blogic> lets chat in 2-3 hours
Jul 23 07:41:36 <blogic> ok ?
Jul 23 07:41:47 <builder> build #280 of sibyte is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/280
Jul 23 07:41:58 * russell_ may be asleep then but we'll see
Jul 23 07:42:14 * russell_ is on US west coast time
Jul 23 07:42:33 <russell_> plus hacker-offset
Jul 23 08:11:55 <blogic> russell_: otherwise wehn you wake up
Jul 23 08:12:09 <blogic> i'll be awake for at least another 12-14 hours
Jul 23 08:15:42 <russell_> blogic: okay, thanks!
Jul 23 09:28:48 <acoul> looking for a way to tune a 16M RAM openwrt router to survive  a high network traffic
Jul 23 09:55:40 <builder> build #282 of xburst is complete: Failure [failed compile_4]  Build details are at http://buildbot.openwrt.org:8010/builders/xburst/builds/282
Jul 23 10:23:15 <Guest92905> juhosg r37514 trunk/include/image.mk * image: fix a typo in JFFS2OPTS to fix jffs2 rootfs generation
Jul 23 10:30:39 <blogic> russell_: ing
Jul 23 10:30:41 <blogic> *ping
Jul 23 10:31:51 <Guest92905> tripolar r37515 packages/net/ git/Makefile git/patches/100-convert_builtin.patch git/patches/200-disable_fasthash.patch * [packages] update git to 1.8.3.4 and refresh patches
Jul 23 10:36:07 <acoul> ping blogic
Jul 23 10:38:17 <blogic> acoul: hello
Jul 23 10:39:49 <acoul> about the 16M RAM atheros routers dying on high network bandwidth, have you been beaten by this at all?
Jul 23 10:40:02 <blogic> yes
Jul 23 10:40:06 <blogic> its the kernel bloat
Jul 23 10:40:12 <blogic> do oyu have a log of it dying ?
Jul 23 10:40:16 <blogic> its most likely a oom
Jul 23 10:41:32 <acoul> no clue on how to deal with it, though I have access to two of those routers with the issue right now
Jul 23 10:42:17 <blogic> can you get a log of the crash ?
Jul 23 10:42:46 <acoul> it's not a crash it's memory starvation
Jul 23 10:43:20 <blogic> yes
Jul 23 10:43:23 <blogic> its an oom
Jul 23 10:45:16 <acoul> I can recreate the problem with a high ping "ping -f -s 31000 ip-on-wireless-end" and watch the free mem going down instantly
Jul 23 11:01:21 <blogic> russell_: i just mailed you a test patch
Jul 23 11:01:37 <blogic> please add it to the procd folder and then rebuild and show me the log of the unit where it fails
Jul 23 11:03:57 <builder> build #329 of orion is complete: Failure [failed compile_8]  Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/329
Jul 23 12:24:38 <OpenWrt-Commits> blogic r37516 trunk/package/ system/ubox/Makefile system/procd/Makefile * update ubox and procd to latest git revision
Jul 23 13:08:52 <OpenWrt-Commits> blogic r37517 trunk/target/linux/ramips/base-files/etc/uci-defaults/02_network * ramips: fix HG255D VLAN initial detect issue
Jul 23 13:13:32 <OpenWrt-Commits> nbd r37518 trunk/include/kernel-defaults.mk * kernel: fix remaining initramfs related breakage
Jul 23 13:34:25 <OpenWrt-Commits> acinonyx r37519 packages/utils/rtl-sdr/Makefile * [packages] rtl-sdr: Update to latest revision
Jul 23 14:27:53 <Pteridium> KanjiMonster: i'm testing a Comtrend VR-3025un (http://wiki.openwrt.org/toh/comtrend/vr3025un) with latest trunk and almost all works fine. The problem is that i'm experiencing some data corruption in rootfs_data when i reboot the router once it is configured.
Jul 23 14:28:16 <Pteridium> If you are busy don't answer.
Jul 23 14:30:41 <KanjiMonster> Pteridium: try adding your board to etc/uci-defaults/09_fix_crc
Jul 23 14:31:11 <KanjiMonster> assuming you mean CFE claims crc errors and refuses to boot the image
Jul 23 14:31:35 <Pteridium> i've done it without success
Jul 23 14:31:40 <Pteridium> :(
Jul 23 14:31:59 <Pteridium> tried mtd fixtrx linux too
Jul 23 14:32:31 <KanjiMonster> what the actual error you get?
Jul 23 14:32:55 <Pteridium> http://pastebin.com/RpXSGig4
Jul 23 14:33:53 <Pteridium> the files changed with UCI or luci are corrupted after reboot
Jul 23 14:34:18 <Pteridium> the name and the content
Jul 23 14:34:51 <blogic> can you try to manually mount the overlay ?
Jul 23 14:34:53 <blogic> or
Jul 23 14:35:06 <blogic> are the files inside /overlay/etc/config/ also broken ?
Jul 23 14:36:07 <Pteridium> ok, i go to see /overlay/etc/config/. one moment, please.
Jul 23 14:36:28 <Pteridium> blogic: take in mind that surely is my fault
Jul 23 14:37:18 <blogic> i would say a bu but if you claim the fault fine with me ;)
Jul 23 14:38:04 <Pteridium> blogic: in /overlay/etc/config/ the files are fine.
Jul 23 14:38:18 <KanjiMonster> with all the procd-switch related breakage, it's currently the best time for blaming blogic ;)
Jul 23 14:38:52 <Pteridium> http://pastebin.com/dpmMPAaP
Jul 23 14:39:06 <Pteridium> :)
Jul 23 14:39:12 <Pteridium> how i can help?
Jul 23 14:41:20 <Pteridium> KanjiMonster: blogic had a lot of patience with me so i want to help him, not blame.
Jul 23 14:42:37 <Pteridium> and you too, of course
Jul 23 14:42:57 <KanjiMonster> I just wanted to troll a bit, too ;)
Jul 23 14:43:14 <Pteridium> xD
Jul 23 14:43:43 <blogic> KanjiMonster: http://linux-lantiq.org/troll.jpeg
Jul 23 14:43:48 <blogic> :-)
Jul 23 14:44:03 <blogic> Pteridium: call "mount" and paste the output
Jul 23 14:44:10 <blogic> and what kernel version is this ?
Jul 23 14:44:20 <blogic> and can oyu show me a full bootlog please ?
Jul 23 14:46:35 <Pteridium> blogig: the info you need. http://pastebin.com/f4Qbe0UR
Jul 23 14:47:18 <Pteridium> blogic: the info you need. http://pastebin.com/f4Qbe0UR*
Jul 23 14:51:29 <Pteridium> Do you think is a procd problem? i'm almost sure that the fault is mine. :-/
Jul 23 14:56:03 <Pteridium> one moment, i go to test r37519
Jul 23 14:56:07 <blogic> i dont see how it could be procd
Jul 23 15:26:22 <russell--> blogic: ping ... i am awake again ;-)
Jul 23 15:28:35 <russell--> i am just trying what i should have tried previously, which is to replicate the problem with a vanilla build, just to be sure it isn't one of my local files/* tweaks (seems unlikely, but ...)
Jul 23 15:32:45 <Pteridium> blogic, KanjiMonster: here is a complete bootlog: http://pastebin.com/Zn6A9Ube, and this called my attention: http://pastebin.com/QN8YmjVV  "xref (0 dead, 2 orphan)"
Jul 23 15:33:21 <Pteridium> http://pastebin.com/Zn6A9Ube *
Jul 23 15:34:26 <russell--> blogic: same thing with none of my files/*, fails to start remote syslog on boot, works after restart
Jul 23 15:37:57 <blogic> mount_root: No jffs2 marker was found
Jul 23 15:38:03 <blogic> what image are you flashing ?
Jul 23 15:38:10 <blogic> there is no deadc0de marker
Jul 23 15:38:53 <Pteridium> sorry, don't understand, deadcode?
Jul 23 15:39:19 <Pteridium> still newbie :(
Jul 23 15:40:34 <blogic> normally an image has kernel + squashfs + 0xdeadc0de
Jul 23 15:40:53 <blogic> this tells mount_root -> "there is an uninitialized jffs2 here"
Jul 23 15:40:58 <blogic> and that deadcode is missing
Jul 23 15:41:06 <blogic> did you add this as a new board ?
Jul 23 15:41:11 <blogic> or is it in owrt already
Jul 23 15:41:22 <Pteridium> no, new board
Jul 23 15:41:29 <blogic> ok
Jul 23 15:41:43 <Pteridium> then i missed something
Jul 23 15:41:43 <blogic> i think maybe you generate the image incorrectly
Jul 23 15:42:00 <blogic> show me you patch to target/linux/bcm63sxx/image/Makefile please
Jul 23 15:42:32 <Pteridium> ok, one moment...
Jul 23 15:43:19 <blogic> thx !
Jul 23 15:45:42 <Pteridium> blogic: https://github.com/Pteridium/openwrt/commit/e11596088fc53f397314877c7e71187772cc12f4  still i haven't the patch for the latest trunk rev
Jul 23 15:47:28 <Pteridium> maybe CFEFIXUP instead CFE?
Jul 23 15:47:50 <russell--> blogic: replicated with a generic .config as well
Jul 23 15:52:16 <blogic> KanjiMonster: ping
Jul 23 15:52:31 <blogic> KanjiMonster: Pteridium's image is missing the 0xdeadc0de tag
Jul 23 15:52:35 <russell--> oh, just spotted the patch in the scrollback
Jul 23 16:04:08 <Pteridium> blogic: could be used this comment as workaround? https://dev.openwrt.org/ticket/9143#comment:8
Jul 23 16:07:01 <DonkeyHotei> ( echo -n -e "# Airstation FirmWare\nrun u_fw\nreset\n\n" | dd bs=512 count=1 conv=sync; dd if=/home/danielg4/openwrt-rt5350/bin/ramips/openwrt-ramips-rt305x-whr-g300n-squashfs-sysupgrade.bin; ) > /home/danielg4/openwrt-rt5350/build_dir/target-mipsel_dsp_uClibc-0.9.33.2/linux-ramips_rt305x/whr-g300n-tftp.tmp
Jul 23 16:07:01 <DonkeyHotei> 0+1 records in
Jul 23 16:07:02 <DonkeyHotei> 1+0 records out
Jul 23 16:07:02 <DonkeyHotei> 512 bytes (512 B) copied, 3.101e-05 s, 16.5 MB/s
Jul 23 16:07:02 <DonkeyHotei> dd: opening `/home/danielg4/openwrt-rt5350/bin/ramips/openwrt-ramips-rt305x-whr-g300n-squashfs-sysupgrade.bin': No such file or directory
Jul 23 16:07:47 <DonkeyHotei> i'm sure i'm missing something obvious
Jul 23 16:08:23 <blogic> you can use jffs2mark for that
Jul 23 16:08:30 <blogic> its a tool on the rootfs
Jul 23 16:10:07 <Pteridium> ok: jffs2mark: /dev/mtdblock3 - marking with deadc0de
Jul 23 16:11:03 <blogic> then reboot
Jul 23 16:11:06 <blogic> try again
Jul 23 16:11:19 <blogic> at least the error should be gone now
Jul 23 16:11:58 <Pteridium> before: mount_root: No jffs2 marker was found, after: mount_root: jffs2 is not ready - marker found
Jul 23 16:12:19 <Pteridium> A lot of thanks blogic!
Jul 23 16:14:39 <blogic> Pteridium: well
Jul 23 16:14:52 <blogic> now edit some files and see if they are intact after a reboot
Jul 23 16:15:28 <Pteridium> yes, i go to make tests
Jul 23 16:15:54 <Pteridium> later i'll tell you the results
Jul 23 16:16:25 <Pteridium> thanks to KanjiMonster an you for your time.
Jul 23 16:16:34 <Pteridium> and*
Jul 23 16:24:27 <russell--> blogic: your debugging printf's never fire ... at least they don't show up on the serial console during boot
Jul 23 16:28:19 <russell__> blogic: your debugging printf's never fire ... at least they don't show up on the serial console during boot
Jul 23 16:31:37 <blogic> russell__: hmmm
Jul 23 16:31:53 <blogic> russell__: you copied it to package/system/procd/patches/
Jul 23 16:31:55 <blogic> ?
Jul 23 16:32:03 <blogic> russell__: and ....
Jul 23 16:32:10 <blogic> 1) boot unit
Jul 23 16:32:21 <blogic> 2) call /etc/init.d/log restart
Jul 23 16:32:26 <blogic> 3) logger test 1
Jul 23 16:32:33 <blogic> 4) /etc/network/restart
Jul 23 16:32:38 <blogic> 5) logger test 2
Jul 23 16:32:51 <blogic> and see if test 2 also shows up in the remote syslog please
Jul 23 16:32:52 <russell__> i had to rework your patch a little, since it was in git format
Jul 23 16:32:58 <russell__> but it applied
Jul 23 16:33:12 * russell__ trying restart (recall that works)
Jul 23 16:33:31 <blogic> i want to know if it works afer a network restart
Jul 23 16:33:52 <blogic> and if that works then move /etc/init.d/log to a later time
Jul 23 16:34:01 <blogic> as in edit START=  to 80 or so
Jul 23 16:34:05 <blogic> see if that works
Jul 23 16:34:17 <russell__> does procd have a stderr in the context it is running?
Jul 23 16:35:40 <russell__> oh, wait, /me looking in the right place now
Jul 23 16:35:48 <russell__> hang on
Jul 23 16:37:46 <russell__> i'm seeing your debugging messages on the remote syslog
Jul 23 16:38:05 <russell__> but split across lines in a highly unreadable way ;-)
Jul 23 16:39:10 <blogic> lol
Jul 23 16:39:11 <blogic> ok
Jul 23 16:40:26 <russell__> this is just from bootup: http://pastebin.com/bC5UMqjw
Jul 23 16:40:33 <russell__> no "logger" testing
Jul 23 16:42:22 <russell__> "logger test 1" results in nothing in remote syslog
Jul 23 16:47:00 <russell__>  /etc/init.d/log restart gives this on remote syslog: http://pastebin.com/Cr0CZWn8
Jul 23 16:48:11 <blogic> ok
Jul 23 16:48:22 <blogic> try moving it to after the firewall start please
Jul 23 16:48:43 <blogic> hand on let me boot a unit to test it here and tell you how the patch looks
Jul 23 16:49:41 <blogic> hmmm
Jul 23 16:49:49 <blogic> its behind firewall already
Jul 23 16:49:57 <blogic> change START=21
Jul 23 16:50:08 <blogic> and use START=99 please
Jul 23 16:50:11 <blogic> and see if that works
Jul 23 16:50:31 <builder> build #252 of iop32x is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/iop32x/builds/252
Jul 23 16:50:55 * russell__ used 95
Jul 23 16:51:53 <blogic> and that also breaks ?
Jul 23 16:52:18 <russell__> yes
Jul 23 16:52:37 <russell__> logger test 3 doesn't show up or generate debugging messages
Jul 23 16:52:53 <blogic> ok
Jul 23 16:52:56 <blogic> ermmm
Jul 23 16:53:09 <blogic> no i am puzzled
Jul 23 16:53:14 * russell__ too
Jul 23 16:53:15 <blogic> *now
Jul 23 16:53:28 <blogic> can you install tcpdump
Jul 23 16:53:38 <blogic> boot the image without any changes applied
Jul 23 16:53:40 <russell__> i can run it upstream, and nothing shows up
Jul 23 16:53:48 <blogic> on the device i mean
Jul 23 16:54:05 <blogic> build an unmdified image and boot it on the unit that fails
Jul 23 16:54:26 <russell__> you mean without your patch?
Jul 23 16:54:27 <blogic> and then run tcpdump in it and run "logger foo" and send me the pcap file ?
Jul 23 16:54:30 <blogic> yes
Jul 23 16:54:31 <blogic> without
Jul 23 16:54:39 <russell__> tcpdump on what interface?
Jul 23 16:54:42 <russell__> wan?
Jul 23 16:54:46 <blogic> the one you log to
Jul 23 16:54:51 <russell__> okay
Jul 23 16:54:52 <blogic> if you log over wan then on wan
Jul 23 16:54:58 <blogic> and you use dhcp on wan ?
Jul 23 16:55:01 <russell__> yes
Jul 23 16:55:08 <blogic> try also with a static ip
Jul 23 16:55:13 <blogic> see if that works
Jul 23 16:55:29 <blogic> maybe we can narrow the cause down this way
Jul 23 16:56:47 <russell__> this device has lots of flash so reflashing+rebuilding jffs takes about 5 minutes ;-)
Jul 23 16:56:56 <blogic> great ! :)
Jul 23 16:57:06 <blogic> i am here for a few more hours
Jul 23 16:57:07 <blogic> ;)
Jul 23 16:57:15 * russell__ has an image with tcpdump in it already built
Jul 23 17:01:43 <russell__> flashing
Jul 23 17:01:57 <russell__> btw, do you see me ping when my nick is russell-- ?
Jul 23 17:03:07 <blogic> ping where ?
Jul 23 17:03:15 <russell__> here in this channel
Jul 23 17:03:31 <blogic> yes
Jul 23 17:03:41 <blogic> i think so
Jul 23 17:03:47 <blogic> i was offline for a few days
Jul 23 17:03:57 <russell__> okay, /me switches back
Jul 23 17:04:00 <blogic> my first day back online today
Jul 23 17:04:15 <russell--> ah, that explains ... vacation++
Jul 23 17:04:42 <blogic> russell--: well
Jul 23 17:04:46 <blogic> works does it not
Jul 23 17:05:44 <blogic> i cant see you say anything
Jul 23 17:05:49 <blogic> say something :)
Jul 23 17:10:46 <russell--> sorry testing
Jul 23 17:11:00 <russell--> you see me?
Jul 23 17:11:14 <russell--> blogic: hello
Jul 23 17:11:33 <russell__> 10:11  russell--: blogic: hell
Jul 23 17:11:35 <russell__> o
Jul 23 17:11:37 <russell__> lol
Jul 23 17:12:31 <russell__> did you see me saying "sorry testing"?
Jul 23 17:12:55 <blogic> 19:10 < russell--> sorry testing
Jul 23 17:12:55 <blogic> 19:11 < russell--> you see me?
Jul 23 17:12:55 <blogic> 19:11 < russell--> blogic: hello
Jul 23 17:12:59 <blogic> i can see you
Jul 23 17:13:02 <blogic> with the other link
Jul 23 17:13:05 * blogic is confused
Jul 23 17:13:07 <blogic> anyhow
Jul 23 17:14:12 <russell__> okay, so i rebooted, ran tcpdump -i eth1 -vv udp port 514, then ran logger test 1, nothing
Jul 23 17:14:20 <blogic> oh
Jul 23 17:14:23 <blogic> ok
Jul 23 17:14:27 <blogic> i never tested on wan
Jul 23 17:14:28 <blogic> only lan
Jul 23 17:14:33 <blogic> i will test wan sid enow ;)
Jul 23 17:14:41 <blogic> thanks for helping narrow it doen
Jul 23 17:14:44 <blogic> thanks for helping narrow it down
Jul 23 17:14:54 <russell__> that's with dhcp
Jul 23 17:14:55 <blogic> lets see what i find ;)
Jul 23 17:14:57 <blogic> ok
Jul 23 17:15:06 <blogic> try static then before i do anything
Jul 23 17:15:08 * russell__ has firewall turned off (as per norm)
Jul 23 17:15:12 <russell__> okay
Jul 23 17:17:49 <russell__> also, i notice that /etc/init.d/log stop doesn't actually stop logread
Jul 23 17:18:10 <blogic> ok
Jul 23 17:19:44 <russell__> static network config results in no change
Jul 23 17:20:00 <russell__> == not working on boot
Jul 23 17:20:11 <blogic> ok
Jul 23 17:20:18 * blogic sets up a testbed
Jul 23 17:20:58 <russell__> works on restart, like dhcp
Jul 23 17:22:37 <russell__> the one difference i saw in the strace was in rt_N's in a rt_sigaction, but i don't know how to decode those
Jul 23 17:23:04 <russell__> it looked suspicious, anyway
Jul 23 17:23:59 <russell__> also note that it works on ubnt-airrouter, normally
Jul 23 17:24:24 <russell__> but not when i wrap logread in an strace
Jul 23 17:26:23 <russell__> that is, i editted /etc/init.d/log to insert "/usr/bin/strace -ff -s128 -o /tmp/strace-logread" in front of the "$PROG" in start_service_remote
Jul 23 17:34:25 <russell__> that is, ubnt-airrouter works on boot without the strace, but doesn't work on boot with the strace.  both work on /etc/init.d/log restart
Jul 23 17:47:09 <blogic> The_Lizard: ping
Jul 23 17:47:19 <blogic> i think i know what might be your problem
Jul 23 17:47:24 <blogic> show me a full bootlog please
Jul 23 18:12:20 <builder> build #255 of ep93xx is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/ep93xx/builds/255
Jul 23 19:03:50 <KanjiMonster> blogic: hm, I'll take a look at it
Jul 23 19:06:12 <blogic> KanjiMonster: thanks
Jul 23 19:06:25 <blogic> if this is the cause for the breakage we still have a bug ;)
Jul 23 19:06:39 <blogic> as it should still work even without the deadc0de marker
Jul 23 19:07:02 <KanjiMonster> there's no special deadc0de code in bcm63xx
Jul 23 19:07:11 <blogic> its in the generic patches
Jul 23 19:07:16 <KanjiMonster> yes
Jul 23 19:07:28 <blogic> the prepare_generic_squashfs function does it for you
Jul 23 19:07:37 <blogic> i saw is called somewhere unrelated in the code though
Jul 23 19:07:39 <blogic> not sure
Jul 23 19:08:00 <blogic> Pteridium never reported if the bug went away after that
Jul 23 19:12:42 <KanjiMonster> blogic: what exactly is the issue?
Jul 23 19:14:01 <blogic> his overlay is corrupted
Jul 23 19:14:09 <blogic>  /overlay has the files intact
Jul 23 19:14:16 <blogic>  /etc/config/ has broken files
Jul 23 19:15:08 <KanjiMonster> you said something about deadc0de
Jul 23 19:15:55 <blogic> well, while looking at it we realized that the deadcode marker is misisng
Jul 23 19:18:26 <KanjiMonster> the deadc0de marker gets overwritten when jffs2 formats the flash
Jul 23 19:22:53 <blogic> yes
Jul 23 19:23:01 <blogic> but its not there on firstboot for him somehow
Jul 23 19:23:29 <KanjiMonster> all the images I checked have it
Jul 23 19:23:35 <blogic> weird
Jul 23 19:23:41 <blogic> then something else is wrong
Jul 23 19:31:00 <builder> build #253 of mcs814x is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/mcs814x/builds/253
Jul 23 19:55:01 <OpenWrt-Commits> jogo r37520 trunk/package/kernel/linux/modules/netfilter.mk * kernel: ebtables depends on bridge
Jul 23 20:11:28 <Pteridium> blogic: no luck. Also tried setting CFEFIXUP instead CFE but still the same problem. Could be the flash chip damaged and how to test it?
Jul 23 20:11:55 <Pteridium> I'm feeling useless... :(
Jul 23 20:12:54 <KanjiMonster> Pteridium: CFEFIXUP just writes a slightly different cfe header that will overwrite CFE's boardid with a different one, and that's all
Jul 23 20:13:08 <Pteridium> ah
Jul 23 20:14:45 <Pteridium> tomorrow i will try more things; today i'm upset of this router.
Jul 23 20:52:38 <builder> build #239 of mpc52xx is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/mpc52xx/builds/239
Jul 23 21:13:41 <The_Lizard> blogic: im here now...
Jul 23 21:13:46 <blogic> hi
Jul 23 21:13:49 <blogic> bootlog ?
Jul 23 21:13:50 <blogic> :)
Jul 23 21:14:02 <blogic> i am going ot bed in 15 minutes
Jul 23 21:14:07 <blogic> so hurry or ping me tomorrow
Jul 23 21:23:37 <The_Lizard> There is a bootlog at the wiki
Jul 23 21:23:42 <The_Lizard> but it isn't the latest anymore
Jul 23 21:23:45 <The_Lizard> will update it now
Jul 23 21:23:55 <blogic> link ?
Jul 23 21:24:37 <The_Lizard> http://wiki.openwrt.org/toh/arcadyan/vgv7519
Jul 23 21:25:15 <The_Lizard> what do you think is wrong?
Jul 23 21:28:47 <blogic> hmmm
Jul 23 21:28:49 <blogic> not
Jul 23 21:28:50 <blogic> [ 0.192000] phy-xrx200 gphy-xrx200.5: requesting lantiq/vr9_phy11g_a1x.bin
Jul 23 21:28:57 <blogic> this is for vr9 v1.1
Jul 23 21:29:02 <blogic> and the board has 1.1
Jul 23 21:29:12 <blogic> i thought maybe oyu loaded the wrong firmware
Jul 23 21:29:20 <The_Lizard> blogic: just opdated
Jul 23 21:29:58 <The_Lizard> It was incorrect earlier (as the one from the easy80920, but I took the one as specified in daniels u-boot tree
Jul 23 21:34:30 <The_Lizard> Should I do some basic configuration before it should work?
Jul 23 21:34:49 <The_Lizard> as in setting the mac addresses etc? they are now around 00:11:22:33:44:55
Jul 23 21:35:45 <The_Lizard> or could it be some default firewall behaviour?
**** ENDING LOGGING AT Wed Jul 24 02:59:59 2013