**** BEGIN LOGGING AT Sat Aug 11 03:00:01 2018 Aug 11 08:07:09 jow: I will take care of the mwlwifi upgrade in 18.06 Aug 11 08:10:51 Hauke: i was going to test that today but go right ahead Aug 11 08:11:08 i'll do more 19.01 preparations today Aug 11 08:12:52 i cannot build a image with image-builder ==> https://paste.debian.net/1037513/ Aug 11 08:14:55 after adding luci-app-wireguard to package-list Aug 11 08:18:33 non existent package i mean Aug 11 08:23:38 i cannot build a image with image-builder after adding luci-app-wireguard to package-list ==> https://paste.debian.net/1037513/ Aug 11 08:31:17 blogic: ok Aug 11 08:32:09 blogic: I saw multiple bug reports that the factory reset described here does not work in 18.06: https://openwrt.org/docs/guide-user/troubleshooting/failsafe_and_factory_reset#factory_reset Aug 11 08:33:14 this https://bugs.openwrt.org/index.php?do=details&task_id=1746 Aug 11 08:39:40 blogic: should I go to version 10.3.8.0-20180615 or 10.3.8.0-20180716, master currently has 10.3.8.0-20180615 ? Aug 11 10:09:24 gninrom Aug 11 10:13:35 are lan and wan led's supposed to show activity by default, or only link state? Aug 11 10:14:35 i think the former is pretty much the usual expectation Aug 11 10:15:00 but for some devices it's not possible. Aug 11 10:15:12 netdev trigger? Aug 11 10:15:41 depends on devices. Usually if you have a switch involved it's not the netdev, but the switch trigger Aug 11 10:15:52 and for some switches that trigger can't reflect activity Aug 11 10:16:34 i seem to have found such a switch Aug 11 10:16:44 but netdev works Aug 11 10:17:08 netdev will reflect the activity of the cpu port, i.e. all/any port Aug 11 10:17:14 iirc Aug 11 10:18:19 ar8xxx switches don't report activity Aug 11 10:18:23 due to excessive cpu load Aug 11 10:18:30 well, afaict the only gpio is for the wan light, so what works is netdev on eth0.2 Aug 11 10:19:21 but mkresin wanted to change it to the switch trigger Aug 11 10:20:14 i cannot build a image with image-builder after adding luci-app-wireguard to package-list ==> https://paste.debian.net/1037513/ Aug 11 10:21:35 DonkeyHotei: because netdev trigger on eth0.2 will only work if $person has a vlan2 defined. If vlan2 is used for a different purpose, the wan led is still triggered Aug 11 10:21:49 DonkeyHotei: if a different vlan is used for wan, led isn't triggered any longer Aug 11 10:22:12 yeah, they'd have to redefine the led Aug 11 10:22:39 DonkeyHotei: because a vlan is referenced instead of a swich port Aug 11 10:23:03 the switch apparently does not report activity Aug 11 10:23:26 mkresin: you could also argue that if $person is redefining their ports vlan they might already be changing the wan port to something else... The argument looks slightly circular to me, imvho Aug 11 10:23:55 you would also expect such $person to be capable of redefining their led triggers :) Aug 11 10:24:01 DonkeyHotei: it is rather a matter of the switch driver reporting activity Aug 11 10:24:11 ^ Aug 11 10:24:18 f00b4r0: sure, we can make it harder than it need to be Aug 11 10:24:33 the switch apparently does not trigger an interrupt for activity Aug 11 10:24:35 f00b4r0: I would agree if it is a vlan2 led Aug 11 10:25:07 DonkeyHotei: you might want to check the code about how it works before starting guessing Aug 11 10:25:32 DonkeyHotei: https://github.com/openwrt/openwrt/commit/eff3549c5883a9abc5dbff00c084cabbcfdf4437#diff-8d035864dc34e116ac7fb27a35c92257 Aug 11 10:26:16 f00b4r0: wasn't the issue fixed by felix and (re)enabled a few weeks ago? Aug 11 10:26:39 f00b4r0: different switch, similar situation Aug 11 10:26:51 mkresin: not that I see from the git log Aug 11 10:27:04 f00b4r0: dammed, I'm quite sure I saw such a commit somewhere Aug 11 10:27:25 f00b4r0: in felixs staging tree it was Aug 11 10:28:51 DonkeyHotei: the swdev led trigger is an interim solution anyway. with switching to Distributed Services Architecture (DSA) drivers, each port will be exposed as netdev and the netdev trigger can be used Aug 11 10:29:11 mkresin: oh i see: https://git.openwrt.org/?p=openwrt/staging/nbd.git;a=commitdiff;h=572805c20cf587793f0366e54f2d6fb51ed9af34 Aug 11 10:29:25 that hasn't reached master afaict Aug 11 10:29:32 DonkeyHotei: but as long as the driver(s) aren't in place, we should trigger based on a port and not s specific vlan Aug 11 10:29:37 it's cool still Aug 11 10:36:16 i just looked at the code, and indeed there is no interrupt for the switch Aug 11 10:37:07 additionally, the icon on the led is an "internet" type icon Aug 11 10:37:40 or "network" Aug 11 10:42:03 mkresin: I have mixed feelings about this patch https://github.com/openwrt/openwrt/commit/17a955d4d7ea36ee41e025d61e600ee143f58b97 which is what felix implemented to reduce the cpu load Aug 11 10:42:17 unless I'm mistaken, cond_resched() cannot be used with locks held Aug 11 10:43:01 f00b4r0: I would need to check cond_resched() really does. You are discussing colours with a colourblind as the moment :-) Aug 11 10:43:29 ok. If I'm correct, the patch is possibly introducing some very nasty things in SMP mode Aug 11 10:43:51 DonkeyHotei: if it isn't a port specific led, don't use it as such Aug 11 10:44:28 there's a cond_resched() added specifically to ar8xxx_mib_fetch_port_stat(), which is called in atomic context (that I'm pretty certain of since that's code I touched). For the others I can't vouch but it seems some other cases are similar Aug 11 10:44:32 so, netdev on the cpu port? Aug 11 10:44:46 DonkeyHotei: leave it unconfigured and leave it up to the user to set the trigger matching to actual wan interface (ppp for example) Aug 11 10:45:47 most devices do not leave it unconfigured by default Aug 11 10:45:47 DonkeyHotei: AFAIR it is done this way for a bunch of (ramips) boards in the tree Aug 11 10:46:58 most of the ramips boards do not put all the external ports on a second switch while only the first switch has an irq Aug 11 10:47:34 at least in the code Aug 11 10:49:54 DonkeyHotei: please do it as requested. if it isn't port specific led, don't use it as such Aug 11 10:50:53 is there a non-port-specific netdev trigger? Aug 11 10:53:05 DonkeyHotei: yes, a netdev trigger on a ppp, umts or what ever netdev Aug 11 10:54:03 DonkeyHotei: which means you can not set a sane default for an "internet" led. as it highly depends on the users configuration/wan proto Aug 11 10:54:51 mkresin: have to run, can't find a definitive answer. If you want to ping felix about this it boils down to: if it's safe to call cond_resched() in atomic context, all is well. Otherwise, there's a problem. Aug 11 10:54:52 i was thinking maybe netdev on the cpu port if possible, which would have the same effect Aug 11 10:55:33 the idea of calling a (re)scheduling function in atomic context is something that doesn't sit well with my guts, but I've been very remote from kernel code for a long time so what do I know ;) Aug 11 10:57:24 DonkeyHotei: no and the last word on the topic. I can only repeat my self. please do it as requested. Aug 11 10:57:39 unset altogether? Aug 11 11:03:36 DonkeyHotei: yes please. with an explaination that a default config can't be added as the led highly depends on the actual wan connection type and the interfaces created/used by the wan connection Aug 11 11:04:18 DonkeyHotei: since it isn't an led for the actual RJ45 port but rather the layer3 connection Aug 11 11:13:30 interestingly, a long list of devices in that 01_leds file set the trigger to eth0.1 or eth0.2; oh well Aug 11 11:19:12 It was done wrong in the past, we must do it wrong forever more Aug 11 11:32:01 speaking of the past, ucidef_set_led_usbdev is still being used, despite that trigger effectively no longer existing Aug 11 11:36:59 if the wan led is unset by default, the same rationale says the wifi led should be unset by default, rather than defaulting to the 5ghz radio only and ignoring the 2.4 Aug 11 11:37:50 mkresin: correct? Aug 11 11:38:03 DonkeyHotei: it isn't a wan LED. it is an internet LED according to your own words Aug 11 11:38:28 i'm asking about the wlan led now Aug 11 11:40:06 DonkeyHotei: sorry. it's tricky with the wlan led. I recommend to set to either of the wireless. problem here is that we can't set two trigger for the same led. looks like a similar issue but is a different problem Aug 11 11:40:24 it's layer 3 Aug 11 11:41:15 DonkeyHotei: no it isn't. it gets trigger way lower in the osi layer. Aug 11 11:41:35 01_leds uses netdev for all wifi Aug 11 11:42:05 that should probably change Aug 11 11:42:36 just like the usbdev trigger use must change Aug 11 11:42:48 DonkeyHotei: mhh. it's done different on lantiq for example. never noticed it due to the abtraction by the function Aug 11 11:43:15 DonkeyHotei: most likely related to the missing blinking (aka no tpt trigger) of the rt2x00 driver Aug 11 11:43:37 DonkeyHotei: I don't get the usb reference. using usbdev trigger still works Aug 11 11:43:56 DonkeyHotei: but yes, it can be nowdays done via devicetree Aug 11 11:44:26 DonkeyHotei: but one step after another Aug 11 11:44:29 the report is that the usbdev trigger does not work, and when i looked, i found it simply no longer exists in the kernel Aug 11 11:45:11 DonkeyHotei: it exists for sure in the kernel. it was even upstreamed Aug 11 11:45:31 hmm. maybe it's built into something else? Aug 11 11:46:51 DonkeyHotei: you have kmod-usb-ledtrig-usbport included? Aug 11 11:47:06 i added it, per your recommendation Aug 11 11:47:21 but usbport != usbdev Aug 11 11:49:25 DonkeyHotei: is your question about ucidef_set_led_usbdev vs. ucidef_set_led_usbport? Aug 11 11:50:02 well, usbdev is the one used in 01_leds, but usbport is the one that works Aug 11 11:51:52 DonkeyHotei: all I can say at the moment is that ucidef_set_led_usbdev should still work. AFAIR there was a glue layer added to be compatible with the updated trigger Aug 11 11:52:38 DonkeyHotei: the easiest explaination would be that the default params applied by set_usb_led() doesn't work for your board Aug 11 11:52:44 is there a .config symbol for this glue layer? Aug 11 11:53:29 no, it should be in the scripts Aug 11 11:53:59 but isn't it something that was broken in support patch for your board from the beginning Aug 11 11:54:00 hmm Aug 11 11:54:46 i'm wondering whether it may be globally broken for ramips Aug 11 11:55:01 DonkeyHotei: the usbdev trigger/ucidef_set_led_usbdev has it's issue. only one usb port can be the trigger. Aug 11 11:55:13 did someone already looked into WPA3 encryption for wifi? Aug 11 11:55:27 DonkeyHotei: on some boards usb 1.0 2.0 3.0 are individual ports Aug 11 11:55:38 Hauke: the version of hostapd in use already supports it, just not uci Aug 11 11:55:46 DonkeyHotei: one of the reasons for the rewrite Aug 11 11:55:49 DonkeyHotei: yes I saw that Aug 11 11:56:55 mkresin: yeah, i'd call that globally broken Aug 11 11:56:55 DonkeyHotei: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/base-files/files/etc/init.d/led;hb=0ddb34b6b56d613939d4e6844b79415f9bf16939#l39 Aug 11 11:57:41 DonkeyHotei: please keep in mind that using set_usb_led() only usb1-port1 will be used as trigger source Aug 11 11:59:16 right, which is what worked for ledtrig-usbport Aug 11 12:01:46 it makes sense to convert 01_leds to use usbport rather than have it use the glue layer Aug 11 12:02:22 doing so would keep luci from nuking it Aug 11 12:04:35 DonkeyHotei: it does make sense to move it straight to the dts files as it is done in ath79. contributions are welcome Aug 11 12:13:11 seems ath79 goes so far as to define individual usb ports rather than just have the ?hci drivers probe for them Aug 11 12:15:18 DonkeyHotei: 13:55 < mkresin> DonkeyHotei: on some boards usb 1.0 2.0 3.0 are individual ports Aug 11 12:15:52 DonkeyHotei: with the result that using usb1-port1 might trigger only if a usb2 device is attached Aug 11 12:16:32 ath79 does not really solve that from what i can see Aug 11 12:17:08 What is the problem with gccgo and musl-libc? Why is it marked as broken? Aug 11 12:17:40 DonkeyHotei: no idea. but it can be solved this way Aug 11 12:21:10 DonkeyHotei: gave set_usb_led() a try on my alfa-network,ac1200rm and it works Aug 11 12:21:32 DonkeyHotei: you might want to consider that you are doing something wrong instead of everything is broken Aug 11 12:22:17 does luci recognize the the result and/or not reset it? Aug 11 12:24:13 DonkeyHotei: no idea. I barely use luci and it wasn'T mentioned in your "yeah, i'd call that globally broken§ call Aug 11 12:25:44 "yeah, i'd call that globally broken" was in reference to "only one usb port can be the trigger" Aug 11 12:30:40 DonkeyHotei: I rather would call it a limitation. there is a reason why we have ucidef_set_led_usbport() now days and the improved trigger Aug 11 12:31:18 yes, and what i was saying was that it makes sense for 01_leds to use it Aug 11 12:40:32 DonkeyHotei: 14:04:35 < mkresin> DonkeyHotei: it does make sense to move it straight to the dts files as it is done in ath79. contributions are welcome Aug 11 12:41:02 anyway, enough time wasted. Aug 11 13:59:40 this may be a dumb question, but I was unable to find any info in the documentation about logging to a locally mounted filesystem as well as network at the same time Aug 11 14:00:36 https://openwrt.org/docs/guide-user/base-system/log.essentials states that logging to a local file needs "option log_remote '0'", but AFAICS that disables remote logging. Aug 11 14:02:49 Is there any way to log to a local file and a remote log server? Aug 11 14:12:11 i cannot build a image with image-builder after adding luci-app-wireguard to package-list ==> https://paste.debian.net/1037513/ Aug 11 14:25:20 Hi there, trying to get the T-Com Speedport 921V working with 18.06, after the initial boot i get "UBIFS (ubi0:1): recovery needed" is this normal for Nand Devices? same happens with trunk. no data loss so far. Aug 11 15:05:55 greearb: does any of these ath10k crashes make sense to you? https://paste.kde.org/pf6mpzjin/ghfpzl Aug 11 15:17:27 wingman2k: I can't rememeber that this device is even supported Aug 11 15:18:45 wingman2k: no it isn't. are you working on adding support or a third party build? Aug 11 15:34:25 mkresin: there was a build from cornelus1978 and some not merged github commits, just tried to get it build with these information, some concerns about the UBI settings, the following works: all LED's and Buttons, USB, DSL, LAN 1-4 mapped correctly. Pots is untested and WAVE300 is unsupported but visible with lspci Aug 11 15:40:48 can build against 18.06 and master at the moment, cleand up dts files, not much changes neccesarry, but the ubifs recovery bugs me, either the device does not power down correctly or something is not right with the storage settings. i don't have another nand device to check. Aug 11 15:53:07 wingman2k: if you only get the error during intial boot it might be correct Aug 11 15:53:23 wingman2k: point me to the code. otherwise it is just guessing Aug 11 17:00:01 xdarklight, this means the driver killed the firmware because the firmware would not communicate. I don't know how to fix the root cause, but it should recover after the crash Aug 11 17:00:04 Cannot communicate with firmware, attempting to fake crash and restart firmware. Aug 11 17:00:40 greearb: too bad, I'd like to know the root cause. anything I can do to help you find it? Aug 11 17:01:02 (this is after 10 days of uptime, "stock" QCA firmware never survives that long...) Aug 11 17:01:29 root cause is something like DMA engine screws up, or IRQs stop coming, or something. Aug 11 17:01:58 I have looked long and hard, I have mostly given up knowing the real answer, newer hardware works better (9984, etc) in this regard Aug 11 17:02:39 I'd say as long as it recovers, then probably it is as good as it is going to get Aug 11 17:02:47 that seems to match with what other people suggested (buy different hardware) unfortunately :/ Aug 11 17:03:02 if you loose connection once in 10 days, maybe that isn't so bad? Aug 11 17:03:23 I'm sure 9984 has its own issues as well, it is certainly not perfect Aug 11 17:04:36 this is on a BT Home Hub 5A which comes with a built-in VDSL modem (connected to the lantiq SoC) - which is nice since it means I only need one device for DSL connection + wifi AP (my flat isn't that big, signal is fine everywhere) Aug 11 17:05:17 there's not too many other choices in terms of having a "supported" 802.11ac chip + lantiq SoC/modem Aug 11 17:05:59 I'm off to town, take it easy Aug 11 17:06:14 OK, have a good time Aug 11 17:06:39 and thanks for the answers (even if they aren't what I hoped them to be) Aug 11 17:29:47 mkresin: just forked openwrt and added VGV953 here https://github.com/Wingman2k/openwrt, taken from https://github.com/openwrt-mirror/openwrt/pull/15/commits, bootlog https://pastebin.com/gYjAnt6q Aug 11 18:23:07 xdarklight: Try the -htt firmware, I haven't seen that behaviour in a long while Aug 11 18:24:53 xdarklight: disable 802.11w Aug 11 19:36:05 mangix: "grep ieee80211w /etc/config/wireless" shows nothing - AFAIK it's disabled by default. or do you mean another setting? Aug 11 19:37:38 Monkeh: you mean "ath10k-firmware-qca988x-ct-htt", right? Aug 11 19:37:53 xdarklight: Yes Aug 11 19:40:02 I'll give that a go - it won't get me closer to upstream code/firmware but it's worth trying Aug 11 19:40:06 thanks for the hint! Aug 11 19:50:17 xdarklight: nah it's that one. it requires wpad (not mini). 802.11w is completely unstable on ath10k firmwares (all of them). Aug 11 20:17:28 For some Aug 11 20:17:32 Not for all.. Aug 11 20:32:47 all the ones i've tested (even -ct) fail in the same way Aug 11 20:32:50 with 802.11w Aug 11 20:33:09 9880, 9984, 6174 Aug 11 21:17:45 why does my c7-v2 always say Bitrate: 6 Mbit/s for it's 5 GHZ radio? Aug 11 21:29:36 Tapper: Someone just asked that on the forums: https://forum.openwrt.org/t/5ghz-rx-rate-only-6mbit-s/18778 Aug 11 21:30:02 luaraneda K thanks Aug 11 21:30:03 Tapper: "This is a driver limitation. ath10k does not report the actual receive speed back to userspace. It will always show 6 Mbps." Aug 11 21:30:31 O thanks! I did not even have to click the link! Aug 11 21:30:37 lol Aug 11 21:30:47 ;) Aug 11 21:34:06 A prity dumb thing for the driver to get rong tho! Aug 11 21:34:17 pretty* Aug 11 21:35:49 Yep, but I think i read somewhere that it's the firmware that's not reporting the speed at all (or correctly). I'not sure Aug 11 22:12:06 lol **** ENDING LOGGING AT Sun Aug 12 03:00:00 2018