**** BEGIN LOGGING AT Thu Feb 14 02:59:57 2019 Feb 14 09:40:08 * russell-- just built some images for dumb aps, they have a static network configuration with an "option dns ", but /etc/resolv.conf is empty Feb 14 09:42:54 * ldir steps away from that rabbit hole! Feb 14 09:43:55 /etc/resolv.conf is a symlink to /tmp/resolv.conf, which is a symlink to /tmp/resolv.conf.auto which is empty Feb 14 09:47:44 dnsmasq isn't running (intentionally) Feb 14 09:49:51 ah, i might have found the problem Feb 14 09:50:07 turns out a , isn't *exactly* the same thing as a . Feb 14 09:51:31 * russell-- checks prescription on glasses Feb 14 09:52:28 assumes russell-- has 2 sets of mostly adequate glasses otherwise the prescription check could get interesting :-) Feb 14 09:53:25 Have to say I don't know what populates /tmp/resolv.conf.auto Feb 14 09:54:55 is the user specific crontab the only way to have cronjobs? i'd like to seperate the root jobs from the system ones Feb 14 09:55:10 * ldir is overjoyed at receiving Benin spam instead of Nigerian spam. Feb 14 09:57:03 * russell-- 's many-many-pixel display bits him in the ass Feb 14 09:57:17 bites* Feb 14 13:36:52 looking at the tplink-tdw8970 target, is it correct that default kernel config includes rtl8366 and rtl8306 modules? Am I wrong or those switches are not present on that device? Feb 14 14:02:13 ^ok got it, other xrx200 devices use that switch Feb 14 16:07:48 * lach1012 waits for the builders Feb 14 16:43:53 dedeckeh_: do you feel like taking over maintainership for net-snmp? I have several issues and/or pr's open on it and I don't seem to get to looking at them Feb 14 16:55:02 stintel:I'm afraid I don't have the bandwidth to take over the maintainership of net-snmp Feb 14 16:55:40 dedeckeh_: ok np, was worth a shot ;) Feb 14 17:02:28 stintel:sure; $dayjob takes most of my time :) Feb 14 17:03:24 stintel: speaking of, I'm going away on holidays for ~5weeks, if anything mosquitto comes up, feel free to hack on it Feb 14 17:03:26 same here, and travel probably 2nd Feb 14 17:03:40 karlp: nice holiday, enjoy! Feb 14 17:04:10 upstream isn't _expecting_ anything new, we just got out a release that should be good for a while. Feb 14 17:04:15 no regressions so far at least. Feb 14 17:04:23 I'm driving to Belgium end of the month for 3 weeks probably, and when I'm there I usually don't have a lot of time or a nice work space to do OpenWrt stuff Feb 14 17:45:56 hm, what's the patchwork slang for "already accepted"? Feb 14 17:53:45 "Score dude!" ?? ;) Feb 14 17:55:41 https://patchwork.ozlabs.org/project/openwrt/list/?series=&submitter=&state=3&q=&archive=&delegate= Feb 14 17:55:53 "State = Accepted" Feb 14 17:59:14 kinda, it's between "accepted" "not applicable" Feb 14 18:30:23 jeffsf: this might help with the slow caldata extraction: https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=commit;h=62f65f876f352eb64f5ebac38d0a6dc2bf0b7995 Feb 14 18:32:35 Thanks! Smart approach Feb 14 18:33:31 Now if I can figure out why the QCA9888 on PCIe and its driver communication time out Feb 14 18:34:04 Definitely reassuring to at least see the three APs up and running! Feb 14 18:34:48 Any meaningful message in the log? Feb 14 18:35:10 ath10k or the pcie subsystem must be spewing other error messages or warnings Feb 14 18:39:08 Yeah -- wmi command timeout Feb 14 18:39:17 Thu Feb 14 18:35:28 2019 user.notice mac80211: mac80211_setup_vif() Feb 14 18:39:26 Thu Feb 14 18:35:52 2019 kern.warn kernel: [ 5170.012044] ath10k_pci 0000:01:00.0: wmi command 36967 timeout, restarting hardware Feb 14 18:39:43 (first is my logging of the calls in mac80211.sh) Feb 14 18:40:15 Then all kinds of errors Feb 14 18:40:43 First pinpointed to backports-4.19.7-1/net/mac80211/util.c:1940 Feb 14 18:41:12 which is the source of Thu Feb 14 18:35:53 2019 kern.info kernel: [ 5170.119782] ieee80211 phy0: Hardware restart was requested Feb 14 18:41:49 drv_start(), as I recall -- which looks like it calls a driver-specific start() from the driver struct Feb 14 18:42:20 Then recurring failures at mac80211/driver-ops.h:19 Feb 14 18:42:39 hm, I'm looking which wmi command maps to 36967 Feb 14 18:42:45 AP is still "live", but seems disconnected from the mac80211 system Feb 14 18:43:09 the address in mac80211 aren't of much use Feb 14 18:43:18 it could be a firmware issue too Feb 14 18:43:37 Possible, yes -- same behavior with "classic" or "CT" Feb 14 18:43:41 I know that ath10k can behave in such a way, if a wmi isn't supported Feb 14 18:44:14 the failed call that is tested that triggers the WARN is `ret = local->ops->start(&local->hw);` Feb 14 18:44:55 ieee80211_reconfig() calls drv_start() which makes that call if !suspended Feb 14 18:47:58 lach1012: the mac80211 update was only to test the backports release I do not know if we want to integarte this in the next few weeks Feb 14 18:52:04 jeffsf: do you think you could add a "WARN_ON(1);" at build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/linux-ipq40xx/ath10k-ct-2018-12-20-118e16da/ath10k-4.19/wmi.c line 1925 ? Feb 14 18:52:56 this should give a stack-trace to the function that's calling "ath10k_wmi_cmd_send" because by the looks of the wmi-cmd number something could be pushing garbage to the firmware. Feb 14 18:55:06 I'll give it a try -- might be a bit, as it's 11 AM here in California Feb 14 18:59:37 Hmmm, don't have that path Feb 14 19:00:26 linux-ipq40xx/backports-4.19.7-1/drivers/net/wireless/ath/ath10k/wmi.o Feb 14 19:01:41 jow: I asum ewe will shift the 19.3 branch to beginning of march? Feb 14 19:01:50 * I assume we Feb 14 19:10:18 jeffsf: do you have a wmi.c? Feb 14 19:11:16 lach1012: yes, made the edit -- causes the system to reboot before I could pull down the logs. Might be too much for the log buffer to handle Feb 14 19:11:21 Looking into it further Feb 14 19:11:29 because you could also just to a text search for "wmi command %d timeout, restarting hardware\n" and add the WARN_ON(1); before the ath10k_warn Feb 14 19:11:42 OK, that I know where it is! Feb 14 19:11:43 Well, WARN_ON_ONCE(1) Feb 14 19:12:08 that will only fire for the first occurrence Feb 14 19:12:31 thanks -- cleaning and then re-editing Feb 14 19:58:10 lach1012: https://pastebin.com/Z3My9Lcp Feb 14 20:02:14 Good idea -- stack trace shows [ 225.286308] [] (set_brightness_delayed) from [] (process_one_work+0x2b8/0x4b8) Feb 14 20:03:23 `[*] Enable LED support ` is "default" -- removing now Feb 14 20:13:36 hmm Feb 14 20:13:51 I also noticed... the qca9888 should have a new firmware Feb 14 20:14:05 *get Feb 14 20:14:14 Still bombs, now on `bss channel survey timed out` and `wmi command 36892 timeout` -- pastebin OTW Feb 14 20:15:05 https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=1bd5312da80a40b49ae8e141fb1d686de8b56e93 Feb 14 20:15:12 it was recently updated Feb 14 20:15:29 From 10.4-3.6-00140 to 10.4-3.9.0.2-00024 Feb 14 20:15:34 https://pastebin.com/hQVqAESS Feb 14 20:16:47 OK, will rebase -- better to test "classic" or -ct driver/firmware? Feb 14 20:17:44 -ct is prefered. Because greearb can debug those Feb 14 20:17:52 OK -- will do Feb 14 20:18:04 you know: greearb Feb 14 20:18:09 https://github.com/greearb/ath10k-ct Feb 14 20:18:15 Personally, no, name, yes Feb 14 20:19:02 hit ctrl+v too soon Feb 14 20:20:08 the weird thing is: the driver seems to initialize just fine Feb 14 20:20:45 I would have expected it to fail much sooner Feb 14 20:20:49 Yes -- I keep thinking it's a misconfigured GPIO somewhere, and keep hoping it's not Feb 14 20:21:00 hm, more like boardfiles? Feb 14 20:21:42 Driver brings up the AP -- I can see it on another with iw scan, with the OpenWrt-specified SSID Feb 14 20:23:02 and also, the qca9888 + ipq4019 is also used by the openmesh a62 Feb 14 20:23:19 Yes, so it should be possible Feb 14 20:23:20 so if this was a systemic problem, Sven would probably have reported it by now. Feb 14 20:23:31 agree Feb 14 20:23:58 hm **** ENDING LOGGING AT Fri Feb 15 02:59:56 2019