openSUSE Kernel November 2017

kernel@lists.opensuse.org

11 participants
8 discussions

[opensuse-kernel] Re: [opensuse-factory] New Tumbleweed snapshot 20171120 released!

by Andreas Färber

Hi Daniel, Let's move the discussion to opensuse-arm list. Am 23.11.2017 um 12:07 schrieb Daniel Molkentin: > On 11/22/2017 06:31 PM, Andreas Färber wrote: >> Am 22.11.2017 um 04:25 schrieb Dominique Leuenberger: >>> ==== kernel-source ==== >>> Version update (4.13.12 -> 4.14.0) >>> Subpackages: kernel-default kernel-default-devel kernel-devel kernel-docs kernel-macros kernel-syms >>> >>> - Update to 4.14-final. >> On the aarch64 based Pine64 board it has been observed that the updated >> dtb-allwinner package now requires the axp20x-regulator module in the >> initrd for using the MMC driver, and its parent module axp20x-rsb does >> not get loaded automatically even if added to the initrd. > I would prefer if that would be fixed in the kernel by adding the proper > dependencies. > Is there any chance for that? There's multiple issues at play here: 1) This is not a module compile-time dependency issue, but rather a run-time dependency issue, which AFAIU dracut is not resolving today. As a result the JeOS images in openSUSE:Factory:ARM etc. contain a number of add_drivers entries to load such extra modules: https://build.opensuse.org/package/view_file/openSUSE:Factory:ARM/JeOS/conf… That is of course ugly and would be nice to get resolved differently. Dracut would need to parse the Device Tree in /sys/firmware/ to discover what regulator, clock, power domain, etc. nodes are being referenced, then read their "compatible" strings and resolve them to the modules to add. The kernel uses generic API calls such as clk_get() and regulator_get(), thus no compile-time dependency for e.g. mmc modules. However when updating from 4.13 to 4.14 or from 4.14-rc4 to -rc8 it would've still read the current Device Tree and not discovered this new dependency for next boot. And Kiwi images get built in KVM, which will have a different Device Tree than the user's system or even ACPI. So I don't see a full solution yet. Let me know if I should report this somewhere upstream - it didn't seem a distro-specific issue for our Bugzilla. https://www.kernel.org/pub/linux/utils/boot/dracut/dracut.html#_troubleshoo… explains what info to include in a bug report, but not actually where to file it. ;) No link on dracut.wiki.kernel.org either. 2) axp20x-rsb driver does have MODULE_DEVICE_TABLE(of, ...), so it is unclear to me why the DT -> module resolution for auto-loading is not working here. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri… It is almost certainly an upstream kernel issue, possibly in sunxi-rsb bus driver. Stefan has already reported this on #linux-sunxi. > Otherwise, the "proper" dracut patch would > looks something like the attached one. Hm, instmod is just the equivalent of "add_drivers", is it? That would not be enough here. Also not all ARM systems need this driver, it's an extra chip on some boards only. What you could do is more generally add all =drivers/mfd drivers. But if we keep adding drivers by category instead of addressing the underlying discovery issue, we risk at some point the initrd getting too large for low-RAM systems. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 years, 5 months

[opensuse-kernel] Re: [opensuse-factory] New Tumbleweed snapshot 20171120 released!

by Andreas Färber

Am 22.11.2017 um 04:25 schrieb Dominique Leuenberger: > ==== kernel-source ==== > Version update (4.13.12 -> 4.14.0) > Subpackages: kernel-default kernel-default-devel kernel-devel kernel-docs kernel-macros kernel-syms > > - Update to 4.14-final. > - commit c152297 > - rpm/kernel-binary.spec.in: rename kGraft to KLP (fate#323682) > - commit 0ed191d On the aarch64 based Pine64 board it has been observed that the updated dtb-allwinner package now requires the axp20x-regulator module in the initrd for using the MMC driver, and its parent module axp20x-rsb does not get loaded automatically even if added to the initrd. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/a… Workaround is to add to your /etc/dracut.conf.d/sunxi_modules.conf: force_drivers+=" axp20x-rsb " and (if after the update) to re-run dracut by, e.g., mkinitrd. Without such an initrd change it will wait indefinitely for the root partition on SD card on next boot. Selecting an older kernel in GRUB will not help - only manually loading an older dtb in U-Boot can help (if e.g. you had multiversion enabled). Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 years, 5 months

[opensuse-kernel] Re: [opensuse-factory] 4.14 bcache regression can destroy fs

by Markos Chandras

On 22/11/17 03:25, Dominique Leuenberger wrote: > > ==== kernel-source ==== > Version update (4.13.12 -> 4.14.0) > Subpackages: kernel-default kernel-default-devel kernel-devel kernel-docs kernel-macros kernel-syms > > - Update to 4.14-final. > - commit c152297 > - rpm/kernel-binary.spec.in: rename kGraft to KLP (fate#323682) > - commit 0ed191d > fwiw it's seems there is a 4.14 regression with bcache https://marc.info/?l=linux-bcache&m=151082122518597&w=2 https://www.reddit.com/r/linux/comments/7eh2oz/serious_regression_in_linux_… The fix is in https://github.com/torvalds/linux/commit/62530ed8b1d but it missed 4.14.1 So be careful when you update to that kernel. -- markos SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 years, 5 months

[opensuse-kernel] TW 4.14.0 kernel fault on Chromebook snow (ARM exynos5250)

by Guillaume Gardet

Hello, On opensuse-arm list a kernel fault for 4.14.0 (latest TW kernel) has been reported. Here is the kernel trace: http://paste.opensuse.org/96574215 Note that previous kernel 4.13.* was ok. Any idea? Guillaume -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 years, 5 months

[opensuse-kernel] Leap 4.4.92 : Story of kernel warnings that finish to be a total lost of data

by Bruno Friedmann

Hi all, Some times ago (after 4.4.92 hit Leap update repository) I've filled the following bug https://bugzilla.opensuse.org/show_bug.cgi?id=1064533 due to warnings and kernel trace about a raid10. Yesterday, after checking every disk with smart test long and as none of them reported an error I've readded the previously failing harddrive. There was one suspicious things, the resynchronisation at half an hour of the estimate time suddendly was ok. I've rebooted the server at that time, and then start to cry (just a bit), filesystem stored in lv or vm image were all destroyed (fsck.ext4 couldn't fix it auto, and even forced, when you tried to rewrite on it it failed) I've added all the informations I can for the moment to the mentionned bug. But I guess there's a number missing, Don't hesitate to comment here, or directly in the bug and ask for more information. The system as it is should still be present during the next 10 days. Thanks for your help and advise. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 years, 6 months

[opensuse-kernel] Re: [opensuse-buildservice] Re: Firefox build fails on i586 Tumbleweed

by Brüns, Stefan

On Dienstag, 14. November 2017 17:08:18 CET Jan Engelhardt wrote: > On Tuesday 2017-11-14 16:47, Andreas Schwab wrote: > >On Nov 14 2017, Jan Engelhardt <jengelh(a)inai.de> wrote: > >> I have a feeling though, that such won't be enough to get those > >> unspeakably fat browsers to link - it may become necessary to use a > >> 64-bit toolchain with -m32 to complete it, and then the baselibs > >> mechanism to export the build results.> > >Getting all build dependencies ready for -m32 would be a challenge, > >though. > > It could yes. The alternative would be to run a 32-bit userspace with a > 64-bit linker program, requiring only a few -64bit baselibs. > If we ever do x32, modifying mkbaselibs will be a necessity anyway. > Might as well do it now :-) For the time being, can we just package kernel-(l)pae as kernel-obs-build on 32 bit archs, i.e. i586/armv7l? A PAE-enabled kernel has a slight overhead, but this is likely more than compensated by hitting the guests swap later. This does not change the 3GByte per process limit, which may cause failing linker runs. Using a 64bit linker is much more effort, so I would vote for a PAE kernel first and *if* we still see OOM errors, reconsider if we should go the 64bit userspace route (i586 is quite dead, but armv7l may stay for a bit longer). CC'ed opensuse-kernel, as I already sent a patch addressing kernel-obs-build a week ago. Kind regards, Stefan -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 years, 6 months

[opensuse-kernel] enabling CONFIG_IMA and friends in the Tumbleweed kernel

by Marcus Meissner

Hi, The Security Team is currently evaluating IMA/EVM binary/file protection mechanisms. Most of the stuff lives only in Tumbleweed, so could someone (Jeff Mahoney?) please enable CONFIG_IMA and friends similar to Leap 42 and SLES? Ciao, Marcus -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 years, 6 months

[opensuse-kernel] [PATCH] rpm/kernel-obs-build.spec.in: use (l)pae kernel on armv7l/ix86

by Stefan Brüns

A non-pae kernel only uses up to 3 GByte of physical RAM, thus a memory constraint for an obs worker is essentially ignored. Although the per-process memory is still limited, parallel builds can use more memory. --- kernel-source-opensuse, packaging branch --- rpm/kernel-obs-build.spec.in | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/rpm/kernel-obs-build.spec.in b/rpm/kernel-obs-build.spec.in index 230b97f126..d47d138bbb 100644 --- a/rpm/kernel-obs-build.spec.in +++ b/rpm/kernel-obs-build.spec.in @@ -35,10 +35,20 @@ BuildRequires: util-linux BuildRequires: kernel-vanilla %define kernel_flavor -vanilla %else +%ifarch %ix86 +BuildRequires: kernel-pae +%define kernel_flavor -pae +%else +%ifarch armv7hl armv7l +BuildRequires: kernel-lpae +%define kernel_flavor -lpae +%else BuildRequires: kernel-default %define kernel_flavor -default %endif %endif +%endif +%endif %if 0%{?rhel_version} BuildRequires: kernel -- 2.14.3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 years, 6 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openSUSE Kernel November 2017