kernel stack trace at boot ...

Xwang · 2025-01-12 12:14:19

Kernel Linux D9330 6.12.9-arch1-1 #1 SMP PREEMPT_DYNAMIC Fri, 10 Jan 2025 00:39:41 +0000 x86_64 GNU/Linux raises the following stack trace:

[    9.866291] ------------[ cut here ]------------
[    9.866300] WARNING: CPU: 11 PID: 139 at drivers/usb/typec/ucsi/ucsi.c:1361 ucsi_reset_ppm+0x1b4/0x1c0 [typec_ucsi]
[    9.866326] Modules linked in: fat mei_vsc spi_pxa2xx_core 8250_dw hid_multitouch spi_ljca pps_core i2c_ljca gpio_ljca snd_ctl_led mei_hdcp mei_pxp intel_rapl_msr dell_wmi processor_thermal_wt_hint iwlwifi btbcm crypto_simd dell_smbios spi_nor snd_timer dell_wmi_sysman i2c_i801 btmtk processor_thermal_rfim dcdbas cryptd rapl intel_cstate intel_uncore pcspkr psmouse dell_wmi_ddv joydev mousedev dell_smm_hwmon firmware_attributes_class mc dell_wmi_descriptor wmi_bmof mtd usb_ljca snd i2c_smbus ucsi_acpi processor_thermal_rapl bluetooth cfg80211 soundcore i2c_mux intel_lpss_pci intel_rapl_common typec_ucsi mei_me thunderbolt processor_thermal_wt_req intel_lpss typec intel_ish_ipc mei intel_ipu6 rfkill processor_thermal_power_floor intel_ishtp idma64 roles processor_thermal_mbox ipu_bridge igen6_edac intel_skl_int3472_tps68470 tps68470_regulator int3403_thermal i2c_hid_acpi mei_vsc_hw clk_tps68470 i2c_hid soc_button_array intel_pmc_core int340x_thermal_zone intel_vsec int3400_thermal pmt_telemetry intel_hid
[    9.866450]  intel_skl_int3472_discrete acpi_thermal_rel acpi_tad sparse_keymap pmt_class intel_skl_int3472_common pinctrl_tigerlake acpi_pad mac_hid vboxnetflt(OE) vboxnetadp(OE) vboxdrv(OE) i2c_dev sg crypto_user loop dm_mod nfnetlink ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 xe drm_ttm_helper gpu_sched drm_suballoc_helper drm_gpuvm drm_exec hid_generic usbhid uas usb_storage i915 serio_raw atkbd libps2 nvme vivaldi_fmap i2c_algo_bit drm_buddy ttm nvme_core intel_gtt video spi_intel_pci drm_display_helper crc32c_intel i8042 spi_intel nvme_auth cec wmi serio
[    9.866555] CPU: 11 UID: 0 PID: 139 Comm: kworker/11:1 Tainted: G           OE      6.12.9-arch1-1 #1 4fef9133193e91ac7130a5fb3d3ffb90eed417ef
[    9.866566] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
[    9.866569] Hardware name: Dell Inc. Latitude 9330/0RN079, BIOS 1.25.0 11/12/2024
[    9.866574] Workqueue: events_long ucsi_init_work [typec_ucsi]
[    9.866588] RIP: 0010:ucsi_reset_ppm+0x1b4/0x1c0 [typec_ucsi]
[    9.866598] Code: 8b 44 24 04 a9 00 00 00 08 0f 85 36 ff ff ff 4c 89 74 24 10 48 8b 05 cb be 7f d8 49 39 c5 79 8f bb 92 ff ff ff e9 1b ff ff ff <0f> 0b e9 50 ff ff ff e8 b0 e0 6a d7 90 90 90 90 90 90 90 90 90 90
[    9.866602] RSP: 0018:ffffb43a4079fda8 EFLAGS: 00010206
[    9.866608] RAX: 0000000008000000 RBX: 0000000000000000 RCX: 0000000000000002
[    9.866611] RDX: 00000000fffeabe6 RSI: ffffb43a4079fdac RDI: ffff88a348a95800
[    9.866615] RBP: ffff88a348a95800 R08: 0000000000000002 R09: 0000000000000014
[    9.866618] R10: 0000000000000001 R11: 0000000000000000 R12: ffffb43a4079fdac
[    9.866621] R13: 00000000fffeabe1 R14: ffff88a348a95860 R15: ffff88a348a958c0
[    9.866624] FS:  0000000000000000(0000) GS:ffff88a6bf980000(0000) knlGS:0000000000000000
[    9.866629] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    9.866632] CR2: 00006409eb03a8e0 CR3: 0000000414422000 CR4: 0000000000f50ef0
[    9.866636] PKRU: 55555554
[    9.866639] Call Trace:
[    9.866644]  <TASK>
[    9.866648]  ? ucsi_reset_ppm+0x1b4/0x1c0 [typec_ucsi fa9d3d79c1eb678ba1cdfcc4e7cff7dd0906c7b8]
[    9.866658]  ? __warn.cold+0x93/0xf6
[    9.866668]  ? ucsi_reset_ppm+0x1b4/0x1c0 [typec_ucsi fa9d3d79c1eb678ba1cdfcc4e7cff7dd0906c7b8]
[    9.866681]  ? report_bug+0xff/0x140
[    9.866691]  ? handle_bug+0x58/0x90
[    9.866699]  ? exc_invalid_op+0x17/0x70
[    9.866705]  ? asm_exc_invalid_op+0x1a/0x20
[    9.866713]  ? ucsi_reset_ppm+0x1b4/0x1c0 [typec_ucsi fa9d3d79c1eb678ba1cdfcc4e7cff7dd0906c7b8]
[    9.866722]  ? ucsi_reset_ppm+0xc6/0x1c0 [typec_ucsi fa9d3d79c1eb678ba1cdfcc4e7cff7dd0906c7b8]
[    9.866732]  ucsi_init_work+0x3c/0xac0 [typec_ucsi fa9d3d79c1eb678ba1cdfcc4e7cff7dd0906c7b8]
[    9.866743]  process_one_work+0x17b/0x330
[    9.866754]  worker_thread+0x2ce/0x3f0
[    9.866761]  ? __pfx_worker_thread+0x10/0x10
[    9.866768]  kthread+0xcf/0x100
[    9.866777]  ? __pfx_kthread+0x10/0x10
[    9.866785]  ret_from_fork+0x31/0x50
[    9.866792]  ? __pfx_kthread+0x10/0x10
[    9.866800]  ret_from_fork_asm+0x1a/0x30
[    9.866810]  </TASK>
[    9.866812] ---[ end trace 0000000000000000 ]---
****

Apparently the system works correctly.
What it is about?

Last edited by Xwang (2025-01-12 21:06:07)

cryptearth · 2025-01-12 14:42:16

at drivers/usb/typec

have you anything plugged in during boot? what is it? have you tried to boot without anything plugged in?

seth · 2025-01-12 15:01:30

https://bbs.archlinux.org/viewtopic.php?id=296367 but you don't have an nvidia GPU (or the module loaded), please don't post isolated stack traces since they provide no hint about the causing device (but most likely this is the controller and nothing is attached there at all)

Xwang · 2025-01-12 15:20:38

This is th lsub output:

lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 002: ID 05e3:0626 Genesys Logic, Inc. Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 0a5c:5843 Broadcom Corp. BCM58200 ControlVault 3 (FingerPrint sensor + Contacted SmartCard)
Bus 003 Device 003: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 003 Device 004: ID 8086:0b63 Intel Corp. USB Bridge
Bus 003 Device 005: ID 12d1:0010 Huawei Technologies Co., Ltd. KT USB Audio
Bus 003 Device 006: ID 8087:0033 Intel Corp. AX211 Bluetooth
Bus 003 Device 007: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 003 Device 008: ID 1bcf:08a0 Sunplus Innovation Technology Inc. Gaming mouse [Philips SPK9304]
Bus 003 Device 009: ID 046d:c31c Logitech, Inc. Keyboard K120
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 002: ID 0bc2:ab65 Seagate RSS LLC One Touch HDD

I have one usb hdd connected to one of the usb-c port and and an usb-c hub with hdmi connected to the other.

The usb-c hub has the pd power connected, and usb audio and the hdmi and usb connected to a kvm which has also an usb2 hub

The kernel stack trace is random (I've restarted the pc and I got no error)

seth · 2025-01-12 15:55:38

The kernel stack trace is random (I've restarted the pc and I got no error)

You can access logs of previous boots, eg.

sudo journalctl -b -1 | curl -F 'file=@-' 0x0.st

will post the previous ("-1") to 0x0.st

Xwang · 2025-01-12 16:40:33

https://0x0.st/8-k-.txt

seth · 2025-01-12 19:42:00

There's a lot of

gen 12 12:43:08 D9330 kernel: intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff
gen 12 12:43:08 D9330 kernel: intel-ipu6 0000:00:05.0: FW version: 20230925

Does your webcam still work if you hit those errors?

My money would however rather be on the ljca device, https://www.phoronix.com/news/Intel-La- … dapter-6.7

gen 12 12:42:57 D9330 kernel: usbcore: registered new interface driver ljca

Can you reliably make the errors go away by blacklisting ljca ?

Xwang · 2025-01-12 19:49:15

seth wrote:

There's a lot of
gen 12 12:43:08 D9330 kernel: intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff
gen 12 12:43:08 D9330 kernel: intel-ipu6 0000:00:05.0: FW version: 20230925
Does your webcam still work if you hit those errors?
My money would however rather be on the ljca device, https://www.phoronix.com/news/Intel-La- … dapter-6.7
gen 12 12:42:57 D9330 kernel: usbcore: registered new interface driver ljca
Can you reliably make the errors go away by blacklisting ljca ?

Thank you for your help.
The webcam has never worked on this laptop (and indeed I do not know if it is due to that message).

I've tried blacklisting using this command line:

cat /proc/cmdline 
initrd=\initramfs-linux.img root=UUID=01483a66-835b-4168-bd0e-c113ca954669 rw module_blacklist=usb_ljca

and now lsmod | grep ljca still returns an empty list.

This is the dmesg with the module blacklisted:

http://0x0.st/8-ne.txt

Being the problem a random one, I'll have to try with this option to see if it doesn't appear anymore.

Blacklisting the module makes the webcam completely not recognized (with module not blacklisted instead the sensor is recognized, a lot of video devices are created, but no webcam is available)

Last edited by Xwang (2025-01-12 20:24:05)

seth · 2025-01-12 20:27:25

lsmod | grep ucsi

Still loaded?

IPU6:
https://bbs.archlinux.org/viewtopic.php?id=297262
https://bbs.archlinux.org/viewtopic.php?id=277462
https://bbs.archlinux.org/viewtopic.php?id=302079
https://wiki.archlinux.org/title/Dell_L … 440#Webcam tl;dr - probably still takes a while

Xwang · 2025-01-12 20:47:31

seth wrote:

lsmod | grep ucsi
Still loaded?
IPU6:
https://bbs.archlinux.org/viewtopic.php?id=297262
https://bbs.archlinux.org/viewtopic.php?id=277462
https://bbs.archlinux.org/viewtopic.php?id=302079
https://wiki.archlinux.org/title/Dell_L … 440#Webcam tl;dr - probably still takes a while

Yes, the ucsi is still loaded even with the blacklisted module.
And I agree with you that webcam will require still some time before working out of the box (indeed some of my posts in the first of the links you have quoted).

EDIT

Now I got another stack trace even with the blacklisted module:
http://0x0.st/8-5c.txt

Last edited by Xwang (2025-01-12 21:18:59)

xerxes_ · 2025-01-12 21:39:41

Blacklist typec_ucsi module?

Xwang · 2025-01-12 21:48:29

xerxes_ wrote:

Blacklist typec_ucsi module?

If I do that will my usb-c ports keep working? I need them for power delivery, hdmi out and any usb since I only have usb-c ports on this pc

Last edited by Xwang (2025-01-12 21:48:56)

seth · 2025-01-12 21:55:56

No. We don't want to blacklist that - just see what device is causing the warning (which doesn't really cause any harm as of now)

Blacklist intel_skl_int3472_discrete and intel-ipu6 instead - the latter is your disfunctional cam, the former some power controller for that.
Both act up in the journal, idk. whether either actually uses ucsi, but hey - we'll see

loqs · 2025-01-12 22:03:04

seth wrote:

Both act up in the journal, idk. whether either actually uses ucsi, but hey - we'll see

If that fails see if `lsmod` lists any module as being Used by the typec_ucsi module.

Xwang · 2025-01-12 22:05:13

Thank to all of you.
I'll try tomorrow evening as soon as I'll be back from work.

Xwang · 2025-01-13 18:35:47

I tried backlisting also the two intel modules and I immediately got the stack trace again:

http://0x0.st/8oi5.txt

lsmod | grep typec_ucsi rports:

typec_ucsi             77824  1 ucsi_acpi
typec                 110592  2 typec_displayport,typec_ucsi
roles                  16384  1 typec_ucsi

Xwang · 2025-01-13 19:19:11

Is it this kernel bug related to mine?
https://bugzilla.kernel.org/show_bug.cgi?id=219590

seth · 2025-01-13 20:53:29

typec_ucsi is only used by ucsi_acpi, so you'd want to check what uses the latter (or post the entire lsmod output)

And yes, the kernel bug looks very related - similar hardware (no GPU, intel TGL)

Xwang · 2025-01-13 21:06:22

seth wrote:

typec_ucsi is only used by ucsi_acpi, so you'd want to check what uses the latter (or post the entire lsmod output)
And yes, the kernel bug looks very related - similar hardware (no GPU, intel TGL)

Nothing is using the ucsi_acpi (lsmod | grep ucsi_aspi returns nothing).

My doubt is that the issue is related to 6.13, but I have the issue on 6.12.9 should I open a new bug on the linux kernel?

seth · 2025-01-13 21:16:13

lsmod | grep ucsi_aspi returns nothing

That's not very surprising, but the grep for "ucsi_acpi" cannot be empty since it has shown up before as typec_ucsi consumer.

The upstream bug only suggests that the problem (still) exists in 6.13-rc2, not that it doesn't exist in any 6.12 kernels.

Xwang · 2025-01-13 21:19:00

seth wrote:

lsmod | grep ucsi_aspi returns nothing
That's not very surprising, but the grep for "ucsi_acpi" cannot be empty since it has shown up before as typec_ucsi consumer.
The upstream bug only suggests that the problem (still) exists in 6.13-rc2, not that it doesn't exist in any 6.12 kernels.

you are right, I mistyped the commad but still it seems not be used:

lsmod | grep ucsi_acpi

ucsi_acpi              12288  0
typec_ucsi             77824  1 ucsi_acpi

loqs · 2025-01-13 21:25:54

Is the issue still present in the latest upstream release candidate?

sudo pacman -U https://pkgbuild.com/\~gromit/linux-bisection-kernels/linux-mainline-6.13rc7-1-x86_64.pkg.tar.zst

Xwang · 2025-01-13 22:48:58

loqs wrote:

Is the issue still present in the latest upstream release candidate?
sudo pacman -U https://pkgbuild.com/\~gromit/linux-bisection-kernels/linux-mainline-6.13rc7-1-x86_64.pkg.tar.zst

It seems that the issue is not present with that

ReDress · 2025-01-14 12:00:43

seth wrote:

https://bbs.archlinux.org/viewtopic.php?id=296367 but you don't have an nvidia GPU (or the module loaded), please don't post isolated stack traces since they provide no hint about the causing device (but most likely this is the controller and nothing is attached there at all)

In fact, most of the time stack trace is barely ever enough unless already quite familiar with the subsystem.

There are probably hundreds of stack traces at https://syzkaller.appspot.com/upstream which noone has fixed because having a stack trace isn't a golden ticket to a bug.

Last edited by ReDress (2025-01-14 12:04:20)

Arch Linux

#1 2025-01-12 12:14:19

kernel stack trace at boot ...

#2 2025-01-12 14:42:16

Re: kernel stack trace at boot ...

#3 2025-01-12 15:01:30

Re: kernel stack trace at boot ...

#4 2025-01-12 15:20:38

Re: kernel stack trace at boot ...

#5 2025-01-12 15:55:38

Re: kernel stack trace at boot ...

#6 2025-01-12 16:40:33

Re: kernel stack trace at boot ...

#7 2025-01-12 19:42:00

Re: kernel stack trace at boot ...

#8 2025-01-12 19:49:15

Re: kernel stack trace at boot ...

#9 2025-01-12 20:27:25

Re: kernel stack trace at boot ...

#10 2025-01-12 20:47:31

Re: kernel stack trace at boot ...

#11 2025-01-12 21:39:41

Re: kernel stack trace at boot ...

#12 2025-01-12 21:48:29

Re: kernel stack trace at boot ...

#13 2025-01-12 21:55:56

Re: kernel stack trace at boot ...

#14 2025-01-12 22:03:04

Re: kernel stack trace at boot ...

#15 2025-01-12 22:05:13

Re: kernel stack trace at boot ...

#16 2025-01-13 18:35:47

Re: kernel stack trace at boot ...

#17 2025-01-13 19:19:11

Re: kernel stack trace at boot ...

#18 2025-01-13 20:53:29

Re: kernel stack trace at boot ...

#19 2025-01-13 21:06:22

Re: kernel stack trace at boot ...

#20 2025-01-13 21:16:13

Re: kernel stack trace at boot ...

#21 2025-01-13 21:19:00

Re: kernel stack trace at boot ...

#22 2025-01-13 21:25:54

Re: kernel stack trace at boot ...

#23 2025-01-13 22:48:58

Re: kernel stack trace at boot ...

#24 2025-01-14 12:00:43

Re: kernel stack trace at boot ...

Board footer