**** BEGIN LOGGING AT Wed Jun 05 02:59:58 2013
Jun 05 05:21:05 <Kaloz> DonkeyHotei: luka doesn't have the hw anymore, so we have no way to test (and it had a lame subtarget as well)
Jun 05 06:00:05 <cyrusff> soma: ipv6-support is only a meta-package these days. you are affected by this if you do anything ipv6-related in connection with netifd / /etc/config/network
Jun 05 06:06:08 <OpenWrt-Commits> kaloz r36850 trunk/target/linux/orion/image/generic.mk * [orion]: don't copy the zImages to the bin dir, factory u-boots can't use them
Jun 05 06:18:34 <OpenWrt-Commits> kaloz r36851 trunk/target/linux/orion/image/generic.mk * [orion]: only copy uImages to the bin dir on ramdisk builds
Jun 05 06:48:02 <OpenWrt-Commits> kaloz r36852 trunk/target/linux/orion/image/generic.mk * [orion]: there's no reason to have these generic files in the bin dir either
Jun 05 09:58:18 <kaspar> hey eveyone, how do I use UCI lists as options for netifd protocols?
Jun 05 09:58:38 <kaspar> e.g., proto_config_add_string stays empty for lists...
Jun 05 10:14:12 <OpenWrt-Commits> jow r36853 branches/attitude_adjustment/ include/netfilter.mk package/iptables/Makefile * AA: iptables: backport r35898 (#13649)
Jun 05 11:22:38 <stintel> hi cyrusff, just updated my home router to BB r36822. since then, devices behind it lost ipv6 connectivity. I use a he.net tunnel, the router has v6 connectivity though
Jun 05 11:23:00 <cyrusff> stintel: what did you use before?
Jun 05 11:23:14 <stintel> cyrusff: sec
Jun 05 11:23:30 <cyrusff> or rather can you show me your /etc/config/network please
Jun 05 11:24:33 <stintel> cyrusff: updated from r36342
Jun 05 11:28:06 <cyrusff> stintel: ok i see, please follow the "Migration from Attitude Adjustment" advice from http://wiki.openwrt.org/doc/uci/network6#in4.tunnel.and.static.ipv6.connection it applies to your situation as well
Jun 05 11:28:53 <cyrusff> especially the paragraphs "Downstream configuration for LAN-Interfaces" and "6in4 tunnel and Static IPv6 connection"
Jun 05 11:32:11 <stintel> cyrusff: hmmz. I have both a delegated /64 and /48
Jun 05 11:32:25 <stintel> cyrusff: can I keep using them both or need to switch the /64 to something in the /48 ?
Jun 05 11:32:39 <cyrusff> what do you mean you have both?
Jun 05 11:32:47 <cyrusff> what do you want to do?
Jun 05 11:33:15 <stintel> I prefer to not change any prefixes
Jun 05 11:33:46 <stintel> but if you look at my config, lan is just a 64 that is delegated to me by he.net
Jun 05 11:34:02 <stintel> later on I added the pxe and other subnets so I requested to delegate a /48
Jun 05 11:34:18 <cyrusff> i see
Jun 05 11:34:49 <cyrusff> not sure if it will work but you could try to leave the ip6addr in lan and mgmt and pxe as it is
Jun 05 11:35:09 <cyrusff> hmm or let me see
Jun 05 11:35:26 <cyrusff> hmm complicated
Jun 05 11:35:31 <cyrusff> it will probably not work
Jun 05 11:35:35 <stintel> I added the ip6prefix to wanv6 with the original /64 that works
Jun 05 11:35:55 <stintel> can't add a 2nd ip6prefix option in there can I ? :)
Jun 05 11:36:00 <cyrusff> you can
Jun 05 11:36:17 <cyrusff> but you have to use "list" instead of "option" before the ip6prefix then
Jun 05 11:36:21 <stintel> ah
Jun 05 11:37:00 <stintel> and keep using static for lan/pxe/.. instead of ip6assign and ip6hint
Jun 05 11:37:01 <stintel> right ?
Jun 05 11:37:14 <cyrusff> hmm
Jun 05 11:37:16 <stintel> static -> ip6addr
Jun 05 11:37:29 <cyrusff> no that won't work probably because of the source-routing, let me think of something
Jun 05 11:38:57 <cyrusff> list ip6prefix 2001:db80::/64,4294967295,4294967295,class=6in4-64 and list ip6prefix 2001:db80::/48,4294967295,4294967295,class=6in4-48 in the 6in4 config
Jun 05 11:39:33 <cyrusff> and then in addition to ip6hint and ip6assign you add to your lan the option ip6class 6in4-64 and for the other 2 option ip6class 6in4-48
Jun 05 11:40:25 <stintel> neat
Jun 05 11:40:42 <stintel> what are the 4294967295 for ?
Jun 05 11:41:17 <cyrusff> these are the values for preferred and valid lifetime of the prefixes and that particular number is 2^32-1 which means "unlimited"
Jun 05 11:41:25 <cyrusff> in this case
Jun 05 11:41:35 <cyrusff> i should probably allow the alias unlimited or so at some point
Jun 05 11:42:01 <OpenWrt-Commits> jow r36854 trunk/package/network/config/firewall/Makefile * firewall: update to git head (#13652)
Jun 05 11:43:59 <OpenWrt-Commits> jow r36855 branches/attitude_adjustment/package/firewall/Makefile * AA: firewall: merge r36854
Jun 05 11:47:05 <stintel> cyrusff: doesn't look like it's assigning a v6 IP to br-lan now
Jun 05 11:47:21 <cyrusff> anything in the syslog?
Jun 05 11:48:04 <stintel> I'll just reboot the thing to be sure
Jun 05 11:48:06 <cyrusff> you need to set option ip6assign 64 and option ip6class 6in4-64 or whatever you called it. if you want you can set option ip6hint 0 as well
Jun 05 11:48:25 <stintel> I added those two, not ip6hint
Jun 05 11:48:30 <cyrusff> thats enough
Jun 05 11:48:37 <cyrusff> or should be
Jun 05 11:48:49 <stintel> ok I'll reboot it, restarting wan is tricky, remote device :)
Jun 05 11:48:57 <cyrusff> hehe
Jun 05 11:51:11 <stintel> gonna be fun to update my OpenWrt in the datacenter
Jun 05 11:51:42 <stintel> it has native v6 from hosting provider (/64), but also HE.net tunnel and /48 that I use to have IPv6 when connecting to VPN
Jun 05 11:52:34 <cyrusff> yeah and routing with multiple wans is the problem we need all this complicated assignment logic for
Jun 05 11:52:54 <cyrusff> some ISPs block outoging traffic which doesn't come from one of their source-addresses
Jun 05 11:53:08 <stintel> well, they should :)
Jun 05 11:53:19 <stintel> no v6 IP on br-lan after reboot
Jun 05 11:53:24 <cyrusff> yeah but it requires us to do routing based on source-addresses
Jun 05 11:53:47 <stintel> it's the same with v4 really ;)
Jun 05 11:54:21 <stintel> but at home I just have the he.net tunnel so it shouldn't be needed there
Jun 05 11:54:35 <cyrusff> can you paste ifstatus wanv6 please?
Jun 05 11:54:35 <stintel> I was surprised not to see a default route in "ip -6 ro"
Jun 05 11:54:45 <cyrusff> yeah now you know the reason ;)
Jun 05 11:55:10 <stintel> cyrusff: http://pastebin.com/39UeF4U6
Jun 05 11:55:13 <stintel> no prefixes
Jun 05 11:56:15 <stintel> you can refresh that network.txt file
Jun 05 11:57:46 <stintel> hmmm and now the router has no v6 connectivity either
Jun 05 11:57:57 <stintel> it does after ifdown wanv6 ; ifup wanv6
Jun 05 11:58:11 <stintel> still no prefixes though in ifstatus
Jun 05 12:02:13 <stintel> cyrusff: seems to ignore the "list ip6prefix ..." stuff
Jun 05 12:02:29 <stintel> commented those and uncommented option 'ip6prefix'  ...
Jun 05 12:02:47 <stintel> and now it shows that prefix in ifstatus
Jun 05 12:02:57 <cyrusff> ah
Jun 05 12:03:00 <cyrusff> well one sec
Jun 05 12:03:08 <cyrusff> yeah
Jun 05 12:03:24 <cyrusff> the protocol handler script doesn't accept lists yet
Jun 05 12:03:29 <cyrusff> haha
Jun 05 12:03:41 <jow_laptop> afair there's a general problem with lists
Jun 05 12:03:45 <jow_laptop> and shell protos
Jun 05 12:03:57 <cyrusff> jow_laptop: do you by chance know what happens?
Jun 05 12:03:58 <stintel> :P
Jun 05 12:04:14 <jow_laptop> cyrusff: they're simply not mapped / processed
Jun 05 12:04:29 <jow_laptop> last time I looked some conversion layer lacked any code to process lists
Jun 05 12:04:54 <jow_laptop> but its been a few months so not sure atm
Jun 05 12:05:20 <KanjiMonster> [11:58:20] <kaspar> hey eveyone, how do I use UCI lists as options for netifd protocols? |  <kaspar> e.g., proto_config_add_string stays empty for lists...
Jun 05 12:06:11 <stintel> cyrusff: any way to hint it to use the last IP in the prefix ? :)
Jun 05 12:06:19 <cyrusff> stintel: i could only offer you a dirty workaround for now which is to edit /lib/netifd/proto/6in4.sh look for the line which says [ -n "$ip6prefix" ] && proto_add_ipv6_prefix "$ip6prefix" and replaces it
Jun 05 12:06:47 <stintel> cyrusff: no worries, I'll just use the /64 for now
Jun 05 12:06:48 <cyrusff> with 2 lines of proto_add_ipv6_prefix "..." where ... is what you initially put after list ip6prefix
Jun 05 12:06:55 <stintel> I usually don't use the two other networks
Jun 05 12:07:02 <cyrusff> ok
Jun 05 12:07:03 <stintel> and my main vlan has v6 connectivity again
Jun 05 12:07:24 <stintel> but thanks for the workaround
Jun 05 12:07:38 <stintel> this will change soon anyway
Jun 05 12:07:45 <cyrusff> ok
Jun 05 12:07:49 <stintel> as I should get native v6 very soon
Jun 05 12:07:53 <cyrusff> nice
Jun 05 12:08:01 <stintel> with a /56 PD
Jun 05 12:08:10 * stintel jumps for joy
Jun 05 12:08:11 <stintel> :P
Jun 05 12:08:26 <stintel> they were even thinking of delegating reverse DNS for the /56 to the CPE
Jun 05 12:08:36 <cyrusff> wow
Jun 05 12:08:50 <cyrusff> well is it a static or a dynamic prefix (e.g. does it change over time?)
Jun 05 12:08:59 <stintel> it is dynamic
Jun 05 12:09:10 <stintel> but with a 7d lifetime
Jun 05 12:09:10 <stintel> iirc
Jun 05 12:09:39 <cyrusff> nevertheless i guess the ip6assign / ip6hint logic comes in handy then, so you don't have to change ip6addr every 7 days or so ;)
Jun 05 12:09:45 <stintel> yep
Jun 05 12:10:05 <stintel> well, it wont change
Jun 05 12:10:15 <stintel> since my router is on 24/7
Jun 05 12:10:31 <cyrusff> yeah ok
Jun 05 12:10:40 <stintel> but only if you have downtime >7d
Jun 05 12:10:52 <stintel> it might be given to someone else
Jun 05 12:11:04 <stintel> so looking pretty good, I'd be very happy with that
Jun 05 12:11:45 <cyrusff> let's hope everything works out as expected
Jun 05 12:11:48 <stintel> yeah
Jun 05 12:12:41 <stintel> I know where to find you if I ran into other issues ;)
Jun 05 12:12:47 <stintel> s/ran/run/
Jun 05 12:12:52 <KanjiMonster> the ip6hint could use some explanation, is this intended as a /64 "offset" into the assigned prefix?
Jun 05 12:13:10 <KanjiMonster> ah, no, it's the full prefix
Jun 05 12:13:15 <cyrusff> no its not
Jun 05 12:13:39 <cyrusff> KanjiMonster: http://wiki.openwrt.org/doc/uci/network6#downstream.configuration.for.lan-interfaces :P
Jun 05 12:13:51 <cyrusff> i actually took some time to document the whole stack ;)
Jun 05 12:14:26 <KanjiMonster> cyrusff: well, I was looking at http://wiki.openwrt.org/doc/uci/network ;)
Jun 05 12:15:26 <cyrusff> ok will make that less ambiguous, it wouldn't make sense to make the hint the full prefix when dealing with dynamic prefixes
Jun 05 12:15:39 <cyrusff> the same problem as with static dhcpv6 leases and changing prefixes ;)
Jun 05 12:15:51 <stintel> ah I don't have 6relayd installed
Jun 05 12:15:55 <KanjiMonster> which is the only wiki-hit in google for ip6hint ;)
Jun 05 12:16:08 <cyrusff> stintel: well you can use radvd if you like
Jun 05 12:16:13 <cyrusff> or dnsmasq-dhcpv6
Jun 05 12:16:19 <cyrusff> its not a must
Jun 05 12:16:25 <cyrusff> to use 6relayd
Jun 05 12:16:46 <stintel> using bird6 for that right now ;)
Jun 05 12:16:55 <stintel> but I probably will move to dnsmasq-dhcpv6
Jun 05 12:18:38 <cyrusff> yeah you have to configure it manually then
Jun 05 12:19:02 <stintel> ah right, so should the prefix change it breaks
Jun 05 12:19:29 <stintel> (will need reconfiguring)
Jun 05 12:19:38 <cyrusff> well it now has support for automatic prefix detection as well i talked to simon about that
Jun 05 12:21:30 <stintel> ic. well that's for later :)
Jun 05 12:21:59 <cyrusff> haha sure
Jun 05 12:22:17 <cyrusff> KanjiMonster: linked that paragraph on the network page
Jun 05 12:23:53 <cyrusff> actually if i google for ip6hint the new documentation comes up as result #3 (#1 and #2 are some trac-pages)
Jun 05 12:24:20 <jow_laptop> unfortuantely it becomes harder this days to say "for me google found x..."
Jun 05 12:24:23 <stintel> no way you can have the default route in the main routing table if there is only one uplink ? :)
Jun 05 12:24:25 <jow_laptop> because it is personalized :)
Jun 05 12:24:35 <stintel> jow_laptop: that's pretty horrible actually
Jun 05 12:24:56 <KanjiMonster> stintel: not necessarily, dnsmasq knows a "constructor" where dnsmasq watches the interface for ip changes and autoupdates the announcements
Jun 05 12:25:06 <stintel> great
Jun 05 12:25:41 <KanjiMonster> it's a bit tricky, but it works
Jun 05 12:25:54 <cyrusff> stintel: option ip6table main or 0 (can't remeber) in your 6in4 / wan6 interface will write the rules to the main-table
Jun 05 12:26:15 <KanjiMonster> jow_laptop: I have that intentionally disabled in my account
Jun 05 12:26:27 <jow_laptop> cyrusff: if the code uses system_resolve_rt_table() then it is "main"
Jun 05 12:26:41 <cyrusff> yeah should be
Jun 05 12:27:06 <jow_laptop> or 254 afair
Jun 05 12:29:26 <cyrusff> man, that ipv6-stuff got so complicated that i probably need my own documentation in a few weeks to remember how it worked ;)
Jun 05 12:29:42 <stintel> cyrusff: main = 254 iirc
Jun 05 12:29:42 <cyrusff> stupid CE router requirements
Jun 05 12:29:44 <stintel> ahright :)
Jun 05 12:30:14 <cyrusff> yeah try main, that should work
Jun 05 12:30:59 <stintel> ip6table might be confusing though ;)
Jun 05 12:31:56 <cyrusff> everything related to that stack is confusing if you are coming from the ipv4 world
Jun 05 12:32:04 <cyrusff> ;)
Jun 05 12:32:42 <cyrusff> but you users always comeup with strange ideas like 2 delegated prefixes on a 6in4-tunnel :P
Jun 05 12:32:51 <stintel> :D
Jun 05 12:33:46 <stintel> guess we all know how those things go
Jun 05 12:34:00 <stintel> initially only needed a /64 so used the /64 delegation from he.net
Jun 05 12:36:06 <stintel> would have been cleaner if I had migrated that one to the /48 as well, once I started using it
Jun 05 12:36:06 <stintel> but lazyness
Jun 05 12:36:23 <cyrusff> yeah i know
Jun 05 12:37:20 <cyrusff> btw. as you were talking about bird and so on, we now also have dhcpv6 prefix-delegation server support
Jun 05 12:37:33 <cyrusff> if it doesn't need to be full-blown ospf
Jun 05 12:45:32 * cyrusff shamelessly advertises the new ipv6 stack to get more testers :P
Jun 05 12:46:27 <stintel> ;)
Jun 05 12:46:35 <stintel> doing bgp and ospf with bird
Jun 05 12:49:58 <KanjiMonster> cyrusff: we are doing our best :P
Jun 05 12:50:21 <cyrusff> KanjiMonster: i know, thanks :P
**** BEGIN LOGGING AT Wed Jun 05 13:15:45 2013
Jun 05 13:28:46 <karlp> I donĂ°t suppose there's an easy way to make a package _always_ download files?
Jun 05 13:29:17 <karlp> I played some tricks and have a package pulling HEAD from a git repo, to try and have daily builds without having to update package makefiles every day,
Jun 05 13:29:43 <karlp> but it doesn't redownload the tarball of the git repo, as it already has project-HEAD.tar.gz in the dl directory.
Jun 05 13:30:17 <karlp> or alternatively, other ideas on always building "latest" in a package would be fine too :)
Jun 05 13:30:28 <karlp> (I realise in most cases this is _not_ what you want to do)
**** BEGIN LOGGING AT Wed Jun 05 13:36:47 2013
Jun 05 13:40:07 <Pteridium> I'm developing a little project with openwrt. The target boards are based in Lantiq Danube and BCM6328.
Jun 05 13:44:05 <Pteridium> I'm a bit concerned about the usb ports for mass storage. Do they follow usb 2.0 specification or lack some functionality?
Jun 05 13:44:43 <[florian]> Pteridium: can't talk about lantiq danube, but on bcm63xx they just lack proper overcurrent reporting
Jun 05 13:44:51 <[florian]> otherwise they are "standard" ehci controllers
Jun 05 13:45:59 <Pteridium> overcurrent is not a problem: the HDD has it's own power supply.
Jun 05 13:46:10 <[florian]> then I guess you should be just fine
Jun 05 13:46:20 <Pteridium> thanks for the help
Jun 05 13:46:21 <[florian]> usb-storage devices are usually the quirky ones ;)
Jun 05 13:46:47 <Pteridium> why quirky?
Jun 05 13:47:05 <[florian]> oh I presume because implementers do not fully understand or care to read the specification
Jun 05 13:48:18 <Pteridium> yes, you are right, but the enclosures i want to use worked well
Jun 05 13:49:02 <Pteridium> hd-idle and smartmon performed fine on them
Jun 05 13:49:11 <[florian]> ok, that's good
Jun 05 13:49:19 <karlp> Pteridium: lots of devices that aren't actually mass storage try and pretend to be mass-storage, some of those are _wayyy_ quirky.
Jun 05 13:50:28 <Pteridium> "try to pretend to be mass storage": funny
Jun 05 13:50:38 <karlp> I wish it was :|
Jun 05 13:52:01 <Pteridium> karlp: maybe the 3G modems with internal flash, no?
Jun 05 13:52:25 <karlp> those probably actually work.
Jun 05 13:52:54 <karlp> there's some jtag device programmers that pretend to be a mass-storage device to let you "flash" the target by dropping a magic filename onto the "flash drive"
Jun 05 13:53:22 <karlp> there's some usb devices that try and present a flash drive based on some tiny ram contents to give you a "readme" type thing, but it's not flash, and not a real file system.
Jun 05 13:53:30 <karlp> plenty of wild and wooly stuff out there
Jun 05 13:54:18 <Pteridium> curious
Jun 05 13:54:46 <Pteridium> thanks a lot for the info
Jun 05 13:56:26 <KanjiMonster> [florian]: Pteridium: there is a chance that the 63xx hcd doesn't do unaligned dma, and I'm not sure that the problem is fixed yet in the kernel
Jun 05 13:57:24 <Pteridium> yes, found the problem with unaligned dma testing the r92su driver
Jun 05 13:57:35 <[florian]> KanjiMonster: ah good point yes
Jun 05 13:58:20 <groz1> karl, one of the freescale dev samples is just that, a boot loader that pretends to be a disk, allowing a re-flash by copying an S19 file to the device
Jun 05 13:58:40 <groz1> it makes for strait forward development, and a boot loader that requires no special things on the host
Jun 05 13:58:49 <Pteridium> but afaik unaligned dma is not a problem with mass storage
Jun 05 13:59:08 <[florian]> probably not, it is for networking though
Jun 05 13:59:25 <KanjiMonster> Pteridium: the fun thing is hcds aren't required to support unaligned dma, and the question how to fix it is unsolved
Jun 05 13:59:43 <groz> I've worked with one of those, and, it really does make life much easier for doing firmware updates in the field
Jun 05 14:01:27 <Pteridium> KanjiMonster: unaligned dma is only needed in some "special" cases.
Jun 05 14:01:47 <Pteridium> afaik
Jun 05 14:06:08 <Pteridium> to summarize: if usb ports in bcm63xx follow the usb standard then i can finish the project without fear.
Jun 05 14:06:48 <KanjiMonster> Pteridium: it's never needed, but used for better perfomance
Jun 05 14:08:05 <Pteridium> perfect, i need the best achievable performance
Jun 05 14:08:56 <KanjiMonster> well used for better performance in network device
Jun 05 14:09:06 <KanjiMonster> because of the 2-byte alignment of ethernet
Jun 05 14:09:06 <KanjiMonster> anything else doesn't care about alignment
Jun 05 14:15:19 <karlp> groz: oh yeah, I understand the motivation, but sometimes the implementations are.... lacking :)
Jun 05 14:15:19 <groz> hehe, well, implementation is often 'cut and paste' from reference docs
Jun 05 14:15:19 <groz> at least in our case, on the freescale gadget, it was
Jun 05 14:15:19 <karlp> yeah, I've seen some good ones,
Jun 05 14:15:20 <Pteridium> freescale powerpc?
Jun 05 14:15:20 <groz> and then , when working on a gadget that only has 64K of flash, towarnds the end
Jun 05 14:15:20 <groz> we end up trimming as much as we can of the 'fat' out of the boot loader
Jun 05 14:15:20 <karlp> Pteridium: probably a kinetis freedom board by the sound of it :)
Jun 05 14:15:20 <groz> to make room for 'real code'
Jun 05 14:15:20 <groz> no, it was a freescale jm60 processor, used as the controller in a vhf radio
Jun 05 14:15:20 <groz> 60K of flash, 4K of ram, and 'raw on the hardware' programs inside it
Jun 05 14:15:20 * groz points to the K, emphasizes it is K not M 
Jun 05 14:15:20 <Pteridium> for the project i think the best is powerPC, but bcm6328 routers are cheap and easy to find
Jun 05 14:15:21 <groz> if memory serves correctly, the boot loader (usb storage code) used about 2.5K of the flash
Jun 05 14:15:21 <karlp> ppc is a dead end man.
Jun 05 14:15:22 <groz> but one huge benefit of doing it the way we did, can reflash from windows, mac, pc, what have you, no funky support programs required
Jun 05 14:15:22 <groz> plug it in, when in boot loader mode, it's 'just a disk'
Jun 05 14:17:46 <Pteridium> karlp: something like mips since the acquisition from imagination?
Jun 05 14:18:04 <KanjiMonster> karlp: not until netcraft confirmed it!
Jun 05 14:20:14 <groz> mips dead ?????
Jun 05 14:20:21 * groz looks at all my routers
Jun 05 14:20:26 <groz> looks alive to me
**** BEGIN LOGGING AT Wed Jun 05 14:29:27 2013
Jun 05 14:30:39 <Pteridium> i think that the target processor is a bit important depending the application.
Jun 05 14:31:14 <Pteridium> each architecture has it's pros and cons
Jun 05 14:43:54 <karlp> Pteridium: I think you have to _realllly_ specific needs to care more than just availability and price
Jun 05 14:46:59 <Pteridium> yes, you are right. Only in few concrete cases the cpu is important.
Jun 05 14:55:22 <karlp> anyone know why there's an rc.d link for starting the watchdog as well as hotplug2.rules to start it?
Jun 05 14:55:40 <karlp> or, anyone know good ways of checking whether you're being resbooted due to watchdog timeouts?
Jun 05 14:55:56 <[florian]> karlp: on some hardware there is a reset condition register
Jun 05 14:56:10 <[florian]> karlp: what pltform do you use?
Jun 05 14:56:14 <karlp> ar2317, old atheros.
Jun 05 14:56:30 <karlp> seeing some unexplained reboots at startup,
Jun 05 14:56:30 <[florian]> there might be, you'd need to check against the material you have
Jun 05 14:56:49 <karlp> thinking it might be some slow startup scripts delaying the watchdog long enough
Jun 05 14:57:20 <karlp> but not entirel sure yet, and debugging the board startup's not really core expertise unfortunately.
Jun 05 14:57:34 <[florian]> yeah that sounds like something I have seen in the past too
Jun 05 14:57:54 <[florian]> you might also want to make sure that the watchdog driver does not start it as soon as it is registered
Jun 05 14:58:23 <karlp> registered by whom?
Jun 05 14:58:24 <[florian]> there have been some platforms doing this and I think this is kind of bad practice, because you may have an extremly big initramfs to boot or something like that which prevents you from poking at the watchdog
Jun 05 14:58:37 <[florian]> by the drivers' probe routine for instance
Jun 05 14:58:40 <groz> more ofen than not, my experience with startup reboots, something got stuck in a name lookup
Jun 05 14:58:53 <groz> before dns was actually up and running
Jun 05 14:59:13 <karlp> groz yeah, we added some ntpdate stuff, which would do that, but I still would only expect _slow_ boot, not reboots.
Jun 05 14:59:27 <karlp> but yeah, if the watchdog was on, it might kill it.
Jun 05 14:59:41 <[florian]> the thing is, your watchdog driver may very well start your watchdog hardware
Jun 05 14:59:56 <[florian]> in case everything goes well, the watchdog daemon is started and finally pokes it
Jun 05 15:00:19 <karlp> I'm using the stock ar2317 board code in openwrt, any idea on what/where I'm looking for?
Jun 05 15:00:46 <[florian]> ar2315_wdt_probe(struct platform_device *dev) in target/linux/atheros/patches-3.8/130-watchdog.patch
Jun 05 15:00:47 <[florian]> and it does enable the watchdog
Jun 05 15:01:00 <karlp> there was an S97 link to start the sbin/watchdog -t 5,
Jun 05 15:01:03 <[florian]> so just remove the call to ar2315_wdt_enable() in that function and see what it gives you
Jun 05 15:01:10 <[florian]> S97 that's very late
Jun 05 15:01:13 <karlp> and also hotplug2_rules that also seemed to turn it on.
Jun 05 15:01:19 <karlp> yeah, I thought it was late too,
Jun 05 15:01:37 <karlp> I removed it entirely, hoping to see it crash reliably, but it didnt' crash at all.
Jun 05 15:01:40 <[florian]> the default timeout is 20 seconds though
Jun 05 15:01:54 <karlp> I guess the hotplug2.rules thing was turning it on instead?
Jun 05 15:02:03 <[florian]> it should yes
Jun 05 15:02:41 <jow_laptop> iirc the problem on legacy atheros was that a high system load can already starve the watchdog so that it triggers a reset
Jun 05 15:03:25 <karlp> tempting to turn it off altogether if it's buggy.
Jun 05 15:03:59 <groz> is your system tight on memory during startup ?
Jun 05 15:04:08 <groz> I've seen oomkiller decide to kill watchdog
Jun 05 15:04:33 <[florian]> groz: that's something that should be fixed by adjusting the oom score of the watchdog pid
Jun 05 15:04:38 <karlp> wouldn't expect it to be, but possible.  another thing to look out for.
Jun 05 15:04:51 <karlp> I have code that makes our own apps more likely to be killed by poking the oom adjustment values
Jun 05 15:04:56 <groz> yes florian, but this is how we learn those things
Jun 05 15:05:03 <groz> watch it get taken out and go 'hmmmmm'
Jun 05 15:05:36 <[florian]> groz: I have been trapped by this too
Jun 05 15:05:42 <karlp> I can try and make sure that the watchdog gets turned on with a "better" oom adjustment.
Jun 05 15:06:20 <[florian]> karlp: just make sure this is the watchdog that reboots you and not something else
Jun 05 15:06:47 <karlp> yeah, that's first order of business:)
Jun 05 15:06:47 <groz> I usually disable watchdog programs
Jun 05 15:06:47 <karlp> booting it now with hotplug and an rc.d link disabled.
Jun 05 15:06:47 <groz> and service it from within my own application
Jun 05 15:06:47 <groz> because, that's what I'm interested in anyways, my own program is running
Jun 05 15:06:47 <[florian]> karlp: not enough, also disable the call to ar2135_wdt_enable() or the driver all together
Jun 05 15:06:53 <karlp> yes, I should see it being killed continuously.
Jun 05 15:06:57 <[florian]> every 20 seconds actually, that's the default timeout it uses
Jun 05 15:06:57 <karlp> (until I remove the call to ar2315_wdt_enable()
Jun 05 15:07:59 <karlp> you've given me some excellent things to look for, I'll poke it for a while.
Jun 05 15:12:06 <karlp> well, that wsa unexpected.  there's no watchdog process running, and it's not crashing at all.
Jun 05 15:14:00 <groz> watchdog is your friend, right up until it's not anymore
Jun 05 15:14:11 <groz> if you aren't crashing without it, kinda points somewhere
Jun 05 15:20:32 <builder> build #287 of orion is complete: Failure [failed compile_8]  Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/287
Jun 05 15:23:22 <builder> build #247 of sibyte is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/247
Jun 05 15:33:00 <karlp> groz: yeah, points to our code, which is fine, but without any /sbin/watchdog -t 5 /dev/watchdog process running at all, I didn't expect it to run at all.
**** BEGIN LOGGING AT Wed Jun 05 15:48:29 2013
**** BEGIN LOGGING AT Wed Jun 05 15:56:07 2013
Jun 05 18:37:37 <OpenWrt-Commits> tripolar r36857 packages/net/ nfs-kernel-server/Makefile nfs-kernel-server/patches/100-nfs_utils_uclibc.patch * [packages/nfs-kernel-server]: update to v1.2.8
Jun 05 19:18:17 <OpenWrt-Commits> nbd r36858 trunk/package/mac80211/patches/300-pending_work.patch * ath9k: merge a fix for ar9550 eeprom access
Jun 05 19:18:17 <OpenWrt-Commits> nbd r36859 trunk/package/mac80211/patches/300-pending_work.patch * ath9k: fix a regression in the powersave handling related changes
**** BEGIN LOGGING AT Wed Jun 05 19:31:19 2013
Jun 05 20:33:59 <tripolar> hi
Jun 05 20:34:01 <tripolar> ping nbd
Jun 05 20:35:14 <nbd> pong
Jun 05 20:36:36 <tripolar> nbd hi i sent a mail to ml to get the maintainer of more packages
Jun 05 20:36:51 <tripolar> but no one answered - to whom do i have to talk to?
Jun 05 20:39:02 <nbd> Kaloz
Jun 05 20:39:18 <tripolar> okay
Jun 05 20:39:37 <tripolar> Kaloz: Ăping
Jun 05 20:39:45 <tripolar> nbd: thanks
Jun 05 20:59:24 <OpenWrt-Commits> jogo r36860 trunk/ include/image.mk Config.in scripts/metadata.pl target/Config.in * target: split jffs2 NAND out of jffs2
Jun 05 21:00:13 <OpenWrt-Commits> jogo r36861 trunk/target/linux/ kirkwood/image/Makefile kirkwood/Makefile * kirkwood: convert to use the new jffs2_nand
Jun 05 21:00:16 <OpenWrt-Commits> jogo r36862 trunk/target/linux/ omap24xx/Makefile omap24xx/image/Makefile * omap24xx: convert to use the new jffs2_nand
Jun 05 21:00:20 <OpenWrt-Commits> jogo r36863 trunk/target/linux/ (26 files in 26 dirs) * target: don't build jffs2 nor images by default
Jun 05 21:02:53 <builder> build #257 of avr32 is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/257
**** BEGIN LOGGING AT Wed Jun 05 21:22:53 2013
Jun 05 21:38:24 <mazilo> nbd: Have you gotten a chance to look at the gcc-4.8.x with Linraro Enchacement? Please take a look at this http://pastebin.com/3zZRLzKU and pay attention to line #18 and #23 which I believe is the cause of failure (no libfloat).
Jun 05 21:38:45 <nbd> haven't had time yet
Jun 05 21:40:46 <mazilo> nbd: OK. But, I believe the failure was caused by libfloat wasn't available when checking for C compiler default output file name.
Jun 05 21:56:56 <builder> build #224 of iop32x is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/iop32x/builds/224
Jun 05 23:38:33 <OpenWrt-Commits> nbd r36864 trunk/toolchain/gcc/ patches/4.8.0/810-arm-softfloat-libgcc.patch patches/4.8-linaro/810-arm-softfloat-libgcc.patch * gcc: fix arm libgcc issues with 4.8.0 and 4.8-linaro
**** ENDING LOGGING AT Thu Jun 06 02:59:58 2013