Error message at boot: ti-sysc 44e31000.target-module: probe with driver ti-sysc failed with error -16

[s13n]

I am getting this error message at boot on a BeagleBone based on the AM335x (I tried Green and Enhanced) using kernel 6.15.4-bone18 from the Debian I installed using the imaging utility.

The error appears to trigger an error output from function sysc_check_active_timer() with error code -EBUSY. I suspect that it is about the system timer that is somehow misconfigured, or maybe the error logic in ti-sysc.c is somehow wrong. In particular, I don't understand why this error should lead to the probe to fail entirely.

[RitikaSen27]

Hi,

I’ve been looking into this boot-time error on AM335x (BeagleBone Green / Enhanced) with 6.15.4-bone18 and was able to locate the failure path in sysc_check_active_timer() returning -EBUSY, which then causes the probe to fail.

From a quick read of drivers/bus/ti-sysc.c, it seems that an active timer is treated as a fatal condition during probe, even though the hardware may already have the timer enabled by firmware or an earlier boot stage. I’m not yet convinced this should always result in a hard probe failure, especially on AM335x where timers can legitimately be running early.

I’d like to dig deeper into whether this is a regression in the current kernel, a DT-related mismatch, or overly strict error handling in ti-sysc. My plan is to:

Trace which timer instance triggers sysc_check_active_timer()

Compare behavior with earlier bone kernels where this did not occur

Check whether probe failure could be downgraded to a warning or deferred handling in this case

If that sounds reasonable, I’d be happy to investigate further and propose a fix or improvement.

Thanks!

[davidjohnsummers]

Has there been an update on this? Think at the mo I'll just consider the error as benign, and just push the kernel config as correct?

[RitikaSen27]

Apologies for the delayed response, and thanks for following up.

I took an initial look at the issue earlier, but I wasn’t able to proceed further as I currently don’t have access to a BeagleBone setup to reproduce and debug the problem.

Given that, I won’t be able to investigate this properly at the moment. I appreciate your time and the follow-up, and I may revisit this once I have the required hardware setup.

Thanks.

[davidjohnsummers]

Ta - thanks for updated. I may do some investigation here - if time allows.

[RitikaSen27]

Thanks for taking a look, I appreciate it.

I don’t currently have access to the hardware to reproduce this, but I’d be happy to help test or verify anything once I have a working setup. Please let me know if there’s anything specific I can check in the meantime.

Thanks again.