November 2022 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[Bug 1191244] New: USB speaker working when plugged while system is up but not on reboot
by bugzilla_noreply＠suse.com 19 Dec '22

19 Dec '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1191244 Bug ID: 1191244 Summary: USB speaker working when plugged while system is up but not on reboot Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: aarch64 OS: openSUSE Leap 15.3 Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: peter.stark(a)storck.net QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I have multiple raspberry PI 4Bs with openSUSE Leap 15.3 and some with raspbian 9. I got a USB speaker (e2b7:0811) which I connected to the 4Bs using Leap 15.3. This speaker works fine when I plug it in when the PI is already running: rpi15:~ # uname -a Linux rpi15 5.3.18-59.24-default #1 SMP Mon Sep 13 15:06:42 UTC 2021 (2f872ea) aarch64 aarch64 aarch64 GNU/Linux rpi15:~ # lsusb Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 005: ID 03eb:2013 Atmel Corp. iAQ Stick Bus 001 Device 007: ID e2b7:0811 Jie Li CD002 Bus 001 Device 003: ID 044f:b351 ThrustMaster, Inc. F16 MFD 1 Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub rpi15:~ # dmesg -T|grep 1-1.2 [Sa Okt 2 10:56:09 2021] usb 1-1.2: USB disconnect, device number 4 [Sa Okt 2 10:56:17 2021] usb 1-1.2: new full-speed USB device number 6 using xhci_hcd [Sa Okt 2 10:56:17 2021] usb 1-1.2: device descriptor read/64, error -32 [Sa Okt 2 10:56:17 2021] usb 1-1.2: device descriptor read/64, error -32 [Sa Okt 2 10:56:17 2021] usb 1-1.2: new full-speed USB device number 7 using xhci_hcd [Sa Okt 2 10:56:17 2021] usb 1-1.2: config 1 has an invalid interface number: 3 but max is 2 [Sa Okt 2 10:56:17 2021] usb 1-1.2: config 1 has no interface number 0 [Sa Okt 2 10:56:17 2021] usb 1-1.2: New USB device found, idVendor=e2b7, idProduct=0811, bcdDevice= 1.00 [Sa Okt 2 10:56:17 2021] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=1 [Sa Okt 2 10:56:17 2021] usb 1-1.2: Product: CD002 [Sa Okt 2 10:56:17 2021] usb 1-1.2: Manufacturer: CD002 [Sa Okt 2 10:56:17 2021] usb 1-1.2: SerialNumber: CD002 [Sa Okt 2 10:56:17 2021] usb 1-1.2: 9:1: bogus dB values (-12800/-12700), disabling dB reporting [Sa Okt 2 10:56:17 2021] input: CD002 CD002 as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2:1.3/0003:E2B7:0811.0003/input/input1 However, after a reboot with the device still connected (no change) the kernel boots and does not even see the device. rpi15:~ # lsusb Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 004: ID 03eb:2013 Atmel Corp. iAQ Stick Bus 001 Device 003: ID 044f:b351 ThrustMaster, Inc. F16 MFD 1 Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub rpi15:~ # dmesg -T|grep 1-1.2 rpi15:~ # I have tried the same USB speaker on another PI4B with Leap 15.3 with the same result. So, it doesn't seem to be that PI. When I connect the speaker to a PI3 with raspbian 9, it works as expected. root@rpi13:~# dmesg -T |grep 1-1.3 [Sa Okt 2 10:33:08 2021] usb 1-1.3: new full-speed USB device number 4 using dwc_otg [Sa Okt 2 10:33:08 2021] usb 1-1.3: config 1 has an invalid interface number: 3 but max is 2 [Sa Okt 2 10:33:08 2021] usb 1-1.3: config 1 has no interface number 0 [Sa Okt 2 10:33:08 2021] usb 1-1.3: New USB device found, idVendor=e2b7, idProduct=0811 [Sa Okt 2 10:33:08 2021] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=1 [Sa Okt 2 10:33:08 2021] usb 1-1.3: Product: CD002 [Sa Okt 2 10:33:08 2021] usb 1-1.3: Manufacturer: CD002 [Sa Okt 2 10:33:08 2021] usb 1-1.3: SerialNumber: CD002 [Sa Okt 2 10:33:08 2021] input: CD002 CD002 as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.3/0003:E2B7:0811.0001/input/input0 [Sa Okt 2 10:42:57 2021] usb 1-1.3: reset full-speed USB device number 4 using dwc_otg [Sa Okt 2 10:42:58 2021] usb 1-1.3: USB disconnect, device number 4 [Sa Okt 2 10:42:58 2021] usb 1-1.3: 9:1: cannot get min/max values for control 2 (id 9) [Sa Okt 2 10:43:04 2021] usb 1-1.3: new full-speed USB device number 6 using dwc_otg [Sa Okt 2 10:43:04 2021] usb 1-1.3: device descriptor read/64, error -32 [Sa Okt 2 10:43:04 2021] usb 1-1.3: config 1 has an invalid interface number: 3 but max is 2 [Sa Okt 2 10:43:04 2021] usb 1-1.3: config 1 has no interface number 0 [Sa Okt 2 10:43:04 2021] usb 1-1.3: New USB device found, idVendor=e2b7, idProduct=0811 [Sa Okt 2 10:43:04 2021] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=1 [Sa Okt 2 10:43:04 2021] usb 1-1.3: Product: CD002 [Sa Okt 2 10:43:04 2021] usb 1-1.3: Manufacturer: CD002 [Sa Okt 2 10:43:04 2021] usb 1-1.3: SerialNumber: CD002 [Sa Okt 2 10:43:04 2021] input: CD002 CD002 as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.3/0003:E2B7:0811.0002/input/input1 I noticed that the raspbian uses dwc_otg vs. xhci_hcd on Leap. However, dwc_otg doesn't seem to be a separate module in raspbian nor it is available on leap. As the speaker is working when I un-plug and plug it in again, I wonder what may causes this strange behavior. Especially as I do not see the device via lsusb after reboot, though it is still connected. Any ideas on how to fix it? -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1201963] New: 11th Gen Intel(R) Core(TM) i5-1145G7 throttling to 400MHz from 70°C until it reaches 54°C
by bugzilla_noreply＠suse.com 16 Dec '22

16 Dec '22

https://bugzilla.suse.com/show_bug.cgi?id=1201963 Bug ID: 1201963 Summary: 11th Gen Intel(R) Core(TM) i5-1145G7 throttling to 400MHz from 70�C until it reaches 54�C 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: gryffus(a)hkfree.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 860458 --> https://bugzilla.suse.com/attachment.cgi?id=860458&action=edit Turbostat log output I have a Dell Latitude 5420 laptop and i am experiencing CPU slowdown when using any graphical / CPU demanding application. The laptop contains 11th Gen Intel(R) Core(TM) i5-1145G7 which can do 4,4GHz on turbo. When the system reaches about 70�C, all cores switch to 400MHz and stay there until temperature hits 53-54�C. I can see this behavior especially in Vulkan graphics applications, but not only in them, it just happens almost instantly there, since the 70�C is reached within about 30 seconds there. I would want to raise the temperature limits to at least 80-90�C or disable throttling completely (at my own responsibility of cooking it). But throttling from 70�C seems as a complete nonsense to me - the CPU package gets to this temperature in 10-20 seconds under load, so i basically never make use of the 4,4GHz. What i have tried: 1) Kernel 5.19 from Kernel:HEAD - no change 2) installed throttled ( https://github.com/erpalma/throttled ) - no change 3) blacklisted intel_powerclamp, intel_rapl_msr, processor_thermal_rapl, intel_rapl_common kernel modules - no change 4) cpupower frequency-set -g performance - no change # cat /sys/devices/platform/*/uuids/current_uuid INVALID # cat /sys/devices/platform/*/uuids/available_uuids UNKNOWN # cpupower frequency-info analyzing CPU 0: driver: intel_pstate CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: Cannot determine or is not supported. hardware limits: 400 MHz - 4.40 GHz available cpufreq governors: performance powersave current policy: frequency should be within 400 MHz and 4.40 GHz. The governor "performance" may decide which speed to use within this range. current CPU frequency: Unable to call hardware current CPU frequency: 3.16 GHz (asserted by call to kernel) boost state support: Supported: yes Active: yes # cpupower idle-info CPUidle driver: intel_idle CPUidle governor: menu analyzing CPU 0: Number of idle states: 4 Available idle states: POLL C1_ACPI C2_ACPI C3_ACPI POLL: Flags/Description: CPUIDLE CORE POLL IDLE Latency: 0 Usage: 265266 Duration: 8068126 C1_ACPI: Flags/Description: ACPI FFH MWAIT 0x0 Latency: 1 Usage: 10617293 Duration: 1984558460 C2_ACPI: Flags/Description: ACPI FFH MWAIT 0x31 Latency: 253 Usage: 273458 Duration: 261649941 C3_ACPI: Flags/Description: ACPI FFH MWAIT 0x60 Latency: 1048 Usage: 206150 Duration: 509227956 # cpupower info analyzing CPU 0: perf-bias: 0 Turbostat debug log attached. Some further reading with probably related reports: https://www.dell.com/community/Latitude/Latitude-5420-7420-7520-CPU-Throttl… https://github.com/intel/thermal_daemon/issues/341 https://github.com/intel/thermal_daemon/issues/293 https://github.com/erpalma/throttled Any clues? -- You are receiving this mail because: You are the assignee for the bug.

1 7

[Bug 1205149] New: %kernel_module_package_buildreqs needs to require suse-kernel-rpm-scriptlets
by bugzilla_noreply＠suse.com 14 Dec '22

14 Dec '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1205149 Bug ID: 1205149 Summary: %kernel_module_package_buildreqs needs to require suse-kernel-rpm-scriptlets 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: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- kernel rpm scriptlets will be moved to a separate subpackage (see https://github.com/openSUSE/suse-module-tools/pull/64). kmps do already (pre)require suse-kernel-rpm-scriptlets just fine. However during build those prerequires are not seen by the OBS schedule as they are hidden inside the %suse_kernel_module_package macro. So the package install check after build fails due to missing scriptlets. Therefore %kernel_module_package_buildreqs needs to list suse-kernel-rpm-scriptlets -- You are receiving this mail because: You are the assignee for the bug.

1 5

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

09 Dec '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 27

[Bug 1203519] New: floating shutdown problem on pinebook pro
by bugzilla_noreply＠suse.com 08 Dec '22

08 Dec '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1203519 Bug ID: 1203519 Summary: floating shutdown problem on pinebook pro Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: werwolf131313(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- intermittent shutdown problem on pinebook pro, the problem is expressed as follows: after the laptop is turned off (it doesn��t matter by the button in the menu or via sudo systemctl shutdown), a regular shutdown occurs, the service stop log is visible and everything is as it should be, BUT, after the screen goes blank, the board remains on. this can be checked if you try to turn it on, pressing the button does not work. only a long press of the power key (to completely turn off) for 7-10 seconds, and a second press (to turn it on) allows you to turn on the pinebook. the problem is not observed in other distributions (tried on manjaro, armbian, gentoo) and is specific to opensuse. in my case, the installation differs from the typical one in that the operating system is installed on a microsd card (due to the death of emmc), can this affect? but in other distributions, even installed on the same microsd card, the problem is not observed. I'm using opensuse tumbleweed installed from the openSUSE-Tumbleweed-ARM-KDE-pinebookpro.aarch64.raw.xz image. at the moment there are all the latest updates, but the problem has existed for quite a long time. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1193599] New: ntel_dp_detect [i915]] *ERROR* LSPCON init failed on port D
by bugzilla_noreply＠suse.com 07 Dec '22

07 Dec '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 33

[Bug 1205774] New: Kernel 6.0.8 + nvidia 525.53 crash on BUG: kernel NULL pointer dereference, #PF: supervisor instruction fetch in kernel mode
by bugzilla_noreply＠suse.com 07 Dec '22

07 Dec '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1205774 Bug ID: 1205774 Summary: Kernel 6.0.8 + nvidia 525.53 crash on BUG: kernel NULL pointer dereference, #PF: supervisor instruction fetch in kernel mode Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: bruno(a)ioda-net.ch QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 863125 --> http://bugzilla.opensuse.org/attachment.cgi?id=863125&action=edit Last kernel 6.0.8 boot and crash Hello I need help to find the root cause of crashes (complete freeze of the workstation). Since the introduction of kernel 6.0.8 and latest nvidia 525.53 I constantly face complete machine freeze, when I'm using my external monitors. nov 25 16:05:34 qt-kt kernel: BUG: kernel NULL pointer dereference, address: 0000000000000000 nov 25 16:05:34 qt-kt kernel: #PF: supervisor instruction fetch in kernel mode nov 25 16:05:34 qt-kt kernel: #PF: error_code(0x0010) - not-present page nov 25 16:05:34 qt-kt kernel: PGD 0 P4D 0 nov 25 16:05:34 qt-kt kernel: Oops: 0010 [#1] PREEMPT SMP PTI nov 25 16:05:34 qt-kt kernel: CPU: 3 PID: 1004 Comm: nvidia-modeset/ Tainted: P OE 6.0.8-1-default #1 openSUSE Tumbleweed 9d20364b934f5aab0a9bdf84e8f45cfdfae39dab nov 25 16:05:34 qt-kt kernel: Hardware name: Dell Inc. Precision 7510/0YH43H, BIOS 1.29.3 09/18/2022 nov 25 16:05:34 qt-kt kernel: RIP: 0010:0x0 nov 25 16:05:34 qt-kt kernel: Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. nov 25 16:05:34 qt-kt kernel: RSP: 0018:ffffadc300703c90 EFLAGS: 00010207 nov 25 16:05:34 qt-kt kernel: RAX: 0000000000000000 RBX: ffff9b2996c75378 RCX: 0000000000000004 nov 25 16:05:34 qt-kt kernel: RDX: 0000000000000010 RSI: ffff9b2996c75378 RDI: ffffadc300703a10 nov 25 16:05:34 qt-kt kernel: RBP: ffff9b292ef8b560 R08: 0000000000000000 R09: 0000000000000040 nov 25 16:05:34 qt-kt kernel: R10: ffff9b2886b28008 R11: ffffadc300703c00 R12: 0000000000000000 nov 25 16:05:34 qt-kt kernel: R13: 0000000000000000 R14: ffffffffc4fbee70 R15: ffffffffc4eb7580 nov 25 16:05:34 qt-kt kernel: FS: 0000000000000000(0000) GS:ffff9b37c44c0000(0000) knlGS:0000000000000000 nov 25 16:05:34 qt-kt kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 nov 25 16:05:34 qt-kt kernel: CR2: ffffffffffffffd6 CR3: 000000075be10001 CR4: 00000000003706e0 nov 25 16:05:34 qt-kt kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 nov 25 16:05:34 qt-kt kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 nov 25 16:05:34 qt-kt kernel: Call Trace: nov 25 16:05:34 qt-kt kernel: <TASK> nov 25 16:05:34 qt-kt kernel: _nv001281kms+0x194/0x1a0 [nvidia_modeset 4cdb9c16932eaf3d76d37eaaf2544a31bf3316d8] nov 25 16:05:34 qt-kt kernel: ? _nv001274kms+0x9a/0xd0 [nvidia_modeset 4cdb9c16932eaf3d76d37eaaf2544a31bf3316d8] nov 25 16:05:34 qt-kt kernel: ? _nv001466kms+0x172/0x180 [nvidia_modeset 4cdb9c16932eaf3d76d37eaaf2544a31bf3316d8] nov 25 16:05:34 qt-kt kernel: ? _nv001149kms+0xf3/0xa50 [nvidia_modeset 4cdb9c16932eaf3d76d37eaaf2544a31bf3316d8] nov 25 16:05:34 qt-kt kernel: ? schedule+0x5a/0xd0 nov 25 16:05:34 qt-kt kernel: ? schedule_timeout+0x10e/0x150 nov 25 16:05:34 qt-kt kernel: ? nvkms_sema_up+0x10/0x10 [nvidia_modeset 4cdb9c16932eaf3d76d37eaaf2544a31bf3316d8] nov 25 16:05:34 qt-kt kernel: ? __down_common+0x10b/0x1e0 nov 25 16:05:34 qt-kt kernel: ? nvkms_sema_up+0x10/0x10 [nvidia_modeset 4cdb9c16932eaf3d76d37eaaf2544a31bf3316d8] nov 25 16:05:34 qt-kt kernel: ? _nv002457kms+0x2d/0x70 [nvidia_modeset 4cdb9c16932eaf3d76d37eaaf2544a31bf3316d8] nov 25 16:05:34 qt-kt kernel: ? nvkms_kthread_q_callback+0x88/0xf0 [nvidia_modeset 4cdb9c16932eaf3d76d37eaaf2544a31bf3316d8] nov 25 16:05:34 qt-kt kernel: ? _main_loop+0x77/0x130 [nvidia_modeset 4cdb9c16932eaf3d76d37eaaf2544a31bf3316d8] nov 25 16:05:34 qt-kt kernel: ? kthread+0xd7/0x100 nov 25 16:05:34 qt-kt kernel: ? kthread_complete_and_exit+0x20/0x20 nov 25 16:05:34 qt-kt kernel: ? ret_from_fork+0x1f/0x30 nov 25 16:05:34 qt-kt kernel: </TASK> nov 25 16:05:34 qt-kt kernel: Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq nf_nat_sip nft_objref af_packet nf_conntrack_sip nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct n> nov 25 16:05:34 qt-kt kernel: processor_thermal_device_pci_legacy irqbypass iwlwifi processor_thermal_device pcspkr ledtrig_audio processor_thermal_rfim snd_usbmidi_lib efi_pstore snd_intel_sdw_acpi sparse_keymap processor_thermal_mbox cdc_wdm videob> nov 25 16:05:34 qt-kt kernel: fuse configfs dmi_sysfs ip_tables x_tables cmac algif_hash algif_skcipher af_alg hid_logitech_hidpp hid_logitech_dj hid_generic dm_crypt usbhid essiv authenc trusted asn1_encoder tee bnep btusb btrtl btbcm btintel btmtk > nov 25 16:05:34 qt-kt kernel: CR2: 0000000000000000 nov 25 16:05:34 qt-kt kernel: ---[ end trace 0000000000000000 ]--- Most of the time this happen after resuming the screens, the primary one get on, but the second is always in suspend mode, I have to open neither display settings in plasma or nvidia-settings to set on the second monitor (displayport slave link) after switching off and on the monitor. -- You are receiving this mail because: You are the assignee for the bug.

1 11

[Bug 1191933] New: Kernel can not update on Secure boot envirnment
by bugzilla_noreply＠suse.com 05 Dec '22

05 Dec '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1191933 Bug ID: 1191933 Summary: Kernel can not update on Secure boot envirnment 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: kokeko(a)mac.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Current 20211012, update to 20211016 or 20211019. Kernel-default update failed by fallowing error. subprocess error, secure boot enabled. Is it something change? -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1200781] New: xhci stop working. Works briefly after reboot, or remove and load xhci_pci & xhci_hcd.
by bugzilla_noreply＠suse.com 30 Nov '22

30 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1200781 Bug ID: 1200781 Summary: xhci stop working. Works briefly after reboot, or remove and load xhci_pci & xhci_hcd. Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: x86-64 OS: openSUSE Leap 15.4 Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: publio.escipion.el.africano(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- openSuSE Leap 15.4 x86_64, kernel 4.14.21-150400.22-default, in a Lenovo IdeaPad 3 15ADA05: https://psref.lenovo.com/syspool/Sys/PDF/IdeaPad/IdeaPad_3_15ADA05/IdeaPad_… An external mouse stops working after a brief period of time, after login into KDE, or after removing and loading xhci_pci & xhci_hcd. System complaints of: �xhci_hcd 0000:02:00.3 WARNIGN: Host System Error� and: �usb 2-3: device not accepting address 2, error -108� I've tried two bluetooth mice, and a standard cord mouse. The same result. It seems that it's the USB controllers are the only components affected, so far. Mousepad works properly, but I'm not use to it. I have to constantly remove and load xhci_pci & xhci_hcd, as root. rmmod xhci_pci rmmod xhci_hcd modprobe xhci_pci modprobe xhci_hcd Mouse works after that for a short time. Nota bene: Devices work properly under openSuSE Leap 15.2 x86_64, kernel 5.3.18-lp152.106-default (old HP Pavillion). This bug resembles https://bugzilla.opensuse.org/show_bug.cgi?id=1193652 -- You are receiving this mail because: You are the assignee for the bug.

1 17

[Bug 1205597] ltp:pty03:slcan: null-ptr-deref in process_one_work
by bugzilla_noreply＠suse.com 30 Nov '22

30 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1205597 https://bugzilla.suse.com/show_bug.cgi?id=1205597#c6 --- Comment #6 from Petr Vorel <petr.vorel(a)suse.com> --- @Jiri: running for many times (~ 50) none of runs on kernel with fix from you [4] failed. But running ~ 20 times on original unfixed openSUSE kernel [5] it failed 6 times (some of the failed tests are visible on [5]). I guess you can send your patch :). Or do you want me to test patch, where flush_work(&sl->tx_work) call is removed from slcan_netdev_close() or it will stay here? -- You are receiving this mail because: You are the assignee for the bug.

1 0