March 2021 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[Bug 1180316] New: [Build 20201222] openQA test fails in kdump_and_crash

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1180316 Bug ID: 1180316 Summary: [Build 20201222] openQA test fails in kdump_and_crash Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/1523048/modules/kdum p_and_crash/steps/58 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-JeOS-for-kvm-and-xen-x86_64-jeos-extra@64bit_virtio-2G fails in [kdump_and_crash](https://openqa.opensuse.org/tests/1523048/modules/kdump_an… After the update to kernel 5.10, kdump_and_crash fails crash: cannot determine length of symbol: log_end ## Test suite description Same as jeos, plus some more tests. ## Reproducible Fails since (at least) Build [20190311](https://openqa.opensuse.org/tests/877894) ## Expected result Last good: (unknown) (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.

3 months, 2 weeks

1
2
0 0

[Bug 1183990] New: I think I found the cause of a kernel lock when attempting hibernation

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1183990 Bug ID: 1183990 Summary: I think I found the cause of a kernel lock when attempting hibernation 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: carlos.e.r(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hi, For months I have been experiencing a kernel "trouble" in _some_ of my attempts to hibernate. Sometimes the hibernation would stall and not proceed. Issuing "systemctl hibernate" replied that there was one in progress, but there was no progress. I would attempt to halt the machine, but this would also stall at some point. If I pressed ctrl-alt-del several times, fast, I would see the message that it had detected the keys seven times and would halt immediately, but it did not. I had no way out but hit the power switch, and suffer the long fsck the next morning. Nothing in the logs whatsoever. Well, one day I noticed in "atop" that one of my disks went to 100% busy when this happened. So I left running another instance of gkrellm, displaying the i/o state of all my partitions in /dev/sdc, and experimenting with "sync" I noticed it was sdc9 which was active, at something like 400 Kbps. I noticed that "sync" would take sometimes a minute to complete. /dev/sdc9 is a reiserfs, and has several bind mounts: /dev/sdc9 on /data/Lareiserfs type reiserfs (rw,relatime,lazytime,user_xattr,acl) bind mounts: /dev/sdc9 on /data/homedvl type reiserfs (rw,relatime,lazytime,user_xattr,acl) /dev/sdc9 on /usr/share/flightgear type reiserfs (rw,relatime,lazytime,user_xattr,acl) /dev/sdc9 on /var/spool/news type reiserfs (rw,relatime,lazytime,user_xattr,acl) /dev/sdc9 on /home/cer/terrasync type reiserfs (rw,relatime,lazytime,user_xattr,acl) /dev/sdc9 on /usr/src type reiserfs (rw,relatime,lazytime,user_xattr,acl) Now, the directory that is active is "/var/spool/news". I use leafnode nntp proxy server. It contains 1.2 million files in about 3 GB of space. I found that if I run this sequence: time sync time sync && systemctl hibernate the machine hibernates successfully - 13 days so far, a record. Most days it takes a minute to sync, but one day, I noticed it took several minutes. Why? Well, it happened that at the same time "/usr/sbin/texpire" was working (a cronjob triggers it). This task runs for about half an hour daily expunging old posts, meaning it examines a million files. Maybe with this (tentative) report you can improve the kernel response so that it doesn't stall when trying to hibernate, assumedly when taking too long to sync. Me would think that the kernel should stop tasks before doing the sync :-? At least, running sync manually I can detect the situation and kill the busy task before suffering the crash. On the other hand, maybe there is an issue on reiserfs with "lazytime" (which is default), delaying the writes of "something" till forced to. My wild guess, it delays the timestamp that registers a file was touched. Each time I read a post, or Thunderbird scans a post, the timestamp (sorry, I don't remember which exact timestamp it is) is written, but it is not actually written but delayed "for ever". I use reiserfs for this mount because in theory it should work better than others with millions of small files. -- You are receiving this mail because: You are the assignee for the bug.

3 months, 3 weeks

1
11
0 0

[kernel-bugs] [Bug 1177624] New: watchdog: BUG: soft lockup - CPU#16 stuck for 23s! [qemu-system-aar:4554]

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1177624 Bug ID: 1177624 Summary: watchdog: BUG: soft lockup - CPU#16 stuck for 23s! [qemu-system-aar:4554] Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: aarch64 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: guillaume.gardet(a)arm.com QA Contact: qa-bugs(a)suse.de CC: afaerber(a)suse.com, dmueller(a)suse.com Found By: --- Blocker: --- Created attachment 842562 --> http://bugzilla.opensuse.org/attachment.cgi?id=842562&action=edit dmesg.log The D05 machine used as a worker for openqa.opensuse.org have been upgraded from Leap 15.1 to Leap 15.2 and shows lots of performance problems. Lots of mistyping in qemu, few screen corruptions. Checking the kernel log (in attachment), we can see some traces related to the watchdog. -- You are receiving this mail because: You are the assignee for the bug.

3 months, 3 weeks

1
5
0 0

[Bug 1182304] New: Integrated USB3 port / hub only works with AC adapter connected

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1182304 Bug ID: 1182304 Summary: Integrated USB3 port / hub only works with AC adapter connected 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: rs.opensuse(a)spitzenpfeil.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Kernel: 5.10.12-1-default Yet again I'm having issues with my laptops integrated USB3 port / hub. One of the USB-3 + USB-C ports only works with the AC adapter plugged in. Pulling the plug with devices connected leads to stuckage. Same hardware as in: https://bugzilla.opensuse.org/show_bug.cgi?id=1167146 -- You are receiving this mail because: You are the assignee for the bug.

4 months

1
8
0 0

[Bug 1180742] New: [amdgpu]An AMD Vega series GPU randomly crashes

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1180742 Bug ID: 1180742 Summary: [amdgpu]An AMD Vega series GPU randomly crashes Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: x86-64 OS: openSUSE Leap 15.2 Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: srid(a)rkmail.ru QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 844970 --> http://bugzilla.opensuse.org/attachment.cgi?id=844970&action=edit partial kernel log The AMDGPU kernel driver randomly crashes GPU, usually under load, with Radeon VII hardware. The GPU hang is relatively hard to hit, as it usually takes 5 to 7 days before it crashes. After a hang it attempts to reset the GPU, but sometimes the reset fails and system stays sort of unresponsive. You can still access it over network, and there's some sort of reaction on keyboard events, but display stays dead. Also, it seems to bring PCIe bus down to 1.0 mode, and it stays that until reboot. There's an upstream bug open that may have something to do about it: https://gitlab.freedesktop.org/drm/amd/-/issues/716 That particular GPU works fine on Windows machine openSUSE Leap 15.2, kernel 5.3.18-lp152.57-default #1 SMP Fri Dec 4 07:27:58 UTC 2020 (7be5551) -- You are receiving this mail because: You are the assignee for the bug.

4 months

1
7
0 0

[Bug 1180380] New: Blank external monitor after resume from suspend

by bugzilla_noreply＠suse.com

https://bugzilla.suse.com/show_bug.cgi?id=1180380 Bug ID: 1180380 Summary: Blank external monitor after resume from suspend 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: jack(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 844706 --> https://bugzilla.suse.com/attachment.cgi?id=844706&action=edit dmesg from the system After resuming from suspend to RAM the external display connected through DVI port on the docking station remains blank. Internal display is fine. I can use xrandr to make the monitor work like: xrandr --output DP1-1 --mode some-other-mode xrandr --output DP1-1 --mode original-mode -- You are receiving this mail because: You are the assignee for the bug.

4 months, 1 week

1
12
0 0

[Bug 1182535] New: Start-up hangs with iommu message

by bugzilla_noreply＠suse.com

https://bugzilla.suse.com/show_bug.cgi?id=1182535 Bug ID: 1182535 Summary: Start-up hangs with iommu message Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: x86-64 OS: openSUSE Leap 15.2 Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: pchadwick(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Leap startup stops with: "Error getting iommu info. ist the iommu enabled?" "Error initializing iommuv2" Hardware is AMD Ryzen 5 3400G on an ASRock B450M based motherboard -- You are receiving this mail because: You are the assignee for the bug.

4 months, 2 weeks

1
2
0 0

[Bug 1182349] New: WARNING: CPU: 7 PID: 90 at ../drivers/gpu/drm/i915/display/intel_dp.c:1895 intel_dp_max_link_rate+0x7e/0xa0

by bugzilla_noreply＠suse.com

https://bugzilla.suse.com/show_bug.cgi?id=1182349 Bug ID: 1182349 Summary: WARNING: CPU: 7 PID: 90 at ../drivers/gpu/drm/i915/display/intel_dp.c:1895 intel_dp_max_link_rate+0x7e/0xa0 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: hare(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Trying to feed an external EDID for i915 to facilitate headless operation on an Intel NUC resulted in repeated warnings Feb 17 08:47:38 localhost kernel: ------------[ cut here ]------------ Feb 17 08:47:38 localhost kernel: i915 0000:00:02.0: drm_WARN_ON(len <= 0) Feb 17 08:47:38 localhost kernel: WARNING: CPU: 7 PID: 90 at ../drivers/gpu/drm/i915/display/in> and a non-working display. (Arguably the display doesn't work as it's headless, but the vncviewer for Intel AMT stays blank, too. It doesn't when a monitor is connected.) -- You are receiving this mail because: You are the assignee for the bug.

4 months, 2 weeks

1
5
0 0

[Bug 1182226] New: amdgpu driver not working in Leap 15.2

by bugzilla_noreply＠suse.com

https://bugzilla.suse.com/show_bug.cgi?id=1182226 Bug ID: 1182226 Summary: amdgpu driver not working in Leap 15.2 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: x86-64 OS: Linux Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: donaldmleslie(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I am running Leap 15.2 on an HP 855 G7 The kernel supplied with Leap 15.2 is kernel-default-5.3.18-lp152.63.1.x86_64 It does not see the HDMI port I get the following results: From hwinfo: 25: PCI 300.0: 0300 VGA compatible controller (VGA) [Created at pci.386] Unique ID: svHJ.HB+rwQfOiT4 Parent ID: JZZT.e+TNXSUNut3 SysFS ID: /devices/pci0000:00/0000:00:08.1/0000:03:00.0 SysFS BusID: 0000:03:00.0 Hardware Class: graphics card Device Name: "Onboard IGD" Model: "ATI Renoir" Vendor: pci 0x1002 "ATI Technologies Inc" Device: pci 0x1636 "Renoir" SubVendor: pci 0x103c "Hewlett-Packard Company" SubDevice: pci 0x8760 Revision: 0xd1 Memory Range: 0x460000000-0x46fffffff (ro,non-prefetchable) Memory Range: 0x470000000-0x4701fffff (ro,non-prefetchable) I/O Ports: 0x1000-0x1fff (rw) Memory Range: 0xfc300000-0xfc37ffff (rw,non-prefetchable) IRQ: 255 (no events) Module Alias: "pci:v00001002d00001636sv0000103Csd00008760bc03sc00i00" Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #39 (PCI bridge) xrandr --listproviders xrandr: Failed to get size of gamma for output default Providers: number : 0 From glxinfo: OpenGL vendor string: VMware, Inc. OpenGL renderer string: llvmpipe (LLVM 9.0.1, 128 bits) OpenGL core profile version string: 3.3 (Core Profile) Mesa 19.3.4 OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.1 Mesa 19.3.4 OpenGL shading language version string: 1.40 OpenGL context flags: (none) OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.1 Mesa 19.3.4 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10 OpenGL ES profile extensions: inxi -G Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Renoir driver: N/A Device-2: N/A type: USB driver: uvcvideo Display: x11 server: X.Org 1.20.3 driver: ati unloaded: fbdev,modesetting,radeon,vesa resolution: 1920x1080~77Hz OpenGL: renderer: llvmpipe (LLVM 9.0.1 128 bits) v: 3.3 Mesa 19.3.4 After much fumbling trying to find what was wrong I added the .../kernel/stable and got a 5.10 kernel. Now everything works fine. I now get: 25: PCI 300.0: 0300 VGA compatible controller (VGA) [Created at pci.386] Unique ID: svHJ.HB+rwQfOiT4 Parent ID: JZZT.e+TNXSUNut3 SysFS ID: /devices/pci0000:00/0000:00:08.1/0000:03:00.0 SysFS BusID: 0000:03:00.0 Hardware Class: graphics card Device Name: "Onboard IGD" Model: "ATI Renoir" Vendor: pci 0x1002 "ATI Technologies Inc" Device: pci 0x1636 "Renoir" SubVendor: pci 0x103c "Hewlett-Packard Company" SubDevice: pci 0x8760 Revision: 0xd1 Driver: "amdgpu" Driver Modules: "amdgpu" Memory Range: 0x460000000-0x46fffffff (ro,non-prefetchable) Memory Range: 0x470000000-0x4701fffff (ro,non-prefetchable) I/O Ports: 0x1000-0x1fff (rw) Memory Range: 0xfc300000-0xfc37ffff (rw,non-prefetchable) IRQ: 49 (no events) Module Alias: "pci:v00001002d00001636sv0000103Csd00008760bc03sc00i00" Driver Info #0: Driver Status: amdgpu is active Driver Activation Cmd: "modprobe amdgpu" Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #39 (PCI bridge) xrandr --listproviders Providers: number : 1 Provider 0: id: 0x57; cap: 0xf (Source Output, Sink Output, Source Offload, Sink Offload); crtcs: 4; outputs: 4; associateproviders: 0; name: Unknown AMD Radeon GPU @ pci:0000:03:00.0 output eDP output HDMI-A-0 output DisplayPort-0 output DisplayPort-1 From glxinfo: OpenGL vendor string: AMD OpenGL renderer string: AMD RENOIR (DRM 3.40.0, 5.10.12-1-default, LLVM 11.0.1) OpenGL core profile version string: 4.6 (Core Profile) Mesa 20.3.4 OpenGL core profile shading language version string: 4.60 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 4.6 (Compatibility Profile) Mesa 20.3.4 OpenGL shading language version string: 4.60 OpenGL context flags: (none) OpenGL profile mask: compatibility profile OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.2 Mesa 20.3.4 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20 OpenGL ES profile extensions: inxi -G Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Renoir driver: amdgpu v: kernel Device-2: Luxvisions Innotech Limited HP HD Camera type: USB driver: uvcvideo Display: x11 server: X.org 1.20.10 driver: amdgpu,ati unloaded: fbdev,modesetting,vesa resolution: <xdpyinfo missing> OpenGL: renderer: AMD RENOIR (DRM 3.40.0 5.10.12-1-default LLVM 11.0.1) v: 4.6 Mesa 20.3.4 -- You are receiving this mail because: You are the assignee for the bug.

4 months, 2 weeks

1
2
0 0

[Bug 1180985] New: Kernel 5.10 breaks ethernet connection with lenovo x390

by bugzilla_noreply＠suse.com

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.

4 months, 2 weeks

1
16
0 0

2022

2021

2020

openSUSE Kernel Bugs March 2021