[PATCH 0/5] staging: vchiq_arm: Fix & improve resource handling

[PATCH 0/5] staging: vchiq_arm: Fix & improve resource handling

[Stefan Wahren]

VCHIQ driver probe und remove have some resource release issues regarding
kthread and debugfs handling.

Stefan Wahren (5):
  staging: vchiq_arm: Register debugfs after cdev
  staging: vchiq_arm: Fix possible NPR of keep-alive thread
  staging: vchiq_arm: Stop kthreads if vchiq cdev register fails
  staging: vchiq_arm: Create keep-alive thread during probe
  staging: vchiq_arm: Improve initial VCHIQ connect

 .../interface/vchiq_arm/vchiq_arm.c           | 121 +++++++++---------
 .../interface/vchiq_arm/vchiq_core.c          |   1 +
 .../interface/vchiq_arm/vchiq_core.h          |   2 +
 3 files changed, 60 insertions(+), 64 deletions(-)

--
2.34.1

[PATCH 1/5] staging: vchiq_arm: Register debugfs after cdev

[Stefan Wahren]

The commit 2a4d15a4ae98 ("staging: vchiq: Refactor vchiq cdev code")
moved the debugfs directory creation before vchiq character device
registration. In case the latter fails, the debugfs directory won't
be cleaned up.

Fixes: 2a4d15a4ae98 ("staging: vchiq: Refactor vchiq cdev code")
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index a4e83e5d619b..e2e80e90b555 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -1386,8 +1386,6 @@ static int vchiq_probe(struct platform_device *pdev)
 		return ret;
 	}

-	vchiq_debugfs_init(&mgmt->state);
-
 	dev_dbg(&pdev->dev, "arm: platform initialised - version %d (min %d)\n",
 		VCHIQ_VERSION, VCHIQ_VERSION_MIN);

@@ -1401,6 +1399,8 @@ static int vchiq_probe(struct platform_device *pdev)
 		return ret;
 	}

+	vchiq_debugfs_init(&mgmt->state);
+
 	bcm2835_audio = vchiq_device_register(&pdev->dev, "bcm2835-audio");
 	bcm2835_camera = vchiq_device_register(&pdev->dev, "bcm2835-camera");

--
2.34.1

[PATCH 2/5] staging: vchiq_arm: Fix possible NPR of keep-alive thread

[Stefan Wahren]

In case vchiq_platform_conn_state_changed() is never called or fails before
driver removal, ka_thread won't be a valid pointer to a task_struct. So
do the necessary checks before calling kthread_stop to avoid a crash.

Fixes: 863a756aaf49 ("staging: vc04_services: vchiq_core: Stop kthreads on vchiq module unload")
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index e2e80e90b555..d3b7d1227d7d 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -1422,7 +1422,8 @@ static void vchiq_remove(struct platform_device *pdev)
 	kthread_stop(mgmt->state.slot_handler_thread);

 	arm_state = vchiq_platform_get_arm_state(&mgmt->state);
-	kthread_stop(arm_state->ka_thread);
+	if (!IS_ERR_OR_NULL(arm_state->ka_thread))
+		kthread_stop(arm_state->ka_thread);
 }

 static struct platform_driver vchiq_driver = {
--
2.34.1

[PATCH 3/5] staging: vchiq_arm: Stop kthreads if vchiq cdev register fails

[Stefan Wahren]

In case the vchiq character device cannot be registered during probe,
all kthreads needs to be stopped to avoid resource leaks.

Fixes: 863a756aaf49 ("staging: vc04_services: vchiq_core: Stop kthreads on vchiq module unload")
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
---
 .../interface/vchiq_arm/vchiq_arm.c           | 25 ++++++++++++-------
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index d3b7d1227d7d..0c7ea2d0ee85 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -308,6 +308,20 @@ static struct vchiq_arm_state *vchiq_platform_get_arm_state(struct vchiq_state *
 	return (struct vchiq_arm_state *)state->platform_state;
 }

+static void
+vchiq_platform_uninit(struct vchiq_drv_mgmt *mgmt)
+{
+	struct vchiq_arm_state *arm_state;
+
+	kthread_stop(mgmt->state.sync_thread);
+	kthread_stop(mgmt->state.recycle_thread);
+	kthread_stop(mgmt->state.slot_handler_thread);
+
+	arm_state = vchiq_platform_get_arm_state(&mgmt->state);
+	if (!IS_ERR_OR_NULL(arm_state->ka_thread))
+		kthread_stop(arm_state->ka_thread);
+}
+
 void vchiq_dump_platform_state(struct seq_file *f)
 {
 	seq_puts(f, "  Platform: 2835 (VC master)\n");
@@ -1396,6 +1410,7 @@ static int vchiq_probe(struct platform_device *pdev)
 	ret = vchiq_register_chrdev(&pdev->dev);
 	if (ret) {
 		dev_err(&pdev->dev, "arm: Failed to initialize vchiq cdev\n");
+		vchiq_platform_uninit(mgmt);
 		return ret;
 	}

@@ -1410,20 +1425,12 @@ static int vchiq_probe(struct platform_device *pdev)
 static void vchiq_remove(struct platform_device *pdev)
 {
 	struct vchiq_drv_mgmt *mgmt = dev_get_drvdata(&pdev->dev);
-	struct vchiq_arm_state *arm_state;

 	vchiq_device_unregister(bcm2835_audio);
 	vchiq_device_unregister(bcm2835_camera);
 	vchiq_debugfs_deinit();
 	vchiq_deregister_chrdev();
-
-	kthread_stop(mgmt->state.sync_thread);
-	kthread_stop(mgmt->state.recycle_thread);
-	kthread_stop(mgmt->state.slot_handler_thread);
-
-	arm_state = vchiq_platform_get_arm_state(&mgmt->state);
-	if (!IS_ERR_OR_NULL(arm_state->ka_thread))
-		kthread_stop(arm_state->ka_thread);
+	vchiq_platform_uninit(mgmt);
 }

 static struct platform_driver vchiq_driver = {
--
2.34.1

[PATCH 4/5] staging: vchiq_arm: Create keep-alive thread during probe

[Stefan Wahren]

Creating the keep-alive thread in vchiq_platform_init_state have
the following advantages:
- abort driver probe if kthread_create fails (more consistent behavior)
- make resource release process easier

Since vchiq_keepalive_thread_func is defined below
vchiq_platform_init_state, the latter must be moved.

Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
---
 .../interface/vchiq_arm/vchiq_arm.c           | 69 +++++++++----------
 1 file changed, 34 insertions(+), 35 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index 0c7ea2d0ee85..64f9536f1232 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -280,29 +280,6 @@ static int vchiq_platform_init(struct platform_device *pdev, struct vchiq_state
 	return 0;
 }

-int
-vchiq_platform_init_state(struct vchiq_state *state)
-{
-	struct vchiq_arm_state *platform_state;
-
-	platform_state = devm_kzalloc(state->dev, sizeof(*platform_state), GFP_KERNEL);
-	if (!platform_state)
-		return -ENOMEM;
-
-	rwlock_init(&platform_state->susp_res_lock);
-
-	init_completion(&platform_state->ka_evt);
-	atomic_set(&platform_state->ka_use_count, 0);
-	atomic_set(&platform_state->ka_use_ack_count, 0);
-	atomic_set(&platform_state->ka_release_count, 0);
-
-	platform_state->state = state;
-
-	state->platform_state = (struct opaque_platform_state *)platform_state;
-
-	return 0;
-}
-
 static struct vchiq_arm_state *vchiq_platform_get_arm_state(struct vchiq_state *state)
 {
 	return (struct vchiq_arm_state *)state->platform_state;
@@ -1011,6 +988,39 @@ vchiq_keepalive_thread_func(void *v)
 	return 0;
 }

+int
+vchiq_platform_init_state(struct vchiq_state *state)
+{
+	struct vchiq_arm_state *platform_state;
+	char threadname[16];
+
+	platform_state = devm_kzalloc(state->dev, sizeof(*platform_state), GFP_KERNEL);
+	if (!platform_state)
+		return -ENOMEM;
+
+	snprintf(threadname, sizeof(threadname), "vchiq-keep/%d",
+		 state->id);
+	platform_state->ka_thread = kthread_create(&vchiq_keepalive_thread_func,
+						   (void *)state, threadname);
+	if (IS_ERR(platform_state->ka_thread)) {
+		dev_err(state->dev, "couldn't create thread %s\n", threadname);
+		return PTR_ERR(platform_state->ka_thread);
+	}
+
+	rwlock_init(&platform_state->susp_res_lock);
+
+	init_completion(&platform_state->ka_evt);
+	atomic_set(&platform_state->ka_use_count, 0);
+	atomic_set(&platform_state->ka_use_ack_count, 0);
+	atomic_set(&platform_state->ka_release_count, 0);
+
+	platform_state->state = state;
+
+	state->platform_state = (struct opaque_platform_state *)platform_state;
+
+	return 0;
+}
+
 int
 vchiq_use_internal(struct vchiq_state *state, struct vchiq_service *service,
 		   enum USE_TYPE_E use_type)
@@ -1331,7 +1341,6 @@ void vchiq_platform_conn_state_changed(struct vchiq_state *state,
 				       enum vchiq_connstate newstate)
 {
 	struct vchiq_arm_state *arm_state = vchiq_platform_get_arm_state(state);
-	char threadname[16];

 	dev_dbg(state->dev, "suspend: %d: %s->%s\n",
 		state->id, get_conn_state_name(oldstate), get_conn_state_name(newstate));
@@ -1346,17 +1355,7 @@ void vchiq_platform_conn_state_changed(struct vchiq_state *state,

 	arm_state->first_connect = 1;
 	write_unlock_bh(&arm_state->susp_res_lock);
-	snprintf(threadname, sizeof(threadname), "vchiq-keep/%d",
-		 state->id);
-	arm_state->ka_thread = kthread_create(&vchiq_keepalive_thread_func,
-					      (void *)state,
-					      threadname);
-	if (IS_ERR(arm_state->ka_thread)) {
-		dev_err(state->dev, "suspend: Couldn't create thread %s\n",
-			threadname);
-	} else {
-		wake_up_process(arm_state->ka_thread);
-	}
+	wake_up_process(arm_state->ka_thread);
 }

 static const struct of_device_id vchiq_of_match[] = {
--
2.34.1

[PATCH 5/5] staging: vchiq_arm: Improve initial VCHIQ connect

[Stefan Wahren]

The code to start the keep-alive thread on initial VCHIQ connect
within vchiq_platform_conn_state_changed is unnecessary complex.
Move the keep-alive thread wake-up into a separate function and call it
during VCHIQ connect.

Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
---
 .../interface/vchiq_arm/vchiq_arm.c           | 28 +++++--------------
 .../interface/vchiq_arm/vchiq_core.c          |  1 +
 .../interface/vchiq_arm/vchiq_core.h          |  2 ++
 3 files changed, 10 insertions(+), 21 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index 64f9536f1232..be0c2bf9561a 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -97,13 +97,6 @@ struct vchiq_arm_state {
 	 * tracked separately with the state.
 	 */
 	int peer_use_count;
-
-	/*
-	 * Flag to indicate that the first vchiq connect has made it through.
-	 * This means that both sides should be fully ready, and we should
-	 * be able to suspend after this point.
-	 */
-	int first_connect;
 };

 static int
@@ -1336,26 +1329,19 @@ vchiq_check_service(struct vchiq_service *service)
 	return ret;
 }

+void vchiq_platform_connected(struct vchiq_state *state)
+{
+	struct vchiq_arm_state *arm_state = vchiq_platform_get_arm_state(state);
+
+	wake_up_process(arm_state->ka_thread);
+}
+
 void vchiq_platform_conn_state_changed(struct vchiq_state *state,
 				       enum vchiq_connstate oldstate,
 				       enum vchiq_connstate newstate)
 {
-	struct vchiq_arm_state *arm_state = vchiq_platform_get_arm_state(state);
-
 	dev_dbg(state->dev, "suspend: %d: %s->%s\n",
 		state->id, get_conn_state_name(oldstate), get_conn_state_name(newstate));
-	if (state->conn_state != VCHIQ_CONNSTATE_CONNECTED)
-		return;
-
-	write_lock_bh(&arm_state->susp_res_lock);
-	if (arm_state->first_connect) {
-		write_unlock_bh(&arm_state->susp_res_lock);
-		return;
-	}
-
-	arm_state->first_connect = 1;
-	write_unlock_bh(&arm_state->susp_res_lock);
-	wake_up_process(arm_state->ka_thread);
 }

 static const struct of_device_id vchiq_of_match[] = {
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index 8d5795db4f39..5e38609aad06 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -3343,6 +3343,7 @@ vchiq_connect_internal(struct vchiq_state *state, struct vchiq_instance *instanc
 			return -EAGAIN;

 		vchiq_set_conn_state(state, VCHIQ_CONNSTATE_CONNECTED);
+		vchiq_platform_connected(state);
 		complete(&state->connect);
 	}

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h
index 9b4e766990a4..3b5c0618e567 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.h
@@ -575,6 +575,8 @@ int vchiq_send_remote_use(struct vchiq_state *state);

 int vchiq_send_remote_use_active(struct vchiq_state *state);

+void vchiq_platform_connected(struct vchiq_state *state);
+
 void vchiq_platform_conn_state_changed(struct vchiq_state *state,
 				       enum vchiq_connstate oldstate,
 				  enum vchiq_connstate newstate);
--
2.34.1

Re: [PATCH 4/5] staging: vchiq_arm: Create keep-alive thread during probe

[Maíra Canal]

Hi Stefan,

On 09/03/25 09:50, Stefan Wahren wrote:
> Creating the keep-alive thread in vchiq_platform_init_state have
> the following advantages:
> - abort driver probe if kthread_create fails (more consistent behavior)
> - make resource release process easier
> 
> Since vchiq_keepalive_thread_func is defined below
> vchiq_platform_init_state, the latter must be moved.
> 
> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
> ---
>   .../interface/vchiq_arm/vchiq_arm.c           | 69 +++++++++----------
>   1 file changed, 34 insertions(+), 35 deletions(-)
> 

After this patch landed on 6.12 stable, I started to observe the
following warning in Mesa CI [1]:

20:07:07.830: [  242.653532] INFO: task vchiq-keep/0:85 blocked for more 
than 120 seconds.
20:07:07.835: [  242.660404]       Not tainted 6.12.34-v8-+ #13
20:07:07.843: [  242.666173] "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
20:07:07.852: [  242.677126] task:vchiq-keep/0    state:D stack:0 
pid:85    tgid:85    ppid:2      flags:0x00000008
20:07:07.854: [  242.690734] Call trace:
20:07:07.857: [  242.693191]  __switch_to+0x188/0x230
20:07:07.858: [  242.697010]  __schedule+0xa54/0xb28
20:07:07.859: [  242.704889]  schedule+0x80/0x120
20:07:07.859: [  242.712581]  schedule_preempt_disabled+0x30/0x50
20:07:07.860: [  242.721437]  kthread+0xd4/0x1a0
20:07:07.861: [  242.724606]  ret_from_fork+0x10/0x20

If I revert this patch, I no longer get those warnings. From that, I was
wondering: is it possible that in some scenarios, we might never
actually get to the connected state and therefore, we wouldn't wake up
the kthread that we created when we initialized the state?

[1] https://gitlab.freedesktop.org/mairacanal/mesa/-/jobs/78940369

Best Regards,
- Maíra

> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> index 0c7ea2d0ee85..64f9536f1232 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> @@ -280,29 +280,6 @@ static int vchiq_platform_init(struct platform_device *pdev, struct vchiq_state
>   	return 0;
>   }
> 
> -int
> -vchiq_platform_init_state(struct vchiq_state *state)
> -{
> -	struct vchiq_arm_state *platform_state;
> -
> -	platform_state = devm_kzalloc(state->dev, sizeof(*platform_state), GFP_KERNEL);
> -	if (!platform_state)
> -		return -ENOMEM;
> -
> -	rwlock_init(&platform_state->susp_res_lock);
> -
> -	init_completion(&platform_state->ka_evt);
> -	atomic_set(&platform_state->ka_use_count, 0);
> -	atomic_set(&platform_state->ka_use_ack_count, 0);
> -	atomic_set(&platform_state->ka_release_count, 0);
> -
> -	platform_state->state = state;
> -
> -	state->platform_state = (struct opaque_platform_state *)platform_state;
> -
> -	return 0;
> -}
> -
>   static struct vchiq_arm_state *vchiq_platform_get_arm_state(struct vchiq_state *state)
>   {
>   	return (struct vchiq_arm_state *)state->platform_state;
> @@ -1011,6 +988,39 @@ vchiq_keepalive_thread_func(void *v)
>   	return 0;
>   }
> 
> +int
> +vchiq_platform_init_state(struct vchiq_state *state)
> +{
> +	struct vchiq_arm_state *platform_state;
> +	char threadname[16];
> +
> +	platform_state = devm_kzalloc(state->dev, sizeof(*platform_state), GFP_KERNEL);
> +	if (!platform_state)
> +		return -ENOMEM;
> +
> +	snprintf(threadname, sizeof(threadname), "vchiq-keep/%d",
> +		 state->id);
> +	platform_state->ka_thread = kthread_create(&vchiq_keepalive_thread_func,
> +						   (void *)state, threadname);
> +	if (IS_ERR(platform_state->ka_thread)) {
> +		dev_err(state->dev, "couldn't create thread %s\n", threadname);
> +		return PTR_ERR(platform_state->ka_thread);
> +	}
> +
> +	rwlock_init(&platform_state->susp_res_lock);
> +
> +	init_completion(&platform_state->ka_evt);
> +	atomic_set(&platform_state->ka_use_count, 0);
> +	atomic_set(&platform_state->ka_use_ack_count, 0);
> +	atomic_set(&platform_state->ka_release_count, 0);
> +
> +	platform_state->state = state;
> +
> +	state->platform_state = (struct opaque_platform_state *)platform_state;
> +
> +	return 0;
> +}
> +
>   int
>   vchiq_use_internal(struct vchiq_state *state, struct vchiq_service *service,
>   		   enum USE_TYPE_E use_type)
> @@ -1331,7 +1341,6 @@ void vchiq_platform_conn_state_changed(struct vchiq_state *state,
>   				       enum vchiq_connstate newstate)
>   {
>   	struct vchiq_arm_state *arm_state = vchiq_platform_get_arm_state(state);
> -	char threadname[16];
> 
>   	dev_dbg(state->dev, "suspend: %d: %s->%s\n",
>   		state->id, get_conn_state_name(oldstate), get_conn_state_name(newstate));
> @@ -1346,17 +1355,7 @@ void vchiq_platform_conn_state_changed(struct vchiq_state *state,
> 
>   	arm_state->first_connect = 1;
>   	write_unlock_bh(&arm_state->susp_res_lock);
> -	snprintf(threadname, sizeof(threadname), "vchiq-keep/%d",
> -		 state->id);
> -	arm_state->ka_thread = kthread_create(&vchiq_keepalive_thread_func,
> -					      (void *)state,
> -					      threadname);
> -	if (IS_ERR(arm_state->ka_thread)) {
> -		dev_err(state->dev, "suspend: Couldn't create thread %s\n",
> -			threadname);
> -	} else {
> -		wake_up_process(arm_state->ka_thread);
> -	}
> +	wake_up_process(arm_state->ka_thread);
>   }
> 
>   static const struct of_device_id vchiq_of_match[] = {
> --
> 2.34.1
> 
> 

Re: [PATCH 4/5] staging: vchiq_arm: Create keep-alive thread during probe

[Stefan Wahren]

Hi Maíra,

[add Arnd]

Am 26.06.25 um 20:22 schrieb Maíra Canal:
> Hi Stefan,
>
> On 09/03/25 09:50, Stefan Wahren wrote:
>> Creating the keep-alive thread in vchiq_platform_init_state have
>> the following advantages:
>> - abort driver probe if kthread_create fails (more consistent behavior)
>> - make resource release process easier
>>
>> Since vchiq_keepalive_thread_func is defined below
>> vchiq_platform_init_state, the latter must be moved.
>>
>> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
>> ---
>>   .../interface/vchiq_arm/vchiq_arm.c           | 69 +++++++++----------
>>   1 file changed, 34 insertions(+), 35 deletions(-)
>>
>
> After this patch landed on 6.12 stable, I started to observe the
> following warning in Mesa CI [1]:
Is this also reproducible with 6.15.x or mainline ?
>
> 20:07:07.830: [  242.653532] INFO: task vchiq-keep/0:85 blocked for 
> more than 120 seconds.
> 20:07:07.835: [  242.660404]       Not tainted 6.12.34-v8-+ #13
> 20:07:07.843: [  242.666173] "echo 0 > 
> /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> 20:07:07.852: [  242.677126] task:vchiq-keep/0    state:D stack:0 
> pid:85    tgid:85    ppid:2      flags:0x00000008
> 20:07:07.854: [  242.690734] Call trace:
> 20:07:07.857: [  242.693191]  __switch_to+0x188/0x230
> 20:07:07.858: [  242.697010]  __schedule+0xa54/0xb28
> 20:07:07.859: [  242.704889]  schedule+0x80/0x120
> 20:07:07.859: [  242.712581]  schedule_preempt_disabled+0x30/0x50
> 20:07:07.860: [  242.721437]  kthread+0xd4/0x1a0
> 20:07:07.861: [  242.724606]  ret_from_fork+0x10/0x20
>
> If I revert this patch, I no longer get those warnings. From that, I was
> wondering: is it possible that in some scenarios, we might never
> actually get to the connected state and therefore, we wouldn't wake up
> the kthread that we created when we initialized the state?
Sure we communicate to the VideoCore and there might be reasons the 
connection fail. I'm not aware that a missing wakeup cause a hanging task.

Best regards
>
> [1] https://gitlab.freedesktop.org/mairacanal/mesa/-/jobs/78940369
>
> Best Regards,
> - Maíra
>
>> diff --git 
>> a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c 
>> b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
>> index 0c7ea2d0ee85..64f9536f1232 100644
>> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
>> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
>> @@ -280,29 +280,6 @@ static int vchiq_platform_init(struct 
>> platform_device *pdev, struct vchiq_state
>>       return 0;
>>   }
>>
>> -int
>> -vchiq_platform_init_state(struct vchiq_state *state)
>> -{
>> -    struct vchiq_arm_state *platform_state;
>> -
>> -    platform_state = devm_kzalloc(state->dev, 
>> sizeof(*platform_state), GFP_KERNEL);
>> -    if (!platform_state)
>> -        return -ENOMEM;
>> -
>> -    rwlock_init(&platform_state->susp_res_lock);
>> -
>> -    init_completion(&platform_state->ka_evt);
>> -    atomic_set(&platform_state->ka_use_count, 0);
>> -    atomic_set(&platform_state->ka_use_ack_count, 0);
>> -    atomic_set(&platform_state->ka_release_count, 0);
>> -
>> -    platform_state->state = state;
>> -
>> -    state->platform_state = (struct opaque_platform_state 
>> *)platform_state;
>> -
>> -    return 0;
>> -}
>> -
>>   static struct vchiq_arm_state *vchiq_platform_get_arm_state(struct 
>> vchiq_state *state)
>>   {
>>       return (struct vchiq_arm_state *)state->platform_state;
>> @@ -1011,6 +988,39 @@ vchiq_keepalive_thread_func(void *v)
>>       return 0;
>>   }
>>
>> +int
>> +vchiq_platform_init_state(struct vchiq_state *state)
>> +{
>> +    struct vchiq_arm_state *platform_state;
>> +    char threadname[16];
>> +
>> +    platform_state = devm_kzalloc(state->dev, 
>> sizeof(*platform_state), GFP_KERNEL);
>> +    if (!platform_state)
>> +        return -ENOMEM;
>> +
>> +    snprintf(threadname, sizeof(threadname), "vchiq-keep/%d",
>> +         state->id);
>> +    platform_state->ka_thread = 
>> kthread_create(&vchiq_keepalive_thread_func,
>> +                           (void *)state, threadname);
>> +    if (IS_ERR(platform_state->ka_thread)) {
>> +        dev_err(state->dev, "couldn't create thread %s\n", threadname);
>> +        return PTR_ERR(platform_state->ka_thread);
>> +    }
>> +
>> +    rwlock_init(&platform_state->susp_res_lock);
>> +
>> +    init_completion(&platform_state->ka_evt);
>> +    atomic_set(&platform_state->ka_use_count, 0);
>> +    atomic_set(&platform_state->ka_use_ack_count, 0);
>> +    atomic_set(&platform_state->ka_release_count, 0);
>> +
>> +    platform_state->state = state;
>> +
>> +    state->platform_state = (struct opaque_platform_state 
>> *)platform_state;
>> +
>> +    return 0;
>> +}
>> +
>>   int
>>   vchiq_use_internal(struct vchiq_state *state, struct vchiq_service 
>> *service,
>>              enum USE_TYPE_E use_type)
>> @@ -1331,7 +1341,6 @@ void vchiq_platform_conn_state_changed(struct 
>> vchiq_state *state,
>>                          enum vchiq_connstate newstate)
>>   {
>>       struct vchiq_arm_state *arm_state = 
>> vchiq_platform_get_arm_state(state);
>> -    char threadname[16];
>>
>>       dev_dbg(state->dev, "suspend: %d: %s->%s\n",
>>           state->id, get_conn_state_name(oldstate), 
>> get_conn_state_name(newstate));
>> @@ -1346,17 +1355,7 @@ void vchiq_platform_conn_state_changed(struct 
>> vchiq_state *state,
>>
>>       arm_state->first_connect = 1;
>>       write_unlock_bh(&arm_state->susp_res_lock);
>> -    snprintf(threadname, sizeof(threadname), "vchiq-keep/%d",
>> -         state->id);
>> -    arm_state->ka_thread = kthread_create(&vchiq_keepalive_thread_func,
>> -                          (void *)state,
>> -                          threadname);
>> -    if (IS_ERR(arm_state->ka_thread)) {
>> -        dev_err(state->dev, "suspend: Couldn't create thread %s\n",
>> -            threadname);
>> -    } else {
>> -        wake_up_process(arm_state->ka_thread);
>> -    }
>> +    wake_up_process(arm_state->ka_thread);
>>   }
>>
>>   static const struct of_device_id vchiq_of_match[] = {
>> -- 
>> 2.34.1
>>
>>
>
>

Re: [PATCH 4/5] staging: vchiq_arm: Create keep-alive thread during probe

[Maíra Canal]

Hi Stefan,

On 26/06/25 17:14, Stefan Wahren wrote:
> Hi Maíra,
> 
> [add Arnd]
> 
> Am 26.06.25 um 20:22 schrieb Maíra Canal:
>> Hi Stefan,
>>
>> On 09/03/25 09:50, Stefan Wahren wrote:
>>> Creating the keep-alive thread in vchiq_platform_init_state have
>>> the following advantages:
>>> - abort driver probe if kthread_create fails (more consistent behavior)
>>> - make resource release process easier
>>>
>>> Since vchiq_keepalive_thread_func is defined below
>>> vchiq_platform_init_state, the latter must be moved.
>>>
>>> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
>>> ---
>>>   .../interface/vchiq_arm/vchiq_arm.c           | 69 +++++++++----------
>>>   1 file changed, 34 insertions(+), 35 deletions(-)
>>>
>>
>> After this patch landed on 6.12 stable, I started to observe the
>> following warning in Mesa CI [1]:
> Is this also reproducible with 6.15.x or mainline ?

I was able to reproduce it with 6.16.0-rc2 [2].

[2] https://gitlab.freedesktop.org/mairacanal/mesa/-/jobs/79092300

Best Regards,
- Maíra

>>
>> 20:07:07.830: [  242.653532] INFO: task vchiq-keep/0:85 blocked for 
>> more than 120 seconds.
>> 20:07:07.835: [  242.660404]       Not tainted 6.12.34-v8-+ #13
>> 20:07:07.843: [  242.666173] "echo 0 > /proc/sys/kernel/ 
>> hung_task_timeout_secs" disables this message.
>> 20:07:07.852: [  242.677126] task:vchiq-keep/0    state:D stack:0 
>> pid:85    tgid:85    ppid:2      flags:0x00000008
>> 20:07:07.854: [  242.690734] Call trace:
>> 20:07:07.857: [  242.693191]  __switch_to+0x188/0x230
>> 20:07:07.858: [  242.697010]  __schedule+0xa54/0xb28
>> 20:07:07.859: [  242.704889]  schedule+0x80/0x120
>> 20:07:07.859: [  242.712581]  schedule_preempt_disabled+0x30/0x50
>> 20:07:07.860: [  242.721437]  kthread+0xd4/0x1a0
>> 20:07:07.861: [  242.724606]  ret_from_fork+0x10/0x20
>>
>> If I revert this patch, I no longer get those warnings. From that, I was
>> wondering: is it possible that in some scenarios, we might never
>> actually get to the connected state and therefore, we wouldn't wake up
>> the kthread that we created when we initialized the state?
> Sure we communicate to the VideoCore and there might be reasons the 
> connection fail. I'm not aware that a missing wakeup cause a hanging task.
> 
> Best regards
>>
>> [1] https://gitlab.freedesktop.org/mairacanal/mesa/-/jobs/78940369
>>
>> Best Regards,
>> - Maíra
>>
>>> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/ 
>>> vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/ 
>>> vchiq_arm.c
>>> index 0c7ea2d0ee85..64f9536f1232 100644
>>> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
>>> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
>>> @@ -280,29 +280,6 @@ static int vchiq_platform_init(struct 
>>> platform_device *pdev, struct vchiq_state
>>>       return 0;
>>>   }
>>>
>>> -int
>>> -vchiq_platform_init_state(struct vchiq_state *state)
>>> -{
>>> -    struct vchiq_arm_state *platform_state;
>>> -
>>> -    platform_state = devm_kzalloc(state->dev, 
>>> sizeof(*platform_state), GFP_KERNEL);
>>> -    if (!platform_state)
>>> -        return -ENOMEM;
>>> -
>>> -    rwlock_init(&platform_state->susp_res_lock);
>>> -
>>> -    init_completion(&platform_state->ka_evt);
>>> -    atomic_set(&platform_state->ka_use_count, 0);
>>> -    atomic_set(&platform_state->ka_use_ack_count, 0);
>>> -    atomic_set(&platform_state->ka_release_count, 0);
>>> -
>>> -    platform_state->state = state;
>>> -
>>> -    state->platform_state = (struct opaque_platform_state 
>>> *)platform_state;
>>> -
>>> -    return 0;
>>> -}
>>> -
>>>   static struct vchiq_arm_state *vchiq_platform_get_arm_state(struct 
>>> vchiq_state *state)
>>>   {
>>>       return (struct vchiq_arm_state *)state->platform_state;
>>> @@ -1011,6 +988,39 @@ vchiq_keepalive_thread_func(void *v)
>>>       return 0;
>>>   }
>>>
>>> +int
>>> +vchiq_platform_init_state(struct vchiq_state *state)
>>> +{
>>> +    struct vchiq_arm_state *platform_state;
>>> +    char threadname[16];
>>> +
>>> +    platform_state = devm_kzalloc(state->dev, 
>>> sizeof(*platform_state), GFP_KERNEL);
>>> +    if (!platform_state)
>>> +        return -ENOMEM;
>>> +
>>> +    snprintf(threadname, sizeof(threadname), "vchiq-keep/%d",
>>> +         state->id);
>>> +    platform_state->ka_thread = 
>>> kthread_create(&vchiq_keepalive_thread_func,
>>> +                           (void *)state, threadname);
>>> +    if (IS_ERR(platform_state->ka_thread)) {
>>> +        dev_err(state->dev, "couldn't create thread %s\n", threadname);
>>> +        return PTR_ERR(platform_state->ka_thread);
>>> +    }
>>> +
>>> +    rwlock_init(&platform_state->susp_res_lock);
>>> +
>>> +    init_completion(&platform_state->ka_evt);
>>> +    atomic_set(&platform_state->ka_use_count, 0);
>>> +    atomic_set(&platform_state->ka_use_ack_count, 0);
>>> +    atomic_set(&platform_state->ka_release_count, 0);
>>> +
>>> +    platform_state->state = state;
>>> +
>>> +    state->platform_state = (struct opaque_platform_state 
>>> *)platform_state;
>>> +
>>> +    return 0;
>>> +}
>>> +
>>>   int
>>>   vchiq_use_internal(struct vchiq_state *state, struct vchiq_service 
>>> *service,
>>>              enum USE_TYPE_E use_type)
>>> @@ -1331,7 +1341,6 @@ void vchiq_platform_conn_state_changed(struct 
>>> vchiq_state *state,
>>>                          enum vchiq_connstate newstate)
>>>   {
>>>       struct vchiq_arm_state *arm_state = 
>>> vchiq_platform_get_arm_state(state);
>>> -    char threadname[16];
>>>
>>>       dev_dbg(state->dev, "suspend: %d: %s->%s\n",
>>>           state->id, get_conn_state_name(oldstate), 
>>> get_conn_state_name(newstate));
>>> @@ -1346,17 +1355,7 @@ void vchiq_platform_conn_state_changed(struct 
>>> vchiq_state *state,
>>>
>>>       arm_state->first_connect = 1;
>>>       write_unlock_bh(&arm_state->susp_res_lock);
>>> -    snprintf(threadname, sizeof(threadname), "vchiq-keep/%d",
>>> -         state->id);
>>> -    arm_state->ka_thread = kthread_create(&vchiq_keepalive_thread_func,
>>> -                          (void *)state,
>>> -                          threadname);
>>> -    if (IS_ERR(arm_state->ka_thread)) {
>>> -        dev_err(state->dev, "suspend: Couldn't create thread %s\n",
>>> -            threadname);
>>> -    } else {
>>> -        wake_up_process(arm_state->ka_thread);
>>> -    }
>>> +    wake_up_process(arm_state->ka_thread);
>>>   }
>>>
>>>   static const struct of_device_id vchiq_of_match[] = {
>>> -- 
>>> 2.34.1
>>>
>>>
>>
>>
> 

Re: [PATCH 4/5] staging: vchiq_arm: Create keep-alive thread during probe

[Stefan Wahren]

Hi Maíra,

[drop bouncing address from Umang and Ojaswin]

Am 26.06.25 um 22:30 schrieb Maíra Canal:
> Hi Stefan,
>
> On 26/06/25 17:14, Stefan Wahren wrote:
>> Hi Maíra,
>>
>> [add Arnd]
>>
>> Am 26.06.25 um 20:22 schrieb Maíra Canal:
>>> Hi Stefan,
>>>
>>> On 09/03/25 09:50, Stefan Wahren wrote:
>>>> Creating the keep-alive thread in vchiq_platform_init_state have
>>>> the following advantages:
>>>> - abort driver probe if kthread_create fails (more consistent 
>>>> behavior)
>>>> - make resource release process easier
>>>>
>>>> Since vchiq_keepalive_thread_func is defined below
>>>> vchiq_platform_init_state, the latter must be moved.
>>>>
>>>> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
>>>> ---
>>>>   .../interface/vchiq_arm/vchiq_arm.c           | 69 
>>>> +++++++++----------
>>>>   1 file changed, 34 insertions(+), 35 deletions(-)
>>>>
>>>
>>> After this patch landed on 6.12 stable, I started to observe the
>>> following warning in Mesa CI [1]:
>> Is this also reproducible with 6.15.x or mainline ?
>
> I was able to reproduce it with 6.16.0-rc2 [2].
Thanks, does these hangs occur without any Mesa test / are these test 
steps necessary to trigger the issue?

Is this reproducible with a real Raspberry Pi 3 (Plus)?

Do you use arm64/defconfig or a special kernel configuration?

Could you please provide kernel logs from boot until the first hang warning?

Best regards
>
> [2] https://gitlab.freedesktop.org/mairacanal/mesa/-/jobs/79092300
>
> Best Regards,
> - Maíra

Re: [PATCH 4/5] staging: vchiq_arm: Create keep-alive thread during probe

[Maíra Canal]

[-- Attachment #1: Type: text/plain, Size: 3232 bytes --]

Hi Stefan,

On 27/06/25 12:18, Stefan Wahren wrote:
> Hi Maíra,
> 
> [drop bouncing address from Umang and Ojaswin]
> 
> Am 26.06.25 um 22:30 schrieb Maíra Canal:
>> Hi Stefan,
>>
>> On 26/06/25 17:14, Stefan Wahren wrote:
>>> Hi Maíra,
>>>
>>> [add Arnd]
>>>
>>> Am 26.06.25 um 20:22 schrieb Maíra Canal:
>>>> Hi Stefan,
>>>>
>>>> On 09/03/25 09:50, Stefan Wahren wrote:
>>>>> Creating the keep-alive thread in vchiq_platform_init_state have
>>>>> the following advantages:
>>>>> - abort driver probe if kthread_create fails (more consistent 
>>>>> behavior)
>>>>> - make resource release process easier
>>>>>
>>>>> Since vchiq_keepalive_thread_func is defined below
>>>>> vchiq_platform_init_state, the latter must be moved.
>>>>>
>>>>> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
>>>>> ---
>>>>>   .../interface/vchiq_arm/vchiq_arm.c           | 69 ++++++++ 
>>>>> +----------
>>>>>   1 file changed, 34 insertions(+), 35 deletions(-)
>>>>>
>>>>
>>>> After this patch landed on 6.12 stable, I started to observe the
>>>> following warning in Mesa CI [1]:
>>> Is this also reproducible with 6.15.x or mainline ?
>>
>> I was able to reproduce it with 6.16.0-rc2 [2].
> Thanks, does these hangs occur without any Mesa test / are these test 
> steps necessary to trigger the issue?

The Mesa tests aren't needed to trigger the hang. Actually, the hang
doesn't even affect the tests running in the CI. However, during a job
execution we can see this warning multiple times, which ends up spamming
the log and can lead to confusion by non-kernel devs.

While inspecting the CI job, I was able to attest two things:

1. Indeed, the thread is created, but it never reaches
`wake_up_process()`, nor `vchiq_keepalive_thread_func()`.

2. Mesa's job environment doesn't load any media-related modules.
Therefore, no bcm2835-audio, no bcm2835-camera.

> 
> Is this reproducible with a real Raspberry Pi 3 (Plus)?

Yes, it is. It's also reproducible in a RPi 4 with the downstream
kernel. As RPi OS loads all those media-related modules, to easily
reproduce the error in RPi OS (without dealing with systemd and such),
you can just add the following modules to the modprobe blacklist:

blacklist snd_bcm2835
blacklist bcm2835_v4l2

# only for rpi4
blacklist bcm2835_codec
blacklist bcm2835_isp
blacklist bcm2835_mmal_vchiq

Reboot the device, wait a couple of minutes (2-3 minutes), and you will
get the warning in the dmesg output.

> 
> Do you use arm64/defconfig or a special kernel configuration?

defconfig

> 
> Could you please provide kernel logs from boot until the first hang 
> warning?

It's attached.

About the first point I mentioned in this e-mail, I'd like to come back
again to the idea that: the kthread is created, but it stays in
TASK_UNINTERRUPTIBLE forever, as we never call `wake_up_process()`. This
might be causing the kernel to report a hung task, which doesn't affect
the system, but ends up spamming the kernel log.

For example, we can see a similar situation described by commit
e5644be40797 ("usb: gadget: uvc: Fix unstarted kthread worker").

Best Regards,
- Maíra

> 
> Best regards
>>
>> [2] https://gitlab.freedesktop.org/mairacanal/mesa/-/jobs/79092300
>>
>> Best Regards,
>> - Maíra

[-- Attachment #2: dmesg.txt --]
[-- Type: text/plain, Size: 40274 bytes --]

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd083]
[    0.000000] Linux version 6.12.34-v8-pr-info+ (mairacanal@morissey) (clang version 19.1.7 (Fedora 19.1.7-3.fc41), LLD 19.1.7) #22 SMP PREEMPT Fri Jun 27 16:25:38 -03 2025
[    0.000000] KASLR enabled
[    0.000000] random: crng init done
[    0.000000] Machine model: Raspberry Pi 4 Model B Rev 1.5
[    0.000000] efi: UEFI not found.
[    0.000000] Reserved memory: created CMA memory pool at 0x000000000ec00000, size 512 MiB
[    0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
[    0.000000] OF: reserved mem: 0x000000000ec00000..0x000000002ebfffff (524288 KiB) map reusable linux,cma
[    0.000000] OF: reserved mem: 0x000000003ef667c0..0x000000003ef667f5 (0 KiB) nomap non-reusable nvram@0
[    0.000000] OF: reserved mem: 0x000000003ef66580..0x000000003ef6677f (0 KiB) nomap non-reusable nvram@1
[    0.000000] NUMA: Faking a node at [mem 0x0000000000000000-0x00000001ffffffff]
[    0.000000] Faking node 0 at [mem 0x0000000000000000-0x0000000103ffffff] (4160MB)
[    0.000000] Faking node 1 at [mem 0x0000000104000000-0x00000001ffffffff] (4032MB)
[    0.000000] NUMA: Initialized distance table, cnt=2
[    0.000000] NODE_DATA(0) allocated [mem 0x103ffd300-0x103ffffff]
[    0.000000] NODE_DATA(1) allocated [mem 0x1feff5300-0x1feff7fff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000000000-0x000000003fffffff]
[    0.000000]   DMA32    [mem 0x0000000040000000-0x00000000ffffffff]
[    0.000000]   Normal   [mem 0x0000000100000000-0x00000001ffffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x000000003b3fffff]
[    0.000000]   node   0: [mem 0x0000000040000000-0x00000000fbffffff]
[    0.000000]   node   0: [mem 0x0000000100000000-0x0000000103ffffff]
[    0.000000]   node   1: [mem 0x0000000104000000-0x00000001ffffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000103ffffff]
[    0.000000] Initmem setup node 1 [mem 0x0000000104000000-0x00000001ffffffff]
[    0.000000] On node 0, zone DMA32: 19456 pages in unavailable ranges
[    0.000000] On node 0, zone Normal: 16384 pages in unavailable ranges
[    0.000000] percpu: Embedded 33 pages/cpu s95128 r8192 d31848 u135168
[    0.000000] pcpu-alloc: s95128 r8192 d31848 u135168 alloc=33*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[    0.000000] Detected PIPT I-cache on CPU0
[    0.000000] CPU features: detected: Spectre-v2
[    0.000000] CPU features: detected: Spectre-v3a
[    0.000000] CPU features: detected: Spectre-v4
[    0.000000] CPU features: detected: Spectre-BHB
[    0.000000] CPU features: kernel page table isolation forced ON by KASLR
[    0.000000] CPU features: detected: Kernel page table isolation (KPTI)
[    0.000000] CPU features: detected: ARM erratum 1742098
[    0.000000] CPU features: detected: ARM errata 1165522, 1319367, or 1530923
[    0.000000] alternatives: applying boot alternatives
[    0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=0 snd_bcm2835.enable_headphones=0 cgroup_disable=memory numa_policy=interleave nvme.max_host_mem_size_mb=0 snd_bcm2835.enable_headphones=1 snd_bcm2835.enable_hdmi=1 snd_bcm2835.enable_hdmi=0  numa=fake=2 system_heap.max_order=0 smsc95xx.macaddr=D8:3A:DD:09:E6:A9 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000  console=ttyS0,115200 console=tty1 root=PARTUUID=49c1e9e8-02 rootfstype=ext4 fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles
[    0.000000] cgroup: Disabling memory control group subsystem
[    0.000000] mempolicy: NUMA default policy overridden to 'interleave:0-1'
[    0.000000] Unknown kernel command line parameters "splash", will be passed to user space.
[    0.000000] Fallback order for Node 0: 0 1
[    0.000000] Fallback order for Node 1: 1 0
[    0.000000] Built 2 zonelists, mobility grouping on.  Total pages: 2061312
[    0.000000] Policy zone: Normal
[    0.000000] mem auto-init: stack:all(zero), heap alloc:off, heap free:off
[    0.000000] software IO TLB: area num 4.
[    0.000000] software IO TLB: mapped [mem 0x0000000037400000-0x000000003b400000] (64MB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=2
[    0.000000] ftrace: allocating 44224 entries in 173 pages
[    0.000000] ftrace: allocated 173 pages with 5 groups
[    0.000000] rcu: Preemptible hierarchical RCU implementation.
[    0.000000] rcu: 	RCU event tracing is enabled.
[    0.000000] 	Trampoline variant of Tasks RCU enabled.
[    0.000000] 	Rude variant of Tasks RCU enabled.
[    0.000000] 	Tracing variant of Tasks RCU enabled.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[    0.000000] RCU Tasks: Setting shift to 2 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=4.
[    0.000000] RCU Tasks Rude: Setting shift to 2 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=4.
[    0.000000] RCU Tasks Trace: Setting shift to 2 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=4.
[    0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[    0.000000] Root IRQ handler: gic_handle_irq
[    0.000000] GIC: Using split EOI/Deactivate mode
[    0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention.
[    0.000000] arch_timer: cp15 timer(s) running at 54.00MHz (phys).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0xc743ce346, max_idle_ns: 440795203123 ns
[    0.000000] sched_clock: 56 bits at 54MHz, resolution 18ns, wraps every 4398046511102ns
[    0.000154] Console: colour dummy device 80x25
[    0.000163] printk: legacy console [tty1] enabled
[    0.000232] Calibrating delay loop (skipped), value calculated using timer frequency.. 108.00 BogoMIPS (lpj=216000)
[    0.000241] pid_max: default: 32768 minimum: 301
[    0.000296] LSM: initializing lsm=capability
[    0.003143] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes, vmalloc hugepage)
[    0.004542] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes, vmalloc hugepage)
[    0.004618] Mount-cache hash table entries: 16384 (order: 5, 131072 bytes, vmalloc)
[    0.004684] Mountpoint-cache hash table entries: 16384 (order: 5, 131072 bytes, vmalloc)
[    0.006157] rcu: Hierarchical SRCU implementation.
[    0.006169] rcu: 	Max phase no-delay instances is 1000.
[    0.006315] Timer migration: 2 hierarchy levels; 8 children per group; 1 crossnode level
[    0.006921] EFI services will not be available.
[    0.007102] smp: Bringing up secondary CPUs ...
[    0.007418] Detected PIPT I-cache on CPU1
[    0.007482] CPU1: Booted secondary processor 0x0000000001 [0x410fd083]
[    0.007819] Detected PIPT I-cache on CPU2
[    0.007854] CPU2: Booted secondary processor 0x0000000002 [0x410fd083]
[    0.008218] Detected PIPT I-cache on CPU3
[    0.008256] CPU3: Booted secondary processor 0x0000000003 [0x410fd083]
[    0.008304] smp: Brought up 2 nodes, 4 CPUs
[    0.008311] SMP: Total of 4 processors activated.
[    0.008314] CPU: All CPU(s) started at EL2
[    0.008326] CPU features: detected: 32-bit EL0 Support
[    0.008329] CPU features: detected: 32-bit EL1 Support
[    0.008332] CPU features: detected: CRC32 instructions
[    0.008363] alternatives: applying system-wide alternatives
[    0.009282] Memory: 7463772K/8245248K available (14336K kernel code, 2450K rwdata, 4712K rodata, 1536K init, 578K bss, 238232K reserved, 524288K cma-reserved)
[    0.009879] devtmpfs: initialized
[    0.013954] Enabled cp15_barrier support
[    0.013971] Enabled setend support
[    0.014054] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.014068] futex hash table entries: 1024 (order: 4, 65536 bytes, vmalloc)
[    0.022777] 2G module region forced by RANDOMIZE_MODULE_REGION_FULL
[    0.022796] 0 pages in range for non-PLT usage
[    0.022801] 518336 pages in range for PLT usage
[    0.022982] pinctrl core: initialized pinctrl subsystem
[    0.023335] DMI not present or invalid.
[    0.025778] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[    0.026393] DMA: preallocated 1024 KiB GFP_KERNEL pool for atomic allocations
[    0.026486] DMA: preallocated 1024 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
[    0.026638] DMA: preallocated 1024 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
[    0.026669] audit: initializing netlink subsys (disabled)
[    0.026805] audit: type=2000 audit(0.024:1): state=initialized audit_enabled=0 res=1
[    0.027034] thermal_sys: Registered thermal governor 'step_wise'
[    0.027054] cpuidle: using governor menu
[    0.027153] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
[    0.027203] ASID allocator initialised with 32768 entries
[    0.027603] Serial: AMBA PL011 UART driver
[    0.029561] /soc/interrupt-controller@40041000: Fixed dependency cycle(s) with /soc/interrupt-controller@40041000
[    0.029959] bcm2835-mbox fe00b880.mailbox: mailbox enabled
[    0.036109] raspberrypi-firmware soc:firmware: Attached to firmware from 2025-04-30T13:33:39, variant start
[    0.040116] raspberrypi-firmware soc:firmware: Firmware hash is 5560078dcc8591a00f57b9068d13e5544aeef3aa
[    0.045409] /scb/pcie@7d500000: Fixed dependency cycle(s) with /scb/pcie@7d500000
[    0.045505] /scb/pcie@7d500000: Fixed dependency cycle(s) with /scb/pcie@7d500000
[    0.048391] bcm2835-dma fe007000.dma-controller: DMA legacy API manager, dmachans=0x1
[    0.049078] iommu: Default domain type: Translated
[    0.049083] iommu: DMA domain TLB invalidation policy: strict mode
[    0.049874] SCSI subsystem initialized
[    0.049954] usbcore: registered new interface driver usbfs
[    0.049974] usbcore: registered new interface driver hub
[    0.049992] usbcore: registered new device driver usb
[    0.050174] pps_core: LinuxPPS API ver. 1 registered
[    0.050178] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    0.050184] PTP clock support registered
[    0.050727] vgaarb: loaded
[    0.050969] clocksource: Switched to clocksource arch_sys_counter
[    0.505395] VFS: Disk quotas dquot_6.6.0
[    0.505423] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    0.508846] NET: Registered PF_INET protocol family
[    0.509700] IP idents hash table entries: 131072 (order: 8, 1048576 bytes, vmalloc)
[    0.512695] tcp_listen_portaddr_hash hash table entries: 4096 (order: 4, 65536 bytes, vmalloc)
[    0.512800] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, vmalloc)
[    0.512862] TCP established hash table entries: 65536 (order: 7, 524288 bytes, vmalloc)
[    0.513172] TCP bind hash table entries: 65536 (order: 9, 2097152 bytes, vmalloc)
[    0.514616] TCP: Hash tables configured (established 65536 bind 65536)
[    0.515061] MPTCP token hash table entries: 8192 (order: 5, 196608 bytes, vmalloc)
[    0.515214] UDP hash table entries: 4096 (order: 5, 131072 bytes, vmalloc)
[    0.515277] UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes, vmalloc)
[    0.515427] NET: Registered PF_UNIX/PF_LOCAL protocol family
[    0.515818] RPC: Registered named UNIX socket transport module.
[    0.515823] RPC: Registered udp transport module.
[    0.515826] RPC: Registered tcp transport module.
[    0.515828] RPC: Registered tcp-with-tls transport module.
[    0.515831] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.515849] PCI: CLS 0 bytes, default 64
[    0.518427] kvm [1]: nv: 554 coarse grained trap handlers
[    0.518632] kvm [1]: IPA Size Limit: 44 bits
[    0.519262] kvm [1]: vgic interrupt IRQ9
[    0.519286] kvm [1]: Hyp nVHE mode initialized successfully
[    0.520199] Initialise system trusted keyrings
[    0.520413] workingset: timestamp_bits=42 max_order=21 bucket_order=0
[    0.520767] NFS: Registering the id_resolver key type
[    0.520782] Key type id_resolver registered
[    0.520784] Key type id_legacy registered
[    0.520796] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[    0.520799] nfs4flexfilelayout_init: NFSv4 Flexfile Layout Driver Registering...
[    0.521097] Key type asymmetric registered
[    0.521102] Asymmetric key parser 'x509' registered
[    0.521131] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 247)
[    0.521229] io scheduler mq-deadline registered
[    0.521233] io scheduler kyber registered
[    0.521249] io scheduler bfq registered
[    0.521692] irq_brcmstb_l2: registered L2 intc (/soc/interrupt-controller@7ef00100, parent irq: 23)
[    0.522957] pinctrl-bcm2835 fe200000.gpio: GPIO_OUT persistence: yes
[    0.525557] ledtrig-cpu: registered to indicate activity on CPUs
[    0.525922] brcm-pcie fd500000.pcie: host bridge /scb/pcie@7d500000 ranges:
[    0.525933] brcm-pcie fd500000.pcie:   No bus range found for /scb/pcie@7d500000, using [bus 00-ff]
[    0.525952] brcm-pcie fd500000.pcie:      MEM 0x0600000000..0x063fffffff -> 0x00c0000000
[    0.525966] brcm-pcie fd500000.pcie:   IB MEM 0x0000000000..0x01ffffffff -> 0x0400000000
[    0.526727] brcm-pcie fd500000.pcie: PCI host bridge to bus 0000:00
[    0.526738] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.526744] pci_bus 0000:00: root bus resource [mem 0x600000000-0x63fffffff] (bus address [0xc0000000-0xffffffff])
[    0.526788] pci 0000:00:00.0: [14e4:2711] type 01 class 0x060400 PCIe Root Port
[    0.526802] pci 0000:00:00.0: PCI bridge to [bus 00]
[    0.526808] pci 0000:00:00.0:   bridge window [mem 0x80000000-0xbfffffff]
[    0.526846] pci 0000:00:00.0: PME# supported from D0 D3hot
[    0.528143] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    0.528197] pci_bus 0000:01: supply vpcie3v3 not found, using dummy regulator
[    0.528258] pci_bus 0000:01: supply vpcie3v3aux not found, using dummy regulator
[    0.528278] pci_bus 0000:01: supply vpcie12v not found, using dummy regulator
[    0.630975] brcm-pcie fd500000.pcie: clkreq-mode set to default
[    0.633034] brcm-pcie fd500000.pcie: link up, 5.0 GT/s PCIe x1 (SSC)
[    0.633144] pci 0000:01:00.0: [1106:3483] type 00 class 0x0c0330 PCIe Endpoint
[    0.633200] pci 0000:01:00.0: BAR 0 [mem 0x00000000-0x00000fff 64bit]
[    0.633254] pci 0000:01:00.0: ASPM: VL805 fixup applied
[    0.633338] pci 0000:01:00.0: PME# supported from D0 D3hot
[    0.639031] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
[    0.639051] pci 0000:00:00.0: bridge window [mem 0x600000000-0x6000fffff]: assigned
[    0.639058] pci 0000:01:00.0: BAR 0 [mem 0x600000000-0x600000fff 64bit]: assigned
[    0.639100] pci 0000:00:00.0: PCI bridge to [bus 01]
[    0.639105] pci 0000:00:00.0:   bridge window [mem 0x600000000-0x6000fffff]
[    0.639111] pci_bus 0000:00: resource 4 [mem 0x600000000-0x63fffffff]
[    0.639115] pci_bus 0000:01: resource 1 [mem 0x600000000-0x6000fffff]
[    0.639233] pcieport 0000:00:00.0: enabling device (0000 -> 0002)
[    0.639299] pcieport 0000:00:00.0: PME: Signaling with IRQ 27
[    0.639435] pcieport 0000:00:00.0: AER: enabled with IRQ 27
[    0.639897] simple-framebuffer 3e402000.framebuffer: framebuffer at 0x3e402000, 0x7f8000 bytes
[    0.639903] simple-framebuffer 3e402000.framebuffer: format=a8r8g8b8, mode=1920x1080x32, linelength=7680
[    0.640111] Console: switching to colour frame buffer device 240x67
[    0.643410] simple-framebuffer 3e402000.framebuffer: fb0: simplefb registered!
[    0.647573] iproc-rng200 fe104000.rng: hwrng registered
[    0.647660] vc-mem: phys_addr:0x00000000 mem_base=0x3ec00000 mem_size:0x40000000(1024 MiB)
[    0.651984] brd: module loaded
[    0.654488] loop: module loaded
[    0.654841] Loading iSCSI transport class v2.0-870.
[    0.656723] bcmgenet fd580000.ethernet: GENET 5.0 EPHY: 0x0000
[    0.846995] unimac-mdio unimac-mdio.-19: Broadcom UniMAC MDIO bus
[    0.847528] usbcore: registered new interface driver lan78xx
[    0.847560] usbcore: registered new interface driver smsc95xx
[    0.939296] xhci_hcd 0000:01:00.0: xHCI Host Controller
[    0.939310] xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 1
[    0.940213] xhci_hcd 0000:01:00.0: hcc params 0x002841eb hci version 0x100 quirks 0x0300240000000890
[    0.940706] xhci_hcd 0000:01:00.0: xHCI Host Controller
[    0.940713] xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 2
[    0.940720] xhci_hcd 0000:01:00.0: Host supports USB 3.0 SuperSpeed
[    0.940834] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.12
[    0.940840] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    0.940844] usb usb1: Product: xHCI Host Controller
[    0.940848] usb usb1: Manufacturer: Linux 6.12.34-v8-pr-info+ xhci-hcd
[    0.940851] usb usb1: SerialNumber: 0000:01:00.0
[    0.941098] hub 1-0:1.0: USB hub found
[    0.941116] hub 1-0:1.0: 1 port detected
[    0.941328] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 6.12
[    0.941334] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    0.941338] usb usb2: Product: xHCI Host Controller
[    0.941341] usb usb2: Manufacturer: Linux 6.12.34-v8-pr-info+ xhci-hcd
[    0.941345] usb usb2: SerialNumber: 0000:01:00.0
[    0.941514] hub 2-0:1.0: USB hub found
[    0.941531] hub 2-0:1.0: 4 ports detected
[    0.941928] dwc_otg: version 3.00a 10-AUG-2012 (platform bus)
[    0.941973] dwc_otg: FIQ enabled
[    0.941976] dwc_otg: NAK holdoff enabled
[    0.941979] dwc_otg: FIQ split-transaction FSM enabled
[    0.941983] Module dwc_common_port init
[    0.942470] usbcore: registered new interface driver uas
[    0.942498] usbcore: registered new interface driver usb-storage
[    0.942723] mousedev: PS/2 mouse device common for all mice
[    0.944217] sdhci: Secure Digital Host Controller Interface driver
[    0.944227] sdhci: Copyright(c) Pierre Ossman
[    0.944315] sdhci-pltfm: SDHCI platform and OF driver helper
[    0.944483] hid: raw HID events driver (C) Jiri Kosina
[    0.944537] usbcore: registered new interface driver usbhid
[    0.944541] usbhid: USB HID core driver
[    0.945452] criou a thread vchiq-keep/0
[    0.948646] hw perfevents: enabled with armv8_cortex_a72 PMU driver, 7 (0,8000003f) counters available
[    0.949202] NET: Registered PF_PACKET protocol family
[    0.949245] Key type dns_resolver registered
[    0.959179] registered taskstats version 1
[    0.959327] Loading compiled-in X.509 certificates
[    0.963116] Demotion targets for Node 0: null
[    0.963129] Demotion targets for Node 1: null
[    0.963628] Key type .fscrypt registered
[    0.963633] Key type fscrypt-provisioning registered
[    0.967105] uart-pl011 fe201000.serial: there is not valid maps for state default
[    0.967346] uart-pl011 fe201000.serial: cts_event_workaround enabled
[    0.967526] fe201000.serial: ttyAMA1 at MMIO 0xfe201000 (irq = 39, base_baud = 0) is a PL011 rev3
[    0.967633] serial serial0: tty port ttyAMA1 registered
[    0.968700] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer
[    0.969051] bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver
[    0.969447] mmc-bcm2835 fe300000.mmcnr: mmc_debug:0 mmc_debug2:0
[    0.969453] mmc-bcm2835 fe300000.mmcnr: DMA channel allocated
[    0.995426] of_cfs_init
[    0.995526] of_cfs_init: OK
[    0.995672] clk: Disabling unused clocks
[    0.995874] PM: genpd: Disabling unused power domains
[    1.031019] mmc0: SDHCI controller on fe340000.mmc [fe340000.mmc] using ADMA
[    1.031124] Waiting for root device PARTUUID=49c1e9e8-02...
[    1.075099] mmc1: new high speed SDIO card at address 0001
[    1.138287] mmc0: new ultra high speed DDR50 SDXC card at address aaaa
[    1.138692] mmcblk0: mmc0:aaaa WX64G 59.5 GiB
[    1.140559]  mmcblk0: p1 p2
[    1.140738] mmcblk0: mmc0:aaaa WX64G 59.5 GiB (quirks 0x00004000)
[    1.160622] EXT4-fs (mmcblk0p2): mounted filesystem d6ecfcd5-2703-41bf-9301-10c403b6fb0c ro with ordered data mode. Quota mode: none.
[    1.160673] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[    1.161313] devtmpfs: mounted
[    1.163472] Freeing unused kernel memory: 1536K
[    1.163594] Run /sbin/init as init process
[    1.163598]   with arguments:
[    1.163600]     /sbin/init
[    1.163603]     splash
[    1.163605]   with environment:
[    1.163607]     HOME=/
[    1.163609]     TERM=linux
[    1.187026] usb 1-1: new high-speed USB device number 2 using xhci_hcd
[    1.325645] usb 1-1: New USB device found, idVendor=2109, idProduct=3431, bcdDevice= 4.21
[    1.325663] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[    1.325668] usb 1-1: Product: USB2.0 Hub
[    1.326873] hub 1-1:1.0: USB hub found
[    1.327396] hub 1-1:1.0: 4 ports detected
[    1.538638] systemd[1]: System time before build time, advancing clock.
[    1.619016] usb 1-1.3: new full-speed USB device number 3 using xhci_hcd
[    1.640138] NET: Registered PF_INET6 protocol family
[    1.640898] Segment Routing with IPv6
[    1.640919] In-situ OAM (IOAM) with IPv6
[    1.685921] systemd[1]: systemd 252.38-1~deb12u1 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified)
[    1.685958] systemd[1]: Detected architecture arm64.
[    1.703083] systemd[1]: Hostname set to <raspberrypi>.
[    1.716827] usb 1-1.3: New USB device found, idVendor=1997, idProduct=2466, bcdDevice= 1.05
[    1.716845] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    1.716850] usb 1-1.3: Product: Wireless Receiver
[    1.716853] usb 1-1.3: Manufacturer: Telink
[    1.726559] input: Telink Wireless Receiver Mouse as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0/0003:1997:2466.0001/input/input0
[    1.726774] input: Telink Wireless Receiver Consumer Control as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0/0003:1997:2466.0001/input/input1
[    1.779441] input: Telink Wireless Receiver System Control as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0/0003:1997:2466.0001/input/input2
[    1.779646] hid-generic 0003:1997:2466.0001: input,hidraw0: USB HID v1.11 Mouse [Telink Wireless Receiver] on usb-0000:01:00.0-1.3/input0
[    1.787981] input: Telink Wireless Receiver as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.1/0003:1997:2466.0002/input/input3
[    1.907242] hid-generic 0003:1997:2466.0002: input,hidraw1: USB HID v1.11 Keyboard [Telink Wireless Receiver] on usb-0000:01:00.0-1.3/input1
[    2.211288] systemd[1]: Queued start job for default target graphical.target.
[    2.236228] systemd[1]: Created slice system-getty.slice - Slice /system/getty.
[    2.236804] systemd[1]: Created slice system-modprobe.slice - Slice /system/modprobe.
[    2.237216] systemd[1]: Created slice system-systemd\x2dfsck.slice - Slice /system/systemd-fsck.
[    2.237499] systemd[1]: Created slice user.slice - User and Session Slice.
[    2.237641] systemd[1]: Started systemd-ask-password-wall.path - Forward Password Requests to Wall Directory Watch.
[    2.237992] systemd[1]: Set up automount proc-sys-fs-binfmt_misc.automount - Arbitrary Executable File Formats File System Automount Point.
[    2.238046] systemd[1]: Expecting device dev-disk-by\x2dpartuuid-49c1e9e8\x2d01.device - /dev/disk/by-partuuid/49c1e9e8-01...
[    2.238067] systemd[1]: Expecting device dev-dri-card0.device - /dev/dri/card0...
[    2.238089] systemd[1]: Expecting device dev-dri-renderD128.device - /dev/dri/renderD128...
[    2.238152] systemd[1]: Reached target integritysetup.target - Local Integrity Protected Volumes.
[    2.238223] systemd[1]: Reached target nss-user-lookup.target - User and Group Name Lookups.
[    2.238275] systemd[1]: Reached target slices.target - Slice Units.
[    2.238324] systemd[1]: Reached target swap.target - Swaps.
[    2.238369] systemd[1]: Reached target veritysetup.target - Local Verity Protected Volumes.
[    2.238663] systemd[1]: Listening on systemd-fsckd.socket - fsck to fsckd communication Socket.
[    2.238786] systemd[1]: Listening on systemd-initctl.socket - initctl Compatibility Named Pipe.
[    2.239410] systemd[1]: Listening on systemd-journald-audit.socket - Journal Audit Socket.
[    2.239675] systemd[1]: Listening on systemd-journald-dev-log.socket - Journal Socket (/dev/log).
[    2.239907] systemd[1]: Listening on systemd-journald.socket - Journal Socket.
[    2.240804] systemd[1]: Listening on systemd-udevd-control.socket - udev Control Socket.
[    2.240993] systemd[1]: Listening on systemd-udevd-kernel.socket - udev Kernel Socket.
[    2.241275] systemd[1]: dev-hugepages.mount - Huge Pages File System was skipped because of an unmet condition check (ConditionPathExists=/sys/kernel/mm/hugepages).
[    2.242796] systemd[1]: Mounting dev-mqueue.mount - POSIX Message Queue File System...
[    2.244797] systemd[1]: Mounting sys-kernel-debug.mount - Kernel Debug File System...
[    2.246918] systemd[1]: Mounting sys-kernel-tracing.mount - Kernel Trace File System...
[    2.247259] systemd[1]: auth-rpcgss-module.service - Kernel Module supporting RPCSEC_GSS was skipped because of an unmet condition check (ConditionPathExists=/etc/krb5.keytab).
[    2.250922] systemd[1]: Starting fake-hwclock.service - Restore / save the current clock...
[    2.253238] systemd[1]: Starting keyboard-setup.service - Set the console keyboard layout...
[    2.255833] systemd[1]: Starting kmod-static-nodes.service - Create List of Static Device Nodes...
[    2.258483] systemd[1]: Starting modprobe@configfs.service - Load Kernel Module configfs...
[    2.262653] systemd[1]: Starting modprobe@dm_mod.service - Load Kernel Module dm_mod...
[    2.265805] systemd[1]: Starting modprobe@drm.service - Load Kernel Module drm...
[    2.270489] systemd[1]: Starting modprobe@efi_pstore.service - Load Kernel Module efi_pstore...
[    2.274377] systemd[1]: Starting modprobe@fuse.service - Load Kernel Module fuse...
[    2.280443] systemd[1]: Starting modprobe@loop.service - Load Kernel Module loop...
[    2.284038] systemd[1]: Starting systemd-fsck-root.service - File System Check on Root Device...
[    2.288978] systemd[1]: Starting systemd-journald.service - Journal Service...
[    2.310296] device-mapper: ioctl: 4.48.0-ioctl (2023-03-01) initialised: dm-devel@lists.linux.dev
[    2.315548] systemd[1]: Starting systemd-modules-load.service - Load Kernel Modules...
[    2.317702] systemd[1]: Starting systemd-udev-trigger.service - Coldplug All udev Devices...
[    2.321962] systemd[1]: Mounted dev-mqueue.mount - POSIX Message Queue File System.
[    2.322205] systemd[1]: Mounted sys-kernel-debug.mount - Kernel Debug File System.
[    2.322361] systemd[1]: Mounted sys-kernel-tracing.mount - Kernel Trace File System.
[    2.327107] systemd[1]: Finished kmod-static-nodes.service - Create List of Static Device Nodes.
[    2.328309] systemd[1]: modprobe@configfs.service: Deactivated successfully.
[    2.328827] systemd[1]: Finished modprobe@configfs.service - Load Kernel Module configfs.
[    2.329644] systemd[1]: modprobe@dm_mod.service: Deactivated successfully.
[    2.330093] systemd[1]: Finished modprobe@dm_mod.service - Load Kernel Module dm_mod.
[    2.330858] systemd[1]: modprobe@efi_pstore.service: Deactivated successfully.
[    2.331503] systemd[1]: Finished modprobe@efi_pstore.service - Load Kernel Module efi_pstore.
[    2.332432] systemd[1]: modprobe@loop.service: Deactivated successfully.
[    2.332853] systemd[1]: Finished modprobe@loop.service - Load Kernel Module loop.
[    2.338205] fuse: init (API version 7.41)
[    2.340580] systemd[1]: Mounting sys-kernel-config.mount - Kernel Configuration File System...
[    2.344314] systemd[1]: Started systemd-fsckd.service - File System Check Daemon to report status.
[    2.344924] systemd[1]: systemd-repart.service - Repartition Root Disk was skipped because no trigger condition checks were met.
[    2.346053] systemd[1]: modprobe@fuse.service: Deactivated successfully.
[    2.351306] systemd[1]: Finished modprobe@fuse.service - Load Kernel Module fuse.
[    2.352768] systemd[1]: Mounted sys-kernel-config.mount - Kernel Configuration File System.
[    2.354837] systemd[1]: Mounting sys-fs-fuse-connections.mount - FUSE Control File System...
[    2.363496] systemd[1]: Mounted sys-fs-fuse-connections.mount - FUSE Control File System.
[    2.386428] systemd[1]: Finished fake-hwclock.service - Restore / save the current clock.
[    2.405251] i2c_dev: i2c /dev entries driver
[    2.409193] systemd[1]: Finished systemd-modules-load.service - Load Kernel Modules.
[    2.443447] systemd[1]: Starting systemd-sysctl.service - Apply Kernel Variables...
[    2.444091] systemd[1]: Started systemd-journald.service - Journal Service.
[    2.708895] EXT4-fs (mmcblk0p2): re-mounted d6ecfcd5-2703-41bf-9301-10c403b6fb0c r/w.
[    2.766938] systemd-journald[146]: Received client request to flush runtime journal.
[    3.485649] rpi-gpiomem fe200000.gpiomem: window base 0xfe200000 size 0x00001000
[    3.487956] rpi-gpiomem fe200000.gpiomem: initialised 1 regions as /dev/gpiomem
[    3.490833] brcmstb-i2c fef04500.i2c:  @97500hz registered in polling mode
[    3.494143] mc: Linux media interface: v0.10
[    3.494461] brcmstb-i2c fef09500.i2c:  @97500hz registered in polling mode
[    3.685969] videodev: Linux video capture interface: v2.00
[    3.815612] v3d fec00000.v3d: [drm] Transparent Hugepage support is recommended for optimal performance on this platform!
[    3.836015] [drm] Initialized v3d 1.0.0 for fec00000.v3d on minor 0
[    3.841204] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[    3.856376] rpi-hevc-dec feb00000.codec: Device registered as /dev/video19
[    3.859763] Loaded X.509 cert 'benh@debian.org: 577e021cb980e0e820821ba7b54b4961b8b4fadf'
[    3.860072] Loaded X.509 cert 'romain.perier@gmail.com: 3abbc6ec146e09d1b6016ab9d6cf71dd233f0328'
[    3.860355] Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[    3.860632] Loaded X.509 cert 'wens: 61c038651aabdcf94bd0ac7ff06c7248db18c600'
[    3.944495] Bluetooth: Core ver 2.22
[    3.944581] NET: Registered PF_BLUETOOTH protocol family
[    3.944584] Bluetooth: HCI device and connection manager initialized
[    3.944608] Bluetooth: HCI socket layer initialized
[    3.944614] Bluetooth: L2CAP socket layer initialized
[    3.944627] Bluetooth: SCO socket layer initialized
[    3.980087] brcmfmac: F1 signature read @0x18000000=0x15264345
[    3.985803] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[    3.994390] usbcore: registered new interface driver brcmfmac
[    4.018255] Bluetooth: HCI UART driver ver 2.3
[    4.018282] Bluetooth: HCI UART protocol H4 registered
[    4.018372] Bluetooth: HCI UART protocol Three-wire (H5) registered
[    4.018741] Bluetooth: HCI UART protocol Broadcom registered
[    4.019987] hci_uart_bcm serial0-0: supply vbat not found, using dummy regulator
[    4.020127] hci_uart_bcm serial0-0: supply vddio not found, using dummy regulator
[    4.267221] brcmfmac: brcmf_c_process_txcap_blob: no txcap_blob available (err=-2)
[    4.269969] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Aug 29 2023 01:47:08 version 7.45.265 (28bca26 CY) FWID 01-b677b91b
[    4.306282] Console: switching to colour dummy device 80x25
[    4.347195] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[    4.348263] Registered IR keymap rc-cec
[    4.348362] rc rc0: vc4-hdmi-0 as /devices/platform/soc/fef00700.hdmi/rc/rc0
[    4.348448] input: vc4-hdmi-0 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input4
[    4.357241] input: vc4-hdmi-0 HDMI Jack as /devices/platform/soc/fef00700.hdmi/sound/card0/input5
[    4.357491] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
[    4.360605] Registered IR keymap rc-cec
[    4.360702] rc rc1: vc4-hdmi-1 as /devices/platform/soc/fef05700.hdmi/rc/rc1
[    4.360839] input: vc4-hdmi-1 as /devices/platform/soc/fef05700.hdmi/rc/rc1/input6
[    4.372817] input: vc4-hdmi-1 HDMI Jack as /devices/platform/soc/fef05700.hdmi/sound/card1/input7
[    4.373150] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
[    4.373881] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
[    4.375512] Bluetooth: hci0: BCM: chip id 107
[    4.375769] Bluetooth: hci0: BCM: features 0x2f
[    4.376824] Bluetooth: hci0: BCM4345C0
[    4.376842] Bluetooth: hci0: BCM4345C0 (003.001.025) build 0000
[    4.377053] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
[    4.377372] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
[    4.377614] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
[    4.377735] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
[    4.377934] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
[    4.380947] Bluetooth: hci0: BCM4345C0 'brcm/BCM4345C0.raspberrypi,4-model-b.hcd' Patch
[    4.382740] [drm] Initialized vc4 0.0.0 for gpu on minor 1
[    4.433940] vc4-drm gpu: [drm] The core clock cannot reach frequencies high enough to support 4k @ 60Hz.
[    4.433958] vc4-drm gpu: [drm] Please change your config.txt file to add hdmi_enable_4kp60.
[    4.464316] Console: switching to colour frame buffer device 240x67
[    4.482913] vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device
[    5.122720] Adding 524284k swap on /var/swap.  Priority:-2 extents:3 across:5185536k SS
[    5.163692] Bluetooth: hci0: BCM: features 0x2f
[    5.164952] Bluetooth: hci0: BCM43455 37.4MHz Raspberry Pi 3+-0190
[    5.164964] Bluetooth: hci0: BCM4345C0 (003.001.025) build 0382
[    5.333672] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[    5.333692] Bluetooth: BNEP filters: protocol multicast
[    5.333705] Bluetooth: BNEP socket layer initialized
[    5.337891] Bluetooth: MGMT ver 1.23
[    5.365411] NET: Registered PF_ALG protocol family
[    6.598601] bcmgenet fd580000.ethernet: configuring instance for external RGMII (RX delay)
[    6.599444] bcmgenet fd580000.ethernet eth0: Link is Down
[    9.518438] Bluetooth: RFCOMM TTY layer initialized
[    9.518476] Bluetooth: RFCOMM socket layer initialized
[    9.518497] Bluetooth: RFCOMM ver 1.11
[   10.687465] bcmgenet fd580000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[  238.018226] bcmgenet fd580000.ethernet eth0: Link is Down
[  241.090770] bcmgenet fd580000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[  242.657892] INFO: task vchiq-keep/0:82 blocked for more than 120 seconds.
[  242.657915]       Not tainted 6.12.34-v8-pr-info+ #22
[  242.657920] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  242.657923] task:vchiq-keep/0    state:D stack:0     pid:82    tgid:82    ppid:2      flags:0x00000008
[  242.657935] Call trace:
[  242.657938]  __switch_to+0x188/0x230
[  242.657953]  __schedule+0xa54/0xb28
[  242.657958]  schedule+0x80/0x120
[  242.657963]  schedule_preempt_disabled+0x30/0x50
[  242.657969]  kthread+0xd4/0x1a0
[  242.657976]  ret_from_fork+0x10/0x20
[  363.491943] INFO: task vchiq-keep/0:82 blocked for more than 241 seconds.
[  363.491987]       Not tainted 6.12.34-v8-pr-info+ #22
[  363.491999] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  363.492008] task:vchiq-keep/0    state:D stack:0     pid:82    tgid:82    ppid:2      flags:0x00000008
[  363.492038] Call trace:
[  363.492046]  __switch_to+0x188/0x230
[  363.492079]  __schedule+0xa54/0xb28
[  363.492095]  schedule+0x80/0x120
[  363.492111]  schedule_preempt_disabled+0x30/0x50
[  363.492126]  kthread+0xd4/0x1a0
[  363.492141]  ret_from_fork+0x10/0x20
[  484.325839] INFO: task vchiq-keep/0:82 blocked for more than 362 seconds.
[  484.325882]       Not tainted 6.12.34-v8-pr-info+ #22
[  484.325894] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  484.325903] task:vchiq-keep/0    state:D stack:0     pid:82    tgid:82    ppid:2      flags:0x00000008
[  484.325933] Call trace:
[  484.325941]  __switch_to+0x188/0x230
[  484.325973]  __schedule+0xa54/0xb28
[  484.325988]  schedule+0x80/0x120
[  484.326003]  schedule_preempt_disabled+0x30/0x50
[  484.326018]  kthread+0xd4/0x1a0
[  484.326035]  ret_from_fork+0x10/0x20
[  605.157552] INFO: task vchiq-keep/0:82 blocked for more than 483 seconds.
[  605.157596]       Not tainted 6.12.34-v8-pr-info+ #22
[  605.157606] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  605.157615] task:vchiq-keep/0    state:D stack:0     pid:82    tgid:82    ppid:2      flags:0x00000008
[  605.157643] Call trace:
[  605.157651]  __switch_to+0x188/0x230
[  605.157682]  __schedule+0xa54/0xb28
[  605.157698]  schedule+0x80/0x120
[  605.157713]  schedule_preempt_disabled+0x30/0x50
[  605.157729]  kthread+0xd4/0x1a0
[  605.157745]  ret_from_fork+0x10/0x20
[  725.989879] INFO: task vchiq-keep/0:82 blocked for more than 604 seconds.
[  725.989918]       Not tainted 6.12.34-v8-pr-info+ #22
[  725.989929] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  725.989939] task:vchiq-keep/0    state:D stack:0     pid:82    tgid:82    ppid:2      flags:0x00000008
[  725.989967] Call trace:
[  725.989976]  __switch_to+0x188/0x230
[  725.990007]  __schedule+0xa54/0xb28
[  725.990022]  schedule+0x80/0x120
[  725.990037]  schedule_preempt_disabled+0x30/0x50
[  725.990053]  kthread+0xd4/0x1a0
[  725.990068]  ret_from_fork+0x10/0x20
[  846.822883] INFO: task vchiq-keep/0:82 blocked for more than 724 seconds.
[  846.822925]       Not tainted 6.12.34-v8-pr-info+ #22
[  846.822936] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  846.822945] task:vchiq-keep/0    state:D stack:0     pid:82    tgid:82    ppid:2      flags:0x00000008
[  846.822974] Call trace:
[  846.822983]  __switch_to+0x188/0x230
[  846.823014]  __schedule+0xa54/0xb28
[  846.823029]  schedule+0x80/0x120
[  846.823044]  schedule_preempt_disabled+0x30/0x50
[  846.823060]  kthread+0xd4/0x1a0
[  846.823075]  ret_from_fork+0x10/0x20
[  967.656157] INFO: task vchiq-keep/0:82 blocked for more than 845 seconds.
[  967.656200]       Not tainted 6.12.34-v8-pr-info+ #22
[  967.656211] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  967.656220] task:vchiq-keep/0    state:D stack:0     pid:82    tgid:82    ppid:2      flags:0x00000008
[  967.656248] Call trace:
[  967.656257]  __switch_to+0x188/0x230
[  967.656290]  __schedule+0xa54/0xb28
[  967.656305]  schedule+0x80/0x120
[  967.656319]  schedule_preempt_disabled+0x30/0x50
[  967.656335]  kthread+0xd4/0x1a0
[  967.656350]  ret_from_fork+0x10/0x20
[ 1088.489535] INFO: task vchiq-keep/0:82 blocked for more than 966 seconds.
[ 1088.489578]       Not tainted 6.12.34-v8-pr-info+ #22
[ 1088.489589] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1088.489598] task:vchiq-keep/0    state:D stack:0     pid:82    tgid:82    ppid:2      flags:0x00000008
[ 1088.489625] Call trace:
[ 1088.489634]  __switch_to+0x188/0x230
[ 1088.489666]  __schedule+0xa54/0xb28
[ 1088.489681]  schedule+0x80/0x120
[ 1088.489695]  schedule_preempt_disabled+0x30/0x50
[ 1088.489711]  kthread+0xd4/0x1a0
[ 1088.489726]  ret_from_fork+0x10/0x20
[ 1209.322955] INFO: task vchiq-keep/0:82 blocked for more than 1087 seconds.
[ 1209.322997]       Not tainted 6.12.34-v8-pr-info+ #22
[ 1209.323008] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1209.323017] task:vchiq-keep/0    state:D stack:0     pid:82    tgid:82    ppid:2      flags:0x00000008
[ 1209.323044] Call trace:
[ 1209.323052]  __switch_to+0x188/0x230
[ 1209.323086]  __schedule+0xa54/0xb28
[ 1209.323100]  schedule+0x80/0x120
[ 1209.323115]  schedule_preempt_disabled+0x30/0x50
[ 1209.323130]  kthread+0xd4/0x1a0
[ 1209.323148]  ret_from_fork+0x10/0x20

Re: [PATCH 4/5] staging: vchiq_arm: Create keep-alive thread during probe

[Stefan Wahren]

Am 28.06.25 um 00:28 schrieb Maíra Canal:
> Hi Stefan,
>
> On 27/06/25 12:18, Stefan Wahren wrote:
>> Hi Maíra,
>>
>> Is this reproducible with a real Raspberry Pi 3 (Plus)?
>
> Yes, it is. It's also reproducible in a RPi 4 with the downstream
> kernel. As RPi OS loads all those media-related modules, to easily
> reproduce the error in RPi OS (without dealing with systemd and such),
> you can just add the following modules to the modprobe blacklist:
>
> blacklist snd_bcm2835
> blacklist bcm2835_v4l2
>
> # only for rpi4
> blacklist bcm2835_codec
> blacklist bcm2835_isp
> blacklist bcm2835_mmal_vchiq
>
> Reboot the device, wait a couple of minutes (2-3 minutes), and you will
> get the warning in the dmesg output.
>
>>
>> Do you use arm64/defconfig or a special kernel configuration?
>
> defconfig
Okay, after disabling all VCHIQ users including VCHIQ_CDEV and enabling 
DETECT_HUNG_TASK, i was able to reproduce it.

I will try to fix that.

Re: [PATCH 4/5] staging: vchiq_arm: Create keep-alive thread during probe

[MichaIng]

 > Okay, after disabling all VCHIQ users including VCHIQ_CDEV and 
enabling DETECT_HUNG_TASK, i was able to reproduce it.

 > I will try to fix that.

Hi Stefan,

is there any progress in this regards, or a way we can help? Would it 
make sense to share the issue to the RPi Ltd. downstream repository?
https://github.com/raspberrypi/linux

We ship images with downstream RPi Ltd. kernel packages, but with 
non-GUI/server setups and low memory usage in mind, we disable/blacklist 
camera and GPU related kernel modules by default, and reduce the 
dedicated GPU memory to the minimal 16 MiB, so that our users report as 
well these errors every few minutes on their main console, until GUI, 
video codec, or camera features are enabled.

I am thinking about letting one kernel module load by default which 
releases the hanging task. But the majority of systems are headless, and 
really don't require any of those. Reducing the console log level or 
muting hung task timeout messages would be another workaround, but that 
could mute important messages as well.

Just in case someone else is in the same situation: I found the VC CMA 
driver "vc_sm_cma" module to be the lightest way of releasing the 
waiting task. Other than the camera/video modules, it does not pull in a 
large stack of dependency modules. With less than 32 MiB GPU memory 
(where the cut-down firmware is used automatically), it fails to 
initialise, but releases the vchiq-keep thread regardless. Its size is 
also tiny compared to the Broadcom camera/video drivers.

-- 
Best regards,

Micha (aka MichaIng)
DietPi project lead

Re: [PATCH 4/5] staging: vchiq_arm: Create keep-alive thread during probe

[Stefan Wahren]

Hi Micha,

Am 24.08.25 um 20:37 schrieb MichaIng:
> > Okay, after disabling all VCHIQ users including VCHIQ_CDEV and 
> enabling DETECT_HUNG_TASK, i was able to reproduce it.
>
> > I will try to fix that.
>
> Hi Stefan,
>
> is there any progress in this regards, or a way we can help? Would it 
> make sense to share the issue to the RPi Ltd. downstream repository?
> https://github.com/raspberrypi/linux
this issue has been fixed in mainline/stable by reverting the commit in 
July. So downstream should have received the fix, too.

Best regards
>
> We ship images with downstream RPi Ltd. kernel packages, but with 
> non-GUI/server setups and low memory usage in mind, we 
> disable/blacklist camera and GPU related kernel modules by default, 
> and reduce the dedicated GPU memory to the minimal 16 MiB, so that our 
> users report as well these errors every few minutes on their main 
> console, until GUI, video codec, or camera features are enabled.
>
> I am thinking about letting one kernel module load by default which 
> releases the hanging task. But the majority of systems are headless, 
> and really don't require any of those. Reducing the console log level 
> or muting hung task timeout messages would be another workaround, but 
> that could mute important messages as well.
>
> Just in case someone else is in the same situation: I found the VC CMA 
> driver "vc_sm_cma" module to be the lightest way of releasing the 
> waiting task. Other than the camera/video modules, it does not pull in 
> a large stack of dependency modules. With less than 32 MiB GPU memory 
> (where the cut-down firmware is used automatically), it fails to 
> initialise, but releases the vchiq-keep thread regardless. Its size is 
> also tiny compared to the Broadcom camera/video drivers.
>

Re: [PATCH 4/5] staging: vchiq_arm: Create keep-alive thread during probe

[MichaIng]

Hi Stefan,

Am 24.08.2025 um 21:58 schrieb Stefan Wahren:
> Hi Micha,
> 
> this issue has been fixed in mainline/stable by reverting the commit in 
> July. So downstream should have received the fix, too.
> 
> Best regards
thanks for the info, I should have checked upstream logs. For 
completeness I am linking them here:
- 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit?id=ebe0b2e
- 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit?id=228af5a5

And on Linux 6.12 branch:
- 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit?h=linux-6.12.y&id=ff62859

Hence next downstream build will contain it.

Best regards,

Micha (aka MichaIng)
DietPi project lead