Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH 0/5] x86: add support for microcode update
On Thu, 18 Jan 2018, Hauke Mehrtens wrote: On 01/18/2018 01:51 PM, Nick Lowe wrote: Does an update to the Kernel, 4.9.77 and 4.14.14 need to be made to properly address this? There are fixes to mitigate Spectre. We even need a patch for GCC which will be in GCC 8 and 7.3. For master we should backport it to GCC 5.5, but what do we want to do with 17.01 and 15.05 ? I'll speak only of CC - there is no microcode updater in it at all, so while 3.18 contains partial patches and GCC 4.8 is unlikely to get fixed, we should add this facility into it anyway. The AMD microcoded updater needs at least kernel 4.15, 4.14.13, 4.9.76, 4.4.111 which we already have. That's only for the fam17h (Zen) CPUs, earlier CPU types should work with earlier kernels, and this can likely be backported into 3.18. (I don't have a Zen-based box to test, hands up whoever has one.) Regards, -w- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH 2/5] firmware: add microcode package for AMD64
On Thu, 18 Jan 2018, Hauke Mehrtens wrote: On 01/17/2018 08:41 PM, Zoltan HERPAI wrote: Signed-off-by: Zoltan HERPAI --- package/firmware/linux-firmware/x86.mk | 9 + 1 file changed, 9 insertions(+) create mode 100644 package/firmware/linux-firmware/x86.mk diff --git a/package/firmware/linux-firmware/x86.mk b/package/firmware/linux-firmware/x86.mk new file mode 100644 index 000..2dfe7b0 --- /dev/null +++ b/package/firmware/linux-firmware/x86.mk @@ -0,0 +1,9 @@ +Package/amd64-microcode = $(call Package/firmware-default,AMD64 CPU microcode) +define Package/amd64-microcode/install + $(INSTALL_DIR) $(1)/lib/firmware/amd-ucode + $(INSTALL_DATA) $(PKG_BUILD_DIR)/amd-ucode/microcode_amd.bin $(1)/lib/firmware/amd-ucode + $(INSTALL_DATA) $(PKG_BUILD_DIR)/amd-ucode/microcode_amd_fam15h.bin $(1)/lib/firmware/amd-ucode + $(INSTALL_DATA) $(PKG_BUILD_DIR)/amd-ucode/microcode_amd_fam16h.bin $(1)/lib/firmware/amd-ucode +endef +$(eval $(call BuildPackage,amd64-microcode)) + These microcodes are still from 2016_03_16, Debian already ships some more recent versions which they got from Suse. Should we upgrade the linux-firmware package to the most recent version after these new microcodes are added and do the same for 17.01 and 15.05? See here for the Debain changelog: http://metadata.ftp-master.debian.org/changelogs/non-free/a/amd64-microcode/amd64-microcode_3.20171205.1_changelog Yes, this was discussed on IRC. My impression was that the linux-firmware git repo should be doing better than the distros in the first place, but looks like that's not the case, so I'll move to use the amd64-microcode from Debian. Regards, -w- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] patchwork
Hi All, 2018-01-18 1:30 GMT-08:00 Piotr Dymacz : > Hi, > > On 18.01.2018 09:44, Jo-Philipp Wich wrote: >> >> Hi John, Alex, >> >> I have no problem with closing / autorejecting open tickets in patchwork >> as long as they somehow remain available for future reference. > > > ACK. > > Would it be possible to send the author short message why the patch was auto > closed/rejected (excluding the auto message from patchwork)? > >>> To add here. Would it be possible/desire-able to add an auto-timeout >>> to patchwork & github PRs, issues to close after X time ? Maybe make >>> it official as part of the submission process. >> >> >> I would very much like that and have been thinking about this various >> times, maybe it is time to finally implement it. For github PRs you might be interrested in https://github.com/probot/stale >> >> I could think of an idle timeout ranging somewhere between 3 to 6 months. > > > Some of us discussed this during the OpenWrt Summit and IIRC we agreed that > it would make sense and is desirable. > > Also, a nice message explaining why this happens, maybe with short list of > what the user can/should do afterwards, would save us time answering the > same questions, especially on GitHub. > > -- > Cheers, > Piotr > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Enable DCO check on Github OpenWrt organisation
Hi All, Could someone enable this https://github.com/integration/dco on the whole OpenWrt github org? (or at least on the packages repo) Thanks Etienne ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH 0/5] x86: add support for microcode update
On 01/18/2018 01:51 PM, Nick Lowe wrote: > Does an update to the Kernel, 4.9.77 and 4.14.14 need to be made to > properly address this? There are fixes to mitigate Spectre. We even need a patch for GCC which will be in GCC 8 and 7.3. For master we should backport it to GCC 5.5, but what do we want to do with 17.01 and 15.05 ? The AMD microcoded updater needs at least kernel 4.15, 4.14.13, 4.9.76, 4.4.111 which we already have. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH 2/5] firmware: add microcode package for AMD64
On 01/17/2018 08:41 PM, Zoltan HERPAI wrote: > Signed-off-by: Zoltan HERPAI > --- > package/firmware/linux-firmware/x86.mk | 9 + > 1 file changed, 9 insertions(+) > create mode 100644 package/firmware/linux-firmware/x86.mk > > diff --git a/package/firmware/linux-firmware/x86.mk > b/package/firmware/linux-firmware/x86.mk > new file mode 100644 > index 000..2dfe7b0 > --- /dev/null > +++ b/package/firmware/linux-firmware/x86.mk > @@ -0,0 +1,9 @@ > +Package/amd64-microcode = $(call Package/firmware-default,AMD64 CPU > microcode) > +define Package/amd64-microcode/install > + $(INSTALL_DIR) $(1)/lib/firmware/amd-ucode > + $(INSTALL_DATA) $(PKG_BUILD_DIR)/amd-ucode/microcode_amd.bin > $(1)/lib/firmware/amd-ucode > + $(INSTALL_DATA) $(PKG_BUILD_DIR)/amd-ucode/microcode_amd_fam15h.bin > $(1)/lib/firmware/amd-ucode > + $(INSTALL_DATA) $(PKG_BUILD_DIR)/amd-ucode/microcode_amd_fam16h.bin > $(1)/lib/firmware/amd-ucode > +endef > +$(eval $(call BuildPackage,amd64-microcode)) > + These microcodes are still from 2016_03_16, Debian already ships some more recent versions which they got from Suse. Should we upgrade the linux-firmware package to the most recent version after these new microcodes are added and do the same for 17.01 and 15.05? See here for the Debain changelog: http://metadata.ftp-master.debian.org/changelogs/non-free/a/amd64-microcode/amd64-microcode_3.20171205.1_changelog Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Booting D-Link DNS-313, kernel requirements for OpenWRT?
On Wed, Jan 17, 2018 at 6:11 PM, Hans Ulli Kroll wrote: > Hi Linus >> I managed to boot a v4.16-ish kernel and OpenWRT rootfs >> on the D-Link DNS-313 >> (reference https://dflund.se/~triad/krad/dlink-dns-313/) > > interesting device, especially for the VBUS "solution", so I decided to > buy for testing. > I assume VBUS is only connected to GPIO. It's pretty easy to use. Some twists to get the console soldered but can hopefully soon be used with a tailored harddrive and just network access. >> I used the raidsonic rootfs built from scratch (the prebuilt >> images on the site seem broken, just contains zeroes). > > OpenWRT is currently in (re)merging status from LEDE > maybe LEDE images can work. > > I've done a testbuild with current LEDE and ext4 target which fails, > make be a > make -j1 V=s > or a testbuild for my ALIX6F2 give me some light here. I got it working I think ... the git is a mirror of LEDE these days so should be the same. >> sd 0:0:0:0: [sda] 312581808 512-byte logical blocks: (160 GB/149 GiB) >> sd 0:0:0:0: [sda] Write Protect is off >> sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't >> support DPO or FUA >> sda: sda1 sda2 sda3 sda4 >> sd 0:0:0:0: [sda] Attached SCSI disk >> EXT4-fs (sda4): couldn't mount as ext3 due to feature incompatibilities >> EXT4-fs (sda4): couldn't mount as ext2 due to feature incompatibilities >> EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: (null) >> VFS: Mounted root (ext4 filesystem) readonly on device 8:4. > > read only ? I fixed it with "rw" in the cmdline, but still the same problem... :( > I think this must be read write, must verify this with my ALIX6F2 running > openWRT on a CF card with ext4 as rootfs. Sadly this doesn't solve it... I confirmed the problem is something with OpenWRT because a flat, dirt-simple Busybox rootfs boots fine. It's probably my fault anyways, just need to figure it out. Yours, Linus Walleij ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/5] x86: add support for microcode update
On 17/01/18 20:41, Zoltan HERPAI wrote: Hi, This series will add support for microcode update on x86 targets, in light of the recent security issues. While other distributions use an early initramfs approach to update the microcode as early as possible, in OpenWrt the earliest place where we can do this is preinit. due to the importance of this i would propose, that we add a dedicated step inside procd that calls right before preinit. John The Intel microcode package is using the source package by Debian, the AMD microcode package is downloaded from the linux-firmware git repository. This was tested on various Intel-based desktops with ancient BIOSes. Once the series is merged into trunk, this could/should be backported into 17.01 and 15.05 without too much hassle. Thanks, Zoltan H Zoltan HERPAI (5): x86: enable microcode loading for Intel and AMD firmware: add microcode package for AMD64 tools: add iucode-tool firmware: add microcode package for Intel packages: intel-microcode: update to 20180108 package/firmware/intel-microcode/Makefile | 51 ++ .../intel-microcode/files/intel-microcode.preinit | 8 package/firmware/linux-firmware/x86.mk | 9 package/system/iucode-tool/Makefile| 47 target/linux/x86/config-4.14 | 5 ++- target/linux/x86/config-4.9| 5 ++- 6 files changed, 123 insertions(+), 2 deletions(-) create mode 100644 package/firmware/intel-microcode/Makefile create mode 100644 package/firmware/intel-microcode/files/intel-microcode.preinit create mode 100644 package/firmware/linux-firmware/x86.mk create mode 100644 package/system/iucode-tool/Makefile ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] patchwork
Hi, On 18.01.2018 09:44, Jo-Philipp Wich wrote: Hi John, Alex, I have no problem with closing / autorejecting open tickets in patchwork as long as they somehow remain available for future reference. ACK. Would it be possible to send the author short message why the patch was auto closed/rejected (excluding the auto message from patchwork)? To add here. Would it be possible/desire-able to add an auto-timeout to patchwork & github PRs, issues to close after X time ? Maybe make it official as part of the submission process. I would very much like that and have been thinking about this various times, maybe it is time to finally implement it. I could think of an idle timeout ranging somewhere between 3 to 6 months. Some of us discussed this during the OpenWrt Summit and IIRC we agreed that it would make sense and is desirable. Also, a nice message explaining why this happens, maybe with short list of what the user can/should do afterwards, would save us time answering the same questions, especially on GitHub. -- Cheers, Piotr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] merging mailing lists
Hi, Please provide me with a dump of all mail addresses / names currently subscribed s.T. we can setup the new ML and send out auto generated invite mails. John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] patchwork
Hi, On Thu, 18 Jan 2018, John Crispin wrote: Hi, I would like to close all ~1000 un-handled patches from the last 3 years and only keep stuff from the last 6 months. any problem with that ? No objections, if something was missed in the last 3 years (and is not in trunk already), then it'd need to be reworked anyway by the submitter. A 6 month timeout period can work I think - the "need to rework anyway" applies similarly. -w- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] patchwork
Hi John, Alex, I have no problem with closing / autorejecting open tickets in patchwork as long as they somehow remain available for future reference. > To add here. Would it be possible/desire-able to add an auto-timeout > to patchwork & github PRs, issues to close after X time ? Maybe make > it official as part of the submission process. I would very much like that and have been thinking about this various times, maybe it is time to finally implement it. I could think of an idle timeout ranging somewhere between 3 to 6 months. ~ Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] patchwork
On Thu, Jan 18, 2018 at 10:31 AM, John Crispin wrote: > Hi, > > I would like to close all ~1000 un-handled patches from the last 3 years and > only keep stuff from the last 6 months. any problem with that ? > To add here. Would it be possible/desire-able to add an auto-timeout to patchwork & github PRs, issues to close after X time ? Maybe make it official as part of the submission process. Reason is: they pile up ; number of stuff can be too much for the same number of core people that have to handle them. And I bet it can be psychologically daunting/depressing to open up Github/patchwork and see 1000 unresolved stuff, and then people have to work up the mood/will to start going through them. Naturally, an auto-message can be added saying "please re-submit this as the auto-timeout has been reached", as to reduce offending/pissing-off people. This can work nicely as an auto-triaging of stuff, since people will make an effort to re-open PRs, resubmit patches. This shows interest and effort for something to go in. Obviously, it's just an idea/proposal. Feel free to disagree/discard/etc :) > John Alex > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] patchwork
Hi, I would like to close all ~1000 un-handled patches from the last 3 years and only keep stuff from the last 6 months. any problem with that ? John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
