[iOS 26] thermalmonitord cpu-avg-limiter-input-w2r read failure + SPMI bus faults on iPhone 15 Pro (A17 Pro) — likely driver regression

I have the same problem on a iPhone 17 Pro Max running iOS 26.5.1, 26.5.2 and even 26.6 beta 3 with constant battery drain and thermal problems.

This is the error from the console: **<Error> could not find `cpu-avg-limiter-input-w2r property **

I wonder if the ` before the cpu-avg-limiter-input-w2r property is some kind of typo and that's why thermalmonitord is not able to read that property.

I've done some troubleshooting on my end and discovered two major issues. First, regarding Apple Intelligence, it seems that if the module doesn't download properly, it gets stuck in an endless download loop, which drains the battery rapidly. Either way, there is clearly a flaw with this module, so it's hard to tell if the thermal management or CPU throttling is even working properly. The second issue, which I'm still investigating, is related to cellular data. I'm seeing constant connection attempts to my mobile data provider that keep failing, as if the network is unstable. This one is actually much worse in terms of power consumption. All of this is causing the iPhone to overheat, and I'm not sure if this is what's triggering the iPhone temperature warning message."

I'm not sure what larger issues you're having, but I can talk about this:

Observed errors (continuous, since boot): thermalmonitord fails to read the cpu-avg-limiter-input-w2r property every 5 seconds indefinitely.

Quinn talks about this issue from an API usage perspective in "On Log Noise" but one of the broad issues the log often has is that the messages are often caused by very different issues than it might seem.

The system is enormously complex and the log is basically the accumulated combination of:

1. Important/useful information that couldn't be outputted through any other means.

2. Useful debugging and analysis data relevant to a specific component.

3. Noise that's basically irrelevant.

However, what's not obvious here is that #1 is by FAR the LEAST common data in the log. One of the system's primary "jobs" is communicating problems or failures to the user and logging to the system log does NOT qualify as meeting that goal. The system does log critical errors as a "backup" and there are components/situations where it doesn't have very many alternatives (low level kernel failures, pre-boot issues, etc.) but, in general, the system’s job is to tell you if/when something has gone wrong, not blindly log it and otherwise ignore the problem.

That then leads to here:

1. Noise that's basically irrelevant.

And more specifically this sort of issue:

The kernel logs SPMI bus faults

As a component, the kernel has a relatively limited ability to interact with the user. Basically, its only choices are:

1. Log messages and hope someone "notices".

2. Use some kind of dedicated user space component to specifically inform the user of an issue (this is how thermal and low memory warnings occur).

3. Catastrophically break things, either by terminating or by panicking the entire system.

That's not a lot of options, particularly since #2 is both complicated to implement and only useful when the issue is something that's actually relevant to the user. For "low grade" issues where the kernel would "like" something to stop but the issue isn't really causing any problems, its only real option is to log.

That leads to here:

thermalmonitord fails to read the cpu-avg-limiter-input-w2r property every 5 seconds indefinitely

As far as I can tell, this is just noise. The exact history isn't clear, but it looks like this was a property we stopped actively using several years ago (~iOS 15) but left in place. This isn't unusual, as it allows the kernel to improve and evolve without forcing every other component to immediately alter its implementation. It also helps smooth over the differences between devices by allowing user space code to use exactly the same code flow for all devices, even if part of that code flow is only relevant to some of those devices.

As to why the message itself specifically started on iOS 26, my guess is that what actually happened is that the kernel fully removed the property, likely as part of some larger rework.

Now, anticipating your question, if none of this matters, why haven't we either stopped logging or fixed the "problem"? Well...

In terms of removing the logging:

As I talked about above, the kernel often has very few options OTHER than simply logging the failure. Indeed, the reason the kernel often ends up logging messages like "failed write" is that it DIDN'T actually fail the write. That is, instead of returning an error (which risked breaking some part of the system), it "lied" to user space (to ensure nothing broke) by returning "success", logged a message (so that there was SOME evidence of an "issue"), and then... did nothing.

In terms of fixing the problem:

The obvious solution here would be for the user space component to "stop" whatever it was doing. There isn't any single reason why that doesn't "immediately" happen, but the biggest factor is that we try to minimize the possibility that software updates will introduce new bugs by keeping the number of changes in that software update as small as possible. That's particularly true of low-level components like the kernel or the heat management system, where the impact is potentially very broad.

Keep in mind that this isn't just about the risk of the specific fix (removing a log message is about as low risk as it gets), but is also about managing the overall complexity of any given update. The best way to ensure that a given component can't introduce new bugs is to not change that component.

Finally, I want to return to something I said earlier:

One of the system's primary "jobs" is communicating problems or failures to the user, and logging to the system log does NOT qualify as meeting that goal.

It's critical to understand that the console log isn't really "for" "you". That is, the point of the console log ISN'T really to communicate useful information to the end user or even to developers. The better way to understand the console log is that it's essentially the system’s internal monologue with "itself". Most of its messages are the equivalent of a person (individual component/subsystem/process) mumbling to themself as they go about their normal business. Some of those messages are essentially one part of the system "yelling" at another component to encourage that other component to change what it's doing, with the tiny part that left over occasionally being real failures.

There are certainly situations where this internal monologue can be an incredibly useful diagnostic tool, but its nature and limitations need to be understood. For example, it's much more useful for trying to investigate a specific point failure in a particular component ("What was happening when my app crashed at <time>") than it is at investigating broad, general failures ("Why is my device <insert>").

Most critically, it's VERY bad at "finding" problems ("Let me look at the log to see what's wrong with my machine"). To be blunt, the system and our log message are sufficiently complex that any reasonably long interval (say, 5+ min) is all but guaranteed to include one or more messages that appear to indicate some "problem"[1]. That's simply a side effect of how that internal monologue comes about, not necessarily because anything is actually broken.

[1] I mean that quite literally. I now make it a point that I only really investigate system log data when a developer can describe a specific problem that happened within a specific time window. I've wasted far too much time trying to figure out "problems" that turned out to be nothing more than a series of unrelated log messages that ended up sounding vaguely problematic.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware