December 2020 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[Bug 1180442] New: amdgpu not detected on boot with eDP connector

by bugzilla_noreply＠suse.com

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 year, 4 months

1
24
0 0

[Bug 1180216] New: LX2160A Networking not supported

by bugzilla_noreply＠suse.com

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 year, 4 months

1
1
0 0

[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

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 year, 4 months

1
4
0 0

[Bug 1180481] New: Linux 5.10.1 with encrypted /home partition stuck at boot

by bugzilla_noreply＠suse.com

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 year, 4 months

1
3
0 0

[Bug 1180484] New: AMDGPU: *ERROR* IB test failed on gfx (-110)

by bugzilla_noreply＠suse.com

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 year, 4 months

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

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 year, 4 months

1
0
0 0

[Bug 1178790] [Build 20201112][s390x] openQA test fails in bootloader_s390 - dasd_configure: Error: Could not write file /sys/bus/ccw/drivers/dasd-eckd/0.0.0150/online: Resource temporarily unavailable (NO VALID SENSE AVAILABLE)

by bugzilla_noreply＠suse.com

https://bugzilla.suse.com/show_bug.cgi?id=1178790 https://bugzilla.suse.com/show_bug.cgi?id=1178790#c17 --- Comment #17 from Ihno Krumreich <ihno(a)suse.com> --- After fixing Bug1180381 the problem has not shown up. -- You are receiving this mail because: You are the assignee for the bug.

1 year, 4 months

1
0
0 0

[Bug 1178790] [Build 20201112][s390x] openQA test fails in bootloader_s390 - dasd_configure: Error: Could not write file /sys/bus/ccw/drivers/dasd-eckd/0.0.0150/online: Resource temporarily unavailable (NO VALID SENSE AVAILABLE)

by bugzilla_noreply＠suse.com

https://bugzilla.suse.com/show_bug.cgi?id=1178790 Ihno Krumreich <ihno(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P2 - High -- You are receiving this mail because: You are the assignee for the bug.

1 year, 4 months

1
0
0 0

[Bug 1180381] [Build 20201225] [s390x] Kernel Panic - No TPM chip found, activating TPM-bypass

by bugzilla_noreply＠suse.com

https://bugzilla.suse.com/show_bug.cgi?id=1180381 https://bugzilla.suse.com/show_bug.cgi?id=1180381#c13 Sarah Julia Kriesch <sarah.kriesch(a)ibm.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Flags|needinfo?(slindomansilla@su | |se.com) | --- Comment #13 from Sarah Julia Kriesch <sarah.kriesch(a)ibm.com> --- The system configuration has fixed the Kernel Panic. -- You are receiving this mail because: You are the assignee for the bug.

1 year, 4 months

1
0
0 0

[Bug 1180476] New: Can't boot past initial ramdisk unless I first successfully start via a btrfs snapshot using kernel 5.8.4

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1180476 Bug ID: 1180476 Summary: Can't boot past initial ramdisk unless I first successfully start via a btrfs snapshot using kernel 5.8.4 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: noahadvs(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- This is a very odd bug that is difficult to explain. Whenever I restart, there is a chance that my laptop (ASUS K501UW) will fail to boot past initial ramdisk. The way to get around this is very complex and when it works is kind of random, which might mean that the methods I use to work around it only happen to cause some of the things that allow the laptop to boot successfully again. Any one or any number of these steps, roughly in the order that I wrote them, appears to sometimes cause the laptop to boot successfully, but only sometimes: - Boot from a snapshot from 2020-11-27 (my 2nd oldest snapshot) using kernel 5.8.4 - Boot from the next snapshot with 5.8.4, then the next one and so on. - Boot from the latest snapshot in read-only mode using 5.8.4 - Boot from the latest snapshot (not read-only, normal mode) using 5.8.4 - Boot from the latest snapshot with the latest kernel (not read-only, recovery mode) Eventually, booting normally with the latest kernel will work. Unfortunately, I can't say how to reproduce this bug because I have no idea how or why it happens. Additional info: I have kernel 5.8.4 locked so that I don't lose it. It began happening a few months ago, probably after upgrading from kernel 5.8.4 to a new version, but I kept putting off writing a bug report because I was able to work around it and I was busy. I usually only reboot after doing a distro-upgrade and otherwise prefer to put the laptop into sleep mode when I'm done using it for the day. Sometimes I wait a whole week with 2 or more distro upgrades before rebooting. -- You are receiving this mail because: You are the assignee for the bug.

1 year, 4 months

1
0
0 0

2022

2021

2020

openSUSE Kernel Bugs December 2020