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
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
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
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
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
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