**** BEGIN LOGGING AT Tue Sep 10 02:59:58 2019 Sep 10 07:14:16 Hello! Is there a way to enable/disable name resolution when looking at Realtime connections on OpenWRT? Sep 10 07:41:38 what is a realtime connection? Sep 10 07:50:06 the luci page presumably Sep 10 07:51:10 right - the luci page. http://openwrt/cgi-bin/luci/admin/status/realtime Sep 10 07:57:07 the connections tab in particular Sep 10 07:57:17 is there a way to see which packages are built in an image without flashing the image? Sep 10 08:08:12 rotanid: maybe grep the .config for =y? Sep 10 08:10:17 e.g.: grep '^CONFIG_PACKAGE_.*=y$' .config Sep 10 08:20:45 reiffert: try disabling rrdns: mv /usr/lib/rpcd/rrdns.so /usr/lib/rpcd/rrdns.so.hide; /etc/init.d/rpcd reload Sep 10 10:38:19 nbd: can I quickly consult your regarding ath79 irq? 2 short questions Sep 10 10:39:15 xback: yes Sep 10 10:39:22 1st one: for ar934x, would you agree with this change (like it's done for qca955x): https://pastebin.com/raw/zMaHc0Gb Sep 10 10:39:52 currently, due to the ifelse, if both interrupt source would be set, only the first one would be handled .. the 2nd would be ignored Sep 10 10:40:39 yes, that makes sense Sep 10 10:40:57 ok, ill send proposal upstream for this then Sep 10 10:41:03 2nd one: Sep 10 10:42:04 on ar934x boards, this splat is seen when enabling lockdep and both PCIe and USB are populated: https://pastebin.com/raw/Ycbw7PG6 Sep 10 10:42:18 after a few minutes, it deadlocks one of the devices Sep 10 10:43:04 checking the code shows that only ar934x uses 2 separate IRQ enable/disable functions, which calls disable_irq Sep 10 10:43:29 disable_irq() synchronizes, which is not allowed (mightsleep) Sep 10 10:43:52 is this a proper way to fix this? : https://pastebin.com/raw/vQ00YNPx Sep 10 10:44:22 or would it be better to follow qca955x implementation and skip providing the separate functions Sep 10 10:46:17 There's an attempt to add a new feed on GitHub: https://github.com/openwrt/openwrt/pull/2396 Sep 10 10:46:37 nbd: here is the full source after applying all patches, currently in openwrt master: https://pastebin.com/raw/zujtcviB Sep 10 10:47:47 nbd: srry, correct paste: https://pastebin.com/raw/VD1fQeA4 Sep 10 10:48:28 I think that's quite a bad idea because it introduces something that isn't under our control. But I can't find a polite way to word this thought :( Sep 10 10:51:13 gch981213: I agree with you there. also experience with external feeds show that they die off eventually, because maintaining stuff long term is hard Sep 10 10:53:37 xback: the problem with those cascaded irqs is that the implementation does not have a way of masking the individual cascaded irqs Sep 10 10:53:50 ath9k needs to be able to turn off the irq during reset, otherwise there's a risk of irq storms Sep 10 10:54:29 so as long as there is no way to do masking of individual cascaded irqs, disable_irq is needed Sep 10 10:54:38 i believe disable_irq_nosync would be fine Sep 10 10:54:59 it should probably be added to qca955x and qca956x as well Sep 10 10:55:01 I would test and stresstest to check for side effects Sep 10 10:55:28 it's been too long since i read the datasheet, but if there is a mask register somewhere for those cascaded irqs Sep 10 10:55:35 then the proper fix would be to implement that masking Sep 10 10:55:53 that would make disable_irq for the main interrupt unnecessary Sep 10 10:56:34 so If I understand this, the issue rises when the irq dispatches gets called in separate instances? Sep 10 10:56:43 like when using 2 devices Sep 10 10:57:11 no, 1 device is enough Sep 10 10:57:23 the problem is the cascading setup Sep 10 10:57:55 during reset, ath9k needs to make sure that its irq does not fire Sep 10 10:58:01 and that only works if the irq controller has a way of shutting up the irq Sep 10 10:58:33 with the cascaded setup, no ops are provided to mask the individual cascaded irqs Sep 10 10:58:55 so it may prevent dispatch of individual irqs Sep 10 10:59:01 but that would mean the underlying irq continues to fire Sep 10 11:00:08 i don't know the exact behavior of the irq controller code Sep 10 11:00:35 i guess if it were to disable the underlying irq if all cascaded irqs are disabled, then it would work if there is only one device Sep 10 11:00:50 but it would fail if there is another device that keeps the underlying irq active Sep 10 11:01:02 this seems to match with the behaviour Sep 10 11:01:06 only ath9k: all is fine Sep 10 11:01:11 only usb modem: all is fine Sep 10 11:01:19 enabling both: issues Sep 10 11:01:35 i'll take a quick look at the datasheet to see if there is a mask register somewhere Sep 10 11:01:55 nbd: There isn't such a mask register. Sep 10 11:02:40 Can you share the document or is it NDA? Sep 10 11:02:58 nbd xback: and I remember that the mentioned ath9k irq storm blocked ath79 target for quite a long time. Sep 10 11:03:15 xback: datasheets? You can even find it with Google :P Sep 10 11:03:28 excellent :) Sep 10 11:03:48 I wish it was also that easy for cns3xxx .. :( Sep 10 12:46:23 nbd: any objections https://patchwork.ozlabs.org/patch/1141597/ ? Sep 10 12:47:04 nbd: fyi, using disable_irq_nosync() doesn't seem to be a workaround. The USB device isn't probed anymore Sep 10 12:50:42 gch981213: I'd ask the submitter to introduce his packages in the general package feed Sep 10 12:55:43 rmilecki: during your sysupgrade refactorings, did you check whether `sysupgrade -T` still works? Sep 10 12:56:05 rmilecki: I've seen reports that sysupgrade via LuCI is broken in master recently and there's been no changes on the LuCI side Sep 10 13:00:04 ynezz: sorry, i had overlooked that when you sent it. it's applied now Sep 10 13:00:05 thanks Sep 10 13:00:31 xback: please show me the full diff Sep 10 13:01:10 jow: I'll check that Sep 10 13:03:15 nbd: https://git.openwrt.org/?p=openwrt/staging/xback.git;a=commit;h=4c013cad34fd45746f9fe93190f527215de80381 Sep 10 13:03:23 rmilecki: much appreciated :) Sep 10 13:04:11 rmilecki: sysupgrade -T is also LuCI's current interface to test firmware images, so maybe it might make sense to dump the json results to stdout there (currently just the exit code is tested) Sep 10 13:04:28 jow: it's on my list Sep 10 13:04:41 jow: is that OK for ubus method to return errnr AND send reply? Sep 10 13:05:08 rmilecki: interesting question, actually I never tried Sep 10 13:05:13 it works Sep 10 13:05:30 so can we assume it's allowed? :P Sep 10 13:05:47 jow: my old WIP: https://pastebin.com/Mqkrq4zA Sep 10 13:06:06 sysupgrade_error() is what's important in above Sep 10 13:07:26 * rmilecki is leaving now Sep 10 13:26:42 xback: no idea, sorry Sep 10 13:27:16 nbd: no worries. thanks for taking the time to share your toughts Sep 10 13:27:40 did you had a chance to check if a register is present to find out the irq? Sep 10 13:29:11 didn't find anything Sep 10 17:49:14 jow hey yes please provide a bugs.ow dump, parsing websites was the slowest part of the migration Sep 10 17:53:52 we should probably as well consider closing old bug reports Sep 10 17:54:58 3-6 months without any activity should be a good candidates Sep 10 17:57:13 probably consider stale patches/PR as well Sep 10 18:41:20 Will do Sep 10 22:40:53 ynezz: a lot of patches on the bug tracker aren't reallt stale. the maintainers just don't look at them. Sep 10 22:40:58 *really Sep 10 22:42:35 or, not everyone works at manginx speed? :) Sep 10 22:43:00 * mangix looks Sep 10 22:43:34 oldest patch is from 2018-07-04 Sep 10 22:43:56 seems nobody commented on it Sep 10 22:45:17 from a quick glance, some of these patches are really good Sep 10 22:46:07 i can rephrase if you want a different answer? Sep 10 22:47:22 I understand what you're getting it at, but it's not speed that's the problem. Sep 11 02:28:18 i'm working on a method for installing openwrt on a stock meraki mr24 using their "factory_boot" script (hold the reset button during power on), it expects the kernel, dtb and "uRamdisl Sep 11 02:28:36 i'm working on a method for installing openwrt on a stock meraki mr24 using their "factory_boot" script (hold the reset button during power on), it expects the kernel, dtb and "uRamdisk" in three separate files. Sep 11 02:29:25 i am having trouble finding a separate initramfs in the build artifacts Sep 11 02:38:17 Wrong Ramdisk Image Format Sep 11 02:38:17 Ramdisk image is corrupt or invalid **** ENDING LOGGING AT Wed Sep 11 03:00:21 2019