**** BEGIN LOGGING AT Sun Jun 28 02:59:58 2015 Jun 28 05:43:00 build #43 of mpc83xx is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/mpc83xx/builds/43 Jun 28 06:16:56 build #43 of ep93xx is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/ep93xx/builds/43 Jun 28 07:53:00 build #51 of ramips is complete: Success [build successful] Build details are at http://buildbot.openwrt.org:8010/builders/ramips/builds/51 Jun 28 07:55:05 build #43 of mpc52xx is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/mpc52xx/builds/43 Jun 28 08:38:11 build #44 of brcm47xx.legacy is complete: Failure [failed shell_14] Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx.legacy/builds/44 Jun 28 08:42:36 build #43 of brcm47xx.mips74k is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx.mips74k/builds/43 Jun 28 09:36:54 build #43 of octeon is complete: Failure [failed compile_3] Build details are at http://buildbot.openwrt.org:8010/builders/octeon/builds/43 Jun 28 10:54:21 SwedeMike: if you press ? over the top of it, you can see what it's being selected by. Jun 28 11:13:04 SwedeMike: if you can only choose between * and M for isdn4linux, it is probably selected by an other package, press h to see the list of packages which could select it Jun 28 11:38:08 karlp / Hauke: thanks! Jun 28 14:37:13 arnd: hi, do you have a moment for some DT & interrut question? Jun 28 14:37:27 arnd: i tried patch like this: http://pastebin.com/2VZT5BdW but it doesn't work (see FIXME in that patch) Jun 28 14:37:55 18000300.serial: ttyS0 at MMIO 0x18000300 (irq = 117, base_baud = 6250000) is a 16550 Jun 28 14:37:57 became Jun 28 14:37:58 18000300.serial: ttyS0 at MMIO 0x18000300 (irq = 0, base_baud = 6250000) is a 16550 Jun 28 14:38:23 arnd: for the full bus specified in DT see http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/bcm5301x.dtsi#n98 Jun 28 14:38:39 rmilecki: the interrupts property does not have a phandle in it Jun 28 14:39:18 so "interrupts = <&gic 85 IRQ_TYPE_LEVEL_HIGH>;" cannot work Jun 28 14:39:31 hm, the first answer would be "it was working before" :P as having the same entries out of "brcm,bus-axi" was working just fine Jun 28 14:39:58 that was "interrupts = ;" Jun 28 14:40:27 and I guess the new parent node has an "interrupt-map" property Jun 28 14:40:48 which changes how the "interrupts" property is interpreted Jun 28 14:40:53 ah, sorry, this s/GIC_SPI/&gic/ was my later try of hacking this code Jun 28 14:41:05 GIC_SPI didn't work as well... because of these mappings as you said Jun 28 14:41:25 arnd: can I tell DT to ignore parent's mappings? Jun 28 14:41:31 what you need to do is to add an entry in the interrupt-map property, and use "interrupts = 0" here Jun 28 14:42:44 it might also work to add an "interrupt-parent = <&gic>" property in the uart node, but I'm not entirely sure if that is supposed to take precedence over an interrupt-map Jun 28 14:43:12 rmilecki: why do you want to move it there in the first place? Jun 28 14:43:28 arnd: because I don't want ChipCommon to be defined twice Jun 28 14:43:36 I think it makes sense? Jun 28 14:43:37 is the uart bcma device? Jun 28 14:43:51 yes, UART is part of ChipCommon (and ChipCOmmon is bcma device) Jun 28 14:44:00 ah, I see Jun 28 14:45:22 arnd: is there any difference between interrupt-parent = <&gic>; interrupts = <85 IRQ_TYPE_LEVEL_HIGH>; Jun 28 14:45:24 and interrupts = <&gic 85 IRQ_TYPE_LEVEL_HIGH>; Jun 28 14:45:50 they are equally wrong, so I'd say no difference Jun 28 14:46:03 :| Jun 28 14:46:18 damn... Jun 28 14:46:27 the correct form would be "interrupt-parent = <&gic>; interrupts = ;" Jun 28 14:46:32 aaah Jun 28 14:46:49 i was thinking GIC_SPI is an alias to &gic Jun 28 14:46:51 omg Jun 28 14:46:55 * rmilecki has to learn Jun 28 14:47:31 GIC_SPI means that the interrupt is in the SPI family of interrupts provided by the gic Jun 28 14:48:45 the arm-gic binding defines the interrupt-specifier as a set of "type, number, flags" Jun 28 14:48:58 all three are integer values Jun 28 14:49:21 other irqchips have a different set of parameters, but usually they have at least a number, and often flags Jun 28 14:49:49 ok, thanks a lot for your help Jun 28 14:50:06 btw. it would be cool to have interrupt-map documented one day Jun 28 14:50:19 e.g. if you will so bored one day :) Jun 28 14:51:05 rmilecki: the more important question here is whether the chipcommon block is normally has its own interrupts that should be part of the interrupt-map, or if the uarts are special and they never show up with interrupts on the BCMA bus (including on the older MIPS parts) Jun 28 14:51:27 if these are normal BCMA interrupts, they should be in the map, otherwise using an interrupt-parent is better Jun 28 14:53:28 Hauke: ^^ Jun 28 14:53:38 arnd: i think ChipCommon has one interrupt Jun 28 14:53:56 plus some extra register that sets triggers of this IRQ Jun 28 14:54:09 so e.g. serial console has IRQ x, GPIOs have x + 1 Jun 28 14:54:25 (both: serial console and GPIO controller are part of ChipCommon) Jun 28 14:55:56 arnd: so I guess the answer is UARTs are not special they share ChipCommon IRQ with e.g. GPIO Jun 28 14:56:10 arnd: OK, let me think Jun 28 14:57:02 arnd: so... I guess we should have IRQ assigned to ChipCommon and then the UART subnodes should have ChipCommn as a parent and use its IRQ Jun 28 14:57:07 does it make more sense? Jun 28 14:57:22 fwiw, http://devicetree.org/Device_Tree_Usage describes the interrupt-map usage, and it's also part of some of the older bindings Jun 28 14:57:56 ah, I didn't think about looking there, thanks Jun 28 14:58:08 rmilecki: I'd have to read up on the definition to see how exactly it should work, but in principle that would be good Jun 28 15:14:02 http://web.archive.org/web/20081012114239/http://playground.sun.com/1275/practice/imap/imap0_9d.html has a copy of the document that originally defined interrupt-map Jun 28 15:19:42 rmilecki: taking the irq from chip common sould like a valid idea Jun 28 16:43:04 Hauke: do you know how to achieve that? Jun 28 16:43:18 Hauke: how to assing an IRQ to ChipCommon node and then tell subnodes to use parent's IRQ? Jun 28 16:44:45 Hauke: this works for me right now, but it a bit hacky as arnd pointed http://pastebin.com/8ngqjhry Jun 28 16:47:50 build #43 of ar71xx.mikrotik is complete: Failure [failed compile_8] Build details are at http://buildbot.openwrt.org:8010/builders/ar71xx.mikrotik/builds/43 Jun 28 16:57:55 rmilecki: I do not know Jun 28 16:58:11 you probably have to follow the call where the driver requests the irq number Jun 28 17:08:43 Hauke: yeah, I was suspecting I may need to handle that in C Jun 28 17:08:47 not DT directly Jun 28 18:10:47 build #43 of adm5120 is complete: Failure [failed compile_5] Build details are at http://buildbot.openwrt.org:8010/builders/adm5120/builds/43 Jun 28 18:24:07 rmilecki: in the interrupt-map, just list the irq you want with the correct address of the device Jun 28 18:35:50 arnd: ah, so it should be already handled Jun 28 18:36:02 it's already listed there Jun 28 18:36:05 yes Jun 28 18:37:19 but I'm still unsure if it needs to be the address of the uart or the address of the chipcommon area Jun 28 18:40:40 arnd: i was planning to have only ChipCommon entry in mapping Jun 28 18:40:54 and then somehow specify ChipCommon's IRQ in its child node uart0 Jun 28 18:41:02 (i don't know how yet) Jun 28 18:47:55 rmilecki: to be on the safe side, you could have another interrupt-map inside of chipcommon Jun 28 18:50:33 Oh Jun 28 18:50:39 I didn't think about that Jun 28 18:51:13 is this nested interrupt-map going to be treated as relative one? Jun 28 18:51:27 will IRQ 0 equal to that parent's first irq? Jun 28 18:52:14 oh, it's too tricky for me Jun 28 18:52:27 sth like? interrupt-map = <0x00000300 0 &gic GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>; Jun 28 18:52:44 or more like interrupt-map = <0x00000300 0 &chipcommon 0 0 IRQ_TYPE_LEVEL_HIGH>; Jun 28 19:52:38 rmilecki: the first two parts are handled in C by bcma Jun 28 19:56:18 Hauke: i'm not sure Jun 28 19:56:23 Hauke: we assign IRQ to bcma's core Jun 28 19:56:29 in the struct bcma_device Jun 28 19:56:39 but not the the DT node in general Jun 28 20:06:30 build #44 of avr32 is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/44 Jun 28 20:06:31 build #45 of cns21xx is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/cns21xx/builds/45 Jun 28 20:06:32 build #45 of cobalt is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/cobalt/builds/45 Jun 28 20:06:32 build #45 of orion is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/45 Jun 28 20:07:14 build #45 of ppc40x is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/ppc40x/builds/45 Jun 28 20:07:27 build #45 of pxa is complete: Failure [failed shell_10] Build details are at http://buildbot.openwrt.org:8010/builders/pxa/builds/45 Jun 28 20:08:59 updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html Jun 28 21:11:01 build #44 of netlogic is complete: Failure [failed compile_3] Build details are at http://buildbot.openwrt.org:8010/builders/netlogic/builds/44 Jun 28 22:08:01 i'm seeing this too, https://forum.openwrt.org/viewtopic.php?id=58149 a musl build problem with diffutils Jun 28 22:08:21 or, rather, a diffutils build problem with musl Jun 28 22:12:57 russell--: this looks more like a fortify protection problem Jun 28 22:16:04 yes, that does seem related Jun 28 22:21:27 is there a way to not enable fortify-headers for a single package ? Jun 28 22:26:06 PKG_FORTIFY_SOURCE:=0 Jun 28 22:26:36 hah, I tried that but forgot the : Jun 28 22:26:55 ncurses seems to need it Jun 28 22:27:38 hmmm, no, that doesn't fix it Jun 28 22:28:38 uClibc & octeon? Jun 28 22:29:08 yes Jun 28 22:29:30 but seems unrelated, someone reported it for ar71xx Jun 28 22:29:58 https://dev.openwrt.org/ticket/19976 Jun 28 22:30:09 both gcc4.8, no? Jun 28 22:30:27 iirc, Ian Kent is waiting for the ncurses fix :P Jun 28 22:30:32 actually gcc 4.6 Jun 28 22:30:45 is the default for octeon Jun 28 22:32:16 I previously built with linaro-4.9 but that seems no longer available in menuconfig Jun 28 22:32:27 just trying to get the damn libpcap segfault fixed Jun 28 22:32:28 remove the BROKEN flag ;) Jun 28 22:32:31 oh Jun 28 22:32:43 not having tcpdump on my main router is a major pita :/ Jun 28 22:32:45 worksforme with octeon too Jun 28 22:32:53 gcc4.9 that is Jun 28 22:33:20 yeah my router is currently running an image with gcc 4.9 Jun 28 22:35:08 swalker: you don't happen to know a fix or workaround for the libpcap segfault ? :) Jun 28 22:44:34 stintel: no Jun 28 22:45:49 stintel did you strace it already? Jun 28 22:53:23 Devastator: strace and gdb are unhelpful. see https://dev.openwrt.org/ticket/17753 Jun 29 01:54:55 ah, linaro gcc 4.8 on octeon doesn't boot, that's probably why it defaults to 4.6 :) **** ENDING LOGGING AT Mon Jun 29 02:59:58 2015