December 2020 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[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

[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 31 Dec '20

31 Dec '20

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 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 31 Dec '20

31 Dec '20

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 0

[Bug 1180381] [Build 20201225] [s390x] Kernel Panic - No TPM chip found, activating TPM-bypass
by bugzilla_noreply＠suse.com 31 Dec '20

31 Dec '20

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 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 31 Dec '20

31 Dec '20

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 0

[Bug 1180381] [Build 20201225] [s390x] Kernel Panic - No TPM chip found, activating TPM-bypass
by bugzilla_noreply＠suse.com 31 Dec '20

31 Dec '20

https://bugzilla.suse.com/show_bug.cgi?id=1180381 https://bugzilla.suse.com/show_bug.cgi?id=1180381#c12 --- Comment #12 from Sarah Julia Kriesch <sarah.kriesch(a)ibm.com> --- I have restarted the tests and it seems there are no problems in the bootloader section any more: https://openqa.opensuse.org/tests/1536533#details Thank you, Ihno! -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1180381] [Build 20201225] [s390x] Kernel Panic - No TPM chip found, activating TPM-bypass
by bugzilla_noreply＠suse.com 30 Dec '20

30 Dec '20

https://bugzilla.suse.com/show_bug.cgi?id=1180381 https://bugzilla.suse.com/show_bug.cgi?id=1180381#c11 --- Comment #11 from Ihno Krumreich <ihno(a)suse.com> --- Additional change in qaboot: The FTP-client can store downloaded file in the fixed record format {"locsite fix 80" command). I added that command to the download sequence and commented out the two command for doing this after the download. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1180381] [Build 20201225] [s390x] Kernel Panic - No TPM chip found, activating TPM-bypass
by bugzilla_noreply＠suse.com 30 Dec '20

30 Dec '20

https://bugzilla.suse.com/show_bug.cgi?id=1180381 https://bugzilla.suse.com/show_bug.cgi?id=1180381#c10 --- Comment #10 from Ihno Krumreich <ihno(a)suse.com> --- I did a manual test with qaboot 192.168.112.100 Tumbleweed-oss-s390x-Snapshot20201229 The system booted and then stopped in the linuxrc for futher action. Doing the math for the temp disk showed that (include a temp file of the initrd size) the disk needs to have a size of 202784 blocks. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1180381] [Build 20201225] [s390x] Kernel Panic - No TPM chip found, activating TPM-bypass
by bugzilla_noreply＠suse.com 30 Dec '20

30 Dec '20

https://bugzilla.suse.com/show_bug.cgi?id=1180381 https://bugzilla.suse.com/show_bug.cgi?id=1180381#c9 --- Comment #9 from Ihno Krumreich <ihno(a)suse.com> --- The content of the disk is the following: LINUX146 FILELIST A0 V 169 Trunc=169 Size=5 Line=1 Col=1 Alt=18 Cmd Filename Filetype Fm Format Lrecl Records Blocks Date Time * FTPBOOT PARM K1 V 70 6 1 2020-12-30 06:48:39 FTPBOOT INITRD K1 V 8192 5673 11348 2020-12-30 06:48:34 FTPBOOT KERN K1 V 80 104353 2090 2020-12-30 06:48:34 * 00EB5CA8 CMSUT1 K1 V 80 573040 11472 2020-12-30 06:48:34 SUSE INS K1 V 57 6 1 2020-12-30 06:48:29 Doing the math shows that the disk is full. The unusual file is 00EB5CA8 CMSUT1. According to Google this is a temporary file created by CMS commands. In qaboot he suspect is "pipe < ftpboot initrd t | fblock 80 00 | > ftpboot initrd t" This converts the fresh downloaded file into a 80-Byte fixed block file. I did the following change to qaboot: - Increased the size of the VDSK disk from 200000 to 300000 Blocks - exchanged the sequence of the download of initrd and kernel (not shure whether this has a real effect) can someone please restart the test? -- You are receiving this mail because: You are the assignee for the bug.

1 0