Re: Tiny Core v17.0 upgrade issues

[Rich]

Hi Stefann
It's looking in the wrong place:

...

Code: [Select]

tc@hp510: ----- Snip -----

modprobe: can't load module p4-clockmod.ko.gz (kernel/drivers/cpufreq/p4-clockmod.ko.gz): No such device

 ----- Snip ----- ...

It should either try to load (full path):

Code: [Select]

/lib/modules/6.18.35-tinycore/kernel/drivers/cpufreq/p4-clockmod.ko.gzor in this case (current directory):

Code: [Select]

./p4-clockmod.ko.gz
You shouldn't need to do this, but try:

Code: [Select]

sudo /sbin/depmod -a
sudo /sbin/udevadm trigger
sudo modprobe p4-clockmod.ko.gz
If that fails, try:

Code: [Select]

sudo modprobe /lib/modules/6.18.35-tinycore/kernel/drivers/cpufreq/p4-clockmod.ko.gz
If it still fails, try:

Code: [Select]

sudo modprobe /lib/modules/$(uname -r)/kernel/drivers/cpufreq/p4-clockmod.ko.gz

[Stefann]

Thanks Rich,

I actually already tried full path already in previous post without success
But anyways... I tried all your suggestions but zero success (data at end of this post).

The strange thing is:
ls -l command clearly shows p4-clockmod.ko.gz to be present in the correct directory, and "not being zero bytes".
But modprobe reports it cannot find it there.

Anyway... don't break your head about it to much.
At least acpi-cpufreq.ko.gz  did work and I got valid content in  scaling_governor
This is my 2nd system "just being a sandbox".
I think I will stop the 5day run on my primary system tomorrow around noon, 5hrs shy of 5 days, Than I have plenty things to try in the afternoon.
- look for power spikes with osciloscope
- test power settings and measure with energy meter
- conclude towards a viable configuration and start it for at least a 24hr testrun.

thanks being with me on this!!

Code: [Select]

tc@hp510:/lib/modules/6.18.35-tinycore/kernel/drivers/cpufreq$ sudo modprobe p4-clockmod.ko.gz
modprobe: can't load module p4-clockmod.ko.gz (kernel/drivers/cpufreq/p4-clockmod.ko.gz): No such device

tc@hp510:/lib/modules/6.18.35-tinycore/kernel/drivers/cpufreq$ sudo modprobe ./p4-clockmod.ko.gz
modprobe: module ./p4-clockmod.ko.gz not found in modules.dep

tc@hp510:/lib/modules/6.18.35-tinycore/kernel/drivers/cpufreq$ sudo /sbin/depmod -a
tc@hp510:/lib/modules/6.18.35-tinycore/kernel/drivers/cpufreq$ sudo /sbin/udevadm trigger

tc@hp510:/lib/modules/6.18.35-tinycore/kernel/drivers/cpufreq$ sudo modprobe p4-clockmod.ko.gz
modprobe: can't load module p4-clockmod.ko.gz (kernel/drivers/cpufreq/p4-clockmod.ko.gz): No such device

tc@hp510:/lib/modules/6.18.35-tinycore/kernel/drivers/cpufreq$ sudo modprobe /lib/modules/6.18.35-tinycore/kernel/drivers/cpufreq/p4-clockmod.ko.gz
modprobe: module /lib/modules/6.18.35-tinycore/kernel/drivers/cpufreq/p4-clockmod.ko.gz not found in modules.dep

tc@hp510:/lib/modules/6.18.35-tinycore/kernel/drivers/cpufreq$ sudo modprobe /lib/modules/$(uname -r)/kernel/drivers/cpufreq/p4-clockmod.ko.gz
modprobe: module /lib/modules/6.18.35-tinycore/kernel/drivers/cpufreq/p4-clockmod.ko.gz not found in modules.dep

tc@hp510:/lib/modules/6.18.35-tinycore/kernel/drivers/cpufreq$ ls -l p4*
-rw-r--r--    1 tc       staff         2447 Jun 20 02:14 p4-clockmod.ko.gz
    [Edit]: Added blank lines inside code tags for readability.  Rich

[Rich]

Hi Stefann
Two more things. What do these commands return:

Code: [Select]

ls -l /lib/modules/$(uname -r)/modules.dep
grep "p4-clockmod" /lib/modules/$(uname -r)/modules.dep

[Stefann]

Hi Stefann
Two more things. What do these commands return:

Code: [Select]

ls -l /lib/modules/$(uname -r)/modules.dep
grep "p4-clockmod" /lib/modules/$(uname -r)/modules.dep

Note, system still running. No crash in 4.5 day.
I have other obligations today. Not sure whether I have time to spend in this today, if not it will become tomorrow.

On the commands:
On my primary system (note, “huis” is Dutch for “home”, it’s my home control computer):

Code: [Select]

tc@huis:~$ ls -l /lib/modules/$(uname -r)/modules.
dep
-rw-r--r--    1 tc       staff        69582 Jun 20 02:16 /lib/modules/6.18.35-tinycore/modules.dep
tc@huis:~$ grep "p4-clockmod" /lib/modules/$(uname -r)/modules.dep
kernel/drivers/cpufreq/p4-clockmod.ko.gz: kernel/drivers/cpufreq/speedstep-lib.ko.gz
tc@huis:~$

On my 2nd, sandbox system:

Code: [Select]

tc@hp510:~$ ls -l /lib/modules/$(uname -r)/modules
.dep
-rw-r--r--    1 tc       staff        69582 Aug 29 16:15 /lib/modules/6.18.35-tinycore/modules.dep
tc@hp510:~$ grep "p4-clockmod" /lib/modules/$(uname -r)/modules.dep
kernel/drivers/cpufreq/p4-clockmod.ko.gz: kernel/drivers/cpufreq/speedstep-lib.ko.gz
tc@hp510:~$

[gadget42]

being curious, i did this on a handy devuan system(bare metal if that makes a difference):

Code: [Select]

root@somewhere:/lib/modules/6.1.0-52-amd64/kernel/drivers/cpufreq# uname -a
Linux somewhere 6.1.0-52-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.180-1 (2026-08-03) x86_64 GNU/Linux
root@somewhere:/lib/modules/6.1.0-52-amd64/kernel/drivers/cpufreq# ls -hl /lib/modules/$(uname -r)/modules.dep
-rw-r--r-- 1 root root 515K Aug  5 10:27 /lib/modules/6.1.0-52-amd64/modules.dep
root@somewhere:/lib/modules/6.1.0-52-amd64/kernel/drivers/cpufreq# grep "p4-clockmod" /lib/modules/$(uname -r)/modules.dep
kernel/drivers/cpufreq/p4-clockmod.ko: kernel/drivers/cpufreq/speedstep-lib.ko
root@somewhere:/lib/modules/6.1.0-52-amd64/kernel/drivers/cpufreq# modprobe /lib/modules/6.1.0-52-amd64/kernel/drivers/cpufreq/p4-clockmod.ko
modprobe: FATAL: Module /lib/modules/6.1.0-52-amd64/kernel/drivers/cpufreq/p4-clockmod.ko not found in directory /lib/modules/6.1.0-52-amd64(everything in the cpufreq directory modprobed fatal, just an fyi)

Stefann is not alone...hmmm...

strange/weird.

[Rich]

Hi Stefann
I see what's going on now.
In your reply #221, the first error listed is:

Code: [Select]

modprobe: can't load module p4-clockmod.ko.gz (kernel/drivers/cpufreq/p4-clockmod.ko.gz): No such devicewhich means there are no devices present that are usable with that driver.

Error number 2:

Code: [Select]

modprobe: module ./p4-clockmod.ko.gz not found in modules.depwas caused by me. modprobe treated  ./  as part of the file name.It's listed as
p4-clockmod.ko.gz  in  /lib/modules/6.18.35-tinycore/modules.dep  so it was
not found.

Error number 3 is the same as the first error.

Errors 4 and 5 are like error number 2. modprobe treated the added path
as part of the file name.

So what's the problem? The problem was I didn't pay close enough attention
to what the error message said. There is no problem. It worked as it should.

[Stefann]

@rich, Thanks for analyzing, so thats one worry less

This afternoon System was still running after 4.9 days. I stopped it manually to do some tests.
SO:
- original configuration: crash within 24hrs; 2 times at a row.
- 100ms additional delay per loop (at 3 loops/second): no crash even after 4.9 day.

I did some power measurements:

Code: [Select]

5.5W baseload, no apps running, monitor and keyboard disconnected
6.7W run application
6.5W run application with 100ms delay per loop (about 3 loops/second so app load reduced by 33%)
7.8W reboot tinycore

Than:
+0.6W spike per minute --> caused by crontab running a php script that does a curl http call
+1.5W spike few times per hour --> caused by python script that gets called every 20 minutes.
+0.1W connect monitor
+0.4W screen change on monitor
+0.5W connect keyboard
+0.0W boot in textmode (so: text & gui mode have same power usage)
also spent last few days to get some specifications on my system:
1.0W tpd for cpu: Via Eden ULV 500MHz 1core 32bit
3.5W tpd for "digital media chipset": single chip VX700 (graphics, sound, usb, power, monitor, keyboard, mouse, HD)

Given these tpd's:
- "5.5W for total system is not strange"
- up to +1W in case of high load is also not strange. My application normally runs below 10% cpu load so high cpu load could easily add the full 1W tpd of the processor
- +1.5W from python script is a bit strange. processor has 1W tpd, how can high load create more extra load than 1 W??

My conclusion "towards the crashing"
- With all these extras around 8...9W peak-use "is not strange". At 5V that implies 1.8A which is quite close to the 2A rating of the ups I'm currently using. So "crash from overload is quite possible". It would probably be triggered from the python script. The 100ms delay did save 0.2W on the load which could "just be enough" to "not crash".

Next test I did start:
- start again with monitor and keyboard connected powered by ups, 0ms extra delay. Basically exactly the same configuration that last week crashed within 24hrs 2x at a row.
- but.... added 2x 4700uF condensator on the 5V power line. The idea is that this "hopefully suppresses power dips"
- I want to see whether this can run a few days. If yes... that would proof "this is fixable with zero software modification" and as a result proof "this is not a software issue".
- note: alternatively I can/could disconnect the keyboard to reduce 0.5W. I first wanted to test "exactly same config only with added stabilization on powerline"

Additionally:
- I did use my osciloscope from 1966 to check the power line while starting applications and doing a reboot. I was not able to see any spike. Only thing I could see was the very high frequency ripple from the switching power supply.
- note: using the scope was an adventure in itself. I had not powered it up in 15 or 20 years. It's made with vacuum tubes so it needs to heat. It drifts like hell. Alls switches needed to be switched multiple times as they were 'cracky'. Anyway... it worked just enough to check on high frequent disturbance and/or dips. Unfortunately I did not see dips.

[Rich]

Hi Stefann

... - +1.5W from python script is a bit strange. processor has 1W tpd, how can high load create more extra load than 1 W?? ...

Because you are not measuring the processor separately.

When the script runs, there is additional activity on the address and data
busses as the script gets loaded and executed in RAM. Additional one and
zero transitions result in additional current consumption by address latches,
data buffers, and RAM. Any peripherals accessed will consume more current
if they are being awakened from a low power mode.

In addition, a power supply will incur some losses. If output power demand
increases by 1 watt, input power being drawn might increase by 1.1 watts.

[Stefann]

Hi Stefann

... - +1.5W from python script is a bit strange. processor has 1W tpd, how can high load create more extra load than 1 W?? ...

Because you are not measuring the processor separately.

When the script runs, there is additional activity on the address and data
busses as the script gets loaded and executed in RAM. Additional one and
zero transitions result in additional current consumption by address latches,
data buffers, and RAM. Any peripherals accessed will consume more current
if they are being awakened from a low power mode.

In addition, a power supply will incur some losses. If output power demand
increases by 1 watt, input power being drawn might increase by 1.1 watts.

Ah.. yes… that makes an enormous amount of sense.
To be honest… I deliberately had selected a 1 watt cpu. I was of course expecting some overhead, but had never imagined it would go to something close to 10 watt or even more.
As said I did some digging last week and found that the “digital media chipset” (of whatever it is called) draws 3.5 watt. 3.5x as much. I had never expected that.

Anyway…
Let’s see where current test brings me.
During measuring with the oscilloscope I did not see any movement in the supply voltage. Even not during boot which was drawing the most power. So it looks like the supply is capable of giving enough power on the seconds timescale. The ripple from the switching power supply is probably 10…30kHz (difficult to say because the old device was not syncing well). That also means it has a reaction time of about 30us. So “powerdips below 30us may very well have been there”. Such dips will well get suppressed by the added condensators.

All in all: this is also quite an adventure. Although I kind of hate the crashes on a system that is live controlling my home, I really appreciate all knowledge that I’m gathering here.

[Rich]

Hi Stefann

... looks like the supply is capable of giving enough power on the seconds timescale. ...

That's way too slow. Even at  1 Sec/Div  you're talking about 10 seconds for 1 sweep
across the screen.

If there's a voltage dip, I would expect it to be in the millisecond range. The only way
you would catch that at such a slow sweep would be with a storage scope.
__________________________________________________________________________________

I would suggest the following settings for voltage dips:

Vertical - 200mV/Div (20mV/Div if using a X10 probe)
           AC coupled
           Position the trace one major division below the top.

Horizontal - 5 mSec/Div

X Magnification - X1

Trigger - Normal (Auto)

Boot Tinycore and see if anything shows up.
__________________________________________________________________________________

I would suggest the following settings for voltage spikes:

Vertical - 200mV/Div (20mV/Div if using a X10 probe)
           AC coupled
           Position the trace on the center major division.

Horizontal - 5 uSec/Div

X Magnification - X1

Trigger - Normal, Set the level to trigger on the negative peaks, then adjust
          the level a little further so the beam disappears.

Boot Tinycore and the scope will trigger on spikes more negative than the
baseline you set for  Trigger. Watch for excessive negative amplitudes.
__________________________________________________________________________________

Repeat the above except:

Trigger - Normal, Set the level to trigger on the positive peaks, then adjust
          the level a little further so the beam disappears.

Boot Tinycore and the scope will trigger on spikes more positive than the
baseline you set for  Trigger. Watch for excessive positive amplitudes.

[Stefann]

Hi Rich,
Ah…. I was probably not completely clear on how I tested with the scope.
For sure on fast setting, I think about 100us/div or so. I tested multiple settings to find a sweet spot.
Tested both ac and dc settings
Ac with more sensitive y (10mV) to try to see high frequency dips.
Dc with less sensitive y (100mV with dc compensation) to see any signs of supply not being able to hold value.
The triggering went on continuously, was not able to stop it.
Note that I have quite some experience with this scope. I used it intensively for 25 years between 1975 and 2000.
But… it’s a very old one, 1966, https://www.radiomuseum.org/r/philips_hf_zweistrahl_oszillogra.html.
Indeed not a storage scope.
I tested things multiple times, watching the screen minutely. Especially during boot and the python script.

What I intended to say when I said “second scale”
- there is zero sign of the power supply no being capable of delivering the higher wattages (8…9 watt).
- even during a boot that draws about 8watt the line on the scope is rock stable, both on ac setting and dc setting. Zero dropping of value.
- it’s not a storage scope but I expect I would at least have seen any 1 volt 10ms event or 0.1 volt 100ms event. Probably even 10x better. No such spikes.

At the same time I DO see a ripple. I forgot to measure the frequency and amplitude exactly but from memory I think it’s 10..30kHz at about 20mV. The reason I did not write down numbers of this is because triggering was very poor so I did not feel writing down values was meaningfull.
At this moment the ripple is completely gone since i now have 2x 4700uF on the Powerline so I can not go back now to measure.
However…..
This ripple made me think…
This is basically means that the power regulator is not controlling frequencies above 30kHz which means that 1us spikes will pass.
By adding the capacitor that mechanism is blocked.
2x 4700uF is likely huge overkill. 100uF would probably be enough. Overkill for finding a rootcause is however not a bad thing.

Note…
If rootcause indeed is “in adequate suppression of high frequent power current spikes”, than that is not necessarily a shortcoming of the power supply. Original crashes were with a well rated 3.5A power adapter.
These power adapters are however not specced for high frequency behavior.
It may very well be a vulnerability of my computer: “Inadequate filtering of Powerline”.
There may even be a capacitor installed. It may simply have weared out of past 18 years.

First see whether I can 100% nail down this rootcause.
After that I can see whether a smaller capacitor also works. I can also see whether it still crashes with usb-serial active, also at blocking setting, also with original power adapter.
Loads of things to evaluate. But…… first see whether it’s stable now..

At this moment still running after 15 hours.

[gadget42]

...
Additionally:
- I did use my osciloscope from 1966 to check the power line while starting applications and doing a reboot. I was not able to see any spike. Only thing I could see was the very high frequency ripple from the switching power supply.
- note: using the scope was an adventure in itself. I had not powered it up in 15 or 20 years. It's made with vacuum tubes so it needs to heat. It drifts like hell. Alls switches needed to be switched multiple times as they were 'cracky'. Anyway... it worked just enough to check on high frequent disturbance and/or dips. Unfortunately I did not see dips.

definitely remember those mechanical "crackling" contacts/switches/etc. and the "tv tuner" we always carried on all the service calls.

memory lane(for the radioshack branded spray):
https://i.etsystatic.com/17806151/r/il/8405db/6805596382/il_680x540.6805596382_7br0.jpg

[Rich]

Hi Stefann

Ah…. I was probably not completely clear on how I tested with the scope. ...

That's OK. I figured you were probably juggling between two languages which
makes communicating a little more difficult.

... The triggering went on continuously, was not able to stop it. ...

That could be due to the scopes trigger circuitry itself.

It can also occur when the vertical sensitivity is set too high and the signal
occupies too much of the screen. Or if the signal appears to have an amplitude
of 20mV but there are random 150mV spikes that are invisible or very hard to see.

... Note that I have quite some experience with this scope. I used it intensively for 25 years between 1975 and 2000. ...

My previous reply was not aimed at your level of expertise. I try to make my posts
as simple and easy to read as possible in the hope that less experienced readers
may benefit from them too. After all, we were not born with the knowledge we have.
That knowledge was acquired from multiple sources as we live our lives, and I try
to share that with as many individuals as possible.

... Indeed not a storage scope. ...

But it is a dual beam oscilloscope, which is not very common.

[Stefann]

Hi rich,
Yes thanks again.
Indeed I appreciate all inputs. You have found me several clues!
It’s a big search.
On the trigger… you’re absolutely right on that, but I have the feeling it simply malfunctions a bit.
The scope is not really in top condition anymore .
I “lost” the signal at some point. The green line drifted away when I went for a sandwich and I did not get it back whatever knob I turned. I got it back with a cooldown and restart. So… I have to constantly monitor the beast to keep track of where it drifts to (drift is very slow so not overly difficult).
On the other hand it’s a lot of fun to service an 18 year old computer with a 60 year old tool.
It still has the original service manual. That includes all schematics and service instructions for all hand soldered boards!
I cannot measure at this moment. With capacitor installed there is nothing to trigger on.

Computer is still running after 28 hours!
This exact configuration did crash 2x after about 15 hours before the capacitor was on the power line. Hope is growing.
Note I installed the capacitor using a screw terminal. The idea is that if this keeps running few more days I can than remove the capacitor without having to power down or reboot. If after that there is quick crash I think the evidence is solid.
Anyway..  I’m not asking again for fingers to be crossed because that went wrong last time.

[Stefann]

Rich…
On 2nd thought…
You got me thinking with your trigger comments…
I will try again when the capacitor is out.
On the one hand I have the idea that the scope is simply polluting signal too much.
On the other hand you may be right and there are hardly visible spikes.

My hopes are low.
Normally if such a thing is the case the image starts to “stutter” if you dial the trigger towards less sensitive. I did not see that.
But I will give it an other try.