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
https://patchwork.kernel.org/patch/5389101/
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
none
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
arm_idle
from trunk R7800 4.14
1 Like
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
/sys/devices/system/cpu/cpuidle/current_driver
has
drv = cpuidle_get_driver();
if (drv)
ret = sprintf(buf, "%s\n", drv->name);
else
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.
yhea... but the real problem will be make it compile...
idk, maybe not - i'd just stick to the cpuidle-arm.c code to start and see if it complies and gives something different in current_driver
BTW what do you see in current_driver for r7800 kernel 4.19?