December 2020 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[kernel-bugs] [Bug 1173776] New: media: add support for eyeTV Geniatech T2 lite
by bugzilla_noreply＠suse.com 05 Feb '21

05 Feb '21

https://bugzilla.suse.com/show_bug.cgi?id=1173776 Bug ID: 1173776 Summary: media: add support for eyeTV Geniatech T2 lite Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other OS: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: thomas(a)abiwatch.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Would you consider to pick following patch into your kernel for Leap 15.2? commit 14494583336880640654300c76d0f5df3360d85f media: dvbsky: add support for eyeTV Geniatech T2 lite It went in to v5.5 and later it got automatically added to stable v5.4.y. It should apply cleanly and just work. -- You are receiving this mail because: You are the assignee for the bug.

1 9

[Bug 1180336] New: [RPi4] No USB in rpi4b and rpi400 since v5.10
by bugzilla_noreply＠suse.com 04 Feb '21

04 Feb '21

https://bugzilla.suse.com/show_bug.cgi?id=1180336 Bug ID: 1180336 Summary: [RPi4] No USB in rpi4b and rpi400 since v5.10 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: nsaenzjulienne(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- RPi4's firmware doesn't support receiving two USB reset signals in a row, even though it's supposed to do so (funnily enough 3 resets in a row work fine). This leaves the xHC in a broken state for TW as both u-boot and Linux perform this operation. I'm in contact with the RPi engineers and a firmware fix should show up eventually. That said we're in the middle of the holiday season, so we'll have to be patient. We could advise TW users to kexec into the same Linux image to trigger a third USB reset, which will fix the issue, but that seems overkill. Otherwise, I prepared a small kernel fix to bypass the reset signal if USB is already up. This fix will never make it upstream, as it's somewhat hacky. But I figure it'll be nice to port it to TW while we wait for the RPi foundation to publish a new firmware. -- You are receiving this mail because: You are the assignee for the bug.

1 7

[Bug 1180344] New: Kernel 5.10.1 fails to boot with workqueue lockup
by bugzilla_noreply＠suse.com 21 Jan '21

21 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1180344 Bug ID: 1180344 Summary: Kernel 5.10.1 fails to boot with workqueue lockup Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Critical Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: adam(a)valkor.net QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 844693 --> https://bugzilla.suse.com/attachment.cgi?id=844693&action=edit journal from failed boot Linux 5.10.1 on my Thinkpad X1 Carbon Gen 7 fails to boot with workqueue lockup messages and a failure to mount /home. I've given it 10 minutes, but it will not complete booting. Previous kernels, including the fallback 5.9.14 do not exhibit this behavior. Dec 24 18:00:05 think kernel: BUG: workqueue lockup - pool cpus=5 node=0 flags=0x0 nice=0 stuck for 50s! Dec 24 18:00:05 think kernel: Showing busy workqueues and worker pools: Dec 24 18:00:05 think kernel: workqueue events: flags=0x0 Dec 24 18:00:05 think kernel: pwq 10: cpus=5 node=0 flags=0x0 nice=0 active=11/256 refcnt=12 Dec 24 18:00:05 think kernel: in-flight: 840:request_firmware_work_func Dec 24 18:00:05 think kernel: pending: delayed_fput, drm_fb_helper_dirty_work [drm_kms_helper], free_work, kfree_rcu_monitor, kernfs_notify_workfn, rfkill_global_led_trigger_worker [rfkill], smp_call_on_c> Dec 24 18:00:05 think kernel: pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 refcnt=2 Dec 24 18:00:05 Previous kernels, including the fallback 5.9.14 do not exhibit this behavior. think kernel: pending: vmstat_shepherd Dec 24 18:00:05 think kernel: workqueue events_long: flags=0x0 Dec 24 18:00:05 think kernel: pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 refcnt=2 Dec 24 18:00:05 think kernel: in-flight: 143:ucsi_init_work [typec_ucsi] Dec 24 18:00:05 think kernel: workqueue events_unbound: flags=0x2 Dec 24 18:00:05 think kernel: pwq 16: cpus=0-7 flags=0x4 nice=0 active=4/512 refcnt=6 Dec 24 18:00:05 think kernel: in-flight: 58:fsnotify_connector_destroy_workfn fsnotify_connector_destroy_workfn, 63:fsnotify_mark_destroy_workfn fsnotify_mark_destroy_workfn Dec 24 18:00:05 think kernel: workqueue rcu_gp: flags=0x8 Dec 24 18:00:05 think kernel: pwq 10: cpus=5 node=0 flags=0x0 nice=0 active=1/256 refcnt=2 Dec 24 18:00:05 think kernel: pending: process_srcu Dec 24 18:00:05 think kernel: workqueue mm_percpu_wq: flags=0x8 Dec 24 18:00:05 think kernel: pwq 10: cpus=5 node=0 flags=0x0 nice=0 active=2/256 refcnt=4 Dec 24 18:00:05 think kernel: pending: vmstat_update, lru_add_drain_per_cpu BAR(907) Dec 24 18:00:05 think kernel: workqueue kec_query: flags=0x0 Dec 24 18:00:05 think kernel: pwq 10: cpus=5 node=0 flags=0x0 nice=0 active=1/16 refcnt=2 Dec 24 18:00:05 think kernel: pending: acpi_ec_event_processor Dec 24 18:00:05 think kernel: workqueue usb_hub_wq: flags=0x4 Dec 24 18:00:05 think kernel: pwq 10: cpus=5 node=0 flags=0x0 nice=0 active=1/256 refcnt=2 Dec 24 18:00:05 think kernel: pending: hub_event [usbcore] Dec 24 18:00:05 think kernel: pool 0: cpus=0 node=0 flags=0x0 nice=0 hung=0s workers=4 idle: 5 770 7 Dec 24 18:00:05 think kernel: pool 10: cpus=5 node=0 flags=0x0 nice=0 hung=50s workers=4 idle: 764 43 133 Dec 24 18:00:05 think kernel: pool 16: cpus=0-7 flags=0x4 nice=0 hung=0s workers=8 idle: 8 60 59 62 61 64 �� rpm -qa | grep kernel-default kernel-default-5.10.1-1.1.x86_64 kernel-default-5.9.14-1.2.x86_64 -- You are receiving this mail because: You are the assignee for the bug.

1 41

[Bug 1180404] New: high idle power consumption of amd gpu 5700xt with kernel 5.10.1
by bugzilla_noreply＠suse.com 19 Jan '21

19 Jan '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1180404 Bug ID: 1180404 Summary: high idle power consumption of amd gpu 5700xt with kernel 5.10.1 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: PC OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: benoit.monin(a)gmx.fr QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- On opensuse tumbleweed with kernel 5.10.1, the idle power consumption of my AMD graphic card (5700xt navi 10) increased from 8W to 29W over previous kernel versions. This is annoying as the graphic card periodically starts and stops the fan to deal with the increased temperature while simply displaying the desktop. I only have one monitor attached (1920x1200@60Hz) but the VRAM clock is now set to 850MHz all the time, while it was as 100MHz with earlier kernels. Is there any way to revert to the old behaviour? With 5.10.1-1-default: cat /sys/kernel/debug/dri/0/amdgpu_pm_info GFX Clocks and Power: 875 MHz (MCLK) 800 MHz (SCLK) 1300 MHz (PSTATE_SCLK) 625 MHz (PSTATE_MCLK) 725 mV (VDDGFX) 29.0 W (average GPU) GPU Temperature: 52 C GPU Load: 0 % MEM Load: 0 % SMC Feature Mask: 0x00000623a3ddaffb VCN: Disabled Clock Gating Flags Mask: 0x38099f05 Graphics Medium Grain Clock Gating: On Graphics Medium Grain memory Light Sleep: Off Graphics Coarse Grain Clock Gating: On Graphics Coarse Grain memory Light Sleep: Off Graphics Coarse Grain Tree Shader Clock Gating: Off Graphics Coarse Grain Tree Shader Light Sleep: Off Graphics Command Processor Light Sleep: Off Graphics Run List Controller Light Sleep: Off Graphics 3D Coarse Grain Clock Gating: Off Graphics 3D Coarse Grain memory Light Sleep: Off Memory Controller Light Sleep: On Memory Controller Medium Grain Clock Gating: On System Direct Memory Access Light Sleep: On System Direct Memory Access Medium Grain Clock Gating: On Bus Interface Medium Grain Clock Gating: On Bus Interface Light Sleep: On Unified Video Decoder Medium Grain Clock Gating: Off Video Compression Engine Medium Grain Clock Gating: Off Host Data Path Light Sleep: On Host Data Path Medium Grain Clock Gating: On Digital Right Management Medium Grain Clock Gating: Off Digital Right Management Light Sleep: Off Rom Medium Grain Clock Gating: Off Data Fabric Medium Grain Clock Gating: Off Address Translation Hub Medium Grain Clock Gating: On Address Translation Hub Light Sleep: On With 5.9.14-1-default: cat /sys/kernel/debug/dri/0/amdgpu_pm_info Clock Gating Flags Mask: 0x38099f05 Graphics Medium Grain Clock Gating: On Graphics Medium Grain memory Light Sleep: Off Graphics Coarse Grain Clock Gating: On Graphics Coarse Grain memory Light Sleep: Off Graphics Coarse Grain Tree Shader Clock Gating: Off Graphics Coarse Grain Tree Shader Light Sleep: Off Graphics Command Processor Light Sleep: Off Graphics Run List Controller Light Sleep: Off Graphics 3D Coarse Grain Clock Gating: Off Graphics 3D Coarse Grain memory Light Sleep: Off Memory Controller Light Sleep: On Memory Controller Medium Grain Clock Gating: On System Direct Memory Access Light Sleep: On System Direct Memory Access Medium Grain Clock Gating: On Bus Interface Medium Grain Clock Gating: On Bus Interface Light Sleep: On Unified Video Decoder Medium Grain Clock Gating: Off Video Compression Engine Medium Grain Clock Gating: Off Host Data Path Light Sleep: On Host Data Path Medium Grain Clock Gating: On Digital Right Management Medium Grain Clock Gating: Off Digital Right Management Light Sleep: Off Rom Medium Grain Clock Gating: Off Data Fabric Medium Grain Clock Gating: Off Address Translation Hub Medium Grain Clock Gating: On Address Translation Hub Light Sleep: On GFX Clocks and Power: 100 MHz (MCLK) 800 MHz (SCLK) 1300 MHz (PSTATE_SCLK) 625 MHz (PSTATE_MCLK) 750 mV (VDDGFX) 8.0 W (average GPU) GPU Temperature: 35 C GPU Load: 0 % MEM Load: 0 % SMC Feature Mask: 0x00000623a3ddaffb VCN: Disabled -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1180442] New: amdgpu not detected on boot with eDP connector
by bugzilla_noreply＠suse.com 12 Jan '21

12 Jan '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1180442 Bug ID: 1180442 Summary: amdgpu not detected on boot with eDP connector 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: jshand2013(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 844743 --> http://bugzilla.opensuse.org/attachment.cgi?id=844743&action=edit Hardware Profile Hi there, just tried kernel version 5.10.3 and unfortunately I still need to specify nomodeset in the grub command line, not graphics driver listed. must be llvmpipe instead. -- You are receiving this mail because: You are the assignee for the bug.

1 24

[Bug 1180216] New: LX2160A Networking not supported
by bugzilla_noreply＠suse.com 07 Jan '21

07 Jan '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1180216 Bug ID: 1180216 Summary: LX2160A Networking not supported Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: aarch64 OS: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: josua.m(a)t-online.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- With either DeviceTree and ACPI hardware description, both on-SoC 1gbps ethernet and 10gbps sfp+ are not currently supported on the Honeycomb Workstation with Leap 15.2. This is mostly because the upstreaming of required support into Linux is still ongoing and taking much time. I'd like to evaluate if it will be possible to either backport some recent enablements into 15.2, or work towards the next release of Leap. The current state is this pile of patches on top of v5.10.1: https://github.com/SolidRun/linux-stable/commits/linux-5.10.y-cex7 Clearly it might be a lot to back-port, especially considering the pile will only grow going back to 5.3 .... Any suggestions if or how to proceed here? Is SUSE tracking this already internally? -- You are receiving this mail because: You are the assignee for the bug.

1 1

[kernel-bugs] [Bug 1179367] New: Driver brcmfmac for Broadcom 43430 or firmware does not use channel 12 and 13 on WiFi 2.4GHz
by bugzilla_noreply＠suse.com 05 Jan '21

05 Jan '21

https://bugzilla.suse.com/show_bug.cgi?id=1179367 Bug ID: 1179367 Summary: Driver brcmfmac for Broadcom 43430 or firmware does not use channel 12 and 13 on WiFi 2.4GHz Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: aarch64 OS: openSUSE Leap 15.2 Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: werner(a)suse.com QA Contact: qa-bugs(a)suse.de CC: cfamullaconrad(a)suse.com, dleuenberger(a)suse.com, karol(a)babioch.de, mpluskal(a)suse.com Depends on: 1179308 Found By: --- Blocker: --- Meanwhile I've installed the missing package wireless-regdb and build and installed the package crda, also I'm abel to set the country code to DE and allow to use the channels 12 and 13 in the 2.4GHz area. This is reported by ``iwlist``: smartmeter:~ # iwlist wlan0 channel wlan0 13 channels in total; available frequencies : Channel 01 : 2.412 GHz Channel 02 : 2.417 GHz Channel 03 : 2.422 GHz Channel 04 : 2.427 GHz Channel 05 : 2.432 GHz Channel 06 : 2.437 GHz Channel 07 : 2.442 GHz Channel 08 : 2.447 GHz Channel 09 : 2.452 GHz Channel 10 : 2.457 GHz Channel 11 : 2.462 GHz Channel 12 : 2.467 GHz Channel 13 : 2.472 GHz Nevertheless the brcmfmac driver does not see my router on channel 13, nor channel 12 of any of my neighbours, the highest channel reported by e.g. the command ``nmcli dev wifi list`` I open this bug because there are reports that in principle the hardware Broadcom 43430 does support channels above channel 11 as seen here https://github.com/raspberrypi/linux/issues/1355 +++ This bug was initially created as a clone of Bug #1179308 +++ this fact leads even after adding the line options cfg80211 ieee80211_regdom=DE in /etc/modprobe.d/99-local.conf and reloading both cfg80211 and brcmfmac kernel modules ... in the kernel logs I see: [ 9360.888829] usbcore: deregistering interface driver brcmfmac [ 9378.151397] cfg80211: Loading compiled-in X.509 certificates for regulatory database [ 9378.152331] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' [ 9378.152533] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 [ 9378.152545] cfg80211: failed to load regulatory.db [ 9382.598023] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1 [ 9382.598335] usbcore: registered new interface driver brcmfmac [ 9382.725940] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1 [ 9382.726020] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available [ 9382.726514] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/1 wl0: Oct 23 2017 03:55:53 version 7.45.98.38 (r674442 CY) FWID 01-e58d219f in other words theregulatory.bin is missed, compare with https://forum-raspberrypi.de/forum/thread/34332-rpi3-trotz-kernel-4-4-50-ke… -- You are receiving this mail because: You are the assignee for the bug.

1 4

[Bug 1180481] New: Linux 5.10.1 with encrypted /home partition stuck at boot
by bugzilla_noreply＠suse.com 03 Jan '21

03 Jan '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1180481 Bug ID: 1180481 Summary: Linux 5.10.1 with encrypted /home partition stuck at boot 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: andreas_nordal_4(a)hotmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The latest Tumbleweed kernel (Linux 5.10.1) hangs during boot. When I press Esc, I see repeated messages about "BUG: ", "runqueue", "cr-auto-1" (which is the block device that houses my /home) and being stuck. Booting into the previous kernel (Linux 5.9.14) works fine. -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 1180484] New: AMDGPU: *ERROR* IB test failed on gfx (-110)
by bugzilla_noreply＠suse.com 31 Dec '20

31 Dec '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1180484 Bug ID: 1180484 Summary: AMDGPU: *ERROR* IB test failed on gfx (-110) 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: dxxf(a)volny.cz QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 844764 --> http://bugzilla.opensuse.org/attachment.cgi?id=844764&action=edit Filtered log of failed bool With kernel update to 5.10.1 I started to encounter random black screen and (probably) hangs at boot. It seems the culprit is AMDGPU kernel module: kernel: [drm] Initialized amdgpu 3.40.0 20150101 for 0000:0f:00.0 on minor 1 kernel: amdgpu 0000:0c:00.0: [drm:amdgpu_ib_ring_tests [amdgpu]] *ERROR* IB test failed on gfx (-110). kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring page0 timeout, signaled seq=4, emitted seq=5 kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process pid 0 thread pid 0 kernel: amdgpu 0000:0c:00.0: amdgpu: GPU reset begin! kernel: amdgpu: [powerplay] No response from smu kernel: amdgpu: [powerplay] Failed message: 0xe, input parameter: 0x0, error code: 0x0 form here I get bunch of "powerplay" errors like: kernel: amdgpu: [powerplay] No response from smu kernel: amdgpu: [powerplay] No response from smu kernel: amdgpu: [powerplay] Failed message: 0x42, input parameter: 0x1, error code: 0x0 The machine has two AMD GPUs in it: RX Vega 64 (primary with monitors connected to it) and Radeon VII. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1179538] FAIL: gdb.arch/amd64-init-x87-values.exp: check_setting_mxcsr_before_enable: check new value of MXCSR is still in place
by bugzilla_noreply＠suse.com 31 Dec '20

31 Dec '20

https://bugzilla.suse.com/show_bug.cgi?id=1179538 https://bugzilla.suse.com/show_bug.cgi?id=1179538#c5 --- Comment #5 from Borislav Petkov <bpetkov(a)suse.com> --- Ok, 15-SP2 host, leap 15.2 guest: $ ./run-gdb.sh Temporary breakpoint 1 at 0x401001: file amd64-init-x87-values.S, line 27. Temporary breakpoint 1, main () at amd64-init-x87-values.S:27 27 nop $1 = 0x9f80 $2 = 0x9f80 28 fwait $3 = 0x9f80 guest kernel is leap152 5.3.18-lp152.57-default, host kernel is 5.3.18-24.43-default and qemu is QEMU emulator version 4.2.0 (SUSE Linux Enterprise 15). I guess I need to try kernel-obs-build-5.9.11-1.1 now. -- You are receiving this mail because: You are the assignee for the bug.

1 0

2023

2022

2021

2020

openSUSE Kernel Bugs December 2020