July 2018 - openSUSE Kernel - openSUSE Mailing Lists

[opensuse-kernel] Reliability test for hard drives and SSD
by Andrey Ponomarenko 29 Jul '18

29 Jul '18

Hi there! Good news for all interested in hardware compatibility and reliability. I've started a new project to estimate reliability of hard drives and SSD in real-life conditions based on the SMART data reports collected by Linux users in the Linux-Hardware.org database since 2014. The initial data (SMART reports), analysis methods and results are publicly shared in a new github repository: https://github.com/linuxhw/SMART. Everyone can contribute to the report by uploading probes of their computers by the hw-probe tool! The primary aim of the project is to find drives with longest "power on hours" and minimal number of errors. The following formula is used to measure reliability: Power_On_Hours / (1 + Number_Of_Errors), i.e. time to the first error/between errors. Please be careful when reading the results table. Pay attention not only to the rating, but also to the number of checked model samples. If rating is low, then look at the number of power-on days and number of errors occurred. New drive models will appear at the end of the rating table and will move to the top in the case of long error-free operation. Thanks to ROSA, openSUSE, Gentoo, Ubuntu, Debian, Mint, Arch, Fedora users and others who had made this work possible by contribution to the database! -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 4

[opensuse-kernel] [PATCH] rpm/kernel-source.spec.in: require bc for kernel-source
by Andreas Schwab 23 Jul '18

23 Jul '18

This is needed for building include/generated/timeconst.h from kernel/time/timeconst.bc. --- rpm/kernel-source.spec.in | 1 + 1 file changed, 1 insertion(+) diff --git a/rpm/kernel-source.spec.in b/rpm/kernel-source.spec.in index f58b8946a0..2d80c45883 100644 --- a/rpm/kernel-source.spec.in +++ b/rpm/kernel-source.spec.in @@ -118,6 +118,7 @@ Prefix: /usr/src # Source is only complete with devel files. Requires: kernel-devel%variant = %version-%source_rel Recommends: openssl-devel +Requires: bc %(chmod +x %_sourcedir/{@SCRIPTS@}) -- 2.18.0 -- Andreas Schwab, SUSE Labs, schwab(a)suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

4 46

[opensuse-kernel] Re: Kernel:stable issues with nvidia-gfxG0{3,4} builds for i586
by Hans-Peter Jansen 20 Jul '18

20 Jul '18

On Dienstag, 17. Juli 2018 20:26:22 Stefan Dirsch wrote: > On Tue, Jul 17, 2018 at 04:11:55PM +0200, Hans-Peter Jansen wrote: > > in an attempt to locally build i586 nvidia-gfxG0{3,4} packages with the > > kernel from Kernel:stable, I harvest strange errors, that seems to stem > > from issues in the i586 kernel builds. That's not such a big surprise of > > course, given that those kernels aren't exercised that much nowadays... > > > > Here's what I've analysed so far. > > > > In %build of nvidia-gfxG03, there's this line (in both %build and %install): > > src=/lib/modules/$(make -siC %{kernel_source $flavor} > > kernelrelease)/source > > > > running in a loop to fetch the kernel module source path for the current > > flavor. Unfortunately, the subshell call > > > > make -siC %{kernel_source $flavor} kernelrelease > > > > detects some inconsistencies, and tries to generate a full .config > > interactively. Needless to say, that $src doesn't point to an existing > > path > > thereafter.. > > > > The nvidia-gfxG04 build fails in a similar way. > > > > Q: What's wrong with that make call for i586? Obviously, this is working > > fine for x86_64? > > Thanks for the reminder. The build on TW/Factory i586 is still broken due to > this issue. Honestly, I don't know how to fix that. :-( > > Maybe Michal has an idea ... Now, that IA32 kernel from Kernel:stable are operational again, it would be nice, if some enlightened person could put some love into our IA32 kernel builds... Cheers, Pete -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

1 0

[opensuse-kernel] How to build and install a 64 debian kernel for PI-3?
by Raz 18 Jul '18

18 Jul '18

hello I am trying to replace the kernel for the PI3. The PI was flushed with the image 018-01-08-raspberry-pi-3-buster-PREVIEW. Are there any special instructions for how to build and install the kernel ? I manage to build and install a kernel for the previous versions ( with the grub) - openSUSE-Leap42.2-ARM-E20-raspberrypi3.aarch64.raw.xz but in the new version I fail. thx -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

1 0

[opensuse-kernel] Kernel:stable issues with nvidia-gfxG0{3,4} builds for i586
by Hans-Peter Jansen 17 Jul '18

17 Jul '18

Hi, in an attempt to locally build i586 nvidia-gfxG0{3,4} packages with the kernel from Kernel:stable, I harvest strange errors, that seems to stem from issues in the i586 kernel builds. That's not such a big surprise of course, given that those kernels aren't exercised that much nowadays... Here's what I've analysed so far. In %build of nvidia-gfxG03, there's this line (in both %build and %install): src=/lib/modules/$(make -siC %{kernel_source $flavor} kernelrelease)/source running in a loop to fetch the kernel module source path for the current flavor. Unfortunately, the subshell call make -siC %{kernel_source $flavor} kernelrelease detects some inconsistencies, and tries to generate a full .config interactively. Needless to say, that $src doesn't point to an existing path thereafter.. The nvidia-gfxG04 build fails in a similar way. Q: What's wrong with that make call for i586? Obviously, this is working fine for x86_64? Thanks in advance, Pete -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

1 0

[opensuse-kernel] [PATCH] config: arm64: enable I2C_PXA, used on Marvel EBU SoCs
by Guillaume GARDET 17 Jul '18

17 Jul '18

Signed-of-by: Guillaume GARDET <guillaume.gardet(a)free.fr> This patch is for stable branch. Please also apply to master and openSUSE-15.0. --- config/arm64/default | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/config/arm64/default b/config/arm64/default index 474974c4e5..bcbdeea935 100644 --- a/config/arm64/default +++ b/config/arm64/default @@ -1,6 +1,6 @@ # # Automatically generated file; DO NOT EDIT. -# Linux/arm64 4.17.2 Kernel Configuration +# Linux/arm64 4.17.5 Kernel Configuration # CONFIG_ARM64=y CONFIG_64BIT=y @@ -3907,7 +3907,8 @@ CONFIG_I2C_MV64XXX=m # CONFIG_I2C_NOMADIK is not set CONFIG_I2C_OCORES=m CONFIG_I2C_PCA_PLATFORM=m -# CONFIG_I2C_PXA is not set +CONFIG_I2C_PXA=m +# CONFIG_I2C_PXA_SLAVE is not set CONFIG_I2C_QUP=m CONFIG_I2C_RK3X=m # CONFIG_I2C_SIMTEC is not set @@ -7055,7 +7056,6 @@ CONFIG_DMA_ENGINE_RAID=y CONFIG_SYNC_FILE=y # CONFIG_SW_SYNC is not set CONFIG_AUXDISPLAY=y -CONFIG_CHARLCD=m CONFIG_HD44780=m # CONFIG_IMG_ASCII_LCD is not set CONFIG_HT16K33=m @@ -7063,6 +7063,7 @@ CONFIG_PANEL=m CONFIG_PANEL_PARPORT=0 CONFIG_PANEL_PROFILE=5 # CONFIG_PANEL_CHANGE_MESSAGE is not set +CONFIG_CHARLCD=m CONFIG_UIO=m CONFIG_UIO_CIF=m CONFIG_UIO_PDRV_GENIRQ=m -- 2.18.0 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 4

[opensuse-kernel] Multiple mkinitrd's run during dup - why?
by Richard Brown 08 Jul '18

08 Jul '18

It's not the first time I've noticed this, but during my zypper dup today my system ran mkinitrd at least twice Once as part of installing kernel-default (in the %post install of that package) and once again as part of installing coreutils (in the %posttrans, using the %{?regenerate_initrd_posttrans} macro) If I understand correctly the whole point of the %{?regenerate_initrd_posttrans} macro is to prevent multiple runs of mkinitrd necessarily - so I guess my question is - why isn't the kernel using it? And would it be a good idea to consider it? -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

2 1