**** BEGIN LOGGING AT Wed Jul 30 03:00:01 2014
Jul 30 07:22:05 <builder_> build #133 of adm8668 is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/adm8668/builds/133
Jul 30 07:27:02 <builder_> build #532 of mcs814x is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/mcs814x/builds/532
Jul 30 07:27:10 <builder_> build #227 of mvebu is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/mvebu/builds/227
Jul 30 08:58:27 <builder_> build #39 of brcm47xx.mips74k is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx.mips74k/builds/39
Jul 30 09:04:25 <builder_> build #573 of au1000 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/au1000/builds/573
Jul 30 09:15:34 <builder_> build #587 of ar71xx is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx/builds/587
Jul 30 10:08:54 <builder_> build #133 of cns3xxx is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/cns3xxx/builds/133
Jul 30 10:34:42 <OpenWrt-Commits> jow r41889 branches/barrier_breaker/feeds.conf.default * BB: feeds: switch to openwrt-routing release branch
Jul 30 10:35:37 <slachta> jow_laptop: ping
Jul 30 10:35:41 <jow_laptop> slachta: pong
Jul 30 10:37:58 <slachta> I just wanted to ask you something. Several packages from oldpackages are not yet ported to new packages repo and I am thinking about telephony repository in bigger context. Should I take over the maintainership of those packages (such as mysql, bluez, libiksemel, ..) or should I reduce the dependencies of telephony packages?
Jul 30 10:38:15 <slachta> When I am done with those changes, I will create a new branch for BB release.
Jul 30 10:38:31 <jow_laptop> slachta: taking over maintainership for high profile packages would be appreciated
Jul 30 10:39:16 <jow_laptop> at least mysql
Jul 30 10:39:28 <jow_laptop> not sure about bluez, iirc its a pretty huge can of worms
Jul 30 10:40:49 <slachta> Well, if I give you a list of packages, could you tell me, what packages are appreciated in OpenWrt? I just need Telephony packages to get into BB, but those missing dependencies breaks almost every package. :)
Jul 30 10:41:15 <jow_laptop> well look after lunch
Jul 30 10:41:20 <jow_laptop> ~20mins
Jul 30 10:41:27 <slachta> This way I would know what to remove from telephony repo.
Jul 30 10:41:35 <slachta> okay
Jul 30 10:43:52 <OpenWrt-Commits> luka r41890 branches/barrier_breaker/feeds.conf.default * BB: feeds: switch management feed to 14.07 branch
Jul 30 10:44:36 <stintel> jow_laptop: found a bug in miniupnpd that is currently used in trunk, reported it upstream @ http://is.gd/fkvtiJ , should I create a ticket in OpenWrt as well, referencing to that bug? to make sure 14.07 won't be released with it ?
Jul 30 10:45:32 <stintel> s/to//
Jul 30 10:50:35 <cyrusff> stintel: i think the problem is that READNU16 is a bit wrong
Jul 30 10:51:13 <stintel> cyrusff: I figured it was somewhere in one of those macros
Jul 30 10:51:19 <cyrusff> #define READNU16(p) (((uint16_t)((p)[0])) << 8 | (uint16_t)((p)[1]))
Jul 30 10:51:21 <stintel> but they have been replaced by functions in a later commit
Jul 30 10:51:23 <cyrusff> that should do the trick
Jul 30 10:51:32 <cyrusff> ah which commit?
Jul 30 10:51:35 <stintel> hold on
Jul 30 10:51:57 <stintel> https://github.com/miniupnp/miniupnp/commit/d31badae7d8edebed7a276d43277f97df241d450
Jul 30 10:52:15 <cyrusff> same issue in these functions
Jul 30 10:52:43 <cyrusff> before bitshifting the values have to be cast to bigger ints
Jul 30 10:53:18 <cyrusff> so return (((uint16_t)(p[0])) << 8 | ((uint16_t)p[1]))
Jul 30 10:53:24 <cyrusff> for the 16 bit function
Jul 30 10:53:39 <cyrusff> equivalently for the others
Jul 30 10:54:12 <cyrusff> well only the readu32 whatever functions
Jul 30 10:54:16 <cyrusff> write functions should be fine
Jul 30 10:54:31 <cyrusff> just fixing this should do the trick
Jul 30 10:54:46 <cyrusff> i can prepare a patch later today or tomorrow morning or you do it if you like
Jul 30 10:55:11 <cyrusff> won't probably make it today
Jul 30 10:55:19 <stintel> np, I can try but it's not urgent
Jul 30 10:56:00 <stintel> I reverted those two commits in my build for now
Jul 30 11:02:23 <cyrusff> ok cu later, hope i don't forget this
Jul 30 11:03:37 <stintel> cyrusff: I'll let you know if I figured out what exactly you mean ;)
Jul 30 11:03:43 <stintel> (need to rtfm)
Jul 30 11:06:49 <slachta> jow_laptop: the list of those packages is here - http://paste.debian.net/112628/ - The packages maintained by me in Telephony repository (everything except FreeSwitch package) depends on the lines marked by "*" on the beginning of the line.
Jul 30 11:08:05 <slachta> dependencies to lang packages (php, perl, python) could be disabled, those packages are just script packages for Yate package (PBX)
Jul 30 11:09:27 <slachta> also would not be better to move telephony to github, if every other repository (management, routing, packages) are located on github?
Jul 30 11:11:26 <jow_laptop> slachta: I'd like to leave the decision where to host up to the feed maintainers
Jul 30 11:12:02 <slachta> okay
Jul 30 11:12:10 <jow_laptop> slachta: microperl has been dropped entirely, not sure if it can be substituted with perl
Jul 30 11:12:31 <jow_laptop> slachta: mysql / radius / ldap are important imho
Jul 30 11:13:02 <jow_laptop> scripting support could be marked @BROKEN for now
Jul 30 11:13:21 <jow_laptop> and we could revise whether to drop or to reenable scripting bindings in a few months, depending on how much was migrated
Jul 30 11:13:50 <slachta> ok
Jul 30 11:14:00 <slachta> how about bash, libsdl or libiksemel?
Jul 30 11:14:14 <jow_laptop> for what is bash needed?
Jul 30 11:14:59 <jow_laptop> was it just added because something ships shell scripts that demand bash?
Jul 30 11:15:35 <slachta> the bash dependency could be removed. Internal console of kamailio package somehow uses it
Jul 30 11:15:43 <slachta> but it should work without that
Jul 30 11:15:51 <slachta> (i will check that)
Jul 30 11:16:47 <jow_laptop> I could take care of libsdl
Jul 30 11:17:03 <jow_laptop> libiksemel is something solely used for telephony afair, so it should go there
Jul 30 11:18:02 <slachta> it is xmpp backend, not purely telephony, but I am ok with it
Jul 30 11:18:14 <jow_laptop> hm okay
Jul 30 11:18:22 <jow_laptop> I always seen it in relation to asterisk and nowhere else
Jul 30 11:19:06 <jow_laptop> last commit oct 2011
Jul 30 11:19:19 <jow_laptop> looks like something that requires little care
Jul 30 11:20:00 <slachta> so I think I can handle ldap/mysql/radius
Jul 30 11:20:26 <jow_laptop> I could take mysql too, its required by collectd as well
Jul 30 11:20:41 <jow_laptop> already took over postgres
Jul 30 11:20:50 <slachta> ok
Jul 30 11:21:32 <slachta> I do not know how about the rest of the dependencies, but it seems that Freeswitch maintainer Mazi Lo does not care about it.
Jul 30 11:21:47 <slachta> I asked him several times, but no response.
Jul 30 11:22:57 <jow_laptop> ok, so I'll take mysql, freeradius, ldns, lzma, openldap, sctp
Jul 30 11:23:18 <jow_laptop> could take libtiff and yaml as well
Jul 30 11:24:00 <jow_laptop> not sure about libedit...
Jul 30 11:24:27 <jow_laptop> seems like a replacement for readline
Jul 30 11:25:22 <jow_laptop> what requires it?
Jul 30 11:25:27 <jow_laptop> and can it be disabled?
Jul 30 11:29:55 <builder_> build #537 of adm5120 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/adm5120/builds/537
Jul 30 11:33:59 <slachta> jow_laptop: I will take a look.
Jul 30 11:35:22 <slachta> jow_laptop: it can be disabled
Jul 30 11:37:28 <slachta> jow_laptop: let me know, if I could also take over maintainership of some packages. It is not a big deal for me.
Jul 30 11:38:48 <slachta> jow_laptop: the libedit package is an internal library of freeswitch package, but it should not be mandatory
Jul 30 11:46:18 <builder_> build #347 of mpc85xx is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/mpc85xx/builds/347
Jul 30 12:29:04 <cyrusff> stintel: p [0] is a uint8_t if you shift it left 8 bits you shift everything out of bounds so it becomes 0
Jul 30 12:29:31 <cyrusff> So you actually need to cast it to uint16_t before shifting
Jul 30 12:29:57 <cyrusff> So the bits don't "fall out on the left side"
Jul 30 12:42:11 <OpenWrt-Commits> nbd r41891 trunk/package/system/procd/Makefile * procd: update to the latest version, fixes parsing of /etc/openwrt_release
Jul 30 13:18:15 <builder_> build #493 of octeon is complete: Failure [failed compile_8]  Build details are at http://buildbot.openwrt.org:8010/builders/octeon/builds/493
Jul 30 13:20:21 <OpenWrt-Commits> cyrus r41892 trunk/package/network/config/netifd/files/lib/netifd/dhcp.script * netifd: suppress fw3 warnings in dhcp script
Jul 30 13:20:25 <OpenWrt-Commits> cyrus r41893 trunk/package/network/ipv6/odhcp6c/files/dhcpv6.script * odhcp6c: Fix white space typo in dhcpv6.script
Jul 30 13:21:00 <OpenWrt-Commits> cyrus r41894 branches/barrier_breaker/package/network/config/netifd/files/lib/netifd/dhcp.script * netifd: suppress fw3 warnings in dhcp script
Jul 30 13:21:01 <OpenWrt-Commits> cyrus r41895 branches/barrier_breaker/package/network/ipv6/odhcp6c/files/dhcpv6.script * odhcp6c: Fix white space typo in dhcpv6.script
Jul 30 13:24:16 <OpenWrt-Commits> cyrus r41896 trunk/package/network/config/netifd/Makefile * netifd: fixes and GRE support (thx Hans Dedecker)
Jul 30 13:24:49 <OpenWrt-Commits> cyrus r41897 trunk/package/ network/config/gre network/config/gre/files/gre.sh network/config/gre/Makefile network/config/gre/files * gre: Generic Routing Encapsulation package support
Jul 30 13:25:10 <KanjiMonster> cyrusff: stintel: I don't think the cast is the issue, the problem is that there is a bug in writenu16 "p[0] = (n < 0xff00) >> 8;" <- I guess "<" was supposed to be "'&"; currently it will evaluate to "(0|1) >> 8;"   https://github.com/miniupnp/miniupnp/blob/master/miniupnpd/natpmp.c#L57
Jul 30 13:25:55 <cyrusff> probably both
Jul 30 13:26:12 <cyrusff> will prepare a patch
Jul 30 13:27:02 <KanjiMonster> I think the uint8 would be "upgraded" automatically to the appropriate type that can fit the new value
Jul 30 13:27:08 <cyrusff> nope
Jul 30 13:28:50 <cyrusff> actually depends i guess
Jul 30 13:28:54 <cyrusff> i have seen it not work
Jul 30 13:31:15 <cyrusff> but could be that it is only relevant for 64-bit types
Jul 30 13:34:07 <KanjiMonster> cyrusff: the C standard defines integer promotion for bitwise shifts
Jul 30 13:34:27 <KanjiMonster> so they will be promoted to a type that can contain the new value
Jul 30 13:34:44 <cyrusff> :q
Jul 30 13:34:48 <cyrusff> sorry
Jul 30 13:34:50 <cyrusff> interesting
Jul 30 13:35:12 <cyrusff> because i remember having a similar case where it didn't work
Jul 30 13:35:32 <cyrusff> or at least where gcc complained about it
Jul 30 13:35:35 <KanjiMonster> (note: this only applies to unsigned types, not signed)
Jul 30 13:36:06 <KanjiMonster> signed is often undefined behaviour
Jul 30 13:36:41 <cyrusff>         uint8_t f = 1;
Jul 30 13:36:41 <cyrusff>         uint64_t g = (f << 32);
Jul 30 13:36:49 <cyrusff> test.c:6:2: warning: left shift count >= width of type [enabled by default]
Jul 30 13:37:20 <cyrusff> so yeah it promotes to 32-bit apparently
Jul 30 13:37:23 <cyrusff> but not above that
Jul 30 13:37:27 <KanjiMonster> yeah
Jul 30 13:37:37 <KanjiMonster> but 32 bit is fine for the read/writeu16/32
Jul 30 13:38:50 <KanjiMonster> the C standard only defines promotion up to unsigned integer
Jul 30 13:39:04 <cyrusff> yeah ok
Jul 30 13:39:07 <cyrusff> mystery solved
Jul 30 13:39:25 <cyrusff> thanks
Jul 30 13:42:12 <cyrusff> oh well wish there was 128-bit arithmetic in gcc on non 64-arches ;)
Jul 30 13:42:27 <cyrusff> i mean "native" 128-bit types
Jul 30 13:45:37 <stintel> cyrusff: I figured that much. but tried this: http://bpaste.net/show/527395/ and it did not work
Jul 30 13:45:58 <cyrusff> stintel: yeah see KanjiMonster's comment
Jul 30 13:46:11 <cyrusff> i was apparently wrong, sorry
Jul 30 13:46:15 <stintel> np
Jul 30 13:46:22 <cyrusff> patch is on the way
Jul 30 13:46:26 <stintel> I didn't have the slightest clue, so .. :)
Jul 30 13:46:38 <cyrusff> well i would have been right if it was 64-bit read :P
Jul 30 13:46:50 <cyrusff> C is so awesome :P
Jul 30 13:48:00 <KanjiMonster> especially all the undefined behaviour ;D
Jul 30 13:50:48 <stintel> hehe
Jul 30 13:51:01 <stintel> maybe it's not so bad that I don't know C :P
Jul 30 13:51:40 <cyrusff> https://github.com/openwrt-routing/packages/commit/2bb7d479d31bf6247a3bdee65918d988f1ece5c2
Jul 30 13:53:00 <stintel> lol
Jul 30 13:55:33 <karlp> what on earth was wrong with htons/htonl?
Jul 30 13:55:52 <cyrusff> well the point was unaligned read
Jul 30 13:56:42 <karlp> so by fixing it, they rewrote their own buggy htnoX on the way?
Jul 30 13:57:20 <cyrusff> apparently
Jul 30 13:57:47 <cyrusff> it makes sense to do it this way well aside from the bug ;)
Jul 30 13:58:23 <karlp> I'
Jul 30 13:58:36 <karlp> ve been caughtr with implicit casts on this sort of thing too, it's a gross world
Jul 30 15:20:32 <stintel> cyrusff: patch seems to fix the problem :)
Jul 30 15:36:33 <stintel> cyrusff: can you link https://github.com/openwrt-routing/packages/commit/2bb7d479d31bf6247a3bdee65918d988f1ece5c2 in that issue I opened for miniupnp ?
Jul 30 15:37:03 <stintel> or I can do it myself, if you prefer :)
Jul 30 15:47:09 <OpenWrt-Commits> luka r41898 trunk/ (6 files in 4 dirs) * kernel: update 3.14 to 3.14.14
Jul 30 17:41:30 <builder_> build #641 of ppc44x is complete: Failure [failed shell_9]  Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/641
Jul 30 18:56:35 <OpenWrt-Commits> hauke r41899 trunk/target/linux/ (6 files in 6 dirs) * kernel: update bcma to version master-2014-07-29-1
Jul 30 18:56:39 <Hauke> zajec: ping
Jul 30 18:59:13 <builder_> build #136 of pxa is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/pxa/builds/136
Jul 30 18:59:15 <zajec> Hauke: pong
Jul 30 18:59:17 * zajec checking e-mails
Jul 30 19:00:19 <Hauke> zajec: when I use BCM43224 (5GHZ only) with b43 I get an data bus error
Jul 30 19:01:12 <zajec> oops
Jul 30 19:01:17 <zajec> on PC?
Jul 30 19:01:19 <zajec> or router?
Jul 30 19:01:34 <zajec> anything interesting in the output?
Jul 30 19:01:36 <Hauke> no on bcm4716, so I think it is caused by the broken PCIe controller
Jul 30 19:01:38 <zajec> pointing to some code?
Jul 30 19:02:09 <Hauke> 2 minutes, just booting from tftp
Jul 30 19:04:32 <builder_> build #681 of cobalt is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/681
Jul 30 19:05:48 <Hauke> zajec: http://pastebin.com/hW1AbXzK
Jul 30 19:06:09 <Hauke> the position is wrong
Jul 30 19:08:39 <zajec> will you add some debugging to the bcma_host_pci_read16?
Jul 30 19:08:49 <zajec> to see what offset it tried to read
Jul 30 19:09:09 <zajec> this b43_cordic is rather wrong
Jul 30 19:09:13 <zajec> but had to be somewhere around
Jul 30 19:09:30 <Hauke> yes that was my plan
Jul 30 19:09:37 <zajec> it's called from b43_nphy_gen_load_samples
Jul 30 19:09:43 <zajec> maybe b43_nphy_gen_load_samples has some bugged read
Jul 30 19:09:48 <Hauke> but if it is the pcie controller adding printks "fixes" the problem
Jul 30 19:10:28 <zajec> oh, i hope not
Jul 30 19:11:26 <Hauke> the pcie controller does some reordering of the commands and that could bring them into the wrong order
Jul 30 19:13:20 <Hauke> it has to do something with 5GHz when I use 2.4 GHz it works
Jul 30 19:13:27 <Hauke> at least it does not oops
Jul 30 19:13:44 <zajec> hm, you could try disabling parts of code
Jul 30 19:13:47 <zajec> but that will take ages :(
Jul 30 19:18:15 <builder_> build #652 of uml is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/652
Jul 30 19:20:40 <builder_> build #610 of sibyte is complete: Failure [failed shell shell_9]  Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/610
Jul 30 19:22:12 <zajec> Hauke: how do you send ARM arch patches?
Jul 30 19:22:15 <zajec> i mean where
Jul 30 19:22:18 <zajec> to who
Jul 30 19:23:24 <Hauke> zajec: I send them to bcm@fixthebug.org and arm@kernel.org and linux-arm-kernel@lists.infradead.org
Jul 30 19:23:53 <zajec> where I can see some git tree?
Jul 30 19:23:59 <zajec> with stuff like arm-next
Jul 30 19:24:13 <Hauke> zajec: https://github.com/broadcom/mach-bcm
Jul 30 19:24:26 <Hauke> at least that was the one I used the last time
Jul 30 19:24:39 <Hauke> I based my changes on the last rc from linus
Jul 30 19:26:08 <zajec> github... i hate it :/
Jul 30 19:28:04 <zajec> can someone here use github web interface?
Jul 30 19:28:18 <zajec> i have this link... https://github.com/broadcom/mach-bcm how the hell can I switch to "log?
Jul 30 19:28:24 <zajec> to see commits one by one
Jul 30 19:28:28 <karlp> click "commits" ?
Jul 30 19:28:41 <karlp> where have you been living?
Jul 30 19:28:52 <zajec> ooooh
Jul 30 19:28:54 <zajec> it's there!
Jul 30 19:28:55 <zajec> really!
Jul 30 19:29:13 <zajec> one more thing... how can I grep commits?
Jul 30 19:29:22 <karlp> not on github...
Jul 30 19:29:23 <zajec> to see only commits with "ARM" in the commit message
Jul 30 19:29:40 <zajec> oh, that's great
Jul 30 19:29:44 <Hauke> zajec: clone https://github.com/broadcom/mach-bcm.git and do whatever your want ;-)
Jul 30 19:32:35 <zajec> Hauke: which branch does include mach-bcm53xx
Jul 30 19:33:14 <zajec> Hauke: i was looking in https://github.com/broadcom/mach-bcm/tree/armsoc/for-3.17/soc/arch/arm and https://github.com/broadcom/mach-bcm/tree/armsoc/for-3.17/dt/arch/arm but they don't have it
Jul 30 19:33:25 <Hauke> there is no mach-bcm53xx, it is in arch/arm/mach-bcm/bcm_5301x.c
Jul 30 19:33:45 <zajec> ah, different that in OpenWrt, right/
Jul 30 19:33:55 <zajec> so OpenWrt has some older patches?
Jul 30 19:34:04 <Hauke> it is in 3.15 I think
Jul 30 19:35:03 <Hauke> yes the broadcom guys change the structure a bit
Jul 30 19:35:24 <Hauke> when you want to work on bcm5301X you should use kernel 3.14 in OpenWrt
Jul 30 19:35:26 <zajec> did you send your OpenWrt patches upstream?
Jul 30 19:36:08 <Hauke> yes they are in kernel 3.15, but the stuff with nvram sprom and bcma integration is only in OpenWrt for now
Jul 30 19:36:09 <zajec> a lot of questions today ;)
Jul 30 19:36:19 <zajec> oh, i was thigkin about bcma ;)
Jul 30 19:36:21 <zajec> ok
Jul 30 19:36:58 <zajec> Hauke: any idea about my SPI question?
Jul 30 19:37:03 <Hauke> I hope I find the time to get it into kernel 3.18
Jul 30 19:38:27 <Hauke> no idea you should probably talk to Brian Norris or [florian]
Jul 30 19:38:47 <[florian]> brian knows better about this SPI controller than I do
Jul 30 19:40:30 <zajec> yeah, I put Brian in "to"
Jul 30 19:40:48 <zajec> what's his IRC nick?
Jul 30 19:40:57 <zajec> you happen to remember
Jul 30 19:40:58 <zajec> ?
Jul 30 19:41:24 <[florian]> cfp
Jul 30 19:41:29 <[florian]> not sure if he is on freenode
Jul 30 19:41:32 <[florian]> he is on oftc
Jul 30 19:41:52 <zajec> yeah, i'm there
Jul 30 19:46:15 <zajec> Hauke: do you think we could switch to 3.14 in trunk?
Jul 30 19:46:21 <zajec> Hauke: at least for bcm53xx?
Jul 30 19:47:22 <Hauke> yes I will do that
Jul 30 19:47:31 <Hauke> this will not get into BB
Jul 30 19:47:37 <Hauke> bcm53xx
Jul 30 19:47:52 <zajec> of course
Jul 30 19:48:00 <zajec> i was talking about trunk :)
Jul 30 19:48:47 <Hauke> 3.14 contains some additional functionality
Jul 30 19:48:53 <Hauke> the pcie stuff is only there
Jul 30 19:49:00 <zajec> cool
Jul 30 19:49:06 <Hauke> I was too lazy to add it to 3.10
Jul 30 19:49:10 <zajec> i vote for switching asap :)
Jul 30 19:54:16 <zajec> Hauke: i wanted to send patch like that: http://pastebin.com/iVExcpiW
Jul 30 19:54:49 <zajec> without this we have BCMA_CORE_PCIE2 and BCMA_CORE_PCIEG2 which is quite confusing
Jul 30 19:56:57 <Hauke> I fine with that
Jul 30 20:04:07 <Hauke> the write to the B43_PHY_B_BBCFG register causes the problem
Jul 30 20:05:13 <Hauke> zajec: http://pastebin.com/t7EnqT8j
Jul 30 20:10:53 <zajec> i'm still not sure abuot this
Jul 30 20:11:02 <zajec> can you comment out this BBCFG operation?
Jul 30 20:11:04 <zajec> and check again?
Jul 30 20:11:10 <zajec> maybe it's some delayed crash
Jul 30 20:14:34 <zajec> Hauke: i compared 0xc01 ops between b43 and wl.ko, they seem identical
Jul 30 20:14:40 <zajec> for my BCM43224 PCIe card
Jul 30 20:16:17 <Hauke> brcmsmac would go into the 2GHz path in this situation in wlc_phy_chanspec_nphy_setup()
Jul 30 20:16:28 <zajec> er?
Jul 30 20:16:40 <Hauke> it does this: val = read_phy_reg(pi, 0x09) & NPHY_BandControl_currentBand; and it returns 0x1
Jul 30 20:16:53 <builder_> build #622 of avr32 is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/622
Jul 30 20:17:07 <Hauke> no it would not do anything
Jul 30 20:17:17 <zajec> have to go afk for a sec
Jul 30 20:18:11 <zajec> Hauke: http://pastebin.com/q6S0aQUy
Jul 30 20:18:45 <Hauke> for me phy_read(0x0009) -> 0x0000 returns 0x0001 in this case
Jul 30 20:19:30 <Hauke> b43_nphy_channel_setup() gets called 2 times when I want to start an AP in OpenWrt
Jul 30 20:19:46 <Hauke> the first time 0x0009 is 0x0 and every thing is fine
Jul 30 20:20:03 <Hauke> the 2. time it is 0x1 and it runs into an error
Jul 30 20:21:12 <Hauke> let me test some stuff I saw in brcmsmac
Jul 30 20:22:42 <Hauke> now it comes up
Jul 30 20:23:58 <Hauke> but serial broke :-(, looks like a hardware problem with my high quality equipment ;-)
Jul 30 20:35:32 <Hauke> zajec: got it working
Jul 30 20:35:38 <Hauke> will send a patch
Jul 30 20:39:58 <Hauke> zajec: http://pastebin.com/PNEQW77d
Jul 30 20:44:07 <zajec> Hauke: i don't get it
Jul 30 20:44:17 <zajec> Hauke: this is something i've recently removed
Jul 30 20:44:59 <zajec> Hauke: http://git.kernel.org/cgit/linux/kernel/git/linville/wireless-next.git/commit/?id=c9325e2f2435d93117e9336d72754b68abda26d4
Jul 30 20:45:20 <zajec> i'm quite sure wl.ko does it every time...
Jul 30 20:45:24 <Hauke> it looks like the hardware does not like it being switched to 5ghz when it is already there
Jul 30 20:45:24 <zajec> let me think about this, ok?
Jul 30 20:45:40 <zajec> i'll show you sth, sec
Jul 30 20:45:51 <Hauke> this is based on brcmsmac
Jul 30 20:45:57 <Hauke> and it fixes my problem
Jul 30 20:46:14 <zajec> brcmsmac is old
Jul 30 20:46:17 <zajec> wl.ko is newer
Jul 30 20:46:25 <Hauke> yes I know
Jul 30 20:46:37 <zajec> as I said, give me a a bit of time
Jul 30 20:46:45 <zajec> i'm sure wl.ko switches band every time
Jul 30 20:46:53 <zajec> it just does it a bit differently
Jul 30 20:46:55 <Hauke> but why do you have the read of 0x0009 in your mimo dump?
Jul 30 20:46:56 <zajec> but it always switches
Jul 30 20:47:01 <zajec> that's correct
Jul 30 20:47:08 <zajec> that what i want tos how
Jul 30 20:52:05 <Hauke> do you have some mimo dump of wl where it is already on that band?
Jul 30 20:52:20 <zajec> working on that
Jul 30 20:52:27 <Hauke> thanks
Jul 30 20:55:29 <zajec> ok, you're right... so far i was comparing dumps of first channeli switches only
Jul 30 20:55:33 <zajec> i was ignoring 5 GHz
Jul 30 20:55:37 <zajec> and didn't spot this mistake in my code
Jul 30 20:56:46 <Hauke> zajec: do you want to send a patch or should I?
Jul 30 20:56:55 <zajec> i'll
Jul 30 20:56:56 <Hauke> thanks for analysing
Jul 30 20:56:57 <zajec> with a comment
Jul 30 20:57:00 <zajec> and explanation
Jul 30 20:57:10 <Hauke> yes that was still missing in my version
Jul 30 21:00:21 <zajec> Hauke: http://pastebin.com/qtPrK2un
Jul 30 21:01:25 <Hauke> so it sets it back to 2GHz and in the 2. 3. , strange
Jul 30 21:02:48 <zajec> that's right
Jul 30 21:02:56 <zajec> this is because BBCFG is specific for 2 GHz
Jul 30 21:03:12 <zajec> we disable it for 5 GHz mode
Jul 30 21:03:21 <zajec> so I guess this register is totally unavailable in 5 GHz mode
Jul 30 21:03:38 <zajec> so it switches back to 2GHz for a moment, just to make sure BPHY is in the reset state
Jul 30 21:03:42 <zajec> thanks  a lot for noticing this!
Jul 30 21:03:49 <zajec> and tracking!
Jul 30 21:03:59 <Hauke> noticing was not the problem ;-)
Jul 30 21:04:10 <zajec> ;p
Jul 30 21:15:38 <zajec> Hauke: so you're working on updating b43? :)
Jul 30 21:16:25 <Hauke> zajec: yes
Jul 30 21:18:07 <OpenWrt-Commits> hauke r41900 trunk/package/kernel/mac80211/patches/ (7 files) * mac80211: b43: update b43 to version master-2014-07-29-1
Jul 30 21:18:19 <zajec> wow :0
Jul 30 21:18:20 <zajec> cool :D
Jul 30 21:18:28 <Hauke> yes
Jul 30 21:18:59 <zajec> oh... will you do the same for 14.09?
Jul 30 21:19:08 <zajec> it would be cool to have at least 5 GHz support in 14.09
Jul 30 21:19:12 <Hauke> probably yes
Jul 30 21:19:18 <zajec> cool ^ 2 :)
Jul 30 21:22:44 <zajec> Hauke: i don't love wl, but https://dev.openwrt.org/ticket/17262 should be fixed for 14.07 i think
Jul 30 21:23:00 <zajec> somebody changed milestone from BB to CC
Jul 30 21:27:44 <zajec> Hauke: could you close https://dev.openwrt.org/ticket/17298 as duplicate?
Jul 30 21:30:30 <zajec> Hauke: one last thing... did you try to compile bcm53xx after your bcma update?
Jul 30 21:30:39 <Hauke> no
Jul 30 21:30:40 <zajec> i think it could break 160-bcma-add-PCI-IDs-for-more-devices.patch
Jul 30 21:31:11 <zajec> btw, adding "{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4360) }," is a bad idea as long as we don't support PCIe Gen 2 as host
Jul 30 21:54:36 <Hauke> zajec: good night
Jul 30 23:12:48 <nighty^> anybody has worked with the WD MyCloud device ? ( Mindspeed C2000 ( ARM ) )
Jul 30 23:51:58 <builder_> build #687 of orion is complete: Failure [failed compile_8]  Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/687
Jul 31 00:04:00 <builder_> build #546 of iop32x is complete: Failure [failed shell_9]  Build details are at http://buildbot.openwrt.org:8010/builders/iop32x/builds/546
Jul 31 00:14:07 <builder_> build #247 of imx6 is complete: Failure [failed shell_14]  Build details are at http://buildbot.openwrt.org:8010/builders/imx6/builds/247
Jul 31 01:29:43 <brnt> please don’t hate me for not subscribing to the openwrt-devel mailing list, but…
Jul 31 01:29:54 <brnt> can somebody look at this and send it to the list so that it makes it into the system?
Jul 31 01:29:55 <brnt> http://pastebin.com/G7TFFEde
Jul 31 01:30:08 <brnt> [PATCH] [ar71xx] oolite: corrected directionality of button
Jul 31 01:31:55 <karlp> you only nee dto subsribe for 10 minutes, to do a git-send-email and unsubscribe
Jul 31 01:32:29 <karlp> you're also really rough on timing, if you're on the mailing list, you can try and ask to get this in before the BB final,
Jul 31 01:32:41 <karlp> a pastebin on irc has, at a guess, slim to no chance of making the cut
Jul 31 01:32:51 <brnt> understood :-)
Jul 31 01:39:27 <brnt> done. phew. so much work just to report three characters’ worth of diff :-)
Jul 31 01:41:37 <karlp> hrm, patchwork seems to have munched it on something: http://patchwork.openwrt.org/patch/6021/
Jul 31 01:42:27 <brnt> wow, i wonder what happened there…
Jul 31 01:44:19 <brnt> do i need to do anything to fix/resubmit that?
Jul 31 01:44:26 * karlp shrugs
Jul 31 01:51:29 <builder_> build #134 of adm8668 is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/adm8668/builds/134
Jul 31 02:09:48 <builder_> build #533 of mcs814x is complete: Failure [failed shell compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/mcs814x/builds/533
Jul 31 02:15:38 <builder_> build #228 of mvebu is complete: Failure [failed compile_5]  Build details are at http://buildbot.openwrt.org:8010/builders/mvebu/builds/228
**** ENDING LOGGING AT Thu Jul 31 03:00:00 2014