**** BEGIN LOGGING AT Sun Jun 09 02:59:57 2019 Jun 09 08:05:40 Is possible to override kernel config values from global .config ? Jun 09 08:09:08 I have a question in the same direction as muhaha -- is there an example how I can add a switch in the menuconfig that toggles a given kernel config option Jun 09 08:09:38 CONFIG_BNX2X_SRIOV=y to be more concrete Jun 09 08:14:04 ignisf: I did https://github.com/lukasmrtvy/docker-lede-apu2c4/blob/openwrt-18.06/kconfig.sh ,but its a pain, I will rather have option to override it from .config itself... Jun 09 08:21:34 muhaha: any config option named CONFIG_KERNEL_FOO will be translated to CONFIG_FOO in the kernel config - see config/Config-kernel.in for currently exposed configs Jun 09 08:22:36 ignisf: this looks like a driver option, and should probably part of the kernel module package definition Jun 09 08:22:45 KanjiMonster: It does not worked like that a year ago... There was only few kernel options that was possible to override Jun 09 08:25:37 I am pretty sure that it was not working a year ago, because I have some options to override in kernel config https://github.com/lukasmrtvy/docker-lede-apu2c4/blob/openwrt-18.06/.config#L144-L161, but these https://github.com/lukasmrtvy/docker-lede-apu2c4/blob/openwrt-18.06/.kconfig was not possible to override Jun 09 08:27:59 muhaha: just putting the values in the .config isn't enough, you need to make sure those values are backed by a "option KERNEL_" somewhere within OpenWrt's config Jun 09 08:29:21 you mean this https://github.com/openwrt/openwrt/blob/master/config/Config-kernel.in? Jun 09 08:30:25 yes Jun 09 09:58:00 As CONFIG_BNX2X is not used in SoCs for device swith small memory, I am alos fine wit activating CONFIG_BNX2X_SRIOV=y by default for CONFIG_BNX2X Jun 09 09:58:20 but there is not even a kmod for CONFIG_BNX2X Jun 09 10:00:39 isn't there a PR or PATCH for that? I have a faint memory of that Jun 09 10:02:12 hi Hauke, I am working on a patch that adds the package for use in a case specific for me Jun 09 10:02:26 and I need to be able to test it with sr-iov enabled Jun 09 10:02:38 KanjiMonster: could be I do not have an overview Jun 09 10:03:04 me neither, but a quick search in my emails says I misremembered Jun 09 11:10:03 KanjiMonster, did I understand you correctly? https://gist.github.com/ignisf/d14342f61b5ba8e40cf31ab6028f6035 Jun 09 11:10:26 this still doesn't have any effect though... :/ Jun 09 11:11:54 ignisf: did you activate CONFIG_PCI_IOV? Jun 09 11:12:36 is there any possible downside from always enabling BNX2X_SRIOV? if not, why not just set KCONFIG:=CONFIG_BNX2X CONFIG_BNX2X_SRIOV=y Jun 09 11:13:11 Where I can request commit access for OpenWrt routing packages repository? Should I create an issue or ask through OpenWrt bug tracker? There are 3 pull requests for Bird ( https://github.com/openwrt-routing/packages/pulls ) but it looks like nobody cares about it. Jun 09 11:13:42 KanjiMonster, I tried this first, it didn't have any effect either and I couldn't find the option in the resulting kernel .config file Jun 09 11:14:00 it may be due to me not specifying the CONFIG_PCI_IOV option that Hauke just mentioned Jun 09 11:14:01 checking Jun 09 11:18:30 must I also add a commented out CONFIG_BNX2X_SRIOV to target/linux/generic/config-4.14? Jun 09 11:29:56 Hauke: looks good, do you plan to backport it? Jun 09 11:34:34 ynezz: yes let me prepare a patch Jun 09 11:34:53 ignisf: are you using x86? Jun 09 11:35:53 If you use x86, I would suggest to creatae a patch activating CONFIG_PCI_IOV for the x86 target and then do KCONFIG:=CONFIG_BNX2X CONFIG_BNX2X_SRIOV=y Jun 09 11:35:59 yes, attempting to run an owrt VM with two bnx2x IOV VFs Jun 09 11:36:22 ignisf: I think you have to add a # CONFIG_BNX2X_SRIOV to target/linux/generic/config-4.14 and config-4.19 Jun 09 11:37:44 testing just that, the bnx2x_sriov.o file finally got compiled and am waiting for the build to finish Jun 09 12:00:35 woo, it works! thanks Hauke and KanjiMonster Jun 09 12:01:21 will flesh out a patch to submit upstream Jun 09 12:51:57 Hi jow, KanjiMonster do you think there is anything wrong with patching /sbin/hotplug-call to including logging like this: https://pastebin.com/zCCb8LUd Jun 09 12:52:55 Specfically are there any pitfalls I haven't thought of. Could programs depend on the stdout of hotplug scripts? If not this has helped me find a bunch of bugs Jun 09 13:22:27 ignisf: o/ Jun 09 13:25:31 stintel, \o Jun 09 13:26:54 I met the spider in the lab today :D Jun 09 13:28:39 just arrived in Hamburg, who else is already here? Jun 09 13:37:18 Hauke: going to arrive around 7 Jun 09 13:38:19 neoraider: I am watching debian talks Jun 09 17:34:08 . Jun 09 17:36:33 .. Jun 09 18:13:58 <_abc_> Hi. I have a question: If I remove the module gpio-button-hotplug then claim an input gpio keeping a file open on it and reload the module, will the module reclaim the button input when I close the read file on the gpio sysfs device file? Jun 09 18:14:09 <_abc_> I can try this but it is easyer to ask.w Jun 09 19:18:15 , Jun 09 20:36:47 DonkeyHotei how goes it Jun 09 20:38:01 last i checked, still no one has taken up the code review under ar71xx, and the ath79 target as a whole has run into problems Jun 09 20:38:12 oh? Jun 09 20:38:28 yeah i dont understand the review process Jun 09 20:39:32 <_abc_> arg79 has run into problems how? Jun 09 20:39:37 <_abc_> *ath79 Jun 09 20:39:47 <_abc_> build problems beyond 18.06.2 ? Jun 09 20:39:52 no you had it right arg79 Jun 09 20:39:55 ;) Jun 09 20:39:58 not build problems Jun 09 20:40:00 <_abc_> argh79 ? Jun 09 20:40:14 lol Jun 09 20:40:15 <_abc_> Then what problems please? I am on ar71xx 3 devices currently... Jun 09 20:45:11 issues with drivers and irq's Jun 09 20:45:31 an ethernet problem Jun 09 20:45:58 performance, too Jun 09 20:46:18 afaik it's all being worked on and close to solved Jun 09 20:46:45 it would still behoove me to just redo the PR as ath79 Jun 09 20:47:27 <_abc_> I see wifi performance problems with ath79/ar71xx Jun 09 20:47:32 is it harder or easier now since its coming from ar71xx Jun 09 20:47:58 some things will be the same Jun 09 20:48:15 <_abc_> Well in 18.06.2 the release download is ar71xx but inside it's all ath79 references in sysfs etc Jun 09 20:48:32 <_abc_> For tp-links I deal with. Jun 09 20:49:07 after making the gpio changes for the radios its been pretty solid on the 1800 Jun 09 20:49:19 <_abc_> What gpio changes please? Jun 09 20:49:41 _abc_ something specific to the hardware of this ap Jun 09 20:49:51 <_abc_> I have stable wifi as client but performance sucks, ping "groups" get cut off, i.e. fast consecurive pings have problems Jun 09 20:50:20 <_abc_> I tried all the throttles limits etc in the sysfs/etc Jun 09 20:54:05 the gpio patch is likely the easy part of forward porting Jun 09 20:56:46 ever since the kids got out of college its been crazy busy Jun 09 20:59:05 updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html Jun 09 20:59:47 <_abc_> Slimey: what has been busy? Jun 09 20:59:58 work Jun 09 21:00:30 <_abc_> uboot-ar71xx only affects units flashed with new bootloader vs the oem one, right? Jun 09 21:02:14 <_abc_> Which code package(s) govern icmp echo/reponse timing? Kernel net2 code? Jun 09 21:02:56 <_abc_> I will try to test whether the drops in fast pings also appear in non wpa2 mode on the wifi. Perhaps it is that. Jun 09 21:05:12 <_abc_> linux kernel sysfs question: Why was it decided to make sysfs files like gpioX/value open-write-close? I find one could use them much better with open-write-write...-close Jun 09 21:05:21 <_abc_> Also would take care of "busy" status. Jun 09 21:05:59 <_abc_> I mean writing 1\n or 0\n is what one does anyway, perhaps the use I would like would require a flush after each write, not a problem. Jun 09 21:06:18 <_abc_> I tried to write consecutive values and it does not work. Jun 09 21:06:24 <_abc_> one value per line Jun 09 21:07:08 <_abc_> I see lua gets bumped from 5.1.x to 5.3.x that is a big bump. Lua is quite version dependent. Jun 09 21:56:26 where do you see that? Jun 09 22:40:56 Could anyone give an advice what to choose Intel 82583v or i211-at? Jun 09 22:41:12 What's the difference? Jun 10 00:20:58 dissent1: afaik 82583v is supported by e1000e and i211-at by igb, I 'think' i211-at might be more targetted at 'server' uses (offloading, white-listed PCIe IDs for VMware, etc.), but... Intel model numbers are hard to decipher and ark.intel.com not always telling much either Jun 10 00:24:50 (other than stating that i211-at is three years newer than 82583v, ark.intel.com doesn't really show any difference) **** ENDING LOGGING AT Mon Jun 10 02:59:57 2019