April 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 28 Nov '22

28 Nov '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 30

[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 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 1188954] New: black screen on initial X open on Kaveri Radeon R7, /dev/dri/card0: No such file or directory with radeon.cik_support=0 amdgpu.cik_support=1
by bugzilla_noreply＠suse.com 26 Oct '22

26 Oct '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1188954 Bug ID: 1188954 Summary: black screen on initial X open on Kaveri Radeon R7, /dev/dri/card0: No such file or directory with radeon.cik_support=0 amdgpu.cik_support=1 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: mrmazda(a)earthlink.net QA Contact: qa-bugs(a)suse.de CC: sndirsch(a)suse.com Found By: --- Blocker: --- Created attachment 851460 --> http://bugzilla.opensuse.org/attachment.cgi?id=851460&action=edit Xorg.0.log and dmesg Initial summary: black screen on initial X open on Kaveri Radeon R7, /dev/dri/card0: No such file or directory with radeon.cik_support=0 amdgpu.cik_support=1 To reproduce: 1-boot with included on kernel cmdline radeon.cik_support=0 amdgpu.cik_support=1 2-wait for X to fail to start 3-login on a tty 4-systemctl restart xdm Actual behavior: 1-X fails to start, finding no /dev/dri/card0, leaving login prompt on tty1 on display screen 2-X starts normally using amdgpu DDX driver Expected behavior: 1-X starts normally using amdgpu DDX driver Tested with kernels 5.12.13, 5.11.16, 5.7.11 # inxi -SGIay System: Host: asa88 Kernel: 5.12.13-1-default x86_64 bits: 64 compiler: gcc v: 11.1.1 parameters: BOOT_IMAGE=/boot/vmlinuz root=LABEL=tvgp07stw noresume ipv6.disable=1 net.ifnames=0 mitigations=auto consoleblank=0 radeon.cik_support=0 amdgpu.cik_support=1 video=1024x768@60 video=1440x900@60 drm.debug=0x1e log_buf_len=1M Console: tty pts/0 DM: TDM Distro: openSUSE Tumbleweed 20210730 Graphics: Device-1: AMD Kaveri [Radeon R7 Graphics] vendor: ASUSTeK driver: amdgpu v: kernel alternate: radeon bus-ID: 00:01.0 chip-ID: 1002:130f class-ID: 0300 Display: server: X.org 1.20.12 driver: loaded: vesa unloaded: fbdev,modesetting alternate: ati Message: Advanced graphics data unavailable for root. Info:...inxi: 3.3.06 Comments: 1-without radeon.cik_support=0 amdgpu.cik_support=1 on cmdline, X cannot be coaxed into using amdgpu DDX driver via /etc/X11/xorg.conf.d/*conf 2-without radeon.cik_support=0 amdgpu.cik_support=1, greeter startup completes (normally, on first try) using modesetting DIX driver -- You are receiving this mail because: You are the assignee for the bug.

1 25

[Bug 1189946] New: [trackerbug] Ancient patch cleanup
by bugzilla_noreply＠suse.com 11 Oct '22

11 Oct '22

https://bugzilla.suse.com/show_bug.cgi?id=1189946 Bug ID: 1189946 Summary: [trackerbug] Ancient patch cleanup 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: jeffm(a)suse.com QA Contact: qa-bugs(a)suse.de CC: jeffm(a)suse.com, mkubecek(a)suse.com Found By: --- Blocker: --- This is the tracker bug for cleaning up old patches in the master branch. -- You are receiving this mail because: You are the assignee for the bug.

1 20

[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

[Bug 1180985] New: Kernel 5.10 breaks ethernet connection with lenovo x390
by bugzilla_noreply＠suse.com 30 Sep '22

30 Sep '22

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.

1 17

[Bug 1198972] New: btrfs send slow
by bugzilla_noreply＠suse.com 07 Sep '22

07 Sep '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1198972 Bug ID: 1198972 Summary: btrfs send slow 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: jon.brightwell(a)zpg.co.uk QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- We have a btrfs send that starts fast (25MiBs) but quickly crawls (100KiBs~). example command: /sbin/btrfs send -v "/sqldata/central/.snapshots/112/snapshot" | pv -btraT -B50m | ssh backup3.repl.x.net sudo btrfs receive "/backup/dbshard1a.prod.x.net/central/112" At subvol /sqldata/central/.snapshots/112/snapshot At subvol snapshot 777MiB {----} 0:02:55 [ 130KiB/s] [4.44MiB/s] It slows down after 400MiB. I added a buffer size to pv check to see if it was network but the buffer never fills. htop doesn't show any kernel threads struggling and dstat and iostat don't show much. It's a live DB server but there's plenty of IO capacity and we have 5 identical servers that cap out the network. # iostat -x 5 Linux 5.3.18-150300.59.54-default (dbshard1a.prod.x.net) 04/28/22 _x86_64_ (48 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 2.22 0.00 1.27 0.09 0.00 96.43 Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util nvme3n1 58.24 441.63 791.34 8244.19 5.67 51.31 8.88 10.41 0.18 0.10 0.06 13.59 18.67 0.55 27.45 nvme0n1 86.05 441.56 1379.26 8244.25 5.18 51.38 5.67 10.42 0.14 0.10 0.06 16.03 18.67 0.53 28.00 nvme1n1 58.27 441.53 791.50 8245.03 5.67 51.32 8.87 10.41 0.18 0.10 0.06 13.58 18.67 0.55 27.40 nvme2n1 86.08 441.46 1379.37 8244.97 5.18 51.38 5.67 10.43 0.14 0.10 0.06 16.02 18.68 0.53 28.04 sda 11.45 14.98 712.51 79.42 0.45 0.08 3.79 0.52 4.37 0.15 0.05 62.20 5.30 1.07 2.84 sdb 11.30 14.98 699.35 79.42 0.44 0.08 3.72 0.52 4.44 0.15 0.05 61.90 5.30 1.08 2.83 avg-cpu: %user %nice %system %iowait %steal %idle 3.85 0.00 3.40 0.12 0.00 92.63 Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util nvme3n1 88.80 867.80 1016.00 11651.20 0.00 68.00 0.00 7.27 0.10 0.08 0.07 11.44 13.43 0.51 48.56 nvme0n1 66.00 867.40 728.80 11651.20 0.00 68.40 0.00 7.31 0.10 0.08 0.07 11.04 13.43 0.52 48.88 nvme1n1 93.00 863.00 1048.00 11732.80 0.00 72.00 0.00 7.70 0.10 0.08 0.08 11.27 13.60 0.51 48.64 nvme2n1 65.20 862.80 768.80 11732.80 0.00 72.20 0.00 7.72 0.18 0.08 0.08 11.79 13.60 0.53 48.72 sda 41.00 72.20 3498.40 445.10 0.00 0.00 0.00 0.00 0.85 0.11 0.05 85.33 6.16 1.28 14.48 sdb 36.60 72.20 2855.20 445.10 0.00 0.00 0.00 0.00 0.79 0.10 0.04 78.01 6.16 1.31 14.24 avg-cpu: %user %nice %system %iowait %steal %idle 4.43 0.00 3.30 0.12 0.00 92.15 Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util nvme3n1 70.80 761.20 769.60 10829.60 0.00 63.40 0.00 7.69 0.10 0.09 0.08 10.87 14.23 0.50 41.92 nvme0n1 92.20 761.00 869.60 10829.60 0.00 63.60 0.00 7.71 0.09 0.09 0.08 9.43 14.23 0.52 44.64 nvme1n1 68.80 751.20 767.20 10528.80 0.00 61.80 0.00 7.60 0.10 0.13 0.10 11.15 14.02 0.51 42.08 nvme2n1 91.00 751.00 931.20 10528.80 0.00 62.00 0.00 7.63 0.09 0.13 0.11 10.23 14.02 0.53 44.56 sda 14.00 46.60 1089.60 297.40 0.00 0.20 0.00 0.43 0.69 0.11 0.02 77.83 6.38 1.48 8.96 sdb 10.00 46.60 552.80 297.40 0.00 0.20 0.00 0.43 0.66 0.11 0.01 55.28 6.38 1.55 8.80 # dstat 5 You did not select any stats, using -cdngy by default. --total-cpu-usage-- -dsk/total- -net/total- ---paging-- ---system-- usr sys idl wai stl| read writ| recv send| in out | int csw 2 1 96 0 0|5753k 32M| 0 0 | 86B 376B| 17k 14k 4 3 92 0 0|8436k 95M|2705k 3862k| 0 0 | 39k 29k 5 3 93 0 0|2510k 34M|2119k 3624k| 819B 0 | 30k 22k 3 3 94 0 0|2274k 39M|3914k 4882k| 0 0 | 37k 27k 3 3 94 0 0|1385k 34M|2466k 3345k| 0 0 | 32k 22k # ps -aux | grep send root 7557 94.8 0.0 24572 172 pts/1 Rl+ 11:40 8:06 /sbin/btrfs send -v /sqldata/central/.snapshots/112/snapshot does seem to be maxing out one core. # ps -auxf | grep "btrfs" root 1679 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-worker] root 1680 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-worker-hi] root 1681 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-delalloc] root 1682 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-flush_del] root 1683 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-cache] root 1684 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-submit] root 1685 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-fixup] root 1686 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-endio] root 1687 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-endio-met] root 1688 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-endio-met] root 1689 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-endio-rai] root 1690 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-endio-rep] root 1691 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-rmw] root 1692 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-endio-wri] root 1693 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-freespace] root 1694 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-delayed-m] root 1695 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-readahead] root 1696 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-qgroup-re] root 1716 0.0 0.0 0 0 ? S Mar19 0:01 \_ [btrfs-cleaner] root 1717 1.5 0.0 0 0 ? S Mar19 872:22 \_ [btrfs-transacti] root 22056 0.8 0.0 0 0 ? I 05:23 3:28 \_ [kworker/u96:10-btrfs-endio-write] root 28815 0.0 0.0 0 0 ? I< 06:41 0:00 \_ [kworker/u97:2-btrfs-worker-high] root 43020 1.5 0.0 0 0 ? I 09:22 2:22 \_ [kworker/u96:12-btrfs-endio-meta] root 44734 1.5 0.0 0 0 ? I 09:41 2:05 \_ [kworker/u96:2-btrfs-endio-meta] root 45641 0.0 0.0 0 0 ? I< 09:51 0:00 \_ [kworker/u97:6-btrfs-worker-high] root 578 0.0 0.0 0 0 ? I< 10:34 0:00 \_ [kworker/u97:1-btrfs-worker-high] root 3129 0.0 0.0 0 0 ? I< 10:59 0:00 \_ [kworker/u97:3-btrfs-worker-high] root 4401 4.2 0.0 0 0 ? I 11:06 1:56 \_ [kworker/u96:8-btrfs-endio] root 5660 0.0 0.0 0 0 ? I< 11:20 0:00 \_ [kworker/u97:4-btrfs-worker-high] root 6567 7.8 0.0 0 0 ? I 11:30 1:45 \_ [kworker/u96:14-btrfs-endio-meta] root 6570 7.6 0.0 0 0 ? I 11:30 1:42 \_ [kworker/u96:20-btrfs-endio-meta] root 6574 4.6 0.0 0 0 ? I 11:30 1:01 \_ [kworker/u96:24-btrfs-endio-meta] root 6584 8.2 0.0 0 0 ? I 11:30 1:49 \_ [kworker/u96:25-btrfs-endio-write] root 6679 0.0 0.0 0 0 ? I< 11:31 0:00 \_ [kworker/u97:5-btrfs-worker-high] root 6681 7.4 0.0 0 0 ? I 11:31 1:34 \_ [kworker/u96:27-btrfs-endio-meta] root 7499 1.7 0.0 0 0 ? I 11:40 0:13 \_ [kworker/u96:1-btrfs-endio-meta] root 7500 2.7 0.0 0 0 ? I 11:40 0:21 \_ [kworker/u96:3-btrfs-endio] root 8460 0.1 0.0 0 0 ? I 11:50 0:00 \_ [kworker/u96:4-btrfs-endio-meta] #iotop PID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND 7557 be/4 root 190.55 K/s 0.00 B/s 0.00 % 0.13 % btrfs send -v /sqldata/central/.snapshots/112/snapshot 6570 be/4 root 9.30 K/s 18.59 K/s 0.00 % 0.01 % [kworker/u96:20-bond0] 12922 be/4 mysql 1692.48 K/s 16.67 M/s 0.00 % 0.01 % mariadbd --defaults-file=/etc/my.appdata.cnf 7499 be/4 root 6.20 K/s 9.30 K/s 0.00 % 0.01 % [kworker/u96:1-btrfs-endio-write] 22056 be/4 root 3.10 K/s 15.49 K/s 0.00 % 0.00 % [kworker/u96:10-bond0] 7500 be/4 root 3.10 K/s 3.10 K/s 0.00 % 0.00 % [kworker/u96:3-btrfs-endio-write] 12761 be/4 mysql 24.79 K/s 1332.29 K/s 0.00 % 0.00 % mariadbd --defaults-file=/etc/my.central.cnf 6359 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/12:1-events] 9123 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/19:0-events] 3015 be/4 dd-agent 0.00 B/s 3.87 K/s 0.00 % 0.00 % agent run -p /opt/datadog-agent/run/agent.pid 6567 be/4 root 0.00 B/s 12.39 K/s 0.00 % 0.00 % [kworker/u96:14-btrfs-endio-write] 6584 be/4 root 0.00 B/s 9.30 K/s 0.00 % 0.00 % [kworker/u96:25-btrfs-endio-write] What diagnostics are recommended to work out why this one server is a slug and possibly bugged? :) scrub is fine but can't take server offline to do a check. No errors in dmesg or journal. -- You are receiving this mail because: You are the assignee for the bug.

1 4

[Bug 1190340] New: armv7hl 5.14 kernel build fails for Leap 15.4
by bugzilla_noreply＠suse.com 06 Sep '22

06 Sep '22

https://bugzilla.suse.com/show_bug.cgi?id=1190340 Bug ID: 1190340 Summary: armv7hl 5.14 kernel build fails for Leap 15.4 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: tiwai(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Now we start building the armv7hl kernel for Leap 15.4, and it fails as: [ 9793s] GEN modules.builtin [ 9793s] LD .tmp_vmlinux.btf [ 9827s] BTF .btf.vmlinux.bin.o [ 9884s] [4957384] STRUCT thread_info's field 'vfpstate' offset=2048 bit_size=0 type=4957356 Error emitting field [ 9884s] Encountered error while encoding BTF. .... [ 9994s] FAILED: load BTF from vmlinux: No such file or directory [ 9994s] make[1]: *** [/home/abuild/rpmbuild/BUILD/kernel-default-5.14.2/linux-5.14/Makefile:1200: vmlinux] Error 255 My initial attempt worked because BTF wasn't enabled due to the old tools. OTOH, the same 5.14 build is OK with stable branch, so there is still some missing piece, supposedly. -- You are receiving this mail because: You are the assignee for the bug.

1 9

[Bug 1195291] New: initrd is being rebuilt when kernel is being removed after kernel update
by bugzilla_noreply＠suse.com 21 Aug '22

21 Aug '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1195291 Bug ID: 1195291 Summary: initrd is being rebuilt when kernel is being removed after kernel update 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: Ulrich.Windl(a)rz.uni-regensburg.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Despite of the problem that initrds are needlessy rebuilt when installing kernel modules (bug 1100885, bug 1191322), there are also needless rebuilds when removing obsolete kernels: Still on the next boot when older kernels are removed, their initrds are being rebuilt before the kernels are removed (it seems at least). Example (combining extracts from journal and /var/log/zypp/history): Jan 27 21:36:03 i7.site [RPM][7347]: install kernel-default-5.3.18-150300.59.43.1.x86_64: success Jan 27 21:36:04 i7.site [RPM][17173]: erase kernel-macros-5.3.18-59.40.1.noarch: success Jan 27 21:36:05 i7.site [RPM][17173]: install kernel-macros-5.3.18-150300.59.43.1.noarch: success Jan 27 21:36:06 i7.site [RPM][17173]: erase kernel-macros-5.3.18-59.40.1.noarch: success Jan 27 21:36:06 i7.site [RPM][17173]: install kernel-macros-5.3.18-150300.59.43.1.noarch: success Jan 27 21:37:32 i7.site [RPM][17175]: install kernel-preempt-5.3.18-150300.59.43.1.x86_64: success Jan 27 21:37:47 i7.site [RPM][27390]: install kernel-default-extra-5.3.18-150300.59.43.1.x86_64: success Jan 27 21:37:55 i7.site [RPM][27492]: install kernel-devel-5.3.18-150300.59.43.1.noarch: success Jan 27 21:37:55 i7.site [RPM][27492]: install kernel-devel-5.3.18-150300.59.43.1.noarch: success Jan 27 21:38:03 i7.site [RPM][27497]: install kernel-preempt-extra-5.3.18-150300.59.43.1.x86_64: success Jan 27 21:38:25 i7.site [RPM][27675]: install kernel-default-optional-5.3.18-150300.59.43.1.x86_64: success Jan 27 21:38:28 i7.site [RPM][27776]: install kernel-preempt-devel-5.3.18-150300.59.43.1.x86_64: success Jan 27 21:38:28 i7.site [RPM][27776]: install kernel-preempt-devel-5.3.18-150300.59.43.1.x86_64: success Jan 27 21:38:31 i7.site [RPM][27782]: install kernel-default-devel-5.3.18-150300.59.43.1.x86_64: success Jan 27 21:38:31 i7.site [RPM][27782]: install kernel-default-devel-5.3.18-150300.59.43.1.x86_64: success Jan 27 21:38:37 i7.site [RPM][27788]: install kernel-preempt-optional-5.3.18-150300.59.43.1.x86_64: success # 2022-01-27 21:43:41 Output of kernel-default-extra-5.3.18-150300.59.43.1.x86_64.rpm %posttrans script: # Creating initrd: /boot/initrd-5.3.18-150300.59.43-default # Creating initrd: /boot/initrd-5.3.18-150300.59.43-preempt # Creating initrd: /boot/initrd-5.3.18-59.40-default # Creating initrd: /boot/initrd-5.3.18-59.40-preempt ### Reboot ### Jan 28 20:24:49 i7 zypper[1916]: The following 9 packages are going to be REMOVED: Jan 28 20:24:49 i7 zypper[1916]: kernel-default-5.3.18-59.37.2 kernel-default-devel-5.3.18-59.37.2 kernel-default-extra-5.3.18-59.37.2 kernel-default-optional-5.3.18-59.37.2 kernel-devel-5.3.18-59.37.2 kernel-preempt-5.3.18-59.37.2 kernel-preempt-devel-5.3.18-59.37.2 kernel-preempt-extra-5.3.18-59.37.2 kernel-preempt-optional-5.3.18-59.37.2 Jan 28 20:24:49 i7 zypper[1916]: 9 packages to remove. Jan 28 20:27:04 i7.site [RPM][2887]: erase kernel-default-devel-5.3.18-59.37.2.x86_64: success Jan 28 20:27:07 i7.site [RPM][2887]: erase kernel-default-devel-5.3.18-59.37.2.x86_64: success Jan 28 20:27:07 i7.site zypper[1916]: (1/9) Removing kernel-default-devel-5.3.18-59.37.2.x86_64 [.....done] Jan 28 20:27:08 i7.site [RPM][4137]: erase kernel-default-optional-5.3.18-59.37.2.x86_64: success Jan 28 20:31:10 i7.site [RPM][4137]: erase kernel-default-optional-5.3.18-59.37.2.x86_64: success Jan 28 20:31:10 i7.site zypper[1916]: (2/9) Removing kernel-default-optional-5.3.18-59.37.2.x86_64 [.....done] Jan 28 20:31:11 i7.site [RPM][11952]: erase kernel-preempt-devel-5.3.18-59.37.2.x86_64: success Jan 28 20:31:20 i7.site [RPM][11952]: erase kernel-preempt-devel-5.3.18-59.37.2.x86_64: success Jan 28 20:31:20 i7.site zypper[1916]: (3/9) Removing kernel-preempt-devel-5.3.18-59.37.2.x86_64 [.....done] Jan 28 20:31:20 i7.site [RPM][11958]: erase kernel-preempt-optional-5.3.18-59.37.2.x86_64: success Jan 28 20:32:24 i7.site [RPM][11958]: erase kernel-preempt-optional-5.3.18-59.37.2.x86_64: success Jan 28 20:32:24 i7.site zypper[1916]: (4/9) Removing kernel-preempt-optional-5.3.18-59.37.2.x86_64 [.....done] Jan 28 20:32:25 i7.site [RPM][19401]: erase kernel-default-extra-5.3.18-59.37.2.x86_64: success Jan 28 20:33:13 i7.site [RPM][19401]: erase kernel-default-extra-5.3.18-59.37.2.x86_64: success Jan 28 20:33:13 i7.site zypper[1916]: (5/9) Removing kernel-default-extra-5.3.18-59.37.2.x86_64 [.....done] Jan 28 20:33:13 i7.site zypper[1916]: Creating initrd: /boot/initrd-5.3.18-59.37-default # Creating initrd: /boot/initrd-5.3.18-59.37-default Jan 28 20:33:17 i7.site [RPM][26818]: erase kernel-devel-5.3.18-59.37.2.noarch: success Jan 28 20:33:24 i7.site [RPM][26818]: erase kernel-devel-5.3.18-59.37.2.noarch: success Jan 28 20:33:24 i7.site zypper[1916]: (6/9) Removing kernel-devel-5.3.18-59.37.2.noarch [.....done] Jan 28 20:33:24 i7.site [RPM][26819]: erase kernel-preempt-extra-5.3.18-59.37.2.x86_64: success Jan 28 20:34:11 i7.site [RPM][26819]: erase kernel-preempt-extra-5.3.18-59.37.2.x86_64: success Jan 28 20:34:11 i7.site zypper[1916]: (7/9) Removing kernel-preempt-extra-5.3.18-59.37.2.x86_64 [.....done] Jan 28 20:34:11 i7.site zypper[1916]: Creating initrd: /boot/initrd-5.3.18-59.37-preempt # Creating initrd: /boot/initrd-5.3.18-59.37-preempt Jan 28 20:34:12 i7.site [RPM][1784]: erase kernel-default-5.3.18-59.37.2.x86_64: success Jan 28 20:34:43 i7.site [RPM][1784]: erase kernel-default-5.3.18-59.37.2.x86_64: success Jan 28 20:34:43 i7.site zypper[1916]: (8/9) Removing kernel-default-5.3.18-59.37.2.x86_64 [.....done] Jan 28 20:34:44 i7.site [RPM][4725]: erase kernel-preempt-5.3.18-59.37.2.x86_64: success Jan 28 20:35:15 i7.site [RPM][4725]: erase kernel-preempt-5.3.18-59.37.2.x86_64: success Jan 28 20:35:15 i7.site zypper[1916]: (9/9) Removing kernel-preempt-5.3.18-59.37.2.x86_64 [.....done] Jan 28 20:35:15 i7.site systemd[1]: purge-kernels.service: Succeeded. In addition to rebuiling the initrds, the bootloader was reinstalled (including the os-prober), so the removal of the old kernels took 10 minutes alltogether! # grep run_command.*grub2 /var/log/pbl.log 2022-01-27 21:35:35 <1> update-bootloader-7882 run_command.294: '/usr/lib/bootloader/grub2/config' = 0, output: 2022-01-27 21:36:03 <1> bootloader_entry-1449 run_command.294: '/usr/lib/bootloader/grub2/config' = 0, output: 2022-01-27 21:37:03 <1> update-bootloader-9958 run_command.294: '/usr/lib/bootloader/grub2/config' = 0, output: 2022-01-27 21:37:32 <1> bootloader_entry-8996 run_command.294: '/usr/lib/bootloader/grub2/config' = 0, output: 2022-01-27 21:41:39 <1> update-bootloader-8968 run_command.294: '/usr/lib/bootloader/grub2/config' = 0, output: 2022-01-27 21:42:20 <1> update-bootloader-0547 run_command.294: '/usr/lib/bootloader/grub2/config' = 0, output: 2022-01-27 21:43:00 <1> update-bootloader-6949 run_command.294: '/usr/lib/bootloader/grub2/config' = 0, output: 2022-01-27 21:43:41 <1> update-bootloader-7629 run_command.294: '/usr/lib/bootloader/grub2/config' = 0, output: 2022-01-28 20:31:09 <1> update-bootloader-0043 run_command.294: '/usr/lib/bootloader/grub2/config' = 0, output: 2022-01-28 20:32:23 <1> update-bootloader-4882 run_command.294: '/usr/lib/bootloader/grub2/config' = 0, output: 2022-01-28 20:33:12 <1> update-bootloader-4790 run_command.294: '/usr/lib/bootloader/grub2/config' = 0, output: 2022-01-28 20:34:11 <1> update-bootloader-4190 run_command.294: '/usr/lib/bootloader/grub2/config' = 0, output: 2022-01-28 20:34:43 <1> bootloader_entry-0829 run_command.294: '/usr/lib/bootloader/grub2/config' = 0, output: 2022-01-28 20:35:14 <1> bootloader_entry-7074 run_command.294: '/usr/lib/bootloader/grub2/config' = 0, output: Reinstalling the boot loader 15 times when updating two kernels!? -- You are receiving this mail because: You are the assignee for the bug.

1 4

2022

2021

2020

openSUSE Kernel Bugs April 2022