Bug 278188 - Marvell Armada 385: clkdev_device_lock not implemented after upgrade to 14.0
Summary: Marvell Armada 385: clkdev_device_lock not implemented after upgrade to 14.0
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: arm (show other bugs)
Version: 14.0-RELEASE
Hardware: arm Any
: --- Affects Many People
Assignee: freebsd-arm (Nobody)
URL:
Keywords: crash, regression
Depends on:
Blocks:
 
Reported: 2024-04-05 20:54 UTC by solo_code
Modified: 2024-04-17 16:10 UTC (History)
1 user (show)

See Also:

Attachments
Kernel config (1.53 KB, text/plain)
2024-04-05 20:54 UTC, solo_code 		no flags Details
implement armada38x_gateclk clkdev methods (4.02 KB, patch)
2024-04-17 16:10 UTC, Mitchell Horne 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description solo_code 2024-04-05 20:54:02 UTC 
Created attachment 249745 [details]
Kernel config

I run FreeBSD on this NAS SBC for several years now:

https://wiki.kobol.io/helios4/intro/

It has a Marvell Armada 385 SOC. After updating to 14.0 and issuing "sysctl -a" I get this kernel panic:

panic: clkdev_device_lock not implemented
cpuid = 1
time = 1712347555
KDB: stack backtrace:
#0 0xc029ad50 at kdb_backtrace+0x40
#1 0xc0243adc at vpanic+0x140
#2 0xc024399c at vpanic+0
#3 0xc007e4d4 at clkdev_default_device_unlock+0
#4 0xc007f5b0 at clknode_gate_get_gate+0x68
#5 0xc007bd24 at clknode_sysctl+0x164
#6 0xc0257c9c at sysctl_root_handler_locked+0x10c
#7 0xc02570f4 at sysctl_root+0x220
#8 0xc0257710 at userland_sysctl+0x178
#9 0xc0257554 at sys___sysctl+0x7c
#10 0xc0586738 at swi_handler+0x148
#11 0xc05677c4 at swi_exit+0

My kernel config (attached) is very close to "sys/arm/conf/ARMADA38X", so this might be a bug.
Comment 1 Mitchell Horne freebsd_committer freebsd_triage 2024-04-17 16:10:12 UTC 
Created attachment 250030 [details]
implement armada38x_gateclk clkdev methods

Are you able to test changes easily?

The attached change will, I believe, resolve the problem. I do not have access to this hardware myself, however.

The commit 1a74d77f85121 seems to have introduced new sysctl nodes exporting the status of gated clocks. The relevant clock driver for this hardware appears incomplete, and so we see the resulting panic.