R7500v2 kernel 4.19 test

and get to be the scapegoat again for usb3 corruptions? Nah.

1 Like

if its your decision to make (i honestly don't know), then do so when you think its ready. I appreciate the effort and hope this thread doesn't cause grief to those who are making contributions.

Well we can at least push it as kernel testing.. by keeping it there we will never discover if we actually have problems with it. IMHO we need more tester. I'm not forcing you but mvebu and others target are already at 4.19 so... Anyway sorry if I caused you trouble.

average of 3 usb (buffered) disk reads via hdparm -tT /dev/sdx

Ubuntu 18.04.2 LTS (using a usb3 express card adapter), average of 3
average: 92.20 MB/s; stdev: 0.10;

r7500v2, 4.19.53
root@OpenWrt:~# uptime
11:04:03 up 1 day, 13:28, load average: 0.01, 0.02, 0.00
average: 88.69 MB/s; stdev: 0.89;

almost 4% slower which for me is not signifcant

well 4% from a x86 system is not that bad

I thought I'd take a look at the cpuidle and thermal sensor errors. My gut says these are not too important, perhaps already resolved, but something I can learn from.

This forum thread looks helpful regarding the thermal sensors - I'm still chewing through that.

EDIT: I'm still working through understanding cpuidle...

about cpu idle i just think that from kernel 4.14 to 4.19 they changed some struct that cpuidle custom driver use... the strange part is that it does compile without any complain... sooooooo ????

ty for responding.

I suppose it would be more beneficial to the community if I posted about the thermal sensors. I just suspect the fix for that is likely already known or easily adapted from previous efforts.

Searching around indicates the cpuidle error turns up elsewhere but I've not (yet) seen anyone talk much about it; hence, I suspect its not that important.

I was really looking for methods to track changes in the kernel tree so I could spot what changed a little more quickly. I suppose cloning the kernel tree via git and then using git log is better. @hnyman has good skills... This is only educational for myself and likely does not have much benefit to others. For the moment, I've fallen back into old habits, download 4.14 and 4.19 source, made some etags files, did some light source code reading and this also helped.

looking at the kernel files.... i notice that the config flag ARM_QCOM_CPUIDLE doesn't point to anything and does only selects arm-cpuidle...

the actually driver is not present the cpuidle driver dirs

this is the most recent patch i found of the actual qcom-cpuidle driver


will try to compile with this

umm, the comment at the top of linux-4.19.53/drivers/cpuidle/cpuidle-arm.c says this file is the driver, and it is present. However,

root@OpenWrt:~# cat /sys/devices/system/cpu/cpuidle/current_driver 

and from my build log:

* ARM CPU Idle Drivers
Generic ARM/ARM64 CPU idle Driver (ARM_CPUIDLE) [N/y/?] (NEW)  

which looks like it didn't get selected.

EDIT: but that's no different than my last 4.14 compile and I don't know what current_driver gives for 4.14 so I'm back to clueless

from more research i think that cpuidle-qcom got ""meged"" to cpuidle-arm

can you test if cpuidle worked in 4.14? (if cat /sys/devices/system/cpu/cpuidle/current_driver gives different output... )

sure, but the router is in use so I'll have to wait a bit.

1 Like

In the mean time, I have a guess as to why I see the error on 4.19 but not 4.14.

between 4.14 and 4.19 the cpuidle-arm.c driver was changed. In 4.14, the driver was registered and then initialized (initialization is the point at which the error msg I see is generated).

In 4.19, the driver registration code was moved to below the the initialization code.

Since the initialization code is executed at least once before the driver is registered the error pops up. After that first time, the driver gets registered (I never see the error msg "Failed to register cpuidle driver", the initialization code probably gets called again later but this time the driver is registered so no more cpuidle error msgs. i.e. the cpuidle driver is present and working on 4.19

so we should do some magic in the dts like we do for usb....

1 Like

no, don't think so. Now the patch I saw (and edited out of) my earlier post is starting to make more sense (as well as the follow on patch. It seems the authors intent is to print the error msg.

Since I'm not entirely sure I know the authors intent yet, I wouldn't propose "fixing" anything just now. I would like to know why current_driver is "none" on 4.19 and what it reports on 4.14.

got to be domestic for a time... bbl

cat /sys/devices/system/cpu/cpuidle/current_driver

from trunk R7800 4.14

1 Like

@nmrh i think this is our answer...

or not.........

ok, so maybe there is something to fix here.

there is a default cpuidle driver if all others fail (documented in kernel 5.0 here but I think this still is in 4.19). sysfs.c (which provides the output to



	drv = cpuidle_get_driver();
	if (drv)
		ret = sprintf(buf, "%s\n", drv->name);
		ret = sprintf(buf, "none\n");

which I interpret as "none" means the kernel is using the default driver and not arm_idle

This commit message refers to the cpuidle 4.19 code as a regression so I can try to edit what's in openwrt ipq1806x 4.19 to look like what is now in the linux kernel master and see if behaves as expected.

I'm not sure I see the error - perhaps with the dev stuff and goto statements that all got removed in the commit.

I'll definitely look over what @ansuel just posted as well

will backport this and try to compile


let's hope they didn't made massive changes between 4.19 and 5.0 to the cpuidle stock driver

I think you'll need to hand edit, I dont think the commit will apply cleanly.