http://bugzilla.opensuse.org/show_bug.cgi?id=1178013
Bug ID: 1178013
Summary: Application Crash when using FUSE
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: x86-64
OS: openSUSE Tumbleweed
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
Assignee: kernel-bugs(a)opensuse.org
Reporter: reiokorn(a)tutanota.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Please read this forum thread, with all the information about that bug that I
can give you:
https://forums.opensuse.org/showthread.php/546202-Cryptomator-Application-C…
btw Leap is unaffected.
--
You are receiving this mail because:
You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1180749
Bug ID: 1180749
Summary: AMD Ryzen 4800H Integrated Graphics brightness control
not working as found in some Lenovo Legion 5 15ARH05
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: x86-64
OS: openSUSE Tumbleweed
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
Assignee: kernel-bugs(a)opensuse.org
Reporter: antonyjr000(a)gmail.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
When using switchable graphics in Lenovo Legion 5 15ARH05, the AMD Renoir APU
works along with NVIDIA Graphics(even non-free and prime works) but the
brightness cannot be controlled by the Fn keys, Software or
/sys/class/backlight
I've tried setting all the kernel params like acpi_backlight=vender or native
but the brightness control still does not work.
I highly suspect it's a bug in the amdgpu kernel driver. For now nvidia
graphics card works with brightness control.
It is also worthy to note that cat /sys/class/backlight/*/actual_brightness
always returns 311 and does not change even when executed echo 50 >
/sys/class/backlight/*/brightness
There are number of reports on this issue over the internet but nothing
official. I've tried a lot of linux distros and none of them work and it seems
it is broken even in the mainline kernel. I've also tried Kernel:HEAD version
of the kernel without the nvidia graphics support but still the brightness
control does not work. At the time writing I've booted linux 5.11-rc2 but the
brightness control still does not work.
--
You are receiving this mail because:
You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173819
Bug ID: 1173819
Summary: 'BUG: workqueue lockup' on ThunderX2 machines with
kernel 4.12.14 in OBS
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.1
Hardware: aarch64
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
Assignee: kernel-bugs(a)opensuse.org
Reporter: guillaume.gardet(a)arm.com
QA Contact: qa-bugs(a)suse.de
CC: adrian.schroeter(a)suse.com, afaerber(a)suse.com,
dmueller(a)suse.com
Found By: ---
Blocker: ---
obs-arm-7, -8 and -9 are often down in OBS these days due to kernel issues.
One issue is a workqueue lockup:
BUG: workqueue lockup - pool cpus=59 node=0 flags=0x0 nice=0 stuck for 92265s!
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1182318
Bug ID: 1182318
Summary: Superfluous mkinitrd / dracut calls at kernel post
scriptlet
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
Assignee: kernel-bugs(a)opensuse.org
Reporter: tiwai(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
The current kernel rpm scriptlets have some room for optimization. Most
notably, the initrd creation and boot loader setup are called at %post, and
those can be postponed to %posttrans instead.
The problem of multiple initrd creations and boot loader setups becomes more
significant when another package touching initrd (e.g. coreutils) is installed
together, or when the split kernel (kernel-default-extra) is installed
together. As the initrd and the bootloeader setup are triggered in %post from
both kernel-default and kernel-default-extra while the re-creation of the all
initrd is triggered by another package update, this will end up two more extra
calls that are superfluous.
In addition to the above, the pre.sh script contains a few almost superfluous
checks no one really cares. We may clean them up, too.
--
You are receiving this mail because:
You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1175105
Bug ID: 1175105
Summary: mdadm doesn't except partition for --add because of
"dirt" in that partition of a fresh gpt table
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.1
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
Assignee: kernel-bugs(a)opensuse.org
Reporter: ralf(a)czekalla.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
I'm about to migrate an important central private nextcloud server to 15.2.
I'm use RAID1 for all my partitions and benefit from that with easy made clones
with the help of mdadm by growing the number of raid-devices and adding a
refreshed SSD with a new gpt partition table and cloned partitions
descriptions.
This worked for most of the six partitions but one. (It's not the first
installation I transform with this idea. Did these processes already several
times)
This faulty one showed weird error messages I couldn't find a real good reason
for, like ...
...on console:
# mdadm --verbose /dev/md2 --add /dev/sdc5
mdadm: add new device failed for /dev/sdc5 as 4: Invalid argument
# mdadm -E /dev/sdc5
/dev/sdc5:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x9
Array UUID : 94bbbcd3:ad4d1b0b:dcd4d548:1af16050
Name : any:2
Creation Time : Fri Feb 2 20:09:03 2018
Raid Level : raid1
Raid Devices : 3
Avail Dev Size : 83892192 sectors (40.00 GiB 42.95 GB)
Array Size : 41945984 KiB (40.00 GiB 42.95 GB)
Used Dev Size : 83891968 sectors (40.00 GiB 42.95 GB)
Super Offset : 83892208 sectors
Unused Space : before=0 sectors, after=224 sectors
State : active
Device UUID : c9e17312:0069d580:42782958:8817e0f7
Internal Bitmap : -16 sectors from superblock
Update Time : Mon Aug 10 18:09:21 2020
Bad Block Log : 512 entries available at offset -8 sectors - bad blocks
present.
Checksum : 7b5d72a - correct
Events : 0
Device Role : spare
Array State : AA. ('A' == active, '.' == missing, 'R' == replacing)
First I was blinded by the "bad blocks present", but all devices checked out
perfectly healthy in smart and also extended device scans didn't show any
problems. Took me several hours to get through all this.
dmesg:
md: sdc5 does not have a valid v1.0 superblock, not importing!
md: md_import_device returned -22
Also tried to --zero-superblock the partition of course. No change of behavior
and still the above error message in dmesg remained.
At the end I found a surprising hint on serverfault.com
(https://serverfault.com/questions/696392/how-to-add-disk-back-to-raid-and-r…)
from Oct. 2015 with a similar behavior that suggested to clean-up of the
partition first with dd writing zeros (dd if=/dev/zero of=/dev/sdc5
status=progress) and try again later to add the last seemingly faulty
partition.
And long story short, this really worked.
Somehow mdadm - and md behind - is choking on some dirt inside of partition
blocks from old content before the disk/ssd was wiped with a new gpt partition
table. (Of course with SSDs you try to prevent unnecessary writes and wiping
every block of a disk first)
I'm using md device type 1.0 here (in contrast to the serverfault.com case),
where the RAID/md setup data is stored at the end of the partition. I had to
wipe exactly this area at the end of the partition to add it afterwards
successfully. Of course, no effect when doing this at the beginning of the
partition (mentioned in the serverfault.com case) where md type 1.2 stores the
md setup data.
I think after 5 years this might need a clean up in mdadm or md device
management.
At least the error message should suggest to clean the partition first instead
of this error message in dmesg. Also the --zero-superblock should wipe out the
dirt beneath the superblock and not seemingly let some stuff leak here.
Thanks
Ralf
--
You are receiving this mail because:
You are the assignee for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1185008
Bug ID: 1185008
Summary: CPU tainted in dmesg since 5.11
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: x86-64
OS: openSUSE Tumbleweed
Status: NEW
Severity: Major
Priority: P5 - None
Component: Kernel
Assignee: kernel-bugs(a)opensuse.org
Reporter: real86bitals(a)gmail.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Created attachment 848532
--> http://bugzilla.opensuse.org/attachment.cgi?id=848532&action=edit
dmesg output
Hello,
Tumbleweed 20210417
Kernel 5.11.12-1.1 (any 5.11.* in fact)
Every time I boot with a 5.11 kernel, I experience a lot of problems. Touchpad
is lagging, Wi-Fi not connecting and so on. But everything is fine on
5.10.16-1.3.
Dmesg is full of this:
[506.529437] CPU: 4 PID: 7993 Comm: kworker/4:0 Tainted: G S W
5.11.12-1-default #1 openSUSE Tumbleweed
More in the attached file.
--
You are receiving this mail because:
You are the assignee for the bug.