August 2022 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[Bug 1193599] New: ntel_dp_detect [i915]] *ERROR* LSPCON init failed on port D
by bugzilla_noreply＠suse.com 07 Dec '22

07 Dec '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1193599 Bug ID: 1193599 Summary: ntel_dp_detect [i915]] *ERROR* LSPCON init failed on port D Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: x86-64 OS: openSUSE Leap 15.4 Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: opendreas(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The following errors appear at boot broken atomic modeset userspace detected, disabling atomic [drm spcon_init [i915]] *ERROR* Failed to probe lspcon [drm ntel_dp_detect [i915]] *ERROR* LSPCON init failed on port D [drm spcon_init [i915]] *ERROR* Failed to probe lspcon [drm ntel_dp_detect [i915]] *ERROR* LSPCON init failed on port D [drm spcon_init [i915]] *ERROR* Failed to probe lspcon [drm ntel_dp_detect [i915]] *ERROR* LSPCON init failed on port D [drm spcon_init [i915]] *ERROR* Failed to probe lspcon [drm ntel_dp_detect [i915]] *ERROR* LSPCON init failed on port D Full log https://paste.opensuse.org/83436185 Hardware Dell Precision 7530 CPU: Intel Xeon E-2186M GPU: Intel P630 / Nvidia Quadro P3200 -- You are receiving this mail because: You are the assignee for the bug.

1 33

[Bug 1191933] New: Kernel can not update on Secure boot envirnment
by bugzilla_noreply＠suse.com 05 Dec '22

05 Dec '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1191933 Bug ID: 1191933 Summary: Kernel can not update on Secure boot envirnment 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: kokeko(a)mac.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Current 20211012, update to 20211016 or 20211019. Kernel-default update failed by fallowing error. subprocess error, secure boot enabled. Is it something change? -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1200781] New: xhci stop working. Works briefly after reboot, or remove and load xhci_pci & xhci_hcd.
by bugzilla_noreply＠suse.com 30 Nov '22

30 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1200781 Bug ID: 1200781 Summary: xhci stop working. Works briefly after reboot, or remove and load xhci_pci & xhci_hcd. Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: x86-64 OS: openSUSE Leap 15.4 Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: publio.escipion.el.africano(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- openSuSE Leap 15.4 x86_64, kernel 4.14.21-150400.22-default, in a Lenovo IdeaPad 3 15ADA05: https://psref.lenovo.com/syspool/Sys/PDF/IdeaPad/IdeaPad_3_15ADA05/IdeaPad_… An external mouse stops working after a brief period of time, after login into KDE, or after removing and loading xhci_pci & xhci_hcd. System complaints of: �xhci_hcd 0000:02:00.3 WARNIGN: Host System Error� and: �usb 2-3: device not accepting address 2, error -108� I've tried two bluetooth mice, and a standard cord mouse. The same result. It seems that it's the USB controllers are the only components affected, so far. Mousepad works properly, but I'm not use to it. I have to constantly remove and load xhci_pci & xhci_hcd, as root. rmmod xhci_pci rmmod xhci_hcd modprobe xhci_pci modprobe xhci_hcd Mouse works after that for a short time. Nota bene: Devices work properly under openSuSE Leap 15.2 x86_64, kernel 5.3.18-lp152.106-default (old HP Pavillion). This bug resembles https://bugzilla.opensuse.org/show_bug.cgi?id=1193652 -- You are receiving this mail because: You are the assignee for the bug.

1 17

[Bug 1202138] New: PowerPC machine crashes frequently after upgrading to Leap 15.4
by bugzilla_noreply＠suse.com 21 Nov '22

21 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1202138 Bug ID: 1202138 Summary: PowerPC machine crashes frequently after upgrading to Leap 15.4 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: PowerPC-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: marius.kittler(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- After upgrading a PowerPC machine (the openQA worker qa-power8-4-kvm.qa.suse.de) from Leap 15.3 to Leap 15.4 that machine crashes frequently. It usually does not stay on for more than a few hours. Downgrading the machine (by rolling back to the last BTRFS snapshot with Leap 15.3) allows the machine to run stable again. Note that there's actually a second machine (the openQA worker qa-power8-5-kvm.qa.suse.de) that we managed to operate without crashes on Leap 15.4. Both machines seems very similar to me so I'm not sure whether one is crashing and the other one not. Note that in the first place both machines did not boot on Leap 15.4. It seemed to be stuck at some point and the kernel logged messages like ``` [ 197.877239][ C62] watchdog: BUG: soft lockup - CPU#62 stuck for 25s! [swapper/62:0]` quite frequently ``` quite frequently. So I added the kernel parameter `nmi_watchdog=0`. With this parameter both machines could boot on Leap 15.4 (but as mentioned only qa-power8-5 runs stable without crashing). So the kernel command line used is: ``` root=UUID=89ca2dff-86af-478b-8d4c-2a45ca689fd5 nospec kvm.nested=1 kvm_intel.nested=1 kvm_amd.nested=1 kvm-arm.nested=1 crashkernel=210M nmi_watchdog=0 ``` Not sure what other details could be relevant. Unfortunately the journal does not have any interesting message right before the crash. Via SOL I could once see a kernel panic being logged: ``` QA-Power8-4-kvm login: [ 365.807470][ T3923] EXT4-fs error (device sdb1) in ext4_free_inode:362: Corrupt filesystem [ 438.050890][ T94] Kernel panic - not syncing: corrupted stack end detected inside scheduler [ 438.051046][ T94] CPU: 16 PID: 94 Comm: ksof ``` (The filesystem error is likely just a symptom of the crashes.) Any advice what I could try? Maybe another kernel parameter? Maybe booting Leap 15.4 but with the kernel version from 15.3 (not sure how I'd do that, though - so any advice would be welcome if that idea sounds helpful)? By the way, that's `/proc/cpuinfo` on the problematic machine: ``` root=UUID=eebe647f-e867-416e-a0fa-7a6732bfcf9d nospec kvm.nested=1 kvm_intel.nested=1 kvm_amd.nested=1 kvm-arm.nested=1 crashkernel=210M martchus@QA-Power8-4-kvm:~> cat /proc/cpuinfo processor : 0 cpu : POWER8, altivec supported clock : 3857.000000MHz revision : 2.0 (pvr 004d 0200) [�� repeated 7 more times with processor 8, 16, 24, 32, 40, 48 and 56] timebase : 512000000 platform : PowerNV model : 8348-21C machine : PowerNV 8348-21C firmware : OPAL MMU : Hash ``` On the stable machine it looks very similar but it is actually a model with more processors: ``` processor : 0 cpu : POWER8 (raw), altivec supported clock : 3857.000000MHz revision : 2.0 (pvr 004d 0200) [�� repeated 13 more times with processor 8, 16, 24, ��] timebase : 512000000 platform : PowerNV model : 8335-GCA machine : PowerNV 8335-GCA firmware : OPAL MMU : Hash ``` That's the relevant ticket on the openQA infrastructure tracker (for additional context): https://progress.opensuse.org/issues/114565 -- You are receiving this mail because: You are the assignee for the bug.

1 32

[Bug 1193064] New: Touchpad doesn't work on Lenovo Yoga Slim7
by bugzilla_noreply＠suse.com 09 Nov '22

09 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1193064 Bug ID: 1193064 Summary: Touchpad doesn't work on Lenovo Yoga Slim7 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: 64bit OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: suse(a)rop.cx QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Touchpad doesn't work on Lenovo Yoga Slim7 That problem on Leap 15.3 and Tumbleweed (also in RHEL 9 beta) And some bugs on Fedora (it failed to start after sleep, but at all is working), so probably problem more on kernel side -- You are receiving this mail because: You are the assignee for the bug.

1 43

[Bug 1199661] New: amd-pstate CPU Performance Scaling Driver
by bugzilla_noreply＠suse.com 07 Nov '22

07 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1199661 Bug ID: 1199661 Summary: amd-pstate CPU Performance Scaling Driver Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Enhancement 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: --- Hello, is there an easy way to activate the new amd-pstate driver on Tumbleweed? I've tried: kernel-parameters: amd_pstate.replace=1 and amd_pstate.shared_mem=1 additionally I created a file named /etc/modules-load.d/amd-pstate.conf inside: # Load amd pstate at boot amd_pstate However it still defaults to: cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver acpi-cpufreq Anything I'm missing here? Thanks for your help -- You are receiving this mail because: You are the assignee for the bug.

1 9

[Bug 1201705] New: kernel-obs-build: include qemu_fw_cfg
by bugzilla_noreply＠suse.com 31 Oct '22

31 Oct '22

https://bugzilla.suse.com/show_bug.cgi?id=1201705 Bug ID: 1201705 Summary: kernel-obs-build: include qemu_fw_cfg 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: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- To be able to pass options into the build vm, the qemu_fg_cfg system can be used. So the module needs to be included. See https://github.com/openSUSE/obs-build/pull/765 -- You are receiving this mail because: You are the assignee for the bug.

1 12

[Bug 1202386] New: after upgrade, pc randomly freezes with kernel panic and segfault in power management
by bugzilla_noreply＠suse.com 28 Oct '22

28 Oct '22

https://bugzilla.suse.com/show_bug.cgi?id=1202386 Bug ID: 1202386 Summary: after upgrade, pc randomly freezes with kernel panic and segfault in power management Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: andrea.manzini(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 860780 --> https://bugzilla.suse.com/attachment.cgi?id=860780&action=edit extract from journalctl --system output after upgrade my laptop to OpenSuse TumbleWeed 20220813, with kernel 5.19.0-1-default , I experience random kernel panics (PC freezes with caps lock blinking) and in system logs I find some error message about power management (see attachment). Hardware name: LENOVO 20YRS2D84A/20YRS2D84A, BIOS N37ET39W (1.20 ) 04/15/2022 -- You are receiving this mail because: You are the assignee for the bug.

1 38

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