November 2023 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[Bug 1211428] New: Steam deck speaker is quiet.
by bugzilla_noreply＠suse.com 24 May '24

24 May '24

https://bugzilla.suse.com/show_bug.cgi?id=1211428 Bug ID: 1211428 Summary: Steam deck speaker is quiet. 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: monkeyboyted(a)yahoo.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Hi everyone, Steam deck speakers finally works in both speakers. Speaker-test works. However, I also notice the sound is quiet compared to SteamOS. Can you fix it? speaker-test -Dplughw:1,1 -c2 Linux steamdeck.lan 6.4.0-rc2-1.g679133f-default #1 SMP PREEMPT_DYNAMIC Sun May 14 21:09:47 UTC 2023 (679133f) x86_64 x86_64 x86_64 GNU/Linux LSB Version: n/a Distributor ID: openSUSE Description: openSUSE Tumbleweed Release: 20230514 Codename: n/a -- You are receiving this mail because: You are the assignee for the bug.

1 10

[Bug 1211761] New: vtty[1-6] nouveau framebuffers produce vast snow/raster on right and bottom border areas on the larger resolution of two displays, in the absence of both plymouth and video= on linu lines
by bugzilla_noreply＠suse.com 17 May '24

17 May '24

https://bugzilla.suse.com/show_bug.cgi?id=1211761 Bug ID: 1211761 Summary: vtty[1-6] nouveau framebuffers produce vast snow/raster on right and bottom border areas on the larger resolution of two displays, in the absence of both plymouth and video= on linu lines Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 URL: https://bugzilla.kernel.org/show_bug.cgi?id=217479 ; https://gitlab.freedesktop.org/drm/nouveau/-/issues/21 4 OS: Other Status: NEW Severity: Minor Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: mrmazda(a)earthlink.net QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Original Summary: vtty[1-6] nouveau framebuffers produce vast snow/raster on right and bottom border areas on the larger resolution of two displays, in the absence of both plymouth and video= on linu lines FTR: Upstream bugs: https://bugzilla.kernel.org/show_bug.cgi?id=217479 (includes most detail, w/ dmesg) https://gitlab.freedesktop.org/drm/nouveau/-/issues/214 To reproduce: 1-connect two unequal native resolution displays to a Tesla or Firmi GPU 2-don't have plymouth in use (I don't ever have it installed, so don't know whether it impacts) 3-don't include e.g. video=1440x900@60 directive on Grub's linu lines 4-boot TW 5-switch to a vtty, e.g. Ctrl-Alt-F3 Actual behavior: 1-Both displays utilize the resolution (same pixel grid) of the lower resolution display 2-Lower resolution display behaves as expected (light text on black background) 3-Higher resolution display uses same pixels as lower resolution display, with light text on black background, leaving right side and bottom raster instead of black Expected behavior: 1-Both displays utilize the resolution (same pixel grid) of the lower resolution display 2-Lower resolution display behaves as expected 3-Entire higher resolution display's background is black instead of portions in raster Workaround: add e.g. video=1440x900@60 to Grub's linu lines, which causes both displays to use the same nominal mode on the full display space. Occurs with TW 6.3.2, 6.2.12 & 6.2.4 kernel-default, and with 6.2.15 on Fedora 38 and Mageia 9. Does not occur with TW 6.1.12 kernel-default on NVidia, or with AMD Caicos (Terascale2) GPU, or with Intel Eaglelake GPU. Tested only on legacy booting (no UEFI support). Others might describe what I call "raster" as multicolored snow. nosimplefb=1 doesn't change anything. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1213148] New: Atomisp results in tumbleweed being unable to boot on some atom computers since kernel 6.2
by bugzilla_noreply＠suse.com 02 May '24

02 May '24

https://bugzilla.suse.com/show_bug.cgi?id=1213148 Bug ID: 1213148 Summary: Atomisp results in tumbleweed being unable to boot on some atom computers since kernel 6.2 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: 64bit OS: openSUSE Tumbleweed Status: NEW Severity: Critical Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: catice567(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Since kernel 6.2, my Tumbleweed refuses to boot because of intel isp. Ubuntu had this problem but they fixed it by disabling atomisp. I have a request to the openSUSE kernel maintainers: Can you please disable atomisp in your kernel, especially since this will affect Leap later on next year? -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 1211975] New: freeze with flip_done time out when external monitor attached
by bugzilla_noreply＠suse.com 26 Mar '24

26 Mar '24

https://bugzilla.suse.com/show_bug.cgi?id=1211975 Bug ID: 1211975 Summary: freeze with flip_done time out when external monitor attached 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: mattm3a(a)yahoo.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Only when external monitor is attached, display freezes for a Lenovo T14. External monitor is connected via HDMI. Mean time between freeze ~1 hour. Output from terminal (CTRL+ALT+F1) looks something like this (from image, not copied in text form): [374.123930][ T1729] i915 0000:00:02.0: [drm] *ERROR* flip_done timed out [374.123938][ T1729] i915 0000:00:02.0: [drm] *ERROR* [PLANE:82:plane 1B] commit wait timed out lspci | grep -i vga 00:02.0 VGA compatible controller: Intel Corporation Alder Lake-UP3 GT2 [Iris Xe Graphics] (rev 0c) lsb-release -a LSB Version: n/a Distributor ID: openSUSE Description: openSUSE Tumbleweed Release: 20230531 Codename: n/a uname -srvp Linux 6.3.4-1-default #1 SMP PREEMPT_DYNAMIC Mon May 29 06:22:29 UTC 2023 (2c66b1f) x86_64 I think this issue first appeared for me in mid-May, but I'm unsure of exactly what Tumbleweed update that was. -- You are receiving this mail because: You are the assignee for the bug.

1 6

Leap 15.6 Alpha uses kernel 6.4.x which is buggy with Adaptec RAID controllers.
by Maxim 08 Mar '24

08 Mar '24

https://bugzilla.kernel.org/show_bug.cgi?id=217599 [ 7427.739081] aacraid: Host bus reset request. SCSI hang ? [ 7427.739101] aacraid 0000:08:00.0: outstanding cmd: midlevel-0 [ 7427.739105] aacraid 0000:08:00.0: outstanding cmd: lowlevel-0 [ 7427.739107] aacraid 0000:08:00.0: outstanding cmd: error handler-0 [ 7427.739109] aacraid 0000:08:00.0: outstanding cmd: firmware-48 [ 7427.739111] aacraid 0000:08:00.0: outstanding cmd: kernel-0 [ 7427.765640] aacraid 0000:08:00.0: Controller reset type is 3 [ 7427.765652] aacraid 0000:08:00.0: Issuing IOP reset [ 7469.875692] aacraid 0000:08:00.0: IOP reset succeeded [ 7469.936116] aacraid: Comm Interface type2 enabled [ 7483.472661] aacraid 0000:08:00.0: Scheduling bus rescan [ 7496.491585] sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16). [ 7496.491764] sd 0:0:1:0: [sdb] Very big device. Trying to use READ CAPACITY(16). [ 7553.768632] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7553.768644] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7553.768650] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7553.768655] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7553.768660] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7553.768664] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7553.768669] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7553.818630] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7553.835297] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7553.835306] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7553.835312] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7553.835317] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7553.835322] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7553.835326] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7553.835331] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7553.835335] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7553.835340] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7553.835344] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7553.835348] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7553.835353] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7553.835357] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7598.355616] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7598.355631] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7598.355637] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7598.355642] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7598.355647] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7598.355652] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7598.355657] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7598.355661] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7598.355666] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7598.382419] aacraid: Host bus reset request. SCSI hang ? [ 7598.382439] aacraid 0000:08:00.0: outstanding cmd: midlevel-0 [ 7598.382443] aacraid 0000:08:00.0: outstanding cmd: lowlevel-0 [ 7598.382445] aacraid 0000:08:00.0: outstanding cmd: error handler-0 [ 7598.382447] aacraid 0000:08:00.0: outstanding cmd: firmware-30 [ 7598.382449] aacraid 0000:08:00.0: outstanding cmd: kernel-0 [ 7598.402360] aacraid 0000:08:00.0: Controller reset type is 3 [ 7598.402371] aacraid 0000:08:00.0: Issuing IOP reset [ 7640.363459] aacraid 0000:08:00.0: IOP reset succeeded [ 7640.422724] aacraid: Comm Interface type2 enabled [ 7653.650105] aacraid 0000:08:00.0: Scheduling bus rescan [ 7666.688374] sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16). [ 7666.688467] sd 0:0:1:0: [sdb] Very big device. Trying to use READ CAPACITY(16). [ 7814.462297] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7814.462308] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7814.462313] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7814.462318] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7814.462322] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7814.462326] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7814.462330] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7814.462334] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7814.462338] aacraid: Host adapter abort request. aacraid: Outstanding commands on (0,0,1,0): [ 7814.478923] aacraid: Host bus reset request. SCSI hang ? [ 7814.478936] aacraid 0000:08:00.0: outstanding cmd: midlevel-0 [ 7814.478938] aacraid 0000:08:00.0: outstanding cmd: lowlevel-0 [ 7814.478940] aacraid 0000:08:00.0: outstanding cmd: error handler-0 [ 7814.478942] aacraid 0000:08:00.0: outstanding cmd: firmware-9 [ 7814.478943] aacraid 0000:08:00.0: outstanding cmd: kernel-0 [ 7814.495578] aacraid 0000:08:00.0: Controller reset type is 3 [ 7814.495587] aacraid 0000:08:00.0: Issuing IOP reset [ 7856.730598] aacraid 0000:08:00.0: IOP reset succeeded [ 7856.779371] aacraid: Comm Interface type2 enabled [ 7869.946607] aacraid 0000:08:00.0: Scheduling bus rescan [ 7882.985564] sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16). [ 7882.985661] sd 0:0:1:0: [sdb] Very big device. Trying to use READ CAPACITY(16). P.S. I was not able to login to SUSE bugzillla. Login to SUSE portal does not work.

2 1

[Bug 1214073] New: [Build 20230807] kernel 6.4.8 complains about ACPI and stops loading
by bugzilla_noreply＠suse.com 27 Feb '24

27 Feb '24

https://bugzilla.suse.com/show_bug.cgi?id=1214073 Bug ID: 1214073 Summary: [Build 20230807] kernel 6.4.8 complains about ACPI and stops loading 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: ilgaz(a)ilgaz.gen.tr QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 868684 --> https://bugzilla.suse.com/attachment.cgi?id=868684&action=edit photo of screen when system frozen As the system frozen and I am in hurry, I could only take photo of screen. It says "ACPI: _SB_.PCIB. IXUE. IGPU: failed to evaluate _DSM" on the last line which was said to be a harmless effect of nvidia chipset. I am using nouveau drivers (built into kernel) and the system is macbook 5,1 I don't want to flood here with needless data, I can provide everything needed. -- You are receiving this mail because: You are the assignee for the bug.

1 10

[Bug 1211796] New: kernel modules not usrmerged
by bugzilla_noreply＠suse.com 27 Feb '24

27 Feb '24

https://bugzilla.suse.com/show_bug.cgi?id=1211796 Bug ID: 1211796 Summary: kernel modules not usrmerged 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: msuchanek(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Currently kernel modules are installed through compatibility symlink, and te assumed location is in /lib. Patch kmod and kernel-binary.spec.in to not rely on this symlink. -- You are receiving this mail because: You are the assignee for the bug.

1 22

[Bug 1210791] New: KMP builds fails with ld: cannot find arch/s390/lib/expoline/expoline.o
by bugzilla_noreply＠suse.com 27 Feb '24

27 Feb '24

https://bugzilla.suse.com/show_bug.cgi?id=1210791 Bug ID: 1210791 Summary: KMP builds fails with ld: cannot find arch/s390/lib/expoline/expoline.o Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: S/390-64 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: ptesarik(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Out-of-tree kernel modules can no longer be built for openSUSE:Factory:zSystems. See See https://build.opensuse.org/build/Kernel:kdump/openSUSE_Factory_zSystems/s39… [ 783s] + make -C /usr/src/linux-obj/s390x/default modules M=/home/abuild/rpmbuild/BUILD/crash-8.0.2/kbuild/default [ 783s] CC [M] /home/abuild/rpmbuild/BUILD/crash-8.0.2/kbuild/default/crash.o [ 784s] MODPOST /home/abuild/rpmbuild/BUILD/crash-8.0.2/kbuild/default/Module.symvers [ 784s] CC [M] /home/abuild/rpmbuild/BUILD/crash-8.0.2/kbuild/default/crash.mod.o [ 784s] LD [M] /home/abuild/rpmbuild/BUILD/crash-8.0.2/kbuild/default/crash.ko [ 784s] ld: cannot find arch/s390/lib/expoline/expoline.o: No such file or directory [ 784s] make[1]: *** [/usr/src/linux-6.2.12-1/scripts/Makefile.modfinal:61: /home/abuild/rpmbuild/BUILD/crash-8.0.2/kbuild/default/crash.ko] Error 1 [ 784s] make: *** [../../../linux-6.2.12-1/Makefile:1953: modules] Error 2 [ 784s] error: Bad exit status from /var/tmp/rpm-tmp.6wzRBp (%build) -- You are receiving this mail because: You are the assignee for the bug.

1 17

[Bug 1214133] New: bluetooth disabled after update to 20230808, firmware load for mediatek/BT_RAM_CODE_MT7922_1_1_hdr.bin failes
by bugzilla_noreply＠suse.com 25 Feb '24

25 Feb '24

https://bugzilla.suse.com/show_bug.cgi?id=1214133 Bug ID: 1214133 Summary: bluetooth disabled after update to 20230808, firmware load for mediatek/BT_RAM_CODE_MT7922_1_1_hdr.bin failes 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: hofmann(a)shiphrah.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 868726 --> https://bugzilla.suse.com/attachment.cgi?id=868726&action=edit dmesg on TW 20230808 After update to Tumbleweed 20230808 bluetooth is disabled and can not be enabled again. dmesg | grep luetooth (on TW 20230806) [ 6.098671] Bluetooth: Core ver 2.22 [ 6.098681] Bluetooth: HCI device and connection manager initialized [ 6.098683] Bluetooth: HCI socket layer initialized [ 6.098684] Bluetooth: L2CAP socket layer initialized [ 6.098685] Bluetooth: SCO socket layer initialized [ 26.836464] Bluetooth: hci0: Device setup in 20228164 usecs [ 26.836469] Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported. [ 27.115864] Bluetooth: hci0: AOSP extensions version v1.00 [ 27.115870] Bluetooth: hci0: AOSP quality report is supported dmesg | grep luetooth (on TW 20230808) [ 4.355787] Bluetooth: Core ver 2.22 [ 4.355794] Bluetooth: HCI device and connection manager initialized [ 4.355797] Bluetooth: HCI socket layer initialized [ 4.355798] Bluetooth: L2CAP socket layer initialized [ 4.355799] Bluetooth: SCO socket layer initialized [ 4.368031] bluetooth hci0: Direct firmware load for mediatek/BT_RAM_CODE_MT7922_1_1_hdr.bin failed with error -2 [ 4.368034] Bluetooth: hci0: Failed to load firmware file (-2) [ 4.368045] Bluetooth: hci0: Failed to set up firmware (-2) [ 4.368053] Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported. [ 4.438485] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 4.438487] Bluetooth: BNEP filters: protocol multicast [ 4.438489] Bluetooth: BNEP socket layer initialized unfortunately I can not say if it was working in TW 20230807 -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1213757] New: All processes that try to communicate with NETLINK socket hang up if running hostapd on Raspberry Pi
by bugzilla_noreply＠suse.com 20 Feb '24

20 Feb '24

https://bugzilla.suse.com/show_bug.cgi?id=1213757 Bug ID: 1213757 Summary: All processes that try to communicate with NETLINK socket hang up if running hostapd on Raspberry Pi Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: aarch64 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: dheidler(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 868483 --> https://bugzilla.suse.com/attachment.cgi?id=868483&action=edit strace of hanging "ip a" The issue appears a few (~5) minutes after hostapd is started. Jul 28 12:47:40 openqa-piworker systemd[1]: Started Hostapd IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator. Jul 28 12:47:40 openqa-piworker hostapd[15307]: Configuration file: /etc/hostapd.conf Jul 28 12:47:40 openqa-piworker kernel: br0: port 1(wlan0) entered blocking state Jul 28 12:47:40 openqa-piworker kernel: br0: port 1(wlan0) entered disabled state Jul 28 12:47:40 openqa-piworker kernel: device wlan0 entered promiscuous mode Jul 28 12:47:40 openqa-piworker hostapd[15307]: wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE Jul 28 12:47:41 openqa-piworker dbus-daemon[629]: [system] Activating via systemd: service name='fi.w1.wpa_supplicant1' unit='wpa_supplicant.service' requested by ':1.31' (uid=0 pid=730 comm="/usr/sbin/wickedd --systemd --foreground ") Jul 28 12:47:41 openqa-piworker systemd[1]: Starting WPA Supplicant daemon... Jul 28 12:47:41 openqa-piworker dbus-daemon[629]: [system] Successfully activated service 'fi.w1.wpa_supplicant1' Jul 28 12:47:41 openqa-piworker systemd[1]: Started WPA Supplicant daemon. Jul 28 12:47:45 openqa-piworker hostapd[15307]: wlan0: Could not connect to kernel driver Jul 28 12:47:45 openqa-piworker hostapd[15307]: Using interface wlan0 with hwaddr e4:5f:01:bb:63:41 and ssid "openQA-worker" Jul 28 12:47:45 openqa-piworker kernel: IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready Jul 28 12:47:45 openqa-piworker kernel: br0: port 1(wlan0) entered blocking state Jul 28 12:47:45 openqa-piworker kernel: br0: port 1(wlan0) entered forwarding state Jul 28 12:47:45 openqa-piworker hostapd[15307]: wlan0: interface state COUNTRY_UPDATE->ENABLED Jul 28 12:47:45 openqa-piworker hostapd[15307]: wlan0: AP-ENABLED openqa-piworker:~ # cat /etc/sysconfig/network/ifcfg-br0 IPADDR='192.168.7.1/24' BOOTPROTO='static' STARTMODE='auto' BRIDGE='yes' BRIDGE_PORTS='' BRIDGE_STP='off' BRIDGE_FORWARDDELAY='15' ZONE=dmz openqa-piworker:~ # cat /etc/hostapd.conf interface=wlan0 bridge=br0 ssid=openQA-worker wpa_passphrase=0foobar12345 driver=nl80211 country_code=DE hw_mode=g channel=7 # Bit field: bit0 = WPA, bit1 = WPA2, 3=both wpa=2 # Bit field: 1=wpa, 2=wep, 3=both auth_algs=1 wpa_pairwise=CCMP wpa_key_mgmt=WPA-PSK logger_stdout=-1 logger_stdout_level=2 openqa-piworker:~ # systemctl cat hostapd.service # /usr/lib/systemd/system/hostapd.service [Unit] Description=Hostapd IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator After=network.target [Service] ExecStart=/usr/sbin/hostapd /etc/hostapd.conf ExecReload=/bin/kill -HUP $MAINPID [Install] WantedBy=multi-user.target # /etc/systemd/system/hostapd.service.d/override.conf # Ensure that wlan0 is up before starting hostapd (otherwise hostapd will not add wlan0 to the bridge) [Unit] BindsTo=sys-subsystem-net-devices-wlan0.device After=sys-subsystem-net-devices-wlan0.device -- You are receiving this mail because: You are the assignee for the bug.

1 32

[Bug 1214049] New: USB audio dies after idle
by bugzilla_noreply＠suse.com 30 Jan '24

30 Jan '24

https://bugzilla.suse.com/show_bug.cgi?id=1214049 Bug ID: 1214049 Summary: USB audio dies after idle Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other OS: openSUSE Leap 15.4 Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: aaron.w2(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 868666 --> https://bugzilla.suse.com/attachment.cgi?id=868666&action=edit lsusb -v output After a recent kernel update within the past week or so I have been experiencing a problem where if audio is stopped for a while it will never restart when using a USB HID audio device. In the logs I see the following: usb_set_interface failed (-19) I have swapped the cable and that made no difference. Note that if audio is constantly active it will continue to work without issues. [33346.442012] usb 7-4: New USB device found, idVendor=1852, idProduct=7022, bcdDevice= 0.01 [33346.442023] usb 7-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [33346.442027] usb 7-4: Product: DigiHug USB Audio [33346.442031] usb 7-4: Manufacturer: GFEC ASSP [33346.529561] input: GFEC ASSP DigiHug USB Audio as /devices/pci0000:40/0000:40:07.1/0000:45:00.3/usb7/7-4/7-4:1.0/0003:1852:7022.001B/input/input54 [33346.586066] hid-generic 0003:1852:7022.001B: input,hidraw11: USB HID v1.00 Device [GFEC ASSP DigiHug USB Audio] on usb-0000:45:00.3-4/input0 [33360.314128] usb 3-1.3.1: reset high-speed USB device number 36 using xhci_hcd Note that the audio recovers if I unplug and reconnect the audio device. It does not matter which application is generating the audio. The USB audio device is also plugged directly into a motherboard USB port and not a hub. Desktop is running KDE factory. Kernel is 5.14.21-150400.24.74-default #1 SMP PREEMPT_DYNAMIC I have a lot of USB devices connected. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1216799] New: Bluetooth headphones disconnect from USB bluetooth dongle
by bugzilla_noreply＠suse.com 17 Jan '24

17 Jan '24

https://bugzilla.suse.com/show_bug.cgi?id=1216799 Bug ID: 1216799 Summary: Bluetooth headphones disconnect from USB bluetooth dongle Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: silviu_marin-caea(a)otpbank.ro QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- I have bluetooth headphones (Jabra Elite 65t) and bluetooth dongle (Asus USB-BT500). They work at first but when the dongle goes into USB powersave, the headphones get disconnected and don't reconnect properly unless I reinsert the dongle. When it's all good, the headphones appear as High Fidelity Playback A2DP Sink, codec AAC. hwinfo --bluetooth 05: USB 00.1: 11500 Bluetooth Device [Created at usb.122] Unique ID: XN68.bg_nBq8ya6A Parent ID: KgLP.erpEvbsFWX1 SysFS ID: /devices/pci0000:00/0000:00:13.0/usb9/9-4/9-4:1.1 SysFS BusID: 9-4:1.1 Hardware Class: bluetooth Model: "ASUSTek ASUS USB-BT500" Hotplug: USB Vendor: usb 0x0b05 "ASUSTek Computer, Inc." Device: usb 0x190e "ASUS USB-BT500" Revision: "2.00" Serial ID: "00E04C239987" Driver: "btusb" Driver Modules: "btusb" Speed: 12 Mbps Module Alias: "usb:v0B05p190Ed0200dcE0dsc01dp01icE0isc01ip01in01" Driver Info #0: Driver Status: btusb is active Driver Activation Cmd: "modprobe btusb" Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #14 (Hub) dmesg | grep Bluetooth [ 6.357471] Bluetooth: Core ver 2.22 [ 6.357495] Bluetooth: HCI device and connection manager initialized [ 6.357499] Bluetooth: HCI socket layer initialized [ 6.357502] Bluetooth: L2CAP socket layer initialized [ 6.357506] Bluetooth: SCO socket layer initialized [ 6.413147] Bluetooth: hci0: RTL: examining hci_ver=0a hci_rev=000b lmp_ver=0a lmp_subver=8761 [ 6.415122] Bluetooth: hci0: RTL: rom_version status=0 version=1 [ 6.415126] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_fw.bin [ 6.439520] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_config.bin [ 6.444090] Bluetooth: hci0: RTL: cfg_sz 6, total sz 30210 [ 6.715122] Bluetooth: hci0: RTL: fw version 0xdfc6d922 [ 6.841248] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 6.841252] Bluetooth: BNEP filters: protocol multicast [ 6.841257] Bluetooth: BNEP socket layer initialized [ 6.843260] Bluetooth: MGMT ver 1.22 [ 50.972325] Bluetooth: RFCOMM TTY layer initialized [ 50.972333] Bluetooth: RFCOMM socket layer initialized [ 50.972338] Bluetooth: RFCOMM ver 1.11 ... [ 54.394435] input: Jabra Elite 65t (AVRCP) as /devices/virtual/input/input19 I see this in dmesg when it reconnects and it works: [ 486.890067] usb 9-4: USB disconnect, device number 2 [ 487.114036] usb 9-4: new full-speed USB device number 3 using ohci-pci [ 487.351164] usb 9-4: New USB device found, idVendor=0b05, idProduct=190e, bcdDevice= 2.00 [ 487.351171] usb 9-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 487.351173] usb 9-4: Product: ASUS USB-BT500 [ 487.351175] usb 9-4: Manufacturer: Realtek [ 487.351177] usb 9-4: SerialNumber: 00E04C239987 [ 487.358124] Bluetooth: hci1: RTL: examining hci_ver=0a hci_rev=dfc6 lmp_ver=0a lmp_subver=d922 [ 487.568138] Bluetooth: hci1: RTL: examining hci_ver=0a hci_rev=000b lmp_ver=0a lmp_subver=8761 [ 487.570174] Bluetooth: hci1: RTL: rom_version status=0 version=1 [ 487.570177] Bluetooth: hci1: RTL: loading rtl_bt/rtl8761bu_fw.bin [ 487.572606] Bluetooth: hci1: RTL: loading rtl_bt/rtl8761bu_config.bin [ 487.572715] Bluetooth: hci1: RTL: cfg_sz 6, total sz 30210 [ 487.842193] Bluetooth: hci1: RTL: fw version 0xdfc6d922 [ 487.944392] Bluetooth: MGMT ver 1.22 [ 493.763658] input: Jabra Elite 65t (AVRCP) as /devices/virtual/input/input20 And many of these when it disconnects and doesn't work anymore: [ 852.621709] usb 9-4: reset full-speed USB device number 3 using ohci-pci [ 856.465806] usb 9-4: reset full-speed USB device number 3 using ohci-pci [ 859.097858] usb 9-4: reset full-speed USB device number 3 using ohci-pci Then this: [ 923.675107] Bluetooth: hci1: command 0x0428 tx timeout [ 963.676107] Bluetooth: hci1: killing stalled connection 70:bf:92:6b:13:31 [ 965.176409] Bluetooth: hci1: link tx timeout [ 965.176429] Bluetooth: hci1: killing stalled connection 70:bf:92:6b:13:31 [ 965.692007] Bluetooth: hci1: command 0x041f tx timeout [ 967.712098] Bluetooth: hci1: command 0x0406 tx timeout [ 968.516073] usb 9-4: reset full-speed USB device number 3 using ohci-pci [ 969.698590] Bluetooth: hci1: link tx timeout [ 969.698605] Bluetooth: hci1: killing stalled connection 70:bf:92:6b:13:31 [ 971.512214] usb 9-4: reset full-speed USB device number 3 using ohci-pci [ 974.560260] usb 9-4: reset full-speed USB device number 3 using ohci-pci ... [ 1080.406158] Bluetooth: hci1: killing stalled connection 70:bf:92:6b:13:31 [ 1082.334436] Bluetooth: hci1: command 0x0408 tx timeout [ 1082.334458] Bluetooth: hci1: No gpio to reset Realtek device, ignoring [ 1084.350582] Bluetooth: hci1: command 0x0408 tx timeout [ 1084.350603] Bluetooth: hci1: No gpio to reset Realtek device, ignoring -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 1212139] New: [amdgpu]] *ERROR* ring sdma0 timeout
by bugzilla_noreply＠suse.com 24 Dec '23

24 Dec '23

https://bugzilla.suse.com/show_bug.cgi?id=1212139 Bug ID: 1212139 Summary: [amdgpu]] *ERROR* ring sdma0 timeout 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: monkeyboyted(a)yahoo.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 867453 --> https://bugzilla.suse.com/attachment.cgi?id=867453&action=edit dmesg-mohamed-mehany-steps-reproduce Linux steamdeck.lan 6.4.0-rc5-1.g2cab33e-default #1 SMP PREEMPT_DYNAMIC Sun Jun 4 20:15:10 UTC 2023 (2cab33e) x86_64 x86_64 x86_64 GNU/Linux Step to reproduce. ``` sudo -i echo "low" > /sys/class/drm/card1/device/power_dpm_force_performance_level exit sudo cat /sys/kernel/debug/dri/1/amdgpu_gpu_recover ``` LSB Version: n/a Distributor ID: openSUSE Description: openSUSE Tumbleweed Release: 20230605 Codename: n/a Information for package plasma5-mobile: --------------------------------------- Repository : openSUSE-Tumbleweed-Oss Name : plasma5-mobile Version : 5.27.5-1.1 Arch : x86_64 Vendor : openSUSE Installed Size : 2.3 MiB Installed : Yes Status : out-of-date (version 5.27.4-1.1 installed) Source package : plasma5-mobile-5.27.5-1.1.src Upstream URL : http://www.kde.org/ Summary : Plasma Mobile Description : Plasma shell and components targeted for phones. https://gitlab.freedesktop.org/drm/amd/-/issues/2220#note_1948249 -- You are receiving this mail because: You are the assignee for the bug.

1 12

[Bug 1217344] New: Linux 6.6.1 fails to boot
by bugzilla_noreply＠suse.com 16 Dec '23

16 Dec '23

https://bugzilla.suse.com/show_bug.cgi?id=1217344 Bug ID: 1217344 Summary: Linux 6.6.1 fails to boot Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Critical Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: neronio(a)outlook.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- The default 6.6.1 kernel installed on my Tumbleweed system does not boot. Upon selecting it in GRUB, I see: "Loading Linux 6.6.1-1-default ..." "Loading initial ramdisk ..." and the system hangs on this screen forever. My workstation's diagnostic LEDs turn on in a pattern that, according to the service manual, indicates an "other type of failure". The workstation is a Dell T5600. CPU: 2x Intel Xeon E5-2680 (v1) RAM: 8x 8 GB DDR3 1600 MHz GPU: Nvidia NVS510, I'm using nouveau drivers. My kernel cmdline: root=UUID=5136bb35-acaa-4796-b463-8c9ef307025d splash=silent quiet mitigations=auto The latest default 6.5.9 kernel works fine on this machine. I'm available for all kinds of testing/debugging, including kernel recompilation with experimental patches and the like. -- You are receiving this mail because: You are the assignee for the bug.

1 12

[Bug 1213830] New: rather current notebook hw (from 2021) has no deep sleep /sys/power/mem_sleep - desktop hw and really old hw does have it
by bugzilla_noreply＠suse.com 15 Dec '23

15 Dec '23

https://bugzilla.suse.com/show_bug.cgi?id=1213830 Bug ID: 1213830 Summary: rather current notebook hw (from 2021) has no deep sleep /sys/power/mem_sleep - desktop hw and really old hw does have it Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: x86-64 OS: openSUSE Leap 15.5 Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: abittner(a)opensuse.org QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Hello Opensuse Kernel team, how come that my rather new notebook hardware (hp probook with amd apu, from 2021) does not sleep properly and eats up the battery all the time. barely any difference between when leaving an idle desktop (KDE) sitting around and blanking the screen and when only s2idle sleeping it (lid close, or kde function: sleep) i have tried to make sense of all of this, also reading about the linux folks over at framework-laptop e.g. <https://community.frame.work/t/responded-linux-deep-sleep/2491> all i can find is the value: cat /sys/power/mem_sleep [s2idle] cat /sys/power/state freeze mem disk also added the kernel boot parameter mem_sleep_default=deep command line via yast2 to grub2 or something: ---------- sudo dmesg -e | grep mem_sleep [ +0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.14.21-150500.55.7-default root=/dev/mapper/system-root splash=silent resume=/dev/system/swap preempt=full quiet security=apparmor mem_sleep_default=deep mitigations=auto [ +0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.14.21-150500.55.7-default root=/dev/mapper/system-root splash=silent resume=/dev/system/swap preempt=full quiet security=apparmor mem_sleep_default=deep mitigations=auto --------------- to sum it up, the system eats away the battery/power at high rates even when sleeping, lid closed etc. how to make this work on leap 15.5 with proper (deep?) memory sleep states and all? is this maybe incompatible with FDE, secureboot? this kernel lockdown stuff? i am not understanding much of this i guess. i am wondering why a really old system and other also older desktop systems just instantly show deep mem_sleep feature activated and working? this system: UEFI ans secureboot system [ +0.109168] smpboot: CPU0: AMD Ryzen 7 5800U with Radeon Graphics (family: 0x19, model: 0x50, stepping: 0x0) full disk encryption on single nvme drive thanks for helping. -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 1212839] New: LTP test cve-2021-22555 setsockopt08.c fails with ENOENT
by bugzilla_noreply＠suse.com 12 Dec '23

12 Dec '23

https://bugzilla.suse.com/show_bug.cgi?id=1212839 Bug ID: 1212839 Summary: LTP test cve-2021-22555 setsockopt08.c fails with ENOENT 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: petr.vorel(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- LTP test cve-2021-22555 setsockopt08.c fails with ENOENT [1], but it expects EINVAL on mostly all archs on Tumbleweed (all but s390x, i.e. aarch64, ppc64le, x86_64 and x86_64 compiled as 32bit). The test has been failing for very long time (our history goes to 6.3.2 20230517, but it's failing on my VM with 6.2.12-1-default 20230502). When test run more times (200x with -i200 [3]) it fails only on first time, the rest happily have EINVAL. And indeed, when verifying manually on VM, only first run fails dmesg on affected archs contains: [ 1514.789118][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 [ 1514.792200][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 [ 1514.795209][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 [ 1514.798209][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 [ 1514.801190][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 [ 1514.804092][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 [ 1514.807159][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 [ 1514.810210][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 [ 1514.813257][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 [ 1514.816227][T28992] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 But when running manually I see on first (failing): [ 208.455124] bpfilter: Loaded bpfilter_umh pid 1223 [ 208.456650] Started bpfilter (this is also in openQA jobs, but earlier, triggered by setsockopt03.c, which runs earlier). And x_tables run is reported on later (successful run): [ 221.292549] x_tables: ip_tables: state.0 match: invalid size 8 (kernel) != (user) 776 => Maybe there is a problem with loading x_tables on these 3 archs Interestingly x_tables is loaded on all archs, including s390x (which does not fail) and the same dmesg [4] FYI we stop and disable firewall in openQA install_ltp job (this qcow is then used for LTP tests) [5]: systemctl --no-pager disable firewalld Removed "/etc/systemd/system/multi-user.target.wants/firewalld.service". Removed "/etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service". systemctl --no-pager stop firewalld [1] https://openqa.opensuse.org/tests/3390125#step/setsockopt08/7 [2] https://github.com/linux-test-project/ltp/blob/a564d3e1672e9cd7ac302d597ffa… [3] https://openqa.opensuse.org/tests/3391862#step/cve-2021-22555/7 [4] https://openqa.opensuse.org/tests/3380876/file/shutdown_ltp-dmesg.txt [5] https://openqa.opensuse.org/tests/3391842/file/serial_terminal.txt -- You are receiving this mail because: You are the assignee for the bug.

1 11

[Bug 1217512] New: [RPi4] kernel: vc4_hdmi fef00700.hdmi: Could not register PCM component: -517
by bugzilla_noreply＠suse.com 11 Dec '23

11 Dec '23

https://bugzilla.suse.com/show_bug.cgi?id=1217512 Bug ID: 1217512 Summary: [RPi4] kernel: vc4_hdmi fef00700.hdmi: Could not register PCM component: -517 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: aarch64 URL: https://openqa.opensuse.org/tests/3760808/modules/jour nal_check/steps/11 OS: Other Status: NEW Severity: Normal 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: ivan.ivanov(a)suse.com Target Milestone: --- Found By: openQA Blocker: Yes ## Observation openQA test in scenario opensuse-Tumbleweed-JeOS-for-RPi-aarch64-jeos@RPi4 fails in [journal_check](https://openqa.opensuse.org/tests/3760808/modules/journal_ch… On Raspberry Pi 4, with latest updates, we now have the following kernel trace in journal: kernel: vc4_hdmi fef00700.hdmi: Could not register PCM component: -517 Related updates: raspberrypi-firmware (2023.04.25 -> 2023.11.21) raspberrypi-firmware-config (2023.04.25 -> 2023.11.21) raspberrypi-firmware-dt (2023.05.02 -> 2023.11.21) ## Test suite description Maintainer: fvogt, mnowak Start JeOS from the HDD image, configure it using the firstboot wizard and then run basic tests. console=tty0 added as needed for aarch64. ## Reproducible Fails since (at least) Build [20231123](https://openqa.opensuse.org/tests/3754946) ## Expected result Last good: [20231122](https://openqa.opensuse.org/tests/3750512) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=aarch64&distri=opensu… -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 1216841] New: [ build 28.1] openQA test fails in fanotify16 (LTP)
by bugzilla_noreply＠suse.com 05 Dec '23

05 Dec '23

https://bugzilla.suse.com/show_bug.cgi?id=1216841 Bug ID: 1216841 Summary: [ build 28.1] openQA test fails in fanotify16 (LTP) Classification: SUSE Linux Enterprise Server Product: SUSE Linux Enterprise Server 15 SP6 Version: unspecified Hardware: x86-64 URL: https://openqa.opensuse.org/tests/2353240/modules/fano tify16/steps/7 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)suse.de Reporter: wegao(a)suse.com CC: guillaume.gardet(a)arm.com, kernel-bugs(a)opensuse.org, petr.vorel(a)gmail.com, qa-bugs(a)suse.de Depends on: 1199618 Target Milestone: --- Group: SUSE Enterprise Partner Found By: openQA Blocker: Yes I clone issue to 15sp6 since i found this issue not exist on Tumbleweed now, but still exist on latest result for 15sp6, see following openqa job, i suppose some fix need backport to sle15sp6. https://openqa.suse.de/tests/12752058#step/fanotify16/7 +++ This bug was initially created as a clone of Bug #1199618 +++ ## Observation openQA test in scenario opensuse-Tumbleweed-JeOS-for-AArch64-aarch64-jeos-ltp-syscalls@aarch64-HD24G fails in [fanotify16](https://openqa.opensuse.org/tests/2353240/modules/fanotify16/st… Error log: fanotify.h:336: TBROK: fanotify_mark (3, FAN_MARK_ADD, ..., AT_FDCWD, ".") failed: EXDEV (18) Test process returned unkown none zero value (2). Test took approximately 0.581575272008195 seconds Some test output could not be parsed: 9 lines were ignored. ## Test suite description ## Reproducible Fails since (at least) Build [20220302](https://openqa.opensuse.org/tests/2224057) ## Expected result Last good: (unknown) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=aarch64&distri=opensu… -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Bug 1196438] Consider switching to 300HZ default
by bugzilla_noreply＠suse.com 30 Nov '23

30 Nov '23

https://bugzilla.suse.com/show_bug.cgi?id=1196438 https://bugzilla.suse.com/show_bug.cgi?id=1196438#c19 --- Comment #19 from Dirk Mueller <dmueller(a)suse.com> --- (In reply to Yousaf Kaukab from comment #17) > So for SLE the consensus is to keep CONFIG_HZ=250. I assume you mean SLE15 here? I think the discussion should be open ended with SLE16. > Cyril recommended to keep CONFIG_HZ=250 citing the bug fixed by commit c7fcb99877f9 and Mel > recommended to keep SLE and ALP aligned which implies CONFIG_HZ=250 for ALP > as well. I'm sorry, but that means there can be no progress of anything anywhere ever. But the matter of fact is that we are improving the config continuously based on feedback. > So I agree we should revert the change. Objections? Well, what about the original suggestion to use a value that is evenly divisible for the user space metrics? I checked again, and RHEL9/10 is going with 100 HZ. So if your concern is that the number of tick interrupts is causing performance issues, why not go to the *same* value across all architectures, and pick a value that is evenly divisible by 100 (the userspace HZ)? Like 100? (or 300, for that matter) I picked 300 because it was closest to the original 250 which I thought is the least concern overall. There were no conclusive benchmarks showing it would be a problem. Why can we not run with that to see partner and customer feedback prior release? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1196438] Consider switching to 300HZ default
by bugzilla_noreply＠suse.com 30 Nov '23

30 Nov '23

https://bugzilla.suse.com/show_bug.cgi?id=1196438 https://bugzilla.suse.com/show_bug.cgi?id=1196438#c18 --- Comment #18 from Jiri Slaby <jslaby(a)suse.com> --- (In reply to Yousaf Kaukab from comment #17) > Objections? Just setting a timeout: If not, let me revert TW to 250 after 8th Dec (next Fri). -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1196438] Consider switching to 300HZ default
by bugzilla_noreply＠suse.com 29 Nov '23

29 Nov '23

https://bugzilla.suse.com/show_bug.cgi?id=1196438 https://bugzilla.suse.com/show_bug.cgi?id=1196438#c17 --- Comment #17 from Yousaf Kaukab <yousaf.kaukab(a)suse.com> --- (In reply to Jiri Slaby from comment #11) > So at last, neither ALP nor Leap will adopt 300. So I think we should switch > the TW back to 250 to be consistent with all our other distros. So for SLE the consensus is to keep CONFIG_HZ=250. Cyril recommended to keep CONFIG_HZ=250 citing the bug fixed by commit c7fcb99877f9 and Mel recommended to keep SLE and ALP aligned which implies CONFIG_HZ=250 for ALP as well. So I agree we should revert the change. Objections? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1196438] Consider switching to 300HZ default
by bugzilla_noreply＠suse.com 29 Nov '23

29 Nov '23

https://bugzilla.suse.com/show_bug.cgi?id=1196438 https://bugzilla.suse.com/show_bug.cgi?id=1196438#c16 Yousaf Kaukab <yousaf.kaukab(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |yousaf.kaukab(a)suse.com --- Comment #16 from Yousaf Kaukab <yousaf.kaukab(a)suse.com> --- For the for the sake of completeness I am adding response from Takashi in <87jzt4g3s6.wl-tiwai(a)suse.de> to the internal kernel ML: On 9/5/23 15:15, Takashi Iwai wrote: > FYI, the switch to HZ=300 was done on TW via bsc#1196438. > There were no major performance degrade, but yes, there can be hidden > corner cases like that, so switching HZ is likely no-go for SLE. But > the question is about ALP. If we rather want to be conservative, > HZ=250 can be used as well. OTOH, there are inconsistent HZ values > among all archs on SLE, and that's another point to consider. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1217512] [RPi4] kernel: vc4_hdmi fef00700.hdmi: Could not register PCM component: -517
by bugzilla_noreply＠suse.com 28 Nov '23

28 Nov '23

https://bugzilla.suse.com/show_bug.cgi?id=1217512 https://bugzilla.suse.com/show_bug.cgi?id=1217512#c7 --- Comment #7 from Ivan Ivanov <ivan.ivanov(a)suse.com> --- Yes, as suspected update of raspberrypi-firmware-dt makes thing break. I will have to take closer look why this is happening... -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1217512] [RPi4] kernel: vc4_hdmi fef00700.hdmi: Could not register PCM component: -517
by bugzilla_noreply＠suse.com 28 Nov '23

28 Nov '23

https://bugzilla.suse.com/show_bug.cgi?id=1217512 https://bugzilla.suse.com/show_bug.cgi?id=1217512#c6 --- Comment #6 from Patrik Jakobsson <patrik.jakobsson(a)suse.com> --- We don't see any issues in the nightly IGT tests so this is likely a firmware or DT issue. Can someone test by rolling back the DT but not the firmware and config packages? That way we can isolate the problem further. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1211117] New: 50-check-kernel-build-id fails to extract vmlinux
by bugzilla_noreply＠suse.com 27 Nov '23

27 Nov '23

https://bugzilla.suse.com/show_bug.cgi?id=1211117 Bug ID: 1211117 Summary: 50-check-kernel-build-id fails to extract vmlinux Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: S/390-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: msuchanek(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- When looking at build log from random stable kernel build I get this: [17308s] ... running 50-check-kernel-build-id [17309s] ... Verifying kernel build-ids for kernel-default 6.3.1-1.gdd8cfff s390x [17309s] ... Processing kernel rpms in '//home/abuild/rpmbuild/RPMS/s390x' [17909s] ... Unable to extract ./usr/lib/modules/6.3.1-1.gdd8cfff-default/vmlinux.xz from //home/abuild/rpmbuild/RPMS/s390x/kernel-default-debuginfo-6.3.1-1.1.gdd8cfff.s390x.rpm [17910s] Giving up vmlinux.xz is in kernel-default, not kernel-default-debuginfo. Either the message is misleading or the script is looking in the wrong place. -- You are receiving this mail because: You are the assignee for the bug.

1 2