**** BEGIN LOGGING AT Wed Jan 14 02:59:59 2015 Jan 14 03:52:48 build #38 of netlogic is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/netlogic/builds/38 Jan 14 04:20:31 build #281 of cns3xxx is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/cns3xxx/builds/281 Jan 14 04:32:34 build #808 of x86 is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/x86/builds/808 Jan 14 04:44:12 build #487 of mpc85xx is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/mpc85xx/builds/487 Jan 14 04:45:18 build #163 of x86.xen_domu is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/x86.xen_domu/builds/163 Jan 14 04:56:40 build #803 of ar7 is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/ar7/builds/803 Jan 14 05:01:33 build #38 of arm64 is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/arm64/builds/38 Jan 14 05:07:51 build #848 of cobalt is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/848 Jan 14 05:53:30 build #38 of ramips.mt7621 is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.mt7621/builds/38 Jan 14 06:03:37 build #175 of ar71xx.mikrotik is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx.mikrotik/builds/175 Jan 14 06:04:52 build #297 of bcm53xx is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/bcm53xx/builds/297 Jan 14 06:17:14 build #185 of ar71xx.nand is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx.nand/builds/185 Jan 14 06:17:26 build #272 of adm8668 is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/adm8668/builds/272 Jan 14 06:17:34 build #809 of rb532 is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/809 Jan 14 06:18:11 build #755 of ixp4xx is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/ixp4xx/builds/755 Jan 14 06:30:41 build #671 of mcs814x is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/mcs814x/builds/671 Jan 14 06:38:54 build #307 of cns21xx is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/cns21xx/builds/307 Jan 14 07:05:32 rmilecki r43963 trunk/target/ linux/bcm53xx/config-3.14 linux/bcm53xx/config-3.18 * bcm53xx: refresh configs Jan 14 07:05:57 rmilecki r43964 trunk/target/ linux/bcm53xx/config-3.14 linux/bcm53xx/config-3.18 * bcm53xx: enable HIGHMEM to support more than 128 MiB of RAM Jan 14 07:13:46 build #747 of ar71xx is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx/builds/747 Jan 14 07:21:17 build #38 of ipq806x is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/ipq806x/builds/38 Jan 14 07:23:08 build #890 of brcm63xx is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/brcm63xx/builds/890 Jan 14 07:29:45 build #816 of uml is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/816 Jan 14 07:41:45 build #306 of pxa is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/pxa/builds/306 Jan 14 07:42:15 build #627 of octeon is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/octeon/builds/627 Jan 14 07:45:10 rmilecki r43965 trunk/target/ linux/bcm53xx/patches-3.14/303-ARM-BCM5310X-activate-early-printk-for-Netgear-R6250.patch linux/bcm53xx/patches-3.14/303-ARM-BCM5310X-Enable-earlyprintk-on-tested-devices.patch linux/bcm53xx/patches-3.18/303-ARM-BCM5310X-activate-early-printk-for-Netgear-R6250.patch linux/bcm53xx/patches-3.18/303-ARM-BCM5310X-Enable-early Jan 14 07:45:10 OpenWrtprintk-on-tested-devices.patch * bcm53xx: enable earlyprintk on more devices Jan 14 07:45:46 build #281 of mpc83xx is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/mpc83xx/builds/281 Jan 14 07:51:33 build #184 of x86.kvm_guest is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/x86.kvm_guest/builds/184 Jan 14 07:52:15 build #652 of mpc52xx is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/mpc52xx/builds/652 Jan 14 08:01:27 build #689 of ep93xx is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/ep93xx/builds/689 Jan 14 08:34:25 build #667 of gemini is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/gemini/builds/667 Jan 14 08:40:56 build #777 of xburst is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/xburst/builds/777 Jan 14 08:45:10 build #674 of adm5120 is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/adm5120/builds/674 Jan 14 08:53:20 build #305 of malta is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/malta/builds/305 Jan 14 08:55:27 kaloz r43966 trunk/include/netfilter.mk * netfilter: handle NFT_MASQ_IPV6 Jan 14 09:13:01 build #399 of mxs is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/mxs/builds/399 Jan 14 09:27:31 build #749 of kirkwood is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/kirkwood/builds/749 Jan 14 09:40:12 build #189 of brcm47xx.mips74k is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx.mips74k/builds/189 Jan 14 10:00:31 build #861 of at91 is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/at91/builds/861 Jan 14 10:01:42 luka r43967 trunk/package/network/services/mdns/Makefile * mdns: install uci package as config Jan 14 10:12:32 build #177 of lantiq.xrx200 is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/lantiq.xrx200/builds/177 Jan 14 10:12:40 build #720 of au1000 is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/au1000/builds/720 Jan 14 11:39:44 kaloz r43968 trunk/target/linux/mvebu/image/Makefile * mvebu: Replace the padjffs2 call by the generic definition Jan 14 11:41:35 kaloz r43969 trunk/target/linux/mvebu/image/Makefile * mvebu: Switch to the generic mkuimage macro Jan 14 12:11:48 kaloz r43970 trunk/target/linux/malta/image/Makefile * malta: copy initramfs images Jan 14 13:22:54 nbd r43971 trunk/package/ kernel/mac80211/patches/542-ath9k_debugfs_diag.patch kernel/mac80211/patches/329-ath9k-fix-race-condition-in-irq-processing-during-ha.patch * ath9k: fix irq storm issues (#18483) Jan 14 13:43:21 rmilecki r43972 trunk/target/ (6 files in 2 dirs) * bcm53xx: support all RAM on devices with more than 128 MiB (HIGHMEM) Jan 14 13:51:46 that last commit worries me, I don't think it's safe without ARM support for SWIOTLB Jan 14 13:52:08 Is rmilecki on this channel? Jan 14 13:53:25 Hauke: it happens to work on block devices when CONFIG_BOUNCE is set right, and it will work on network devices by chance when all the memory that is not DMA capable happens to be HIGHMEM Jan 14 13:54:08 however, any other DMA master (e.g. USB) is broken in this configuration without SWIOTLB Jan 14 13:57:14 arnd: his nick is zajec Jan 14 13:57:24 thanks nbd Jan 14 13:58:42 zajec: one more thing: you should really enable SPARSEMEM on this platform to avoid wasting lots of memory for the page array. It's currently not supported on ARCH_MULTIPLATFORM, but I think that is only for historical reasons and can trivially be changed Jan 14 14:00:04 Unfortunately the __virt_to_phys from arch/arm/mach-realview/include/mach/memory.h is fundamentally incompatible with MULTIPLATFORM, but in a bcm53xx-only kernel one could do the same trick to avoid highmem Jan 14 14:00:28 which in turn would break network devices unless you also enable SWIOTLB Jan 14 14:02:10 i'm worried about the performance impact of that stuff Jan 14 14:03:22 caches are small enough that anything you stuff into the network hotpath hurts Jan 14 14:03:33 especially if it increases the number of memory accesses Jan 14 14:05:40 arnd: i just enabled HIGHMEM and left other options default Jan 14 14:05:51 arnd: i've to admit, i don't understand them :| Jan 14 14:06:09 * zajec laving for a dinner Jan 14 14:06:35 nbd: swiotlb is indeed rather slow, but I think it's not worse than the bounce buffers that the network and blockdev code use with the current code Jan 14 14:06:49 arnd: on some mips routers with comparable cache sizes, even something as simple as inlining the dma mapping ops was visibly increasing network throughput Jan 14 14:06:56 zajec: yes, I saw the patch to enable HIGHMEM Jan 14 14:07:46 well, bounce buffers for network stuff can be avoided by adding GFP_DMA to skb allocs Jan 14 14:07:52 at least that's how i did it on ixp4xx Jan 14 14:08:12 the bounce buffers were quite fragile there Jan 14 14:08:21 nbd: I suppose for any routing and for network packets from kernel space you never get highmem Jan 14 14:08:34 you don't even need GFP_DMA, just the absence of GFP_HIGHMEM Jan 14 14:08:47 right. though on ixp4xx i needed GFP_DMA Jan 14 14:09:06 the only case in which the bounce buffers are needed here is when user space sends a packet that happens to be in a high page Jan 14 14:09:07 PCI DMA had a 64 MB memory window Jan 14 14:10:06 if i understand this correctly, then swiotlb will hurt even when packets aren't in high pages Jan 14 14:10:19 or did i get that part wrong? Jan 14 14:11:31 i guess we need to run some tests Jan 14 14:11:34 I don't think it does: it should be transparent for any buffers that fit into the dev->dma_mask Jan 14 14:11:58 except for one conditional branch on the test for the address Jan 14 14:13:03 ok Jan 14 14:13:03 from swiotlb_map_page(): if (dma_capable(dev, dev_addr, size) && !swiotlb_force) return dev_addr; Jan 14 14:25:14 arnd: nbd: it seems we already have SWIOTLB enabled Jan 14 14:25:16 grep CONFIG_SWIOTLB build_dir/target-*/linux-*/linux-3.*/.config Jan 14 14:25:20 CONFIG_SWIOTLB=y Jan 14 14:25:25 k Jan 14 14:25:34 we should still investigate the performance impact of it Jan 14 14:25:43 btw. have you made any progress with smp on 53xx? Jan 14 14:25:51 no, i started with highmme Jan 14 14:25:54 SMP is next Jan 14 14:25:56 ok Jan 14 14:26:03 nbd: should I just try to disable it and then try network performance? Jan 14 14:26:12 or do i need some more tricks? Jan 14 14:26:37 yeah Jan 14 14:26:46 "yeah" about first or 2nd question? ;) Jan 14 14:26:47 you should compare the performance of simple routing from lan to wan Jan 14 14:26:56 preferably with an empty firewall config Jan 14 14:26:58 * zajec shouldn't ask two opposite questions :P Jan 14 14:26:59 first one Jan 14 14:27:01 ok Jan 14 14:27:14 will do Jan 14 14:27:35 arnd: nbd: so what about CONFIG_BOUNCE? should we keep it enabled? Jan 14 14:28:08 (afair it's really needed *without* SWIOTLB.... but what now that we have SWIOTLB?) Jan 14 14:28:11 zajec: actually I think it's a bug that CONFIG_SWIOTLB is enabled: there is no code on ARM outside of Xen that uses it Jan 14 14:28:43 so we build lib/swiotlb.c into the kernel but nothing references the functions it exports Jan 14 14:28:47 arnd: ahh, shit, I misread your "I don't think it's safe without ARM support for SWIOTLB" Jan 14 14:28:53 i ddon't notice the negation Jan 14 14:29:31 well, we do want to enable it, but only when we actually have the code to use it Jan 14 14:30:18 build #853 of orion is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/853 Jan 14 14:30:32 zajec: arch/arm64/mm/dma-mapping.c uses swiotlb if you want a reference to look at Jan 14 14:30:53 I suspect it's not even hard to do the same on arch/arm/, but so far I haven't found anyone who was willing to try it out Jan 14 14:34:35 build #218 of brcm47xx.legacy is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx.legacy/builds/218 Jan 14 14:46:55 hm, first test show me only 307 Mb/s Jan 14 14:47:14 i was hopig for a bit more on this ARM Jan 14 14:53:14 nbd: arnd: with CONFIG_SWIOTLB=y i got: Jan 14 14:53:15 0.0-120.0 sec 4.23 GBytes 302 Mbits/sec Jan 14 14:53:36 now... i wanted to disable SWIOTLB, but I can't Jan 14 14:53:54 Selected by: (...) && PCI [=y] && ACPI Jan 14 14:54:25 well, i could try to disable the whole PCI... but I don't think that's the point, is it? Jan 14 14:54:56 zajec: it's turned on unconditionally from arch/arm/Kconfig, but is never used Jan 14 14:55:16 build #38 of ramips.mt7620 is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.mt7620/builds/38 Jan 14 14:55:18 arnd: yeah, but nbd suggested it can affect performance anyway Jan 14 14:55:50 zajec: no, what nbd meant was that he thought it would affect performance when it's used but not needed Jan 14 14:56:09 just turning the option on only makes the kernel slightly larger than it should be Jan 14 14:56:16 ahh, ok Jan 14 14:57:30 so... do we have any issue there at all? Jan 14 14:57:36 cause I got a bit lost Jan 14 14:57:53 build #38 of ramips.mt7628 is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.mt7628/builds/38 Jan 14 14:58:19 first you were saying it's unsafe to use SWIOTLB without support for it on ARM... but now it turns out no code will really ever use it... did I get it right? Jan 14 15:17:26 zajec: I think you misunderstood my initial comment. What I meant was that your patch to use highmem on bcm53xx is unsafe, unless we use swiotlb Jan 14 15:18:42 in theory it is safe as long as you only ever have SCSI (including sata and usb-storage) devices and network devices on PCI, but if any of the machines has other PCI devices, they are now broken Jan 14 15:19:52 on a related topic, does bcm53xx have any high-speed devices that do DMA on chip, or are they always on PCI? Jan 14 15:20:50 ah, I see it has gbit ethernet and "Hardware Flow Accelerator" Jan 14 15:43:59 arnd: so is HIGHMEM unsafe on ARM in general? Jan 14 15:47:42 no, what's unsafe is PCI controllers that have a DMA mask of less than 32-bit wide Jan 14 15:47:46 on all architectures Jan 14 15:48:34 well, in combination with the mask being smaller than available RAM Jan 14 15:49:01 omg, what a complex sh*t Jan 14 15:49:33 this is the same problem that nbd mentioned with https://dev.openwrt.org/browser/trunk/target/linux/ixp4xx/patches-3.14/600-skb_avoid_dmabounce.patch Jan 14 15:50:07 the difference is that in case of bcm53xx, the memory that is outside of the mask is also outside of lowmem Jan 14 15:51:08 so you are lucky that the network stack does its own bounce buffers based on the skb pointing to highmem, so you don't need that same hack Jan 14 15:51:32 but ixp4xx could also be fixed using swiotlb to avoid the ugly network stack hack Jan 14 15:54:29 so shoud I just look at arch/arm64/mm/dma-mapping.c and implement similar thing for arm? seems pretty easy Jan 14 15:54:34 and there any surprises I should expet? Jan 14 15:59:00 build #858 of atheros is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/atheros/builds/858 Jan 14 16:02:12 build #306 of realview is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/realview/builds/306 Jan 14 16:08:01 build #192 of ramips.rt3883 is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/ramips.rt3883/builds/192 Jan 14 16:09:02 build #865 of brcm47xx is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx/builds/865 Jan 14 16:11:21 build #839 of ramips is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/ramips/builds/839 Jan 14 16:24:40 i think i found some nice documentation: https://www.kernel.org/doc/gorman/html/understand/understand012.html Jan 14 16:24:45 "High Memory Management" Jan 14 16:24:59 build #40 of oxnas is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/oxnas/builds/40 Jan 14 16:39:35 build #415 of imx6 is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/imx6/builds/415 Jan 14 16:47:33 Is there a preferred way to determine the target profile of an image? Either at compile time or run time wouldn't matter, I'd just like to be able to use it at runtime somehow. Jan 14 16:50:25 zajec: I haven't tried myself to implement swiotlb on arm, but I'd hope it would be straightforward Jan 14 16:50:42 the document you found is a bit old, and it predates the swiotlb code I think Jan 14 16:51:47 the bounce buffers are the blockdev equivalent of the generic swiotlb Jan 14 16:53:02 zajec: actually one small problem: we don't yet have the code to set the dma-mask correctly on PCI devices, so for testing you'd have to hardcode that in pci_device_add or similar Jan 14 16:53:49 also we should eventually be able to pick either arm_dma_ops or arm_swiotlb_dma_ops depending on the dma_mask Jan 14 16:55:01 Murali Karicheri recently posted a patch series for 3.20 to linux-arm-kernel that should get this mostly right, the exception being the missing swiotlb_dma_ops Jan 14 17:11:47 build #308 of x86_64 is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/x86_64/builds/308 Jan 14 17:16:39 build #850 of lantiq is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/lantiq/builds/850 Jan 14 17:57:21 Hi! Jan 14 17:57:55 Is there anyone here who has managed to boot the sysupgrade binary for openwrt into the Netgear WNR2000v4 ? Jan 14 18:43:18 build #780 of avr32 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/780 Jan 14 18:51:37 Umeaboy: I've put off messing with mine until I've heard if someone else has :) Jan 14 18:52:21 proidiot: I got bootloader access to it. ;) Jan 14 18:57:12 nice... i think i put dd on a v3 a while back, and while i meant to put open on that v3 and the v4, i've had so many other routers to tinker with that worked quite nicely with open that i never got around to it Jan 14 19:19:18 build #285 of sunxi is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/sunxi/builds/285 Jan 14 19:19:59 build #263 of omap is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/omap/builds/263 Jan 14 19:20:02 build #833 of ppc40x is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/ppc40x/builds/833 Jan 14 19:20:07 build #370 of mvebu is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/mvebu/builds/370 Jan 14 19:21:36 build #282 of brcm2708 is complete: Failure [failed compile_4] Build details are at http://buildbot.openwrt.org:8010/builders/brcm2708/builds/282 Jan 14 19:57:42 arnd: is there a way to tell kernel to use only lowmem for all in-kernel stuff Jan 14 19:57:52 and leave highmem for user space only? Jan 14 20:00:52 http://www.quora.com/Linux-Kernel/What-is-the-difference-between-high-memory-and-normal-memory states the flags requesting highmem Jan 14 20:06:33 arnd: plntyk: i'm not sure if I can handle this... Jan 14 20:06:37 arnd: plntyk: i was thinking we are afraid of problem described in "High Memory Management" - that devices won't be able to access highmem using DMA :| Jan 14 20:06:55 arnd: plntyk: but now it seems like sth more complex... i'll continue reading, maybe i'll become easier Jan 14 20:09:00 currently trying to search , track and report "random" bugs in buildroot with different OSes - compiling on BSD seems to be a pain - dont know why ppl do stuff there ^^ Jan 14 20:24:48 hi all Jan 14 20:24:58 hi Jan 14 20:25:30 is it the place for openwrt dev? topic seems quite old ) Jan 14 20:25:55 yes this is the place Jan 14 20:26:28 ok, thank you ) Jan 14 20:26:30 noone cares about trivalities like irc topic - all dev are busy doing other stuff Jan 14 20:27:30 what I'm doing now is adding support for freescale vybrid VF6 platform for openWRT. I didn't find any who worked on that platform Jan 14 20:28:37 and what I'm trying to do is add 3.0.15 kernel heavily patched by vendor to BarrierBreaker. How do you think how many chances I have that it will work? ) Jan 14 20:29:16 or is someone interested in that platform? or maybe I'm doing it wrong etc? Jan 14 20:32:19 "interest" regarding openwrt on different platforms probably really depends - some platforms only have a few devs / tester - and for some platforms its more "educational" - one can argue why broadcom platforms without working wifi are supported ^^ Jan 14 20:33:09 raspberryPi? ) Jan 14 20:33:45 I think keyword is "popular". Jan 14 20:33:45 brcm2708 != brcm47xx or 63xx (used in cable modems sometimes) Jan 14 20:34:35 and regarding you question regarding development - instead of BB you a kernel from like before AA which has 3.3 Jan 14 20:35:56 yeah, I thought about it. It is a planB if it wont work with BB Jan 14 20:36:37 actually after few hacks it seems that I could build it but didnt try to deploy yet ) Jan 14 20:37:39 what I was surprised about is that openWRT has no possibility to select custom kernel from local folder (or I was not able to find it). In buildroot everything is more clear and obvious for devs Jan 14 20:46:16 repu1sion: well buildroot has sort of monthly releases Jan 14 20:47:24 mailing volume with patches etc. is quite large too Jan 14 20:48:26 I tried trunk, it was not able to build well some atheros target for me so I forked BB Jan 14 20:48:52 also I ve not found any tags in trunk or so Jan 14 20:49:22 Is there a possibility to get it with git? Jan 14 20:50:27 there are no tags since its atm svn based and AA,BB are separate branches Jan 14 20:52:26 git are separate repos: see for example http://git.openwrt.org/ Jan 14 20:59:53 yeah, I see thanks ) Jan 14 21:00:33 never thought there is still some serious sw development based on svn ) Jan 14 21:01:19 well one should consider the transaction costs of a project - thats probably why there are still ppl using sourceforge Jan 14 21:02:43 I dont know if its possible to have simple increasing version numbers with git - thats a little bit practical regarding revisions Jan 14 21:04:31 I think its impossible to have revisions in git because the idea was you could move commit easy: rebase, merge etc Jan 14 21:05:10 as I remember from reading half of git book - this is another philosophy ) Jan 14 21:05:44 as for me - I was happy with svn because git has very complicated and not obvious interface and svn was simpler to use Jan 14 21:06:01 afaik most ppl use git when developing openwrt - according to recommendations on mailing list "send your patches with git send-mail" Jan 14 21:06:43 but git is better inside and everyone likes creating 10 brances in few seconds ) Jan 14 21:06:59 so I had to learn it and use it ) Jan 14 21:07:35 do you think if I bring up new platform for openwrt should I try to send patches? Jan 14 21:11:24 maybe ask on the mailing list too - atm work is being done on some platforms with 3.18 - and I dont know how different the 3.0 tree is from vanilla or 3.18 - some arch are more synced with upstream kernel - afaik ramips, brcm47xx/brcm ARM units have sometimes backports from upstream/later kernel versions Jan 14 21:12:12 in contrast there is ar71xx - which is a huge patchset against the in kernel ath79 that only has support for a few boards Jan 14 21:13:42 last year putting some switch drivers / infrastructure in kernel was denied - so openwrt carries that stuff too and has to look for kernel compatibility there Jan 14 21:17:32 a newbie question - does Openwrt require some stuff in kernel to work properly or not? What I found - series of patches applied for different targets but is there something general required for any? Jan 14 21:22:21 so if I have just custom kernel without any openwrt patches on it - will it probably work or not? Jan 14 21:22:34 I can only think of the trivial thing - the device should boot the kernel - besides the normal stuff (coding conventions etc) - "patches are welcome" - maybe check other mailing lists regarding that board - buildroot list, theres yocto/openembedded and the "arch" list for your CPU might provide hints Jan 14 21:23:13 well a patch adding a 3.0 kernel will not be accepted Jan 14 21:23:51 sure ) Jan 14 21:23:53 for trunk a 3.14 or 318 version is probably required Jan 14 21:26:37 thats a strange thing. there is a timesys 3.0.15 kernel heavily patched for vybrid and other similar platforms support (about 1100 files). It is open-source and could be downloaded from github etc Jan 14 21:26:51 diff is really huge Jan 14 21:27:34 and also there are some patches for vybrid VF6 in 3.18 mainline, but I'm not sure that is enough for my board Jan 14 21:28:04 what timesys does is really different from mainline Jan 14 21:29:02 write a ticket "bad coding" "why your patches too big?" :) Jan 14 21:30:06 wtf Jan 14 21:30:15 do you mean http://repository.timesys.com/buildsources/k/kernel/kernel-3.0/linux-3.0-vybrid-ts2.17.patch ? Jan 14 21:30:20 a ticket to who? timesys? they will answer: "we have own kernel fork and we provide it for free with our boards and cpus" ) Jan 14 21:30:24 are these really kernel patches for that ? Jan 14 21:30:33 42MB oO Jan 14 21:31:18 seems so Jan 14 21:31:28 here is it on github: https://github.com/Timesys/linux-timesys Jan 14 21:33:42 they just move their own fork. so in few years they made 42MB diff ) Jan 14 21:38:19 you probably should read sth about porting, git, tree management etc - that might save you some time - at least one can filter those "bad" commits because of their email/author and git assist by creating numbered patch series Jan 14 21:39:40 using a vanilla 3.18 kernel and then searching through the 3.0 tree might be quicker than forward porting the whole mess Jan 14 21:40:42 actually what I want now is just run OpenWRT with that timesys kernel to see will it work or not Jan 14 21:42:56 I'm not going to port the whole timesys 40Mb mess to vanilla 3.14 or 3.18 Jan 14 21:45:20 zajec: memory that you can access in the kernel is practically always lowmem, except if you do kmap() or kmap_atomic() Jan 14 21:45:38 so the only time you need to do DMA on a highmem buffer is for zero-copy with user space data Jan 14 21:46:24 which typically happens on send(), or when dealing with memory-mapped files Jan 14 21:47:02 arnd: so the only problem we'll hit if when user-space will try to provide data (buffer) to device that doesn't support 64b DMA? Jan 14 21:48:22 64bit isn't the exact issue, but I guess you mean a device with a dma_mask that is lower than the physical memory address of that buffer Jan 14 21:48:30 right Jan 14 21:48:57 PCI devices normally have a 32-bit dma_mask, but yours have a 27-bit mask Jan 14 21:49:17 ok, one more question: what is the difference between CONFIG_BOUNCE and CONFIG_SWIOTLB? I can't really find a good documentation of that Jan 14 21:49:34 or possibly a 31-bit mask, which would have the same effect when the second 128MB of RAM are above 0x80000000 Jan 14 21:49:47 CONFIG_BOUNCE is specific to block devices Jan 14 21:50:16 CONFIG_SWIOTLB works independent of which driver does it by overriding the dma_map_* operations Jan 14 21:50:36 ok, i guess i have very last question now Jan 14 21:50:46 why we need anything ARM specific for swiotlb? Jan 14 21:50:50 it sounds like a very generic thing Jan 14 21:51:07 allow lowmem, use it for bounce buffers when needed Jan 14 21:51:15 each architecture provides its own dma_map_* functions, and they differ much more than they really should Jan 14 21:51:42 ARM e.g. does more complex cache management there than most others Jan 14 21:52:07 but this arch/arm64/mm/init.c seems to use moslt ythe generic swiotlb functions Jan 14 21:52:22 it uses only arm64_swiotlb_alloc_coherent and arm64_swiotlb_free_coherent that are ARM specific Jan 14 21:52:33 would it be the same for ARM (not ARM64)? Jan 14 21:52:48 can I just cp this file to arch/arm/ and call this init function? Jan 14 21:52:50 is that it? Jan 14 21:53:06 the alloc_coherent/free_coherent functions don't go through swiotlb, those would be the same ones we already use Jan 14 21:53:44 only the map_single/unmap_single/sync_single_for_cpu/sync_single_for_device/... functions use swiotlb by copying the data around Jan 14 21:54:12 err, but there is function like swiotlb_alloc_coherent Jan 14 21:55:58 I don't think you need that, but I might be missing something Jan 14 21:56:53 ok... what would be the simples way to trigger the bug right now? Jan 14 21:57:10 should I write a user space app that will alloc buffer in highmem and pass it to the network interface? Jan 14 21:57:14 will it trigger the problem? Jan 14 21:57:17 what you need to do is add a noncoherent_swiotlb_dma_ops structure and fill it with appropriate functions Jan 14 21:57:42 network is fine unless you have a device that sets NETIF_F_HIGHDMA Jan 14 21:59:06 it's everything except block or network that may be broken Jan 14 21:59:08 hm... so any other idea how to trigger it? Jan 14 21:59:16 what PCI devices do you have? Jan 14 21:59:23 wireless devices only Jan 14 21:59:25 nothing else Jan 14 21:59:52 I think all BCM5301X routers have only wireless devices connected to the PCI bus Jan 14 22:00:03 so none of the machines have on-board pci devices like USB3 controllers? Jan 14 22:00:07 (and there aren't even PCI slots, so I can't connect anything else) Jan 14 22:00:30 USB 3 host is attached to the SoC directly Jan 14 22:00:33 it's part of the soc Jan 14 22:00:40 it doesn't use PCI bus Jan 14 22:01:25 e.g. drivers/usb/host/bcma-hcd.c Jan 14 22:01:32 I guess that means your setup will work fine, as long as nobody adds other PCI devices Jan 14 22:02:26 if you want to provoke the error, you can set CONFIG_VMSPLIT_1G Jan 14 22:02:52 ok, so I'll look at NETIF_F_HIGHDMA and VMSPLIT_1G tomorrow Jan 14 22:02:55 to trigger the problem Jan 14 22:02:59 thanks for your help! Jan 14 22:02:59 this will put all of your RAM into lowmem, and at that point the heuristic in net/core/dev.c whether to use bounce buffers goes wrong Jan 14 22:03:20 sounds perfect! :P Jan 14 22:04:29 ok, i have to go sleep now Jan 14 22:04:38 arnd: really thanks for all this info Jan 14 22:04:39 Using VMSPLIT_1G instead of HIGHMEM might be a good choice for this platform anyway, since you don't have swap, so user space won't be able to use large address spaces Jan 14 22:04:40 goodnight Jan 14 22:04:49 good night, I should go sleep as well Jan 14 22:04:53 :) Jan 14 22:21:34 ima koga ko zna upogoniti asterisk na sx763??? Jan 14 22:28:47 english please :) Jan 14 22:39:33 anyone here knows how to setup asterisk on siemens sx763?? Jan 14 23:37:08 subixonfire: i don't think openwrt can do it, because the sx763 has only 32mb ram Jan 15 00:00:12 build #306 of malta is complete: Exception [exception MasterShellCommand] Build details are at http://buildbot.openwrt.org:8010/builders/malta/builds/306 **** ENDING LOGGING AT Thu Jan 15 02:59:59 2015