September 2021 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[Bug 1190764] New: [Build 20210920] btrfs: invalid qgroupid or subvolume path
by bugzilla_noreply＠suse.com 26 Oct '22

26 Oct '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1190764 Bug ID: 1190764 Summary: [Build 20210920] btrfs: invalid qgroupid or subvolume path Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/1929805/modules/btrf s_qgroups/steps/24 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: dimstar(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: openQA Blocker: Yes ## Observation openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-extra_tests_filesystem@64bit fails in [btrfs_qgroups](https://openqa.opensuse.org/tests/1929805/modules/btrfs_qgro… The openQA test code is this: assert_script_run "btrfs quota enable ."; # Create subvolumes, qgroups, assigns and limits # 2/1 # / \ # 1/1 1/2 # / \ / | \ # a b c d(k) assert_script_run "for c in {a..d}; do btrfs subvolume create \$c; done"; assert_script_run "for c in 1/1 1/2 2/1; do btrfs qgroup create \$c .; done"; assert_script_run "for c in a b; do btrfs qgroup assign \$c 1/1 .; done"; assert_script_run "for c in b c d; do btrfs qgroup assign \$c 1/2 .; done"; assert_script_run "for c in 1/1 1/2; do btrfs qgroup assign \$c 2/1 .; done"; And the last command here returns: ERROR: invalid qgroupid or subvolume path: a ERROR: invalid qgroupid or subvolume path: b ## Test suite description Maintainer: QE Core Filesystem related tests, for example snapper and btrfs features. ## Reproducible Fails since (at least) Build [20210920](https://openqa.opensuse.org/tests/1928938) ## Expected result Last good: [20210918](https://openqa.opensuse.org/tests/1927312) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensus… -- You are receiving this mail because: You are the assignee for the bug.

1 4

[Bug 1188954] New: black screen on initial X open on Kaveri Radeon R7, /dev/dri/card0: No such file or directory with radeon.cik_support=0 amdgpu.cik_support=1
by bugzilla_noreply＠suse.com 26 Oct '22

26 Oct '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1188954 Bug ID: 1188954 Summary: black screen on initial X open on Kaveri Radeon R7, /dev/dri/card0: No such file or directory with radeon.cik_support=0 amdgpu.cik_support=1 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: mrmazda(a)earthlink.net QA Contact: qa-bugs(a)suse.de CC: sndirsch(a)suse.com Found By: --- Blocker: --- Created attachment 851460 --> http://bugzilla.opensuse.org/attachment.cgi?id=851460&action=edit Xorg.0.log and dmesg Initial summary: black screen on initial X open on Kaveri Radeon R7, /dev/dri/card0: No such file or directory with radeon.cik_support=0 amdgpu.cik_support=1 To reproduce: 1-boot with included on kernel cmdline radeon.cik_support=0 amdgpu.cik_support=1 2-wait for X to fail to start 3-login on a tty 4-systemctl restart xdm Actual behavior: 1-X fails to start, finding no /dev/dri/card0, leaving login prompt on tty1 on display screen 2-X starts normally using amdgpu DDX driver Expected behavior: 1-X starts normally using amdgpu DDX driver Tested with kernels 5.12.13, 5.11.16, 5.7.11 # inxi -SGIay System: Host: asa88 Kernel: 5.12.13-1-default x86_64 bits: 64 compiler: gcc v: 11.1.1 parameters: BOOT_IMAGE=/boot/vmlinuz root=LABEL=tvgp07stw noresume ipv6.disable=1 net.ifnames=0 mitigations=auto consoleblank=0 radeon.cik_support=0 amdgpu.cik_support=1 video=1024x768@60 video=1440x900@60 drm.debug=0x1e log_buf_len=1M Console: tty pts/0 DM: TDM Distro: openSUSE Tumbleweed 20210730 Graphics: Device-1: AMD Kaveri [Radeon R7 Graphics] vendor: ASUSTeK driver: amdgpu v: kernel alternate: radeon bus-ID: 00:01.0 chip-ID: 1002:130f class-ID: 0300 Display: server: X.org 1.20.12 driver: loaded: vesa unloaded: fbdev,modesetting alternate: ati Message: Advanced graphics data unavailable for root. Info:...inxi: 3.3.06 Comments: 1-without radeon.cik_support=0 amdgpu.cik_support=1 on cmdline, X cannot be coaxed into using amdgpu DDX driver via /etc/X11/xorg.conf.d/*conf 2-without radeon.cik_support=0 amdgpu.cik_support=1, greeter startup completes (normally, on first try) using modesetting DIX driver -- You are receiving this mail because: You are the assignee for the bug.

1 25

[Bug 1189946] New: [trackerbug] Ancient patch cleanup
by bugzilla_noreply＠suse.com 11 Oct '22

11 Oct '22

https://bugzilla.suse.com/show_bug.cgi?id=1189946 Bug ID: 1189946 Summary: [trackerbug] Ancient patch cleanup 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: jeffm(a)suse.com QA Contact: qa-bugs(a)suse.de CC: jeffm(a)suse.com, mkubecek(a)suse.com Found By: --- Blocker: --- This is the tracker bug for cleaning up old patches in the master branch. -- You are receiving this mail because: You are the assignee for the bug.

1 20

[Bug 1187566] New: Display connected to Thunderbolt 3 Docking Station is not detected on cold boot
by bugzilla_noreply＠suse.com 10 Oct '22

10 Oct '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1187566 Bug ID: 1187566 Summary: Display connected to Thunderbolt 3 Docking Station is not detected on cold boot Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: x86-64 OS: openSUSE Leap 15.3 Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: eecdc3.opensuse(a)coders-haven.net QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I am using a HP Elitebook 1040 G4 notebook connected to a HP Thunderbolt 3 Docking Station, which in turn is connected to multiple USB devices and an external monitor via DisplayPort. Unfortunately, I am experiencing issues with this configuration as described below. I am using boltd from the hardware repository to authorize my Thunderbolt 3 Docking Station during startup. (Boot ACLs are not supported by my BIOS, as far as I can tell.) While devices connected to the docking station via USB will work afterwards, my external monitor, which is connected via DisplayPort, will not be detected automatically. Only when I manually reconnect the docking station after startup has completed, it will finally be detected (and awoken from standby). This leads me to believe that this issue is boot order related. (Previously, I was using openSUSE Leap 15.2 and a custom udev rule to authorize the docking station via sysfs and I did not experience this issue but the system would occasionally hang while booting instead. I have already tried the udev rule with openSUSE Leap 15.3 but this made the issue worse as the display was then only detected if I reconnected the external monitor itself.) Any help investigating this issue is appreciated as I do not have in-depth knowledge of the kernel or its Thunderbolt subsystem and cannot really make any progress towards a resolution on my own. -- You are receiving this mail because: You are the assignee for the bug.

1 8

[Bug 1180985] New: Kernel 5.10 breaks ethernet connection with lenovo x390
by bugzilla_noreply＠suse.com 30 Sep '22

30 Sep '22

https://bugzilla.suse.com/show_bug.cgi?id=1180985 Bug ID: 1180985 Summary: Kernel 5.10 breaks ethernet connection with lenovo x390 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: fcastelli(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I have a lenovo x390 laptop with an intel CPU. I've been running Tumbleweed on it since a while because I needed a newer kernel compared to Leap to get my network card to work. Everything worked fine since I upgraded to 5.10.x. The upgrade caused the ethernet card to became unreliable (like it happened with old Leap 15.1 kernel). The network card works fine for some time, then it suddenly loses the connection. I can see Gnome NetworkManager trying to setup the card, but the process never ends. The x390 doesn't have a physical eth port, it has a proprietary adapter that provides that to the laptop. This adapter is plagued by the issue. The same issue happens when I connect the computer to its USB-C docking station (an official one provided by Lenovo). The docking station provides an eth port which is affected by this issue. The 5.9.14-1.2 and the 5.9.12-1.1 kernels are the last kernels I tested on my computer that proved to be fine. I'll try to collect more detailed logs from syslog, but right now it's a bit hard for me because I cannot reproduce the issue. I just have to wait for it to happen... -- You are receiving this mail because: You are the assignee for the bug.

1 17

[Bug 1190340] New: armv7hl 5.14 kernel build fails for Leap 15.4
by bugzilla_noreply＠suse.com 06 Sep '22

06 Sep '22

https://bugzilla.suse.com/show_bug.cgi?id=1190340 Bug ID: 1190340 Summary: armv7hl 5.14 kernel build fails for Leap 15.4 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 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: --- Now we start building the armv7hl kernel for Leap 15.4, and it fails as: [ 9793s] GEN modules.builtin [ 9793s] LD .tmp_vmlinux.btf [ 9827s] BTF .btf.vmlinux.bin.o [ 9884s] [4957384] STRUCT thread_info's field 'vfpstate' offset=2048 bit_size=0 type=4957356 Error emitting field [ 9884s] Encountered error while encoding BTF. .... [ 9994s] FAILED: load BTF from vmlinux: No such file or directory [ 9994s] make[1]: *** [/home/abuild/rpmbuild/BUILD/kernel-default-5.14.2/linux-5.14/Makefile:1200: vmlinux] Error 255 My initial attempt worked because BTF wasn't enabled due to the old tools. OTOH, the same 5.14 build is OK with stable branch, so there is still some missing piece, supposedly. -- You are receiving this mail because: You are the assignee for the bug.

1 9

[Bug 1180591] New: Display backlight stuck at 100%
by bugzilla_noreply＠suse.com 08 Aug '22

08 Aug '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1180591 Bug ID: 1180591 Summary: Display backlight stuck at 100% 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: maurizio.galli(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 844855 --> http://bugzilla.opensuse.org/attachment.cgi?id=844855&action=edit system information I have just upgraded my device to Tumbleweed and now backlight brightness is stuck at 100% with no way to change it. I have tried several methods, including xbacklight and Xfce settings. Backlight control used to work fine with Kernel 5.3 shipped by Leap. I found a recent report using similar hardware that could suggest a regression in the kernel: https://discuss.getsol.us/d/6039-brightness-control-not-working-on-apple-di… I attached information about my system but please let me know what else I can provide. -- You are receiving this mail because: You are the assignee for the bug.

1 24

[Bug 1188934] New: bluetooth not automatically powered on
by bugzilla_noreply＠suse.com 22 Jul '22

22 Jul '22

https://bugzilla.suse.com/show_bug.cgi?id=1188934 Bug ID: 1188934 Summary: bluetooth not automatically powered on 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: msuchanek(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- There is yet another way to make bluetooth devices unusable. The beluetooth adapter is by default powered off, and has to be manually powered on to be able to connect devices. [bluetooth]# scan on Failed to start discovery: org.bluez.Error.NotReady [bluetooth]# scan on Failed to start discovery: org.bluez.Error.NotReady [bluetooth]# scan on Failed to start discovery: org.bluez.Error.NotReady [bluetooth]# power on [bluetooth]# scan on Failed to start discovery: org.bluez.Error.NotReady [bluetooth]# scan on Failed to start discovery: org.bluez.Error.NotReady Failed to set power on: org.bluez.Error.Failed [DEL] Controller 00:E0:3C:87:B8:03 naga [default] [NEW] Controller 00:E0:3C:87:B8:03 naga [default] [CHG] Controller 00:E0:3C:87:B8:03 UUIDs: 0000110e-0000-1000-8000-00805f9b34fb [CHG] Controller 00:E0:3C:87:B8:03 UUIDs: 0000111f-0000-1000-8000-00805f9b34fb [CHG] Controller 00:E0:3C:87:B8:03 UUIDs: 00001200-0000-1000-8000-00805f9b34fb [CHG] Controller 00:E0:3C:87:B8:03 UUIDs: 00001112-0000-1000-8000-00805f9b34fb [CHG] Controller 00:E0:3C:87:B8:03 UUIDs: 00001108-0000-1000-8000-00805f9b34fb [CHG] Controller 00:E0:3C:87:B8:03 UUIDs: 0000110c-0000-1000-8000-00805f9b34fb [CHG] Controller 00:E0:3C:87:B8:03 UUIDs: 00001800-0000-1000-8000-00805f9b34fb [CHG] Controller 00:E0:3C:87:B8:03 UUIDs: 0000110a-0000-1000-8000-00805f9b34fb [CHG] Controller 00:E0:3C:87:B8:03 UUIDs: 00001801-0000-1000-8000-00805f9b34fb [CHG] Controller 00:E0:3C:87:B8:03 UUIDs: 0000110b-0000-1000-8000-00805f9b34fb [CHG] Controller 00:E0:3C:87:B8:03 UUIDs: 0000180a-0000-1000-8000-00805f9b34fb [bluetooth]# power on [CHG] Controller 00:E0:3C:87:B8:03 Class: 0x006c010c Changing power on succeeded [CHG] Controller 00:E0:3C:87:B8:03 Powered: yes [bluetooth]# scan on Discovery started I think that it's quite clear you wanted your adapter powered on if you tried to scan for devices. The Linux kernel got automatic power management ages ago. Can't that apply to bluetooth as well? -- You are receiving this mail because: You are the assignee for the bug.

1 1

[kernel-bugs] [Bug 1174622] New: System not reconnecting to WLAN after suspend/resume
by bugzilla_noreply＠suse.com 22 Jul '22

22 Jul '22

https://bugzilla.suse.com/show_bug.cgi?id=1174622 Bug ID: 1174622 Summary: System not reconnecting to WLAN after suspend/resume Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: x86-64 OS: SUSE Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: holgi(a)suse.com QA Contact: qa-bugs(a)suse.de CC: tiwai(a)suse.com Found By: Development Blocker: --- Created attachment 840122 --> https://bugzilla.suse.com/attachment.cgi?id=840122&action=edit Output of hwinfo --netcard System with NetworkManger is connected to a wifi network. After suspend and resume later, it is not able to reconnect to the same wifi network. After a reboot, system is connecting to the same wifi network without any problems. -- You are receiving this mail because: You are the assignee for the bug.

1 27

[kernel-bugs] [Bug 1174868] New: Upgrade to LEAP 15.2 makes Thinkpad 480s sometimes completely freezes, 20°C warmer and journal is trimmed
by bugzilla_noreply＠suse.com 20 Jul '22

20 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1174868 Bug ID: 1174868 Summary: Upgrade to LEAP 15.2 makes Thinkpad 480s sometimes completely freezes, 20°C warmer and journal is trimmed Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: markus.zimmermann(a)symflower.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- One of our machines here a Thinkpad T480s on openSUSE 15.2 kernel 5.3.18-lp152.33-default. In general this machine was upgraded from LEAP 15.1 to 15.2 and then the problems started to show. The CPU is constantly hotter while working. by 20°C. This machine now freezes sometimes completely. The machine is then - not pingable - no keyboard interaction works - lid close/open does nothng - no mouse interaction works - the notebook is really warm - When a freeze happens also a trim of the journal happens... e.g. we loose the whole journal for the day. - We SSH'ed into the machine and watched via "htop", "journal -f" and "sensors". WHen the machine freezes, there is no significant load via htop seeable, there are no interesting logs in journal and sensors shows that it is simply hotter. Interestingly, we upgraded another machine before (also a Thinkpad T480s) and this does not have any problems. We are btw on the latest firmwares using fwupdmgr. What should we try? How can we debug it? -- You are receiving this mail because: You are the assignee for the bug.

1 20

2022

2021

2020

openSUSE Kernel Bugs September 2021