modprobe of speakup modules on ARM RT kernel ends up in a lockup of module loading
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ubuntu-realtime |
New
|
Medium
|
Unassigned | ||
linux (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
Noble |
New
|
Undecided
|
Unassigned |
Bug Description
ARM64, Ubuntu Noble, RT kernel 6.8.1.1002-realtime in VM (using virt-manager), hosted on a 24 proc ARM server with 24 processor ARM64 client server installation.
In theory, loading modules that the H/W does not support should not cause subsequent module loading issues. The speakup modules on a VM ARM64 server image don't seem to follow this rule.
Example
root@noble-
root@noble-
[ 621.072682] INFO: task modprobe:1703 blocked for more than 122 seconds.
[ 621.072786] Not tainted 6.8.1-1002-realtime #2-Ubuntu
[ 621.072794] "echo 0 > /proc/sys/
message.
The loading of the speakup_apolloc is locked up on a rt_mutex_slowlock, dmesg reports:
[ 388.982489] input: Speakup as /devices/
[ 388.985305] initialized device: /dev/synth, node (MAJOR 10, MINOR 122)
[ 388.986350] speakup 3.1.6: initialized
[ 388.986366] synth name on entry is: (null)
[ 388.996839] synth probe
[ 621.072682] INFO: task modprobe:1703 blocked for more than 122 seconds.
[ 621.072786] Not tainted 6.8.1-1002-realtime #2-Ubuntu
[ 621.072794] "echo 0 > /proc/sys/
[ 621.072799] task:modprobe state:D stack:0 pid:1703 tgid:1703 ppid:1687 flags:0x00000004
[ 621.072821] Call trace:
[ 621.072826] __switch_
[ 621.072849] __schedule+
[ 621.072859] rt_mutex_
[ 621.072874] rt_mutex_
[ 621.072887] __rt_mutex_
[ 621.072898] __rt_mutex_
[ 621.072912] mutex_lock+
[ 621.072922] synth_add+
[ 621.072995] synth_apollo_
[ 621.073019] do_one_
[ 621.073031] do_init_
[ 621.073043] load_module+
[ 621.073053] init_module_
[ 621.073064] idempotent_
[ 621.073074] __arm64_
[ 621.073085] invoke_
[ 621.073095] el0_svc_
[ 621.073105] do_el0_
[ 621.073113] el0_svc+0x44/0x1c0
[ 621.073125] el0t_64_
[ 621.073137] el0t_64_
Changed in ubuntu-realtime: | |
importance: | Undecided → Medium |
Hi Colin, I've consistently reproduced this issue in QEMU VMs on arm64 realtime (6.8.1. 1002-realtime) . However, it also occurs with the generic kernel (6.8.0-35-generic) on arm64. I couldn't get it to happen with amd64.
Here's the dmesg output on 6.8.0-35-generic after the modprobe gets stuck:
[ 303.168453] input: Speakup as /devices/ virtual/ input/input1 kernel/ hung_task_ timeout_ secs" disables this message. to+0xbc/ 0xf0 0x2a8/0x7b0 preempt_ disabled+ 0x30/0x68 lock.constprop. 0+0x31c/ 0x5d0 lock_slowpath+ 0x20/0x48 0x8c/0xc0 0x3c/0x110 [speakup] init+0x24/ 0xff8 [speakup_apollo] initcall+ 0x64/0x3b8 module+ 0xa4/0x280 0x7b8/0x8f0 from_file+ 0x98/0x118 init_module+ 0x1a4/0x2c8 sys_finit_ module+ 0x70/0xf8 syscall+ 0x7c/0x128 common. constprop. 0+0x4c/ 0x140 svc+0x28/ 0x58 sync_handler+ 0x148/0x158 sync+0x1b0/ 0x1b8
[ 303.174246] initialized device: /dev/synth, node (MAJOR 10, MINOR 122)
[ 303.176539] speakup 3.1.6: initialized
[ 303.176600] synth name on entry is: (null)
[ 303.187469] synth probe
[ 492.396049] INFO: task modprobe:1042 blocked for more than 122 seconds.
[ 492.397557] Not tainted 6.8.0-35-generic #35-Ubuntu
[ 492.398493] "echo 0 > /proc/sys/
[ 492.399616] task:modprobe state:D stack:0 pid:1042 tgid:1042 ppid:1041 flags:0x00000004
[ 492.401357] Call trace:
[ 492.401789] __switch_
[ 492.403196] __schedule+
[ 492.403312] schedule+0x40/0x168
[ 492.403363] schedule_
[ 492.403408] __mutex_
[ 492.403454] __mutex_
[ 492.403502] mutex_lock+
[ 492.403541] synth_add+
[ 492.404115] synth_apollo_
[ 492.404213] do_one_
[ 492.404260] do_init_
[ 492.404316] load_module+
[ 492.404364] init_module_
[ 492.404412] idempotent_
[ 492.404459] __arm64_
[ 492.404511] invoke_
[ 492.404563] el0_svc_
[ 492.404763] do_el0_
[ 492.404823] el0_svc+0x44/0x1a0
[ 492.404874] el0t_64_
[ 492.404926] el0t_64_
We'll continue investigating this.