**** BEGIN LOGGING AT Mon Jan 18 02:59:58 2016 Jan 18 04:31:52 I resubmitted a patch - is it OK now? Jan 18 04:31:53 Allow UCI dhcp classifier to accept a list of MAC Jan 18 06:40:56 luka r48298 trunk/target/linux/imx6/Makefile * imx6: move to 4.4 kernel Jan 18 06:44:28 luka r48299 trunk/target/linux/ imx6/files-4.3 imx6/config-4.3 imx6/patches-4.3 * imx6: drop 4.3 support Jan 18 06:44:30 luka r48300 trunk/target/linux/ imx6/files-4.1 imx6/config-4.1 imx6/patches-4.1 * imx6: drop 4.1 support Jan 18 09:23:58 jow r48301 trunk/package/libs/libiconv/src/include/iconv.h * package/libs/libiconv: function names Jan 18 09:26:42 Is it required that every router has to have a selectable profile in menuconfig ? if not #21628,#19645 could be closed Jan 18 10:47:27 jogo r48302 trunk/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h * b53: update header register difinitions Jan 18 10:47:30 jogo r48303 trunk/target/linux/ brcm63xx/patches-4.1/377-MIPS-BCM63XX-register-lookup-for-ephy-reset-gpio.patch brcm63xx/patches-4.1/378-MIPS-BCM63XX-do-not-register-gpio-controller-if-pres.patch brcm63xx/patches-4.4/378-MIPS-BCM63XX-do-not-register-gpio-controller-if-pres.patch brcm63xx/patches-4.4/377-MIPS-BCM63XX-register-lookup-for-ephy-reset-gpio.p Jan 18 10:47:31 OpenWrtatch * brcm63xx: fix platform gpio lookups for gpios < 32 Jan 18 10:47:38 jogo r48304 trunk/target/linux/ipq806x/base-files/lib/upgrade/platform.sh * ipq806x: fix sysupgrade for AP148 Jan 18 10:48:03 jogo r48305 trunk/target/linux/ (11 files in 10 dirs) * brcm63xx: add support for Huawei HG622 Jan 18 11:12:06 nbd r48306 trunk/package/utils/busybox/patches/010-networking-fix-uninitialized-memory-when-displaying-.patch * busybox: fix broken IPv6 address displaying in ifconfig Jan 18 11:41:00 nbd r48307 trunk/target/linux/ (36 files in 2 dirs) * lantiq: Add support for linux 4.4 Jan 18 11:41:19 nbd r48308 trunk/package/kernel/ lantiq/ltq-deu/src/ltq_deu_testmgr.c lantiq/ltq-deu/src/ifxmips_testmgr.h lantiq/ltq-deu/src/Makefile * lantiq: ltq-deu: Remove the "DEU test manager" Jan 18 11:41:24 nbd r48309 trunk/package/network/services/hostapd/files/netifd.sh * wpa_supplicant: improve generating phase2 config line for WPA-EAP Jan 18 11:41:29 nbd r48310 trunk/target/linux/generic/patches-4.4/010-Kbuild-don-t-hardcode-path-to-awk-in-scripts-ld-vers.patch * kernel: fix MIPS linux-4.4 build on non-GNU systems Jan 18 11:45:40 any more changes planned for CC before the .1 release Jan 18 11:45:41 ? Jan 18 11:45:52 none that i know of Jan 18 11:46:44 ok, going to fininsh these 4 wndr3800's then and bring them to client Jan 18 12:42:43 nbd r48311 trunk/target/linux/brcm2708/base-files/lib/brcm2708.sh * brcm2708: fix RPi model B plus support Jan 18 12:42:49 nbd r48312 trunk/package/libs/openssl/Config.in Jan 18 12:42:49 openssl: remove the separate configuration menu, use the implicit one (via MENU:=1) Jan 18 12:48:16 nbd r48313 trunk/config/Config-build.in * build: use sstrip by default for musl Jan 18 13:22:12 nbd r48314 trunk/package/network/utils/iptables/Makefile * iptables: fix rebuild errors on configuration changes Jan 18 13:22:17 nbd r48315 trunk/package/network/config/firewall/Makefile * firewall: add CONFIG_IPV6 to PKG_CONFIG_DEPENDS to fix a rebuild error Jan 18 13:23:14 nbd r48316 trunk/target/linux/ramips/modules.mk * ramips: fix kernel config handling for mt7620/mt7628 sound module Jan 18 13:23:18 nbd r48317 trunk/target/linux/ramips/modules.mk * ramips: mark kmod-sound-mtk as broken, it does not compile properly Jan 18 13:40:52 karlp: there's anotheri ssue with mosquitto Jan 18 13:40:55 nbd r48318 trunk/target/linux/ ramips/patches-4.3/0050-alsa-add-ralink-sdk-driver.patch ramips/modules.mk * ramips: delete the broken sound driver Jan 18 13:41:34 karlp: now you always attempt to package mosqitto_passwd if the config option is set but it can't possibly exist for the nossl build variant Jan 18 13:41:56 karlp: you need to wrap this into a further ifneq ($(BUILD_VARIANT),nossl) ... endif Jan 18 13:44:16 Is OpenWRT's OpenSSH updated to fix that recent CVE yet? Jan 18 13:44:21 karlp: http://pastebin.com/T7yFaC1U Jan 18 13:44:43 mamarley: https://lists.openwrt.org/pipermail/openwrt-security-announce/2016-January/000000.html Jan 18 13:45:14 jow_laptop: Thanks! Jan 18 14:14:13 jow_laptop: https://dev.openwrt.org/ticket/19645 can be closed - I added a little info in dev faq (https://wiki.openwrt.org/doc/faq/development) Jan 18 14:44:19 hi Jan 18 14:44:54 i have an question, after i flashed my tp link device telnet isn't available and i could directly login with ssh without a password Jan 18 14:45:12 does this mean that dropbear accepts users logins that have no password setß Jan 18 14:45:15 ? Jan 18 14:47:15 okay found the explaination : https://dev.openwrt.org/changeset/46809 Jan 18 15:35:58 nbd r48319 trunk/target/linux/lantiq/base-files/etc/board.d/02_network * lantiq: fix VDSL device detection with Linux 4.4 Jan 18 15:36:05 nbd r48320 trunk/package/network/utils/linux-atm/patches/500-br2684ctl_script.patch * br2684ctl: add support for notifying nas* bringup via a script Jan 18 15:36:10 nbd r48321 trunk/package/network/utils/ linux-atm/Makefile linux-atm/files/br2684ctl linux-atm/files/br2684-up Jan 18 15:36:10 br2684ctl: resolve a boot time race condition with nas0 bringup by using explicit notification when init is done Jan 18 15:48:27 jow_laptop: but the config option can't be set if you're not building the no-ssl variant? unless you're modifying the config by hand? Jan 18 15:50:45 karlp: I noticed while trying to refresh the mosquitto binaries for CC Jan 18 15:51:10 how does the config get generated for that? Jan 18 15:51:29 if you turn on the no-ssl in menuconfig it doesn't try and include it, Jan 18 15:51:30 karlp: doesn't matter - variants can be built concurrently Jan 18 15:51:56 if both ssl and nossl is enabled and ssl enables passwd, we'll attempt to package the passwd variant in the nossl variant as well Jan 18 15:52:06 oh, if _both_ are turned on. Jan 18 15:52:09 *package the passwd binary Jan 18 15:52:10 oh right, Jan 18 15:52:22 who on earht (other than you) woudl do that.... Jan 18 15:52:29 bloody hell, mega fail on me Jan 18 15:52:30 buildbots Jan 18 15:52:36 sdk builds Jan 18 15:52:41 config_all builds Jan 18 15:52:46 :) Jan 18 15:53:13 in that case I could also make the target for /install be based on the no-ssl, instead of no-ssl copying the ssl variant Jan 18 15:53:22 right Jan 18 15:53:24 and then the ssl could _add_ the mosquitto password if it was enabled. Jan 18 15:53:48 yes Jan 18 15:54:19 I held off on this for ages while I tested it on my old BB branch and CC and trunk and still mangled it so badly :| Jan 18 15:54:46 ok, I'll go fix my mess, thanks for pointing this out. Jan 18 15:54:50 np Jan 18 15:54:58 nbd r48322 trunk/target/linux/lantiq/Makefile * lantiq: switch to linux 4.4 Jan 18 15:55:03 nbd r48323 trunk/target/linux/ lantiq/patches-4.1 lantiq/config-4.1 * lantiq: drop linux 4.1 support Jan 18 16:08:35 Hey, I can't build trunk anymore with CONFIG_PACKAGE_tor-fw-helper=y. I've seen this in package sources: Jan 18 16:08:46 We no longer recommend the use of this tool. Instead, please use the Jan 18 16:08:47 pure-Go version of tor-fw-helper available at Jan 18 16:08:49 https://gitweb.torproject.org/tor-fw-helper.git Jan 18 16:09:07 (hope this doesn't count as spam). Should I think about adjusting package feeds? Jan 18 16:09:31 msgctl: we do not support Go on openwrt Jan 18 16:10:07 so we should probably remove it completely Jan 18 16:10:27 I see, thanks! Jan 18 16:10:36 jow_laptop: what's the problem with Go? Jan 18 16:11:06 its big Jan 18 16:15:41 like 2.5MB for a static hello world big Jan 18 16:16:18 thats like 60%-90% of the entire available space for many targets Jan 18 16:17:07 jow_laptop: why not support it on opt-in basis? Jan 18 16:17:31 because last time someone tried to add it it didn't work with the default uclibc Jan 18 16:17:41 and since then nobody tested against musl Jan 18 16:17:57 and since its too huge to be useful for most users the interest in it is quite low Jan 18 16:19:08 on top of that it cannot be added via feeds but most be built along with the cross toolchain Jan 18 16:19:13 I see Jan 18 16:19:14 s/most/must/ Jan 18 16:20:15 what was wrong with the C code? Jan 18 16:20:50 let me post it in full Jan 18 16:22:11 >README Jan 18 16:22:13 Why? Jan 18 16:22:15 Jan 18 16:22:17 The C code here was fine, but frankly: we don't trust the underlying Jan 18 16:22:19 libraries. They don't seem to have been written with network security Jan 18 16:22:21 in mind, and we have very little faith in their safety. Jan 18 16:22:23 Jan 18 16:22:31 ----8<---- Jan 18 16:23:57 complain to tor that go isn't appropriate? Jan 18 16:25:16 we should support Rust :) Jan 18 16:25:59 you can run rust already Jan 18 16:26:04 but it suffers from much the same problems Jan 18 16:26:06 huge binaries Jan 18 16:26:42 I haven't tried since oct 2014 mind you: http://false.ekta.is/2014/10/rust-on-openwrt-baby-steps/ Jan 18 16:26:55 sure. but if supporting any of those type of languages, Rust would be what I'd want to see... Jan 18 16:27:11 sure, many people want to see node.js Jan 18 16:27:20 or whatever crap is hot this week Jan 18 16:27:43 php is wehere it's at y0 Jan 18 16:29:03 what about llvm? wouldn't that at least ease the pain of integrating cross-target support for every fashion-lang individually? Jan 18 16:29:57 dangole: llvm vs gcc doesn't change much if the project you want to compile uses explicit things for an arch Jan 18 16:30:06 msgctl: thanks for the insight. I'm not sure how to go on from here - there's no roadmap or eta for having Go available in openwrt and from my totally-not-tor-involved objective pov you're replacing a 52K C binary with one thatsl ikely going to eat up several MB of space Jan 18 16:30:17 that's the issue with node (depends on v8, with gobs of asm optimization) same for luajit for instance. Jan 18 16:30:44 msgctl: ... which will limit its usefulness for a large number of users. If you say there are security issues with the C implementation then we can flag it as broken so that its not getting built anymore Jan 18 16:31:29 and eventually make it available again once we have Go support Jan 18 16:33:26 jow_laptop: thank you for your input, I'll see what they'll say on #tor-dev. Jan 18 16:34:05 karlp: that's not what i meant. there are llvm frontends for many fancy languages including Go, Rust, jxcore, ... Jan 18 16:34:36 dangole: as usual, someone has to do the work :) Jan 18 16:34:45 jow_laptop: and... that's my exact problem ;-) We were trying to release http://netaidkit.net this week. Jan 18 16:35:06 dangole: are you saying there's another _implementation_ of rust explicitly for llvm? Jan 18 16:36:05 karlp: Rust original implementation *is* an LLVM frontend Jan 18 16:36:38 karlp: ... and there is a Golang frontend as well as JavaScript/NodeJS frontend (jxcore) Jan 18 16:37:01 but you need gcc to compile it's source? I maybe missing something, but the size of rust binaries, and the target work include in many projects like node.js and luajit doesn't mean they magically get fixed by simply saying "use llvm" Jan 18 16:37:37 no-ones stopping you or anyone from doing work ong packaging these, just that traditionally, it's gone into the too hard basket. Jan 18 16:39:45 uhm Jan 18 16:39:51 how does one build a go program? Jan 18 16:41:29 ah, its one these remote code loaders Jan 18 16:42:30 lol Jan 18 16:43:53 seriously, this is already taking too long Jan 18 16:44:06 just tried to quickly build that nat-fw-helper to get a rough estimate Jan 18 16:44:17 no makefiles, no configure or traces of any other known build system Jan 18 16:44:30 instead I wants me to set up a workspace (?) Jan 18 16:44:51 and apparently I have to mkdir -p a bunch of source dirs and cloen stuff into it? Jan 18 16:45:45 jow Jan 18 16:45:48 was thinking about the partition stuff Jan 18 16:45:51 got some ideas im going to try out Jan 18 16:47:19 my attempts: http://pastebin.com/x4sTfT9Z Jan 18 16:53:21 -rw-r--r-- 1 jow jow 6,6K Jan 18 17:54 main.go Jan 18 16:53:21 -rwxr-xr-x 1 jow jow 6,1M Jan 18 17:55 tor-fw-helper Jan 18 16:53:30 seriously -- wtf guys?! Jan 18 16:53:56 we stuff an entire operating system plus gui webserver and crypto support into that, with space to spare for additional packages Jan 18 16:54:17 "no package problems" Jan 18 16:54:24 it's ok guys, static linking is cool Jan 18 16:54:34 six fucking megabyte to send a bunch of xml to an udp socket? are you out of your mind?! Jan 18 17:00:49 lol Jan 18 17:02:51 okay, excuse the rant above please. I did hope that the reported executable sizes are exaggerated but apparently they aren't. I also tried to strip the resulting executable but that still leaves a 4.4 MB binary Jan 18 17:03:24 allegedly it is somehow possible to build a shared runtime but I suspect the resulting libgo.so will be quite huge still Jan 18 17:03:51 but all your apps are written in go now right? this is the future! Jan 18 17:04:29 i also heard that go garbage collection really sucks on 32 bit machines Jan 18 17:04:36 because it was pretty much designed for 64 bit Jan 18 17:05:53 seems to me like we could emulate tor-fw-helper using a shell script or wrapper binary which calls upnpc or something Jan 18 17:06:26 even bundled with a Lua runtime and liberal use of 3rd party libs it would still be smaller Jan 18 17:09:42 --fetch-public-ip => upnpc -e / --forward-port => upnpc -a / --unforward-port => upnpc -d / --list-ports => upnpc -l Jan 18 17:10:40 you're just going to get them complainging that "while the lua and shell looks ok, we simply don't trust that the underlying libraries were written with security in mind" Jan 18 17:16:57 karlp: I don't think any bad things were intended here, people just forget about small platforms. For most people embedded is something with a touchscreen nowadays Jan 18 17:20:23 bleh, I want to just get rid of this mosquitto-nossl package altogether :| Jan 18 17:20:23 jow_laptop: you forget that some ppl advertise systemd for embedded too for example Jan 18 17:20:38 can someone merge this? Required for building on 4.3+ https://github.com/openwrt/packages/pull/2277 Jan 18 17:21:13 karlp: do it then. I suppose users using mosquitto can afford the ssl overhead Jan 18 17:21:14 I was led to believe that systemd was much much smaller than golang stuff, Jan 18 17:21:44 jow_laptop: well, actually, mosquitto byitself is tiny, it's adding in openssl and then libwebsockets that grow it a lot Jan 18 17:21:57 just trying to fix up the libwebsockets-nossl now :) Jan 18 17:22:46 I guess this is the same problem when building both variants at the same time though? I thought this worked before, but I'd never tried building both in the past. Jan 18 17:23:34 https://trac.torproject.org/projects/tor/ticket/13338 - "I wrote my own UPnP client, because of licensing, code quality/auditability concerns, and not-invented-here reasons." Jan 18 17:24:12 sounds like totally legit reasons Jan 18 17:24:33 isnt arma the nick of jacob applebaum? Jan 18 17:25:21 next step: writing platform specific code to query default routes: "Dumping the routing table is not portable, and currently only the Linux code to pull the default gateway from the routing table is written." Jan 18 17:26:03 ah no arma is Roger Dingledine Jan 18 17:41:20 nbd r48324 trunk/target/linux/generic/patches-4.4/010-Kbuild-don-t-hardcode-path-to-awk-in-scripts-ld-vers.patch * kernel: fix a build regression in the ld-version script fix Jan 18 17:52:29 http://pastebin.com/A34LqZz1 neat things coming soon ;) Jan 18 17:52:35 nbd r48325 trunk/target/linux/arc770/dts/axs101.dts * arc770/axs101: fix console output Jan 18 17:52:47 nbd r48326 trunk/ target/linux/arc770/Makefile include/target.mk * arc: clean-up and move CFLAGS to include/target.mk Jan 18 18:01:37 jow_laptop: redid that mosquitto_passwd thing: https://github.com/openwrt/packages/pull/2283 Jan 18 18:01:58 that built both of them on trunk in the same build, Jan 18 18:41:23 How imminent are plans to migrate ar91xx platform to 4.4? Jan 18 19:36:17 I resubmitted a patch - is it OK now? Jan 18 19:36:17 Allow UCI dhcp classifier to accept a list of MAC Jan 18 19:38:16 KevinDB: I believe the plan is _all_ go to 4.4 before the DD release. Jan 18 19:38:18 No - wait - just found an email response. Jan 18 19:54:06 KevinDB: ar71xx will migrate once the devs manage to port all the patches to 4.4 kernel - ar71xx is more complex compared to other platforms (see # platform patches) Jan 18 19:57:03 Thanks - I manually went from 4.1.13 to 4.1.15 and that was interesting enough for me :-) Jan 18 19:59:28 i once did a kernel update myself - but I was lazy and skipped most of ar71xx patches since many are device specific ^^ Jan 18 20:16:55 nbd: since r48277 I have a missing symbol CRYPTO_DRBG_HMAC Jan 18 20:17:01 I can add it to the crypto-rng package as well Jan 18 20:17:17 nbd r48327 trunk/target/linux/generic/patches-4.4/645-bridge_multicast_to_unicast.patch * kernel: fix uninitialized variable in bridge multicast-to-unicast patch on 4.4 Jan 18 20:17:30 with =y, but it would need crypto-hmac Jan 18 20:17:47 maybe I should Jan 18 20:18:05 https://bpaste.net/show/1d86a9280fd1 Jan 18 20:18:16 but CONFIG_CRYPTO_DRBG_HMAC defaults to y Jan 18 20:18:22 so not sure what is the best solution here Jan 18 20:40:44 hauke r48328 trunk/ (5 files in 5 dirs) * lantiq: add support for TP-Link VR200v Jan 18 20:41:43 I'll just send a patch :) Jan 18 20:41:59 how I think it should be Jan 18 20:43:30 hmm, if something depends on hmac, and since hmac depends on hash, should I remove the explicit dependency for hash, or leave it ? Jan 18 22:38:19 nbd: ok, so i have compiled kernel 4.3.3 again, and the mt76 cards are still unusable. Can the reason be that i do not use compat-wireless, but instead i copy the mt76 sources into kernel/drivers/net/wireless/mediatek and change Kconfigs and Makefiles appropriately, so that kernel's Makefile compiles mt76pci.ko without compat wireless? Jan 18 22:38:31 nbd r48329 trunk/target/linux/cns3xxx/files/drivers/net/ethernet/cavium/cns3xxx_eth.c * cns3xxx: remove unused define and use of a deprecated function Jan 18 22:38:38 nbd r48330 trunk/target/linux/cns3xxx/files/arch/arm/mach-cns3xxx/localtimer.c * cns3xxx: remove obsolete file Jan 18 22:38:43 nbd r48331 trunk/target/linux/ (6 files) * cns3xxx: fix adding twd local timers Jan 18 22:38:49 nbd r48332 trunk/target/linux/ cns3xxx/files/arch/arm/mach-cns3xxx/headsmp.S cns3xxx/files/arch/arm/mach-cns3xxx/platsmp.c * cns3xxx: clean up SMP related code Jan 18 22:38:54 nbd r48333 trunk/target/linux/cns3xxx/files/drivers/net/ethernet/cavium/cns3xxx_eth.c * cns3xxx: fix a ethernet driver napi poll handling bug Jan 18 22:39:04 nbd r48334 trunk/target/linux/ (29 files in 3 dirs) * cns3xxx: update to linux 4.4 Jan 18 22:39:12 kab-el: yes, that's a very likely reason Jan 18 22:39:35 hmm Jan 18 22:39:43 now please test openwrt at least once before asking me about mt76 again Jan 18 22:40:15 i already tested it, openwrt worked fine (just, as nitroshift said, with the 4.3 kernel it was slower than with 3.x) Jan 18 22:40:23 ah, ok Jan 18 22:40:39 ~2.5MB/s, but stable Jan 18 22:40:40 then you should start using compat-wireless Jan 18 22:40:43 we don't use the in-kernel stuff for a reason Jan 18 22:40:50 it's usually too old Jan 18 22:40:52 ok, thanks Jan 18 22:41:06 how fast was it with 3.x? Jan 18 22:41:30 i don't tested it myself, but i think nitroshift said it was 20 MB/s or so Jan 18 22:41:50 in what kind of test? Jan 18 22:41:56 dont know Jan 18 22:42:09 ah, so you're potentially comparing apples and oranges here ;) Jan 18 22:42:28 i can try to compile specific openwrt commit Jan 18 22:42:52 in my test i did see around 230 mbit/s when routing traffic between two witi devices over wireless in ad-hoc mode Jan 18 22:43:13 with kernel 4.3 ? Jan 18 22:43:14 this is limited by the rx performance, which isn't very good with mt76x2 and mt7621 Jan 18 22:43:17 yes Jan 18 22:43:25 tested recently, with the latest stuff Jan 18 22:43:39 ok, i shall try compat wireless Jan 18 22:43:46 maybe try to compare with witi's stock firmware Jan 18 22:46:33 nbd: reviewing hostapd/wpa_supplicant netifd integration, i noticed that when enforcing a WPA cipher, this only ever happens to have any effect for AP mode Jan 18 22:47:28 nbd: and only set the pairwise=CCMP or such in hostapd.conf, keeping the selection 'group' ciphers untouched Jan 18 22:47:52 hm Jan 18 22:47:59 yeah, i guess we should set the group ciphers explicitly too Jan 18 22:48:12 nbd: was that part, only setting pairwise and not setting group, done so on purpose? is there good reason not to touch the selection of group cipher as well? Jan 18 22:48:46 i don't think that was done on purpose Jan 18 22:48:47 nbd: and have them configurable individually or just set both to what is currently extracted from the 'encryption' option Jan 18 22:49:10 i don't think it makes sense to configure them individually Jan 18 22:49:19 people should just use CCMP anyway ;) Jan 18 22:49:28 TKIP is not usable with 802.11n aynway Jan 18 22:49:58 btw. have you attempted to update the kernel on oxnas yet? Jan 18 22:50:13 sure, so it makes total sense to just rename that variable (currently $wpa_pairwise coming from netifd-wireless.sh Jan 18 22:50:40 i just spent some hours debugging a nasty issue with cns3xxx on 4.4, only to find that enabling CONFIG_CPU_SW_DOMAIN_PAN makes user space crash very early Jan 18 22:50:54 since the oxnas cpu is similar, maybe this piece of information can save you some time ;) Jan 18 22:51:04 sounds like what i'm suffering from on oxnas Jan 18 22:51:15 this stuff was added with linux 4.3 Jan 18 22:51:38 i only found it because i tested 4.1-4.4 individually and found that 4.2 -> 4.3 broke it Jan 18 22:52:10 i reviewed the changes since 4.1 a lot of times and there were some phishy changes around that arm_introduce-dma-fiq-irq-broadcast stuff, too Jan 18 22:52:20 those were easy to fix Jan 18 22:52:32 two functions moved to arch/arm/mm/dma.h Jan 18 22:52:36 yeah, but apart from that and stmmac stuff, it was all straight forward for oxnas Jan 18 22:52:47 yet userspace crashes early Jan 18 22:53:00 ok, then i guess it will work if you disable CONFIG_CPU_SW_DOMAIN_PAN ;) Jan 18 22:53:30 maybe it needs a 'depends on !CPU_V6' Jan 18 22:53:32 no idea Jan 18 22:53:38 cool, i can check if i had that enabled in the target kernel config and post the patchset as RFC, so people with the hardware can test it Jan 18 22:53:57 it was enabled by default for me when i forward ported the config Jan 18 22:54:25 it's =y in the generic config Jan 18 22:55:07 yep, guessed so, it didn't occur to me as a oldconfig question when upgrading Jan 18 22:55:36 so i just add the # CONFIG_CPU_SW_DOMAIN_PAN is not set to target/linux/oxnas/config-4.4 and that should do it? Jan 18 22:55:42 yes Jan 18 22:55:47 ha, this seems to be a known issue Jan 18 22:55:47 nice one Jan 18 22:55:48 http://permalink.gmane.org/gmane.linux.ports.arm.kernel/445910 Jan 18 23:15:20 dangole: the fix from that thread resolves the issue Jan 18 23:15:27 i'll push it to generic-4.4 Jan 18 23:20:58 nbd r48335 trunk/target/linux/generic/patches-4.4/100-ARM-work-around-CONFIG_CPU_SW_DOMAIN_PAN-breakage-on.patch * kernel: work around CONFIG_CPU_SW_DOMAIN_PAN breakage on ARM11 MPCore Jan 18 23:21:13 dangole: there, now you don't need to change the config anymore ;) Jan 18 23:21:19 nbd r48336 trunk/target/linux/cns3xxx/config-4.4 * cns3xxx: re-enable CONFIG_CPU_SW_DOMAIN_PAN Jan 18 23:22:51 dangole: do you want to send v2 without the config override, or should i take your current series? Jan 18 23:29:22 nbd: you reckon it matters? if so, i'll send a an update version of the patch adding config-4.4 Jan 18 23:29:42 it's not critical, just a potentially useful kernel security feature Jan 18 23:35:23 nbd r48337 trunk/target/linux/ oxnas/base-files/etc/board.d/01_leds oxnas/base-files/lib/oxnas.sh oxnas/base-files/etc/diag.sh * oxnas: fix the incorrect board names Jan 18 23:35:31 nbd r48338 trunk/target/linux/ oxnas/files/arch/arm/mach-oxnas/mach-ox820.c oxnas/files/drivers/irqchip/irq-rps.c * oxnas: prepare platform and drivers for Linux 4.4 Jan 18 23:35:40 nbd r48339 trunk/target/linux/ (16 files in 2 dirs) * oxnas: add patches and config for Linux 4.4 Jan 18 23:35:45 nbd r48340 trunk/target/linux/oxnas/Makefile * oxnas: switch to Linux 4.4 Jan 18 23:35:53 nbd r48341 trunk/package/kernel/linux/modules/crypto.mk * kernel/modules: add missing symbol for crypto-rng Jan 18 23:35:59 nbd r48342 trunk/target/linux/generic/config-4.1 * kernel: add missing symbols for 4.1 Jan 18 23:36:06 dangole: btw. i pinged russell king and the arm mailing list about the fix Jan 18 23:36:32 hopefully they will push it soon Jan 18 23:36:43 seems like they may have just forgotten it **** ENDING LOGGING AT Tue Jan 19 02:59:58 2016