error while loading shared libraries: libusb-1.0.so.0: cannot open shared object file: No such file or directoryI was able to fix that by adding libusb.tcz to the onboot.lsttc@huis:/opt$ sudo /usr/local/sbin/rsyslogd
rsyslogd: pidfile '/var/run/rsyslogd.pid' and pid 4789 already exist.However... nothing gets logged.$DebugFile /var/log/log_debug.txt
$DebugLevel 2 # 0=off, 2 = full debugAfter a reboot I indeed get an enormous /var/log/log_debug.txt file$WorkDirectory /var/log
$ModLoad imudp
$UDPServerRun 514
$ModLoad imtcp
$InputTCPServerRun 514
$ModLoad imklog
$ModLoad imuxsock
$template MyFormat,"%timegenerated:1:19% %msg:::drop-last-lf%\n"
$template FullFormat,"%timegenerated% %HOSTNAME% %syslogtag%%msg%\n"
$DebugFile /var/log/log_debug.txt
$DebugLevel 2 # 0=off, 2 = full debug
#example
# $outchannel log_rotation,/var/log/log_rotation.log, 52428800,/home/me/./log_rotation_script
# activate the channel and log everything to it
# *.* :omfile:$log_rotation
#
# /home/me/log_rotation_script:
# mv -f /var/log/log_rotation.log /var/log/log_rotation.log.1
# ------------- User section -------------------
# max 100k debugfile = 1000 lines x 100chars
# Need script: /var/log/rotate:
# tail -n 500 /var/log/${1} > /var/log/${1}.tmp
# cat /var/log/${1}.tmp > /var/log/${1}
# rm -f /var/log/${1}.tmp
# Heat Control: HeatPump and CV
$outchannel heat_log, /var/log/heatlog.txt, 100000, /var/log/rotate heatlog.txt
local1.=info :omfile:$heat_log;MyFormat
# Solar Thermal
$outchannel solar_log,/var/log/solarlog.txt, 100000, /var/log/rotate solarlog.txt
local1.=notice :omfile:$solar_log;MyFormat
# Main (normal main logging)
$outchannel main_log, /var/log/mainlog.txt, 100000, /var/log/rotate mainlog.txt
local1.=debug :omfile:$main_log;MyFormat
# EVSE
$outchannel evse_log, /var/log/evselog.txt, 100000, /var/log/rotate evselog.txt
local2.=notice :omfile:$evse_log;MyFormat
# Weather
$outchannel weather_log, /var/log/weatherlog.txt, 100000, /var/log/rotate weatherlog.txt
local3.=notice :omfile:$weather_log;MyFormat
# PV, enphase and solaredge
$outchannel PV_log, /var/log/PVlog.txt, 100000, /var/log/rotate PVlog.txt
local3.=info :omfile:$PV_log;MyFormat
# Debug, catch all that have not been catched before
$outchannel debug_log,/var/log/debuglog.txt, 100000, /var/log/rotate debuglog.txtcat /etc/ld.so.conf
/usr/local/libsudo ldconfig
... - On a next update I will use the command line tools. ...Tinycore has a single command that handles that. It's called:
update-everythingI can no longer edit the previous post ...That's right. Years ago we added a 30 minute time limit after
... any tips on how I can put logging in place?Yes, but your extensions are on persistent storage, right?
- problem is that everything runs in ram. So I have zero diagnostics in case of a crash. ...
Hi StefannTrue… but “what should I log”?... any tips on how I can put logging in place?Yes, but your extensions are on persistent storage, right?
- problem is that everything runs in ram. So I have zero diagnostics in case of a crash. ...
So send any log messages to /etc/sysconfig/tcedir/SomeFileName.log
With everything running in RAM and you backups suddenly getting bigger, maybe you're running out of memory? Does the test system have more memory than the live system?No, backups are not suddenly bigger.
Mem: 410040K used, 551480K free, 34800K shrd, 4412K buff, 204960K cached
CPU: 5.4% usr 6.4% sys 0.0% nic 88.1% idle 0.0% io 0.0% irq 0.0% sirq
Load average: 0.31 0.23 0.16 2/197 4900
PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND
4130 1 tc S 11572 1.2 0 10.6 /krubo/work/krubo /krubo/work/1wire.def
3481 1 root S 54508 5.6 0 0.3 /usr/local/sbin/rsyslogd
4880 4849 tc R 3600 0.3 0 0.3 top
4014 1 root S 8192 0.8 0 0.2 x0vncserver -PasswordFile=/home/tc/.vnc/passwd
4848 4844 tc S 7968 0.8 0 0.2 sshd-session: tc@pts/0
4017 3993 tc S 442m 47.0 0 0.0 /usr/local/sbin/httpd -k start
4019 3993 tc S 395m 41.9 0 0.0 /usr/local/sbin/httpd -k start
4050 3993 tc S 391m 41.6 0 0.0 /usr/local/sbin/httpd -k start
4314 3993 tc S 382m 40.6 0 0.0 /usr/local/sbin/httpd -k start
3993 1 root S 162m 17.2 0 0.0 /usr/local/sbin/httpd -k start
3995 1 root S 44968 4.6 0 0.0 Xvesa -br -screen 1024x768x32 -shadow -2button -mouse /dev/i
3821 3798 root S 18868 1.9 0 0.0 /usr/local/sbin/smbd -D
3798 1 root S 18812 1.9 0 0.0 /usr/local/sbin/smbd -D
4120 1 tc S 9852 1.0 0 0.0 wbar
4003 1 tc S 9628 1.0 0 0.0 flwm
4844 3855 root S 7564 0.7 0 0.0 sshd-session: tc [priv]
3855 1 root S 7312 0.7 0 0.0 sshd: /usr/local/sbin/sshd [listener] 0 of 10-100 startups
3641 1 root S 6056 0.6 0 0.0 /usr/local/sbin/nmbd -D
... True… but “what should I log”? ...
/sbin/syslogd -O /etc/sysconfig/tcedir/messages -s 1000 -b 5 -l 5-O The log files will be messages, messages.0, ..., messages.4.Level Severity Description Example Use Case
0 Emergency System is unusable Hardware failure causing a full system crash
1 Alert Immediate action required Database corruption detected
2 Critical Critical conditions Firewall dropping all traffic unexpectedly
3 Error Error conditions Authentication failures
4 Warning Potential issues High CPU or memory usage
5 Notice Normal but significant events Configuration changes applied
6 Informational General system activity User logins, completed backups
7 Debug Debugging information Function traces, variable dumps#!/bin/sh
Dest="/etc/sysconfig/tcedir/FreeMem.log"
while true
do
echo -ne "$(date)\n$(free -m)\n\n" >> "$Dest"
# Limit log file to last 2400 lines (400 entries) if it is greater or equal to 2460 lines (410 entries).
[ $(wc -l "$Dest" | cut -d " " -f1) -ge 2460 ] && echo "$(tail -n 2400 $Dest)" > "$Dest"
sleep 300
doneThe log file will hold about 33 hours worth of entries and be about 100 Kbytes in size./home/tc/.local/bin/FreeMem.sh &This assumes you are running as user tc. Change tc to your user name if required.... To my relieve the logging from syslog is "not overly big". No immediate worry that I break the usb drive within an hour. Breaking it is not a problem but that would stop the logging and that would bring me nowhere. ...The commands I listed limit the space the logs will occupy so they can not fill your disk.
- "remove the kernel extension and not use the peripheral" for next testrun.Hi Stefann. Having a log capture an error at the time of the crash would be the best, of course, but the above also sounds like a excellent strategy.
...
Would be a very clear pointer if I can get the "test system" to crash with this usb-serial peripheral.
... It reads data from my energy meter but it opens the connection and keeps reading without ever closing. ...That makes me wonder if any USB devices are being put to sleep.
... This extension allows to connect a RS232 connection over USB port. It's connected to my energy meter where it reads data every second. ...Yeah, I saw that too. But this isn't a real time kernel. So it's possible that if the
usbcore.autosuspend=-1echo -1 | sudo tee /sys/module/usbcore/parameters/autosuspendBut in order for it to take effect on existing devices, you would probablysudo udevadm triggerDEFAULT gui17
LABEL gui17
KERNEL /tce/boot/vmlinuz17
INITRD /tce/boot/core17.gz
APPEND quiet host=huis cron tz=CET-1CEST,M3.5.0,M10.5.0/3 waitusb=5:UUID="a6f362cf-6c77-4fb7-bb05-76724d3b8113" tce=UUID="a6f362cf-6c77-4fb7-bb05-76724d3b8113"
usbcore.autosuspend=-1cat /proc/cmdline
showbootcodes
Mar 23 19:31:00 huis cron.err crond[3358]: USER tc pid 4738 cmd php /home/tc/php/knmi.php
Mar 23 20:01:00 huis cron.err crond[3358]: USER tc pid 4760 cmd /krubo/work/krubo_watchdog
Mar 23 20:31:00 huis cron.err crond[3358]: USER tc pid 4783 cmd /krubo/work/krubo_watchdog
Mar 23 20:31:00 huis cron.err crond[3358]: USER tc pid 4784 cmd php /home/tc/php/knmi.php
Mar 23 21:01:00 huis cron.err crond[3358]: USER tc pid 4803 cmd /krubo/work/krubo_watchdog
Mar 23 21:31:00 huis cron.err crond[3358]: USER tc pid 4823 cmd /krubo/work/krubo_watchdog
Mar 23 21:31:00 huis cron.err crond[3358]: USER tc pid 4824 cmd php /home/tc/php/knmi.php
Mar 23 22:01:00 huis cron.err crond[3358]: USER tc pid 4844 cmd /krubo/work/krubo_watchdog/sbin/syslogd -O /krubo/work/logging.txt -s 1000 -b 20 -l 5
... Unfortunately there is no logging of the crash.
Here you see the logging I haver. Its basically just logging the crontab ...
tc@E310:~$ crond --help
BusyBox v1.29.3 (2018-12-19 15:29:37 UTC) multi-call binary.
Usage: crond -fbS -l N -d N -L LOGFILE -c DIR
-f Foreground
-b Background (default)
-S Log to syslog (default)
-l N Set log level. Most verbose 0, default 8
-d N Set log level, log to stderr
-L FILE Log to FILE
-c DIR Cron dir. Default:/var/spool/cron/crontabstry starting crond with the -L option and point it to another file, orused this command as suggested by @rich for logging:Then you should be able to reduce the number of log files keptCode: [Select]/sbin/syslogd -O /krubo/work/logging.txt -s 1000 -b 20 -l 5
LABEL gui17tst
KERNEL /tce/boot/vmlinuz17
INITRD /tce/boot/core17.gz
APPEND quiet usbcore.autosuspend=-1 host=huis cron tz=CET-1CEST,M3.5.0,M10.5.0/3 waitusb=5:UUID="a6f362cf-6c77-4fb7-bb05-76724d3b8113" tce=UUID="a6f362cf-6c77-4fb7-bb05-76724d3b8113" tc@huis:/krubo/work$ showbootcodes
BOOT_IMAGE=/tce/boot/vmlinuz17 quiet usbcore.autosuspend=-1 host=huis cron tz=CET-1CEST,M3.5.0,M10.5.0/3 waitusb=5:UUID="a6f362cf-6c77-4fb7-bb05-76724d3b8113" tce=UUID="a6f362cf-6c77-4fb7-bb05-76724d3b8113" initrd=/tce/boot/core17.gz... With that said... "any tips to get better crash logging"?? I basically have zero logging from last crash. I probably need to set -l to 6 instead of 5. ...Not at the moment. you seem to have it figured out for now.
... Does anybody know where I can find the source code of usb-serial-6.18.2-tinycore.tcz ?? ...That's a kernel driver.
Hi StefannThanks.... Does anybody know where I can find the source code of usb-serial-6.18.2-tinycore.tcz ?? ...That's a kernel driver.
You would have to look under drivers/usb/serial/ in the kernel source package.
... pfew.... that is not simple....Yeah, there are 80 source files in there. I would have mentioned that
usb/serial is not so bad, Only a few files in that directory are related to your specific chipset. Did you ever say which kernel module was being loaded?
Your best bet would be to connect to the kernel git (https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git) or one of the github clones. and then look for driver updates or compare between branches. USB is a convoluted monster, you have usb/serial for the endpoint driver, but its also going to have drivers/usb/core /drivers/usb/dwc2 (USB2) or drivers/usb/dwc3 (USB3) For the USB host adapter and core.
But yes, logging is important to see if you can find which rabbit hole to start looking. Did you ever tell us?
Which USB serial driver is being used (Also the USB IDs)
What the USB host adapter is (USB2 or USB3) and USB IDs of it.
IS there a USB hub involved?
Everything related to USB in dmesg would be useful. (And turn up the KERNEL Logging level in cmdline.txt ) and of course anything syslog picks up from the kernel from that logging.
cat /dev/ttyUSB0- The data is send as broadcast by my energy meter (using DSMR5 standard, Dutch Smart Meter Requirements). You donot have to request it. It just spits out a report every second.tce-load -wi lsusb
lsusb > lsusb.txt
lsusb -t >> lsusb.txt
dmesg | grep -iE "usb|serial" > dmesgusb.txt
lsmod | head -n 1 > lsmod.txt
lsmod | tail -n +2 | sort >> lsmod.txttce-load -wi usbutils
lsusb > lsusb.txt
lsusb -t >> lsusb.txt
tc@huis:/$ lsusb -t
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
|__ Port 1: Dev 2, If 0, Class=(Defined at Interface level), Driver=usbfs, 1.5M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=usbfs, 12M
|__ Port 2: Dev 3, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/4p, 480Mtc@huis:/$ dmesg | grep -iE "usb|serial"
Kernel command line: BOOT_IMAGE=/tce/boot/vmlinuz17 quiet usbcore.autosuspend=-1 host=huis cron tz=CET-1CEST,M3.5.0,M10.5.0/3 waitusb=5:UUID="a6f362cf-6c77-4fb7-bb05-76724d3b8113" tce=UUID="a6f362cf-6c77-4fb7-bb05-76724d3b8113" initrd=/tce/boot/core17.gz
Unknown kernel command line parameters "cron host=huis tz=CET-1CEST,M3.5.0,M10.5.0/3 waitusb=5:UUID="a6f362cf-6c77-4fb7-bb05-76724d3b8113" tce=UUID="a6f362cf-6c77-4fb7-bb05-76724d3b8113"", will be passed to user space.
ACPI: bus type USB registered
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
ehci-pci 0000:00:10.4: new USB bus registered, assigned bus number 1
ehci-pci 0000:00:10.4: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
uhci_hcd 0000:00:10.0: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
uhci_hcd 0000:00:10.1: new USB bus registered, assigned bus number 3
hub 3-0:1.0: USB hub found
usbcore: registered new interface driver uas
usbcore: registered new interface driver usb-storage
usbcore: registered new interface driver ums-alauda
usbcore: registered new interface driver ums-cypress
usbcore: registered new interface driver ums-datafab
usbcore: registered new interface driver ums_eneub6250
usbcore: registered new interface driver ums-freecom
usbcore: registered new interface driver ums-isd200
usbcore: registered new interface driver ums-jumpshot
usbcore: registered new interface driver ums-karma
usbcore: registered new interface driver ums-onetouch
usbcore: registered new interface driver ums-sddr09
usbcore: registered new interface driver ums-sddr55
usbcore: registered new interface driver ums-usbat
usbcore: registered new interface driver appletouch
usbcore: registered new interface driver bcm5974
usbcore: registered new interface driver synaptics_usb
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
usb 2-1: new full-speed USB device number 2 using uhci_hcd
waitusb=5:UUID="a6f362cf-6c77-4fb7-bb05-76724d3b8113"
usb 2-2: new full-speed USB device number 3 using uhci_hcd
usb 3-1: new low-speed USB device number 2 using uhci_hcd
usbcore: registered new interface driver usbserial_generic
usbserial: USB Serial support registered for generic
usbcore: registered new interface driver ftdi_sio
usbserial: USB Serial support registered for FTDI USB Serial Device
ftdi_sio 2-2:1.0: FTDI USB Serial Device converter detected
usb 2-2: Detected FT232R
usb 2-2: FTDI USB Serial Device converter now attached to ttyUSB0tc@huis:/$ lsmod | head -n 1 && lsmod | tail -n +2 | sort
Module Size Used by Not tainted
8139cp 20480 0
8139too 20480 0
cifs 454656 2
cifs_md4 12288 1 cifs
cpufreq_conservative 12288 0
cpufreq_powersave 12288 0
cpufreq_userspace 12288 0
ftdi_sio 36864 1
loop 20480 314
mii 12288 2 8139too,8139cp
netfs 36864 1 cifs
nls_ucs2_utils 8192 1 cifs
pcspkr 12288 0
serio_raw 12288 0
squashfs 36864 157
usbserial 20480 3 ftdi_sio# debug tc17 crash
*.notice :omfile:$tc17_log;MyFormat- I made this write to my network connected test-system where it writes to an old usb-stick I had lying around. it's a 200M stick. So I can fully overload and fry that with data. don't care if that breaks....You forgot to run the first version of the command.Code: [Select]tce-load -wi usbutils
lsusb > lsusb.txt
lsusb -t >> lsusb.txt
...These two commands were not meant to be run in isolation. When run asCode: [Select]----- Snip -----...
lsmod | head -n 1 > lsmod.txt
lsmod | tail -n +2 | sort >> lsmod.txt
lsmod | head -n 1 && lsmod | tail -n +2 | sort
You forgot to run the first version of the command.
tc@huis:~$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 0bc7:0001 X10 Wireless Technology, Inc. ActiveHome (ACPI-compliant)
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 003: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub...I don't know if it's an issue, but your peripherals appear to be pluggedCode: [Select]tc@huis:/$ lsusb -t...
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M <-------------------- Slow port
|__ Port 1: Dev 2, If 0, Class=(Defined at Interface level), Driver=usbfs, 1.5M <-- X10 Wireless Technology, Inc. ActiveHome (ACPI-compliant)
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M <-------------------- Slow port
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=usbfs, 12M <---------- Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter
|__ Port 2: Dev 3, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M <------- Future Technology Devices International, Ltd FT232 Serial (UART) IC
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/4p, 480M <------------------- Fast port
Hi StefannWell…it’s a low power low spec computer from 2008. 500MHz single core. So it’s definitely not fast....I don't know if it's an issue, but your peripherals appear to be pluggedCode: [Select]tc@huis:/$ lsusb -t...
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M <-------------------- Slow port
|__ Port 1: Dev 2, If 0, Class=(Defined at Interface level), Driver=usbfs, 1.5M <-- X10 Wireless Technology, Inc. ActiveHome (ACPI-compliant)
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M <-------------------- Slow port
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=usbfs, 12M <---------- Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter
|__ Port 2: Dev 3, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M <------- Future Technology Devices International, Ltd FT232 Serial (UART) IC
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/4p, 480M <------------------- Fast port
into slow speed (12 Mbits/sec) ports.
If I'm reading it correctly:
The X10 Wireless device is connecting at 1.5 Mbits/sec, which sounds fine.
The other 2 devices are connecting at 12 Mbits/sec, which may be taxing that slow speed bus.
The faster (480 Mbits/sec) port might be a better choice if it
provides external USB ports.
... Speed however is not a big thing. ...Agreed. I does not appear like any of those devices would tax the USB ports.
... - the serial port reads my energy meter that spits out a data block of 500 bytes each second. ...You haven't mention the baud rate you are using and whether your
int start_meter(char * dev)
{ struct termios pts = { 0 }; /* termios settings on port */
int fd;
/* some things we want to set arbitrarily */
pts.c_lflag &= ~ICANON;
pts.c_lflag &= ~(ECHO | ECHOCTL | ECHONL);
pts.c_cflag |= HUPCL;
pts.c_cc[VMIN] = 1;
pts.c_cc[VTIME] = 0;
/* Standard CR/LF handling: this is a dumb terminal.
* Do no translation:
* no NL -> CR/NL mapping on output, and
* no CR -> NL mapping on input.
*/
pts.c_oflag |= ONLCR;
pts.c_iflag &= ~ICRNL;
/* set hardware flow control by default */
pts.c_cflag |= CRTSCTS;
pts.c_iflag &= ~(IXON | IXOFF | IXANY);
/* set 9600 bps speed by default */
// cfsetospeed(&pts, B9600);
// cfsetispeed(&pts, B9600);
cfsetospeed(&pts, B115200);
cfsetispeed(&pts, B115200);
temp.E_night = -1.0;
temp.E_day = -1.0;
temp.E_rnight = -1.0;
temp.E_rday = -1.0;
temp.E_power = -1.0;
temp.E_rpower = -1.0;
temp.E_id = -1.0;
temp.gaz_time_sec = -1.0;
temp.gaz_count = -1.0;
fd = open(dev, O_RDWR);
if (fd>=0)
tcsetattr(fd, TCSANOW, &pts);
return fd;
}
tc@huis:/krubo/work$ /krubo/work/krubo /krubo/work/1wire.def
/krubo/work/krubo: /lib/libc.so.6: version `GLIBC_ABI_GNU_TLS' not found (required by /krubo/work/krubo)
/krubo/work/krubo: /lib/libc.so.6: version `GLIBC_2.42' not found (required by /krubo/work/krubo)mon march 16: start around 12:00 //full TC17
Tue march 17: crashed in morning without yesterday data, so 24:00 latest
Tue march 17: start around 13:00 //full TC17
Wed march 18: crashed in morning without yesterday data, so 24:00 latest
Wed march 18: start around 23:00 //TC17 core & vmlinuz but no apps, add logging
Fri march 20: crashed in morning without yesterday data, so 24:00 latest // no logging due to mount mistake
Fri march 20: start around 14:00 //TC17 core & vmlinuz but no apps, no X10 interface on usb because usb port used for logging on usb-stick
mon march 23: manual stop around 9:00 // no crash after 4 days
mon march 23: start with full TC17 and P1 & X10 interface 8:30 // X10 interface installed again, check that it still crashes
mon march 23: crash, no logging 22:00 - 23:00 // no logging because usb-slot used by X10 interface, not available for logging usb stick
tue march 24: restart with usbcore.autosuspend=-1 bootcode around 9:00 // usbcore.autosuspend=-1 bootcode
tue march 24: manual stop around 12:00
multiple manual start/stop due to install of home battery
Wed march 25: restart with usbcore.autosuspend=-1 bootcode around 20:00 // usbcore.autosuspend=-1 bootcode
Fri march 27: manual stop for maintenance 10:00; 38hr crash-free run
Fri march 27: restart with usbcore.autosuspend=-1 bootcode around 14:20 // usbcore.autosuspend=-1 bootcode
Sat march 28: crash around 9:00 //after 19hrs
Sat march 28: restart with usbcore.autosuspend=-1 bootcode around 13:30 // introduced serious logging, *.notice
Mon march 30: manual stop around 14:00 // 48hr run without issues
Mon march 30: restart under TC15, no extra bootcode around 17:00
Thu april 02: still running on TC15. Leaving for a 8 day travel
tc@huis:/krubo/work$ showbootcodes
BOOT_IMAGE=/tce/boot/vmlinuz17 quiet host=huis cron tz=CET-1CEST,M3.5.0,M10.5.0/3 waitusb=5:UUID="a6f362cf-6c77-4fb7-bb05-76724d3b8113" tce=UUID="a6f362cf-6c77-4fb7-bb05-76724d3b8113" initrd=/tce/boot/core17.gztc@huis:/krubo/work$ uname -a
Linux huis 6.18.2-tinycore #1 SMP Sat Dec 20 21:06:22 UTC 2025 i686 GNU/Linuxtc@huis:/krubo/work$ ls -l krubo
-rwxr-xr-x 1 tc staff 242508 Mar 14 16:33 krubo
sat april 18 15:00, start again under TC17
- using full recompiled executable under TC17
- WITHOUT usbcore.autosuspend=-1 bootcode // try to get it to crash within a day
- including usb-serial-6.18.2-tinycore.tcz
- "per second reading" of serial interface
- rsyslog logging at debug level (kern.*), writing over network to Ramdisk of 2nd computer (avoid flash-wear)
19 april
15:25 Mem: 468928K used, 492592K free, 35852K shrd, 3844K buff, 283808K cached
15:38 Mem: 489316K used, 472204K free, 36036K shrd, 3852K buff, 283992K cached
15:41 Mem: 497508K used, 464012K free, 35900K shrd, 3852K buff, 283856K cached
16:00 Mem: 497464K used, 464056K free, 35832K shrd, 3868K buff, 283852K cached
16:16 Mem: 497672K used, 463848K free, 35880K shrd, 3868K buff, 283900K cached
16:53 Mem: 506816K used, 454704K free, 35876K shrd, 3868K buff, 283896K cached
17:02 Mem: 507040K used, 454480K free, 35956K shrd, 3868K buff, 283976K cached
17:43 Mem: 515232K used, 446288K free, 35912K shrd, 3884K buff, 283932K cached
18:02 Mem: 523640K used, 437880K free, 36028K shrd, 3884K buff, 284048K cached
sync
sudo cache-clear
syncThis helps to insure other processes are not skewing the results.NO CACHE CLEAR
Sun Apr 19 19:57:41 CEST 2026
m total used free shared buff/cache available
Mem: 961520 228600 424736 35888 308184 559560
Swap: 226116 0 226116
WITH CASH CLEAR
Sun Apr 19 19:59:40 CEST 2026
m total used free shared buff/cache available
Mem: 961520 258156 635764 35948 67600 578960
Swap: 226116 0 226116
... - did I now cleanup the analysis? ...Yes you did.
... - or did I inject a solution? (doing a cleanup that the application or kext should have done)? ...No, you did not. If you really have a memory leak, free
Do you leak on your own app ?On the one hand: "everything is possible"
Maybe valgrind time then. :)
mon Apr 20 16:15:18 // restart with full recompile under TC17
tue apr 21 8:50 //crashed
- hardwired connected monitor does not show anything, "no signal"
- kernel logging not present (Rsyslog logging kern.* messages)
- memory logging shows no issue:
Tue Apr 21 07:57:25 CEST 2026
m total used free shared buff/cache available
Mem: 961520 278448 445316 42608 237756 503028
Tue Apr 21 08:12:25 CEST 2026
m total used free shared buff/cache available
Mem: 961520 279016 444812 42544 237692 502524
Tue Apr 21 08:27:25 CEST 2026
m total used free shared buff/cache available
Mem: 961520 279084 444812 42476 237624 502524
Tue Apr 21 08:42:25 CEST 2026
m total used free shared buff/cache available
Mem: 961520 279028 444812 42532 237680 502524
>> 8 minutes later it had crashed... I got a tip from my brother that "SELECT" is a quite complicated kernel call.
I'm using SELECT to check that the pipe is ready for read but I can just as well call read from it in nonblocking mode without checking.
So... I now changed that...
- removed the SELECT
- read in non-blocking mode ...
C_Programs/AutoCursor/AutoCursor.c: int fdmax=0; // Highest file descriptor select() should monitor.
C_Programs/AutoCursor/AutoCursor.c: select((fdmax + 1), &Dcursor, NULL, NULL, NULL);Select is limited to somewhere around 1024 file descriptors. If you keepif(file_descriptor >= FD_SETSIZE)
{
print error message
exit program
}
fd = open("/dev/ttyUSB0", O_RDWR);call this as part of forever loop:
{ static char buf[BUFSIZE+1];
fd_set fd_check;
struct timeval wait = {0};
FD_ZERO(&fd_check);
FD_SET(fd, &fd_check);
select(fd+1, &fd_check, NULL, NULL, &wait);
if (FD_ISSET(fd, &fd_check) )
{ j = read(fd, &buf[i], BUFSIZE-i);
... process results...
}
other commands...
}
try upgrade tc 16 ,maybe can shrink this problemI thought about that but that would not help me.
Through all this, you still have not managed to capture any sort of log or crash dump. You likely need a direct console connection on a monitor and local keyboard.Before answering,..
... But after a crash:It's not the monitor doing that. It's the operating system disabling the
- monitor is still on “screensaver”, not able to wake up. If I press a button on the monitor it says “no signal” ...
consoleblank=0xset dpms 0 0 0
xset s noblank
xset s off
xset -dpmsThanks a lot!After you do that, unplug the keyboard and mouse. Then check
I will do that.
Yes there is a gui and vnc server running. ...
#define meterREAD 1
#define meterFD 2
#define meterSELECT 4
#define meterREFRESH 8
#define meterBLOCKING 16int start_meter(tmeter *X)
{ int flags;
meterMODE = enable_meter;
/* some things we want to set arbitrarily */
(X->pts).c_lflag &= ~ICANON;
(X->pts).c_lflag &= ~(ECHO | ECHOCTL | ECHONL);
(X->pts).c_cflag |= HUPCL;
(X->pts).c_cc[VMIN] = 1;
(X->pts).c_cc[VTIME] = 0;
/* Standard CR/LF handling: this is a dumb terminal.
* Do no translation:
* no NL -> CR/NL mapping on output, and
* no CR -> NL mapping on input.
*/
(X->pts).c_oflag |= ONLCR;
(X->pts).c_iflag &= ~ICRNL;
/* set hardware flow control by default */
(X->pts).c_cflag |= CRTSCTS;
(X->pts).c_iflag &= ~(IXON | IXOFF | IXANY);
/* set 115200 bps speed by default */
cfsetospeed(&(X->pts), B115200);
cfsetispeed(&(X->pts), B115200);
X->fd = open(X->dev, O_RDWR);
if (X->fd>=0)
{ flags = fcntl(X->fd, F_GETFL);
if ( !(meterMODE & meterBLOCKING) )
fcntl(X->fd, F_SETFL, flags | O_NONBLOCK);
tcsetattr(X->fd, TCSANOW, &(X->pts));
X->SecLastRefresh = SECNOW();
}
return 1;
}int do_readmeter(tmeter *X)
{ static int i=0;
static int j=0;
static int n=0;
static int k=0;
static char buf[BUFSIZE+1];
fd_set fd_check;
struct timeval wait = {0};
meterMODE = enable_meter;
if (meterMODE & meterFD)
{ FD_ZERO(&fd_check);
FD_SET(X->fd, &fd_check);
}
if (meterMODE & meterSELECT)
select(X->fd +1, &fd_check, NULL, NULL, &wait);
if (meterMODE & meterFD)
FD_ISSET(X->fd, &fd_check);
//if (FD_ISSET(X->fd, &fd_check) ) //this was originally there but removed for this investigation
if (meterMODE & meterREAD)
{ j = read(X->fd, &buf[i], BUFSIZE-i);
while (j>0)
{ buf[i] &=0x007F;
if ( buf[i]=='\n' )
{ do_parsemeter(buf, X);
i++; j--;
n=i;
i=0;
for (k=0; k<=j; k++)
buf[i+k]=buf[i+n+k];
}
else
{ i++; j--;
}
if (i >= BUFSIZE)
{ i=0; j=0;
}
}
}
return 1;
}
#include <sys/time.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <time.h>
#include <termios.h>
#include <stddef.h>
#include <signal.h>
#include <fcntl.h>
#include <sys/times.h>
#include <sys/time.h>
#include <sys/stat.h>
#include <sys/select.h>
//#include <syslog.h>
#define usDELAYTIME 100
#define minLOGINTERVAL 10
#define meterREAD 1
#define meterFD 2
#define meterSELECT 4
#define meterREFRESH 8
#define meterBLOCKING 16
#define BUFSIZE 8191
int meterMODE = meterREAD | meterBLOCKING;
char logfile[128] = "/remote/home/tc/crashlog.txt";
struct termios pts; // interface settings
int fd;
void usDelay(int len)
{ struct timespec delay;
delay.tv_sec = 0;
delay.tv_nsec = len;
delay.tv_nsec *= 1000; //1000=us, set in us * 10e3
nanosleep(&delay, NULL);
}
static void dummy_func(int sig)
{
}
int start_meter()
{ int flags;
/* some things we want to set arbitrarily */
pts.c_lflag &= ~ICANON;
pts.c_lflag &= ~(ECHO | ECHOCTL | ECHONL);
pts.c_cflag |= HUPCL;
pts.c_cc[VMIN] = 1;
pts.c_cc[VTIME] = 0;
/* Standard CR/LF handling: this is a dumb terminal.
* Do no translation:
* no NL -> CR/NL mapping on output, and
* no CR -> NL mapping on input.
*/
pts.c_oflag |= ONLCR;
pts.c_iflag &= ~ICRNL;
/* set hardware flow control by default */
pts.c_cflag |= CRTSCTS;
pts.c_iflag &= ~(IXON | IXOFF | IXANY);
/* set 115200 bps speed by default */
cfsetospeed(&pts, B115200);
cfsetispeed(&pts, B115200);
fd = open("/dev/ttyUSB0", O_RDWR);
if (fd>=0)
{ flags = fcntl(fd, F_GETFL);
if ( !(meterMODE & meterBLOCKING) )
fcntl(fd, F_SETFL, flags | O_NONBLOCK);
tcsetattr(fd, TCSANOW, &pts);
}
return 1;
}
int main()
{ char buf[BUFSIZE+1];
fd_set fd_check;
struct tm *tm_now;
time_t now, tstamp;
struct timeval wait = {0};
FILE *f_log;
int j =0;
unsigned long long count =0;
unsigned long long kcount =0;
struct itimerval interval = { 0 };
interval.it_interval.tv_sec = 0;
interval.it_interval.tv_usec = 1000; // repeat interval after 1st trigger; 1000 = 1ms
interval.it_value.tv_sec = 0;
interval.it_value.tv_usec = 1000; // time until first trigger
start_meter( );
if (fd < 0)
{ printf("cannot open device");
exit(1);
}
setitimer(ITIMER_REAL, &interval, NULL); //set interval timer
signal(SIGALRM, dummy_func); // dummy interrupt call
while (1)
{ if (meterMODE & meterFD)
{ FD_ZERO(&fd_check);
FD_SET(fd, &fd_check);
}
if (meterMODE & meterSELECT)
select(fd +1, &fd_check, NULL, NULL, &wait);
if (meterMODE & meterFD)
FD_ISSET(fd, &fd_check);
if (meterMODE & meterREAD)
{ j = read(fd, buf, BUFSIZE); // read
}
usDelay(usDELAYTIME);
count++;
time(&now);
if (now > tstamp+60*minLOGINTERVAL )
{ tm_now = localtime(&now);
tstamp = now;
kcount+= count/1000;
count %= 1000;
f_log = fopen(logfile, "a");
if (f_log!=NULL)
fprintf(f_log, "mon day: %2d %2d | hh:mm:ss: %02d:%02d:%02d | Still alive after %lldk + %lld loops\n",
tm_now->tm_mon+1, tm_now->tm_mday, tm_now->tm_hour, tm_now->tm_min, tm_now->tm_sec, kcount, count);
fclose(f_log);
}
}
exit(0);
}
... The serial port is getting "every second 812byte datablock on /dev/ttyUSB0; baudrate 11520" ...I'm guessing you meant 115200 there.
Hi StefannAh!... The serial port is getting "every second 812byte datablock on /dev/ttyUSB0; baudrate 11520" ...I'm guessing you meant 115200 there.
Assuming 8 data bits + 1 start bit + 1 stop bit + 2 bits of gap time
between each byte transmitted:
Bits per datablock = 12 * 812 = 9744 bit times.
Transmit time per datablock = 9744 / 115200 = 0.0846 seconds, or
just under 85ms.
mon day: 5 8 | hh:mm:ss: 15:07:48 | Still alive after 0k + 1 loops
.............
mon day: 5 9 | hh:mm:ss: 15:09:47 | Still alive after 219k + 471 loops
First logging: mon day: 5 8 | hh:mm:ss: 15:07:48 | Still alive after 0k + 1 loops
.............
Last logging: mon day: 5 10 | hh:mm:ss: 12:21:54 | Still alive after 414k + 476 loops
... The screensaver was not active but it did not help me much
flwm was active but did simply show a frozen screen.
I have no mouse but keyboard did not give any response. ...
Hi StefannAh.. no..... The screensaver was not active but it did not help me much
flwm was active but did simply show a frozen screen.
I have no mouse but keyboard did not give any response. ...
Did you try hitting Ctrl-Alt-F1 ?
Normally that should switch you to the console so you can see messages.
Ctrl-Alt-F2 returns you to the GUI>
mon day: 5 10 | hh:mm:ss: 13:49:56 | Still alive after 0k + 1 loops
.....
mon day: 5 12 | hh:mm:ss: 15:04:58 | Still alive after 453k + 670 loopsmon day: 5 10 | hh:mm:ss: 13:49:56 | Still alive after 0k + 1 loops
.....
mon day: 5 14 | hh:mm:ss: 13:19:37 | Still alive after 878k + 109 loopsTC15:
> tty = tty_port_tty_get(&port->port);
> if (tty) {
> tty_vhangup(tty);
> tty_kref_put(tty);
> }
TC17:
< tty_port_tty_vhangup(&port->port);The tty port has a different lifetime to the tty so must be kept apart. In addition be careful as tty -> port mappings are valid for the life of the tty object but in many cases port -> tty mappings are valid only until a hangup so don’t use the wrong path.
$$ TC17 crash work % diff TC17_drivers_usb_serial/usb-serial.c TC15_drivers_usb_serial/usb-serial.c
709c709
< guard(mutex)(&usb_dynids_lock);
---
> spin_lock(&drv->dynids.lock);
711a712
> spin_unlock(&drv->dynids.lock);
714a716
> spin_unlock(&drv->dynids.lock);
1178a1181
> struct tty_struct *tty;
1193c1196,1200
< tty_port_tty_vhangup(&port->port);
---
> tty = tty_port_tty_get(&port->port);
> if (tty) {
> tty_vhangup(tty);
> tty_kref_put(tty);
> }
1455c1462
< * __usb_serial_register_drivers - register drivers for a usb-serial module
---
> * usb_serial_register_drivers - register drivers for a usb-serial module
1457d1463
< * @owner: owning module
1464,1466c1470,1472
< int __usb_serial_register_drivers(struct usb_serial_driver *const serial_drivers[],
< struct module *owner, const char *name,
< const struct usb_device_id *id_table)
---
> int usb_serial_register_drivers(struct usb_serial_driver *const serial_drivers[],
> const char *name,
> const struct usb_device_id *id_table)
1511d1516
< (*sd)->driver.owner = owner;
1519c1524
< rc = driver_attach(&udriver->driver);
---
> rc = driver_attach(&udriver->drvwrap.driver);
1530c1535
< EXPORT_SYMBOL_GPL(__usb_serial_register_drivers);
---
> EXPORT_SYMBOL_GPL(usb_serial_register_drivers);$$ diff TC17_drivers_usb_serial/usb-serial.c TC16_drivers_usb_serial/usb-serial.c
709c709
< guard(mutex)(&usb_dynids_lock);
---
> spin_lock(&drv->dynids.lock);
711a712
> spin_unlock(&drv->dynids.lock);
714a716
> spin_unlock(&drv->dynids.lock);
1178a1181
> struct tty_struct *tty;
1193c1196,1200
< tty_port_tty_vhangup(&port->port);
---
> tty = tty_port_tty_get(&port->port);
> if (tty) {
> tty_vhangup(tty);
> tty_kref_put(tty);
> }
< guard(mutex)(&usb_dynids_lock);Especially because the "spin_lock()" seems to be replaced by "guard()" but its unclear what happened to the 2x "spine_unlock()"
---
> spin_lock(&drv->dynids.lock);
711a712
> spin_unlock(&drv->dynids.lock);
714a716
> spin_unlock(&drv->dynids.lock);
1178a1181
USB: make single lock for all usb dynamic id lists
There are a number of places where we accidentally pass in a constant
structure to later cast it off to a dynamic one, and then attempt to
grab a lock on it, which is not a good idea. To help resolve this, move
the dynamic id lock out of the dynamic id structure for the driver and
into one single lock for all USB dynamic ids. As this lock should never
have any real contention (it's only every accessed when a device is
added or removed, which is always serialized) there should not be any
difference except for some memory savings.
Note, this just converts the existing use of the dynamic id lock to the
new static lock, there is one place that is accessing the dynamic id
list without grabbing the lock, that will be fixed up in a follow-on
change.
tty: introduce and use tty_port_tty_vhangup() helper
This code (tty_get -> vhangup -> tty_put) is repeated on few places.
Introduce a helper similar to tty_port_tty_hangup() (asynchronous) to
handle even vhangup (synchronous).
And use it on those places.
In fact, reuse the tty_port_tty_hangup()'s code and call tty_vhangup()
depending on a new bool parameter.
How can I create a dedicated usb-serial-x.y.z-tinycore.tcz?
I would like to change usb-serial.c and generate usb-serial-x.y.z-tinycore.tcz for TC17 but do not know how to do that.
... - I tried to boot with kext usb-serial-6.12.11-tinycore.tcz (from TC16) on TC17 for reason this version does still have the "check on tty" and "spin_lock() and spin_unlock()" calls. I was well aware that using a TC16 kext on TC17 would likely not work but "why not try". But... indeed. the TC16 kext does not function on TC17. serial port does not function with that kext. ...You can not use a 6.12.11-tinycore kernel module with a 6.18.2-tinycore kernel.
... It basically contains:You can find out which of those modules are being loaded with this command:
/usr/local/lib/modules/6.18.2-tinycore/kernel/drivers/usb/misc/uss720.ko.gz
and
/usr/local/lib/modules/6.18.2-tinycore/kernel/drivers/usb/serial/[multiple files].gz ...
lsmod... I also did find "config-6.18.28-tinycore" on the download pages but have no clue what to do with it. ...That is the config file for a later kernel TC17 is being updated to.
... With that said...I think nowadays you need to recompile the kernel and all enabled modules.
- I do not need to fully create a new kernel
- I only need to rebuilt usb-serial-6.18.2-tinycore.tcz ...
tc@huis:~$ lsmod
Module Size Used by Not tainted
cifs 454656 2
cifs_md4 12288 1 cifs
netfs 36864 1 cifs
nls_ucs2_utils 8192 1 cifs
cpufreq_conservative 12288 0
cpufreq_userspace 12288 0
cpufreq_powersave 12288 0
ftdi_sio 36864 1
usbserial 20480 3 ftdi_sio
squashfs 36864 155
pcspkr 12288 0
8139too 20480 0
8139cp 20480 0
mii 12288 2 8139too,8139cp
loop 20480 310 $$ TC17 crash work % diff TC17_drivers_usb_serial/ftdi_sio.c TC15_drivers_usb_serial/ftdi_sio.c
631,632c631,634
< { USB_DEVICE_INTERFACE_NUMBER(FTDI_VID, FTDI_TIAO_UMPA_PID, 1) },
< { USB_DEVICE_INTERFACE_NUMBER(FTDI_VID, FTDI_NT_ORIONLXM_PID, 1) },
---
> { USB_DEVICE(FTDI_VID, FTDI_TIAO_UMPA_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
> { USB_DEVICE(FTDI_VID, FTDI_NT_ORIONLXM_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
804,805d805
< { USB_DEVICE(FTDI_NDI_VID, FTDI_NDI_EMGUIDE_GEMINI_PID),
< .driver_info = (kernel_ulong_t)&ftdi_NDI_device_quirk },
843c843,844
< { USB_DEVICE_INTERFACE_NUMBER(FTDI_VID, CYBER_CORTEX_AV_PID, 1) },
---
> { USB_DEVICE(FTDI_VID, CYBER_CORTEX_AV_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
848,853c849,860
< { USB_DEVICE_INTERFACE_NUMBER(FIC_VID, FIC_NEO1973_DEBUG_PID, 1) },
< { USB_DEVICE_INTERFACE_NUMBER(FTDI_VID, FTDI_OOCDLINK_PID, 1) },
< { USB_DEVICE_INTERFACE_NUMBER(FTDI_VID, LMI_LM3S_DEVEL_BOARD_PID, 1) },
< { USB_DEVICE_INTERFACE_NUMBER(FTDI_VID, LMI_LM3S_EVAL_BOARD_PID, 1) },
< { USB_DEVICE_INTERFACE_NUMBER(FTDI_VID, LMI_LM3S_ICDI_BOARD_PID, 1) },
< { USB_DEVICE_INTERFACE_NUMBER(FTDI_VID, FTDI_TURTELIZER_PID, 1) },
---
> { USB_DEVICE(FIC_VID, FIC_NEO1973_DEBUG_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
> { USB_DEVICE(FTDI_VID, FTDI_OOCDLINK_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
> { USB_DEVICE(FTDI_VID, LMI_LM3S_DEVEL_BOARD_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
> { USB_DEVICE(FTDI_VID, LMI_LM3S_EVAL_BOARD_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
> { USB_DEVICE(FTDI_VID, LMI_LM3S_ICDI_BOARD_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
> { USB_DEVICE(FTDI_VID, FTDI_TURTELIZER_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
895,896c902,905
< { USB_DEVICE_INTERFACE_NUMBER(ADI_VID, ADI_GNICE_PID, 1) },
< { USB_DEVICE_INTERFACE_NUMBER(ADI_VID, ADI_GNICEPLUS_PID, 1) },
---
> { USB_DEVICE(ADI_VID, ADI_GNICE_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
> { USB_DEVICE(ADI_VID, ADI_GNICEPLUS_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
902c911,912
< { USB_DEVICE_INTERFACE_NUMBER(MARVELL_VID, MARVELL_SHEEVAPLUG_PID, 1) },
---
> { USB_DEVICE(MARVELL_VID, MARVELL_SHEEVAPLUG_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
925,926c935,938
< { USB_DEVICE_INTERFACE_NUMBER(FTDI_VID, MARVELL_OPENRD_PID, 1) },
< { USB_DEVICE_INTERFACE_NUMBER(FTDI_VID, TI_XDS100V2_PID, 1) },
---
> { USB_DEVICE(FTDI_VID, MARVELL_OPENRD_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
> { USB_DEVICE(FTDI_VID, TI_XDS100V2_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
935,937c947,952
< { USB_DEVICE_INTERFACE_NUMBER(FTDI_VID, XVERVE_SIGNALYZER_ST_PID, 1) },
< { USB_DEVICE_INTERFACE_NUMBER(FTDI_VID, XVERVE_SIGNALYZER_SLITE_PID, 1) },
< { USB_DEVICE_INTERFACE_NUMBER(FTDI_VID, XVERVE_SIGNALYZER_SH2_PID, 1) },
---
> { USB_DEVICE(FTDI_VID, XVERVE_SIGNALYZER_ST_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
> { USB_DEVICE(FTDI_VID, XVERVE_SIGNALYZER_SLITE_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
> { USB_DEVICE(FTDI_VID, XVERVE_SIGNALYZER_SH2_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
942c957,958
< { USB_DEVICE_INTERFACE_NUMBER(IONICS_VID, IONICS_PLUGCOMPUTER_PID, 1) },
---
> { USB_DEVICE(IONICS_VID, IONICS_PLUGCOMPUTER_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
957,958c973,976
< { USB_DEVICE_INTERFACE_NUMBER(QIHARDWARE_VID, MILKYMISTONE_JTAGSERIAL_PID, 1) },
< { USB_DEVICE_INTERFACE_NUMBER(ST_VID, ST_STMCLT_2232_PID, 1) },
---
> { USB_DEVICE(QIHARDWARE_VID, MILKYMISTONE_JTAGSERIAL_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
> { USB_DEVICE(ST_VID, ST_STMCLT_2232_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
962c980,981
< { USB_DEVICE_INTERFACE_NUMBER(FTDI_VID, FTDI_DISTORTEC_JTAG_LOCK_PICK_PID, 1) },
---
> { USB_DEVICE(FTDI_VID, FTDI_DISTORTEC_JTAG_LOCK_PICK_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
1017,1019c1036,1038
< { USB_DEVICE(FTDI_VID, ACTISENSE_UID_PID) },
< { USB_DEVICE(FTDI_VID, ACTISENSE_USA_PID) },
< { USB_DEVICE(FTDI_VID, ACTISENSE_NGX_PID) },
---
> { USB_DEVICE(FTDI_VID, ACTISENSE_D9AC_PID) },
> { USB_DEVICE(FTDI_VID, ACTISENSE_D9AD_PID) },
> { USB_DEVICE(FTDI_VID, ACTISENSE_D9AE_PID) },
1037c1056,1057
< { USB_DEVICE_INTERFACE_NUMBER(TI_VID, TI_CC3200_LAUNCHPAD_PID, 1) },
---
> { USB_DEVICE(TI_VID, TI_CC3200_LAUNCHPAD_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
1055d1074
< { USB_DEVICE_INTERFACE_NUMBER(UBLOX_VID, UBLOX_EVK_M101_PID, 2) },
1057,1076c1076,1079
< { USB_DEVICE_INTERFACE_NUMBER(FTDI_VID, FTDI_FALCONIA_JTAG_BUF_PID, 1) },
< { USB_DEVICE_INTERFACE_NUMBER(FTDI_VID, FTDI_FALCONIA_JTAG_UNBUF_PID, 1) },
< /* GMC devices */
< { USB_DEVICE(GMC_VID, GMC_Z216C_PID) },
< /* Altera USB Blaster 3 */
< { USB_DEVICE_INTERFACE_NUMBER(ALTERA_VID, ALTERA_UB3_6022_PID, 1) },
< { USB_DEVICE_INTERFACE_NUMBER(ALTERA_VID, ALTERA_UB3_6025_PID, 2) },
< { USB_DEVICE_INTERFACE_NUMBER(ALTERA_VID, ALTERA_UB3_6026_PID, 2) },
< { USB_DEVICE_INTERFACE_NUMBER(ALTERA_VID, ALTERA_UB3_6026_PID, 3) },
< { USB_DEVICE_INTERFACE_NUMBER(ALTERA_VID, ALTERA_UB3_6029_PID, 2) },
< { USB_DEVICE_INTERFACE_NUMBER(ALTERA_VID, ALTERA_UB3_602A_PID, 2) },
< { USB_DEVICE_INTERFACE_NUMBER(ALTERA_VID, ALTERA_UB3_602A_PID, 3) },
< { USB_DEVICE_INTERFACE_NUMBER(ALTERA_VID, ALTERA_UB3_602C_PID, 1) },
< { USB_DEVICE_INTERFACE_NUMBER(ALTERA_VID, ALTERA_UB3_602D_PID, 1) },
< { USB_DEVICE_INTERFACE_NUMBER(ALTERA_VID, ALTERA_UB3_602D_PID, 2) },
< { USB_DEVICE_INTERFACE_NUMBER(ALTERA_VID, ALTERA_UB3_602E_PID, 1) },
< { USB_DEVICE_INTERFACE_NUMBER(ALTERA_VID, ALTERA_UB3_602E_PID, 2) },
< { USB_DEVICE_INTERFACE_NUMBER(ALTERA_VID, ALTERA_UB3_602E_PID, 3) },
< /* Abacus Electrics */
< { USB_DEVICE(FTDI_VID, ABACUS_OPTICAL_PROBE_PID) },
---
> { USB_DEVICE(FTDI_VID, FTDI_FALCONIA_JTAG_BUF_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
> { USB_DEVICE(FTDI_VID, FTDI_FALCONIA_JTAG_UNBUF_PID),
> .driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
1441d1443
< mutex_lock(&priv->cfg_lock);
1445d1446
< mutex_unlock(&priv->cfg_lock);
1839c1840
< static int ftdi_gpio_set(struct gpio_chip *gc, unsigned int gpio, int value)
---
> static void ftdi_gpio_set(struct gpio_chip *gc, unsigned int gpio, int value)
1843d1843
< int result;
1852c1852
< result = ftdi_set_cbus_pins(port);
---
> ftdi_set_cbus_pins(port);
1855,1856d1854
<
< return result;
1874c1872
< static int ftdi_gpio_set_multiple(struct gpio_chip *gc, unsigned long *mask,
---
> static void ftdi_gpio_set_multiple(struct gpio_chip *gc, unsigned long *mask,
1879d1876
< int result;
1885c1882
< result = ftdi_set_cbus_pins(port);
---
> ftdi_set_cbus_pins(port);
1888,1889d1884
<
< return result;
2618c2613
< unsigned int cflag;
---
> unsigned int cflag = termios->c_cflag;
2876a2872
> .owner = THIS_MODULE,
Like @Rich says, you can't take some modules from one kernel version to another.Thanks.
The modules have to come from the same compiling/building.
I think i have a old thread on this forum, let me search for it how to extract and build a new tcz so you don't need to load them all.
Here you are:
https://forum.tinycorelinux.net/index.php/topic,18858.msg129216.html#msg129216
https://forum.tinycorelinux.net/index.php/topic,20195.msg129372.html#msg129372
And you can also read lots of things in the wiki(lets promote that):
https://wiki.tinycorelinux.net/doku.php?id=wiki:creating_extensions
What change do you want to make to the kernel module code?It's definitely a gamble,
Rebuilding a single in tree module, requires it to match the current kernel, which can be done. With the files from the source directory.
But let’s start with what you want to change?
... but 2x spin_unlock() in TC15 ...Code inside a spin_lock should be brief and not take long to execute.
Hi StefannYou are right.... but 2x spin_unlock() in TC15 ...Code inside a spin_lock should be brief and not take long to execute.
It's likely the code can take one of two possible paths, so each path
has a spin_unlock included.
% diff TC17_drivers_usb_serial/usb-serial.c TC15_drivers_usb_serial/usb-serial.c
1193c1196,1200
< tty_port_tty_vhangup(&port->port);
---
> tty = tty_port_tty_get(&port->port);
> if (tty) {
> tty_vhangup(tty);
> tty_kref_put(tty);
> }TC15 has a check on tty not being NULL before hangup while TC17 is missing that.What change do you want to make to the kernel module code?Some help would be appreciated....
Rebuilding a single in tree module, requires it to match the current kernel, which can be done. With the files from the source directory.
But let’s start with what you want to change?
On the other hand... "I could try"...
step6:
I do not understand what config file to move where.
It says "kernel config file" but I do not see that.
THANKS... alike you said vaguely referenced and not explicitly stated made the above not enough for me....
how ever i imagine
this
http://tinycorelinux.net/17.x/x86/release/src/kernel/linux-6.18.28/config-6.18.28-tinycore
or one on/in a similar path:17.x/x86/release/src/kernel/ ( remember to match the kernel versions )
might be what the guide is referring to
afaik ( and tbh i know very little :s ) the above link is/should be what the core 17.x kernel was built with !
good luck!
it can be tricky fishing for the relevant details , esp when they are vaguely referenced and not explicitly stated ...imho
wow.......... I succeeded to compile and built a kernel from source....
I'm a bit in shock
tce-load -i /mnt/hda1/tce/optional/nano.tcz
gets me:
mount: can't setup loop device: No such device or address1/ get files you need
On laptop:
- find download location on http://tinycorelinux.net/downloads.html
- download [version]/x86/release/src/kernel/linux-x.y.z-patched.tar.xz
- download [version]/x86/release/src/kernel/linux-x.y.z/config-x.y.z-tinycore
On tinycore:
- create toplevel directory that you want to use for kernel customization. Can have 1 top-level for all versions. Assume path to be [TC]
- cp above 2 files to [TC]
2/ goto your [TC] toplevel directory and prepare kernel make
- cd [TC]
- tar xvf linux-x.y.z-patched.tar.xz (this creates a linux-x.y.z directory)
- cp config-x.y.z-tinycore linux-x.y.z/.config
- cd linux-x.y.z
3/ make kernel image
- make clean
- make bzImage (this makes kernel image, takes 3 hrs on my 1GHz 2core machine)
4/ Install image, on main system:
- cp [TC]/linux-x.y.z/arch/x86/boot/bzImage /mnt/sda1/tce/boot/vmlinuzCUSTOM
- modify /mnt/sda1/tce/boot/extlinux/extlinux.conf to boot from vmlinuzCUSTOMsudo depmod -a -b /tmp/extract $KERNEL...assuming you have the initrd under /tmp/extract
cd ./linux-x.y.z
make mrproper
cp ../[downloaded config] ./.config
make oldconfigmake bzImage
cp bzImage [bootdrive]/tce/boot/vmlinuz... I just recompiled the kernel without usb-serial to see whether that explains the file size difference;Did you use the original config-6.18.2-tinycore or did you run make menuconfig
-rw-r--r-- 1 tc staff 6287872 May 25 08:43 bzImage
==> so "no"; freshly compiled kernel without usb-serial included is 200k bigger than published kernel at download location
Make mrproper
Cp “www.tinycorelinux.net/17.x/x86/release/src/kernel/linux-6.18.2/config-6.18.2-tinycore” .config
Make menuconfig
…. Change usb-serial from “module” to “yes”
… Save
… exit
Make bzImageMake menuconfig
… change usb-serial back from “yes” to “module”
… save
… exit
Make bzImageMake mrproper
Cp “www.tinycorelinux.net/17.x/x86/release/src/kernel/linux-6.18.2/config-6.18.2-tinycore” .config
Make bzImage... I will do a fresh run to be absolutely sure:That's exactly what I was getting at.Code: [Select]Make mrproper
Cp “www.tinycorelinux.net/17.x/x86/release/src/kernel/linux-6.18.2/config-6.18.2-tinycore” .config
Make bzImage
That's exactly what I was getting at.Yeahh... That's How I did interpret your message.
When selecting options in make menuconfig , whether it's support for certainThanks for that explanation. Makes a lot of sense.
hardware, compiling a driver as a module, or building it into the kernel, the
menuconfig script is selecting other options required to support your choices
in the background.
However, reversing one of your choices does not necessarily cause the script
to unselect its additional choices, since they may be valid to select on their own.
Don’t forget that after copying the tinycore config to .config you need to make oldconfigAh.... I did not do that...
tc@hp510:/krubo/work/TC/linux-6.18.2$ make mrproper
tc@hp510:/krubo/work/TC/linux-6.18.2$ cp ../config-6.18.2-tinycore ./.config
tc@hp510:/krubo/work/TC/linux-6.18.2$ make oldconfig
tc@hp510:/krubo/work/TC/linux-6.18.2$ make bzImageI did not get any questions from "make oldconfig"Don’t forget that after copying the tinycore config to .config you need to make oldconfigOK.. I again made a new kernel.
Hi StefannOK.....
I'm not certain of this and may be misremembering.
I think the new kernel is built on the previous version of Tinycore.
If that's the case, it might be built with the previous version of GCC.
Newer versions of GCC typically build larger executables.
I'm not certain of this and may be misremembering.
I think the new kernel is built on the previous version of Tinycore.
If that's the case, it might be built with the previous version of GCC.
Newer versions of GCC typically build larger executables.
Maybe Juanito and/or Paul_123 can comment.
There were quite a few changes in the kernel config between 17.0 and 17.1 proposed kernel, in addition the kernel version. That is why its size changed.So.. that is strange. Because on TC17.0 I compiled a TC17.1 kernel that is 20kB bigger than the published TC17.1 kernel.
It should not make a difference what CPU a kernel is compiled under, as the kernel config dictates the compiler output, as long as its the same compiler version. It is true that the x86 kernel is built on a 64bit cpu, but done in the tc 32bit environment.
Check that I run latest TC17.0 vmlinuz:
TC17.0 download location:
vmlinuz 10-Feb-2026 12:03 6087168
tc@hp510:/mnt/sda1/tce/boot$ ls -l *17
-rwxrw-r-- 1 tc staff 6087168 Feb 10 13:10 vmlinuz17
Download may-8 version of TC17.1 from http://tinycorelinux.net/17.x/x86/release/src/kernel/
linux-6.18.28-patched.tar.xz 08-May-2026 15:47 159508120
config-6.18.28-tinycore 08-May-2026 18:09 218173
On hp510 system:
tc@hp510:/krubo/work/TC$ tar xvf linux-6.18.28-patched.tar.xz
tc@hp510:/krubo/work/TC$ cd *28
tc@hp510:/krubo/work/TC/linux-6.18.28$ cp ../config-6.18.28-tinycore ./.config
tc@hp510:/krubo/work/TC/linux-6.18.28$ make mrproper
CLEAN .config
tc@hp510:/krubo/work/TC/linux-6.18.28$ cp ../config-6.18.28-tinycore ./.config
tc@hp510:/krubo/work/TC/linux-6.18.28$ make oldconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/confdata.o
HOSTCC scripts/kconfig/expr.o
LEX scripts/kconfig/lexer.lex.c
YACC scripts/kconfig/parser.tab.[ch]
HOSTCC scripts/kconfig/lexer.lex.o
HOSTCC scripts/kconfig/menu.o
HOSTCC scripts/kconfig/parser.tab.o
HOSTCC scripts/kconfig/preprocess.o
HOSTCC scripts/kconfig/symbol.o
HOSTCC scripts/kconfig/util.o
HOSTLD scripts/kconfig/conf
#
# No change to .config
#
tc@hp510:/krubo/work/TC/linux-6.18.28$ make bzImage
tc@hp510:/krubo/work/TC/linux-6.18.28$ cd arch/x86/boot
tc@hp510:/krubo/work/TC/linux-6.18.28/arch/x86/boot$ ls -l bz*
-rw-r--r-- 1 tc staff 6312448 May 27 12:42 bzImage
bzImage on TC17.1 download location http://tinycorelinux.net/17.x/x86/release_candidates/tc17.1/
bzImage 08-May-2026 18:33 6111744... What i did:Now you see why you run make mrproper before copying the config file.
Code: [Select]----- Snip -----...
tc@hp510:/krubo/work/TC/linux-6.18.28$ cp ../config-6.18.28-tinycore ./.config
tc@hp510:/krubo/work/TC/linux-6.18.28$ make mrproper
CLEAN .config
tc@hp510:/krubo/work/TC/linux-6.18.28$ cp ../config-6.18.28-tinycore ./.config
----- Snip -----
./ProgramNameThis tells the shell to look in the current directory instead of searching $PATH:tc@E310:~$ echo $PATH
/home/tc/.local/bin:/usr/local/sbin:/usr/local/bin:/apps/bin:/usr/sbin:/usr/bin:/sbin:/bin:/etc/sysconfig/tcedir/ondemandcd ./ # This does nothing
cd ../ # This moves you up one level in the directorytc@hp510:/krubo/work/TC/linux-6.18.28$ cp ../config-6.18.28-tinycore ./.config # The ./ is redundant
tc@hp510:/krubo/work/TC/linux-6.18.28$ cp ../config-6.18.28-tinycore .config # This accomplishes the same thing...Code: [Select]----- Snip -----
tc@hp510:/krubo/work/TC/linux-6.18.28/arch/x86/boot$ ls -l bz*
-rw-r--r-- 1 tc staff 6312448 May 27 12:42 bzImage
bzImage on TC17.1 download location http://tinycorelinux.net/17.x/x86/release_candidates/tc17.1/
bzImage 08-May-2026 18:33 6111744
So....
My bzImage is 20k bigger than the published version ...
tc@E310:~$ calc 6312448-6111744
200704... mmmmh... calc is a fun tool. ThanksYes it is. Just bear in mind, it's a simple calculator:
tc@E310:~$ cat /usr/bin/calc
#!/bin/busybox ash
. /etc/init.d/tc-functions
useBusybox
if [ -z ${1} ]; then
echo
echo " -=[ Simple Awk Calculator ]=-"
echo "Put formula in quotes (single or double) examples:"
echo "calc '3*4'"
echo "calc 'sqrt(9)'"
exit 0
fi
awk "BEGIN{ print $* }"
... What i did:
Code: [Select]----- Snip -----...
tc@hp510:/krubo/work/TC/linux-6.18.28$ cp ../config-6.18.28-tinycore ./.config
tc@hp510:/krubo/work/TC/linux-6.18.28$ make mrproper
CLEAN .config
tc@hp510:/krubo/work/TC/linux-6.18.28$ cp ../config-6.18.28-tinycore ./.config
----- Snip -----
Hi Paul_123In reality..
Actually, he realized what happened, and copied the config a second time:
Ok, I missed that. So back to my original statement. I wonder if there is a problem with your compression setup.Ok.. I tried but “advdef not found”.
What happens if you try to recompress the kernel with advdef -z4
tce-load -wi advcomp
Hi StefannAlmost!…… This worked:
Install advcomp.tcz.
tc@hp510:~$ tce-load -wi advcomp.tczBut thanks for the tcz name. I would not have found that otherwisetc@hp510:/krubo/work/TC/linux-6.18.28/arch/x86/boot$ advdef -z4 bzImage
File type not supported on bzImage [at void convert_inplace(const string&):redef.cc:498]It wants the file name to end in .gz But if you did not have advcomp.tcz installed when compiling the kernel, then it did not get fully compressed.
With advcomp installed just remove the old bzImage from arch/x86/boot. Then run "make bzImage" again
It should go faster as it should not have to recompile most of the code from the last run.
tc@hp510:/krubo/work/TC/linux-6.18.28/arch/x86/boot$ ls -l bz*
-rw-r--r-- 1 tc staff 6312448 May 28 21:43 bzImagetc@Devel:~/linux-6.18.28/arch/x86/boot/compressed$ ls -l vmlinux*
-rwxr-xr-x 1 tc staff 6107368 May 29 23:38 vmlinux
-rwxr-xr-x 1 tc staff 12469728 May 29 23:38 vmlinux.bin
-rw-r--r-- 1 tc staff 6046727 May 29 23:38 vmlinux.bin.gz
-rw-r--r-- 1 tc staff 3077 May 29 23:38 vmlinux.lds
-rw-rw-r-- 1 tc staff 2308 May 8 06:40 vmlinux.lds.S
-rw-r--r-- 1 tc staff 666652 May 29 23:38 vmlinux.relocs
tc@hp510:/krubo/work/TC/linux-6.18.28/arch/x86/boot/compressed$ ls -l vm*
-rwxr-xr-x 1 tc staff 6308072 May 27 12:42 vmlinux
-rwxr-xr-x 1 tc staff 12469728 May 27 12:42 vmlinux.bin
-rw-r--r-- 1 tc staff 6248050 May 27 12:42 vmlinux.bin.gz
-rw-r--r-- 1 tc staff 3077 May 27 12:42 vmlinux.lds
-rw-r--r-- 1 tc staff 2308 May 8 08:40 vmlinux.lds.S
-rw-r--r-- 1 tc staff 666652 May 27 12:42 vmlinux.relocsdownload http://tinycorelinux.net/17.x/x86/release/src/kernel/linux-6.18.2/config-6.18.2-tinycore
download http://tinycorelinux.net/17.x/x86/release/src/kernel/linux-6.18.2-patched.tar.xz
tc@hp510:/krubo/work/TC$ tar xvf linux-6.18.2-patched.tar.xz
tc@hp510:/krubo/work/TC$ cd linux-6.18.2
tc@hp510:/krubo/work/TC/linux-6.18.2$
tc@hp510:/krubo/work/TC/linux-6.18.2$ cp ../config-6.18.2-tinycore .config
tc@hp510:/krubo/work/TC/linux-6.18.2$ make mrproper
CLEAN .config
tc@hp510:/krubo/work/TC/linux-6.18.2$ cp ../config-6.18.2-tinycore .config
tc@hp510:/krubo/work/TC/linux-6.18.2$ make oldconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/confdata.o
HOSTCC scripts/kconfig/expr.o
LEX scripts/kconfig/lexer.lex.c
YACC scripts/kconfig/parser.tab.[ch]
HOSTCC scripts/kconfig/lexer.lex.o
HOSTCC scripts/kconfig/menu.o
HOSTCC scripts/kconfig/parser.tab.o
HOSTCC scripts/kconfig/preprocess.o
HOSTCC scripts/kconfig/symbol.o
HOSTCC scripts/kconfig/util.o
HOSTLD scripts/kconfig/conf
#
# configuration written to .config
#
tc@hp510:/krubo/work/TC/linux-6.18.2$ make bzImage
...................lots of logging................
tc@hp510:/krubo/work/TC/linux-6.18.2$
tc@hp510:/krubo/work/TC/linux-6.18.2$ cd arch/x86/boot
tc@hp510:/krubo/work/TC/linux-6.18.2/arch/x86/boot$ ls -l bz*
-rw-r--r-- 1 tc staff 6087168 Jun 2 17:00 bzImage
tc@hp510:/krubo/work/TC/linux-6.18.2/arch/x86/boot$ cd compressed
tc@hp510:/krubo/work/TC/linux-6.18.2/arch/x86/boot/compressed$ ls -l vm*
-rwxr-xr-x 1 tc staff 6082840 Jun 2 17:00 vmlinux
-rwxr-xr-x 1 tc staff 12428768 Jun 2 16:55 vmlinux.bin
-rw-r--r-- 1 tc staff 6025154 Jun 2 17:00 vmlinux.bin.gz
-rw-r--r-- 1 tc staff 3106 Jun 2 16:55 vmlinux.lds
-rw-r--r-- 1 tc staff 2296 Dec 18 14:03 vmlinux.lds.S
-rw-r--r-- 1 tc staff 663872 Jun 2 16:55 vmlinux.relocs
- copy to production machine
- reboot towards this new kernel
- recompile application
- recompile accelerated crash program
- start application
- start accelerated crash programtc@huis:/mnt/sda1/tce/boot$ ls -l vm*
-rwxrw-r-- 1 tc staff 6087168 Feb 10 13:10 vmlinuz
-rw-rw-r-- 1 tc staff 6087168 Jun 2 17:11 vmlinuz17C2xSo... apparently the install of advcomp.tcz fixed thatmon day: 6 2 | hh:mm:ss: 20:18:50 | Still alive after 0k + 1 loops | 0k + 2 bytes read
mon day: 6 3 | hh:mm:ss: 18:41:05 | Still alive after 31324k + 802 loops | 62588k + 776 bytes readtc@huis:/mnt/sda1/tce/boot$ ls -l vm*
-rwxrw-r-- 1 tc staff 6087168 Feb 10 13:10 vmlinuz
-rw-rw-r-- 1 tc staff 6087168 Jun 2 17:11 vmlinuz17C2x
tc@huis:/mnt/sda1/tce/boot$ cmp vmlinuz vmlinuz17C2x
vmlinuz vmlinuz17C2x differ: char 105, line 1So: size is exactly the same but they still differ... So: size is exactly the same but they still differ ...It's possible a timestamp or some other unique identifier gets added
tc@huis:/tmp$ mkdir TC
tc@huis:/tmp$ cd TC
tc@huis:/tmp/TC$ wget --header='Accept-Language: en-us,en;q=0.5' http://tinycorelinux.net/17.x/x86/release/Core-17.0.iso
Connecting to tinycorelinux.net (128.127.66.77:80)
saving to 'Core-17.0.iso'
Core-17.0.iso 100% |***************************************************************************| 19.5M 0:00:00 ETA
'Core-17.0.iso' saved
tc@huis:/tmp/TC$ wget --header='Accept-Language: en-us,en;q=0.5' http://tinycorelinux.net/17.x/x86/release/Core-17.0.iso.md
5.txt
Connecting to tinycorelinux.net (128.127.66.77:80)
saving to 'Core-17.0.iso.md5.txt'
Core-17.0.iso.md5.tx 100% |***************************************************************************| 48 0:00:00 ETA
'Core-17.0.iso.md5.txt' saved
tc@huis:/tmp/TC$ md5sum -c Core-17.0.iso.md5.txt
Core-17.0.iso: OK
tc@huis:/tmp/TC$ mkdir tc17
tc@huis:/tmp/TC$ ls
Core-17.0.iso tc17/
tc@huis:/tmp/TC$ sudo mount Core-17.0.iso tc17
tc@huis:/tmp/TC$ cd tc17
tc@huis:/tmp/TC/tc17$ cd boot
tc@huis:/tmp/TC/tc17/boot$ ls
core.gz isolinux/ vmlinuz
tc@huis:/tmp/TC/tc17/boot$ cp vmlinuz /mnt/sda1/tce/boot/vmlinuz_org2
tc@huis:/tmp/TC/tc17/boot$ cd /mnt/sda1/tce/boot
tc@huis:/mnt/sda1/tce/boot$ ls -l vm*
-rwxrw-r-- 1 tc staff 6087168 Feb 10 13:10 vmlinuz
-rw-rw-r-- 1 tc staff 6087168 Jun 2 17:11 vmlinuz17C2x
-r--r--r-- 1 tc staff 6087168 Jun 4 08:35 vmlinuz_org2
tc@huis:/mnt/sda1/tce/boot$ cmp --verbose vmlinuz vmlinuz_org2
tc@huis:/mnt/sda1/tce/boot$ // no respons so they are equalso... no... the vmlinuz that has been crashing so often is exactly equal to a freshly downloaded one.tc@huis:/mnt/sda1/tce/boot$ cmp -b vmlinuz vmlinuz17C2x
vmlinuz vmlinuz17C2x differ: byte 105, line 1 is 271 M-9 211 M-^I
tc@huis:/mnt/sda1/tce/boot$ cmp --verbose vmlinuz vmlinuz17C2x
105 271 211
106 201 210
589 363 302
590 350 357
613 314 234
614 101 110
617 234 174
618 205 214
9463 210 200
9469 334 324
9565 210 200
9572 334 324
10472 210 200
10479 334 324
10539 210 200
10545 334 324
10594 334 324
10670 210 200
10701 334 324
10903 210 200
10914 334 324
11658 174 164
11665 224 214
11672 160 150
11679 210 200
11686 144 134
12357 110 100
13099 260 250
13848 314 304
15381 116 150
15382 125 160
15383 103 65
.............. and it keeps going......
........ just skipping the middle part....
6085719 0 123
6085721 0 145
6085723 0 145
6085725 0 144
6085729 0 123
6085731 0 145
6085733 0 143
6085735 0 165
6085737 0 162
6085739 0 145
6085741 0 102
6085743 0 157
6085745 0 157
6085747 0 164
6085751 0 123
6085753 0 145
6085755 0 164
6085757 0 165
6085759 0 160
6085761 0 115
6085763 0 157
6085765 0 144
6085767 0 145...... so... the filesize being equal is likely related to snapping to some blocksizetc@huis:/mnt/sda1/tce/boot$ ls -l vmlinuz17C2*
-rw-rw-r-- 1 tc staff 6087168 Jun 2 17:11 vmlinuz17C2x
-rw-r--r-- 1 tc staff 6087168 Jun 5 12:51 vmlinuz17C2xx
tc@huis:/mnt/sda1/tce/boot$ cmp vmlinuz17C2x vmlinuz17C2xx
vmlinuz17C2x vmlinuz17C2xx differ: char 105, line 1
tc@huis:/mnt/sda1/tce/boot$ cmp --verbose vmlinuz17C2x vmlinuz17C2xx
105 211 171
589 302 261
613 234 214
617 174 134
15395 124 106
15396 165 162
15397 145 151
15404 62 65
15407 66 61
15409 65 60
15410 65 64
15412 61 60
15413 62 63
16527 130 110
4956393 334 33
4956394 106 107
4956396 145 345
4956397 352 324
4956398 174 371
4956399 245 112
4956400 117 237
4956401 201 2
4956402 311 231
4956403 226 55
4956404 52 325
4956405 63 44
4956407 222 226
4956411 75 35
4956412 316 317
4956413 233 313
4956414 255 326
.............. and it keeps going......
........ just skipping the middle part....
6085688 56 0
6085689 12 145
6085691 151 145
6085693 156 144
6085695 151 0
6085697 164 123
6085699 162 145
6085701 144 143
6085703 75 165
6085705 0 162
6085707 122 145
6085709 141 102
6085711 156 157
6085713 144 157
6085715 157 164
6085717 155 0
6085723 145 164
6085725 144 165
6085727 0 160
6085729 123 115
6085731 145 157
6085733 143 144
6085735 165 145
6085737 162 0
6085739 145 0
6085741 102 0
6085743 157 0
6085745 157 0
6085747 164 0
6085751 123 0
6085753 145 0
6085755 164 0
6085757 165 0
6085759 160 0
6085761 115 0
6085763 157 0
6085765 144 0
6085767 145 0
mon day: 6 2 | hh:mm:ss: 20:18:50 | Still alive after 0k + 1 loops | 0k + 2 bytes read
mon day: 6 6 | hh:mm:ss: 14:47:54 | Still alive after 126702k + 554 loops | 253158k + 172 bytes read@Stefann, just out of sheer curiosity, what are you planning to use after your current hardware fails?Ha! fun question.
@Stefann, thanks for your latest reply(#187) to my previous question regarding eventual hardware failure. Very informative!Well.. thanks for the mental support, at least I feel "some are reading/appreciating this"
hopefully at some point we will know exactly what is happening with your system and this thread will assist other future visitors with troubleshooting.
again, huge kudos and thanks for all your efforts!
(hope your garden survived the extra watering)
... - I could go back to TC15 to at least get a confirmation that "crash free running is possible" ...I would do that just to make sure something in the hardware hasn't changed.
Hi StefannYes thanks for the thoughts.... - I could go back to TC15 to at least get a confirmation that "crash free running is possible" ...I would do that just to make sure something in the hardware hasn't changed.
I would also recommend you replace the TC17 install with TC15 on the same
storage device it currently occupies, just to rule out any random storage
device data errors.
power supplies can become faulty over time. degraded board-level components can cause low/poor performance regarding hertz/voltage/wattage/etc. nothing lasts forever(naturally).Status: still running after 48 hrs… hope is growing.
kudos and keep us posted!
Power est. Usage Events/s Category Description
0 mW 100.0% Device PCI Device: VIA Technologies, Inc. CX700/VX700 [S3 UniChrome Pro]
0 mW 100.0% Device PCI Device: VIA Technologies, Inc. VX900/VT8xxx High Definition Audio Controller
0 mW 100.0% Device PCI Device: VIA Technologies, Inc. VT82xx/62xx/VX700/8x0/900 UHCI USB 1.1 Controller
0 mW 100.0% Device PCI Device: VIA Technologies, Inc. CX700M2/VX700/VX800/820-Series Serial ATA & EIDE-Controller
0 mW 100.0% Device PCI Device: VIA Technologies, Inc. CX700/VX700-Series Host Interface Control
0 mW 100.0% Device USB device: UHCI Host Controller
0 mW 100.0% Device PCI Device: VIA Technologies, Inc. CX700/VX700 Host Bridge
0 mW 100.0% Device USB device: UHCI Host Controller
0 mW 100.0% Device PCI Device: VIA Technologies, Inc. CX700/VX700-Series North-South Module Interface Control
0 mW 100.0% Device PCI Device: VIA Technologies, Inc. VT82xx/62xx/VX700/8x0/900 UHCI USB 1.1 Controller
0 mW 59.4 pkts/s Device Network interface: eth0 (8139too)
0 mW 100.0% Device PCI Device: VIA Technologies, Inc. USB 2.0 EHCI-Compliant Host-Controller
0 mW 100.0% Device PCI Device: VIA Technologies, Inc. CX700/VX700-Series Error Reporting
0 mW 100.0% Device PCI Device: VIA Technologies, Inc. CX700/VX700 Internal Module Bus
0 mW 100.0% Device PCI Device: VIA Technologies, Inc. CX700/VX700-Series DRAM Bus Control
0 mW 100.0% Device PCI Device: VIA Technologies, Inc. CX700/VX700-Series Power Management and Testing Control
0 mW 100.0% Device PCI Device: VIA Technologies, Inc. CX700/VX700 Host Bridge
0 mW 100.0% Device PCI Device: VIA Technologies, Inc. CX700/VX700-Series Bus Control and Power Management
0 mW 100.0% Device PCI Device: VIA Technologies, Inc. VT8237/CX700/VX700-Series PCI to PCI Bridge
0 mW 0.0% Device runtime-alarmtimer.0.auto
0 mW 0.0% Device runtime-pcspkr
0 mW 0.0% Device runtime-vga-framebuffer.0
0 mW 0.0% Device runtime-i8042
0 mW 0.0% Device runtime-PNP0C0C:00
0 mW 0.0% Device runtime-serial8250
0 mW 0.0% Device runtime-PNP0C04:00
0 mW 0.0% Device runtime-PNP0C0E:00
0 mW 0.0% Device runtime-PNP0103:00
0 mW 0.0% Device runtime-PNP0800:00
0 mW 0.0 pkts/s Device nic:dummy0
0 mW 0.0 pkts/s Device nic:tunl0
0 mW 0.0% Device USB device: EHCI Host ControllerMem: 699732K used, 261736K free, 48616K shrd, 6768K buff, 329676K cached
CPU: 3.8% usr 3.8% sys 0.0% nic 92.2% idle 0.0% io 0.0% irq 0.0% sirq
Load average: 0.05 0.20 0.17 1/216 11868
PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND
5399 1 tc S 11584 1.2 0 6.4 /krubo/work/krubo /krubo/work/1wire.def
11868 11358 tc R 3600 0.3 0 0.5 top
3379 1 root S 54620 5.6 0 0.1 /usr/local/sbin/rsyslogd
11357 11353 tc S 7972 0.8 0 0.1 sshd-session: tc@pts/0
15 2 root IW 0 0.0 0 0.1 [rcu_sched]
25 2 root SW 0 0.0 0 0.1 [kcompactd0]
3882 3873 tc S 443m 47.1 0 0.0 /usr/local/sbin/httpd -k start
3879 3873 tc S 443m 47.1 0 0.0 /usr/local/sbin/httpd -k start
3894 3873 tc S 443m 47.1 0 0.0 /usr/local/sbin/httpd -k start
4056 3873 tc S 443m 47.1 0 0.0 /usr/local/sbin/httpd -k start
3873 1 root S 162m 17.2 0 0.0 /usr/local/sbin/httpd -k start
3871 1 root S 51160 5.3 0 0.0 Xvesa -br -screen 1024x768x32 -shadow -2button -mouse /dev/input/mice,5 -nolisten tcp -I
3721 3707 root S 18868 1.9 0 0.0 /usr/local/sbin/smbd -D
3707 1 root S 18812 1.9 0 0.0 /usr/local/sbin/smbd -D
3969 1 root S 11864 1.2 0 0.0 x0vncserver -PasswordFile=/home/tc/.vnc/passwd
3991 1 tc S 9852 1.0 0 0.0 wbar
3876 1 tc S 9844 1.0 0 0.0 flwm
4154 3991 tc S 8768 0.9 0 0.0 apps
4158 3991 tc S 8768 0.9 0 0.0 apps
4156 3991 tc S 8768 0.9 0 0.0 apps
4157 3991 tc S 8768 0.9 0 0.0 apps
4160 3991 tc S 8768 0.9 0 0.0 apps
4161 3991 tc S 8768 0.9 0 0.0 apps
4159 3991 tc S 8768 0.9 0 0.0 apps
11410 3991 tc S 8768 0.9 0 0.0 apps
11411 3991 tc S 8768 0.9 0 0.0 apps
11353 3747 root S 7564 0.7 0 0.0 sshd-session: tc [priv]
3747 1 root S 7312 0.7 0 0.0 sshd: /usr/local/sbin/sshd [listener] 0 of 10-100 startups
3546 1 root S 6056 0.6 0 0.0 /usr/local/sbin/nmbd -D
3269 1 root S 3604 0.3 0 0.0 crond
1 0 root S 3604 0.3 0 0.0 /sbin/init
3875 1 root S 3604 0.3 0 0.0 ntpd -p pool.ntp.org
11864 3269 tc S 3604 0.3 0 0.0 {exe} ash /krubo/work/krubo_watchdog
3326 1 root S 3604 0.3 0 0.0 /sbin/udhcpc -b -i eth0 -x hostname:huis -p /var/run/udhcpc.eth0.pid
11358 11357 tc S 3600 0.3 0 0.0 -sh
3310 1 tc S 3600 0.3 0 0.0 -sh
11867 11864 tc S 3468 0.3 0 0.0 sleep 3m
90 1 root S 2352 0.2 0 0.0 /sbin/udevd --daemon
388 90 root S 2352 0.2 0 0.0 /sbin/udevd --daemon
392 90 root S 2352 0.2 0 0.0 /sbin/udevd --daemon
27 2 root SWN 0 0.0 0 0.0 [khugepaged]
56 2 root IW 0 0.0 0 0.0 [kworker/0:2-eve]
14 2 root SW 0 0.0 0 0.0 [ksoftirqd/0]
12 2 root IW 0 0.0 0 0.0 [kworker/u4:0-ev]
52 2 root IW 0 0.0 0 0.0 [kworker/u4:3-kv]
3356 2 root SW 0 0.0 0 0.0 [cifsd]Only “slightly remarkable thing” is the 92.2% nic use. I constantly poll network connected devices so this is not strange.... Also, observing top:Actually, you misread the nic use, so no, it's not alarming.Code: [Select]Mem: 699732K used, 261736K free, 48616K shrd, 6768K buff, 329676K cachedOnly “slightly remarkable thing” is the 92.2% nic use. I constantly poll network connected devices so this is not strange.
CPU: 3.8% usr 3.8% sys 0.0% nic 92.2% idle 0.0% io 0.0% irq 0.0% sirq
Load average: 0.05 0.20 0.17 1/216 11868
----- Snip -----
is that alarming??
Hi StefannAh! Thanks. At least “reducing ip traffic” is not a high priority.... Also, observing top:Actually, you misread the nic use, so no, it's not alarming.Code: [Select]Mem: 699732K used, 261736K free, 48616K shrd, 6768K buff, 329676K cachedOnly “slightly remarkable thing” is the 92.2% nic use. I constantly poll network connected devices so this is not strange.
CPU: 3.8% usr 3.8% sys 0.0% nic 92.2% idle 0.0% io 0.0% irq 0.0% sirq
Load average: 0.05 0.20 0.17 1/216 11868
----- Snip -----
is that alarming??
What it really says is:
CPU usage (or cycles if you wish)
3.8% usr - time running un-niced user processes
3.8% sys - time running kernel processes
0.0% nic - time running niced user processes
92.2% idle - time spent in the kernel idle handler
0.0% io - time waiting for I/O completion
0.0% irq - time spent servicing hardware interrupts
0.0% sirq - time spent servicing software interrupts
Found here:
https://unix.stackexchange.com/a/499297
If you want to monitor the NIC, maybe iftop.tcz would be of some help.
Hi StefannThanks... so using power top has only limited value. Well... at least I have a view on "what devices are in use".
I suspect your motherboard does not measure/expose power readings.
I think powertop is intended for battery powered devices like laptops.
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governorcat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governorsecho conservative | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governorYou'll definitely want your energy for this test.tc@huis:/sys/devices/system/cpu$ ls
cpu0/ hotplug/ offline present
cpufreq/ isolated online smt/
cpuidle/ kernel_max possible uevent
enabled modalias power/ vulnerabilities/
tc@huis:/sys/devices/system/cpu$ cd cpu0
tc@huis:/sys/devices/system/cpu/cpu0$ ls
cpu_capacity firmware_node power/ topology/
driver hotplug/ subsystem uevent
tc@huis:/sys/devices/system/cpu/cpu0$ cd power
tc@huis:/sys/devices/system/cpu/cpu0/power$ ls
autosuspend_delay_ms pm_qos_resume_latency_us runtime_status
control runtime_active_time runtime_suspended_time
tc@huis:/sys/devices/system/cpu/cpu0/power$ cd ..
tc@huis:/sys/devices/system/cpu/cpu0$ cat cpu_capacity
1024
tc@huis:/sys/devices/system/cpu/cpu0$ cd ..
tc@huis:/sys/devices/system/cpu$ ls
cpu0/ hotplug/ offline present
cpufreq/ isolated online smt/
cpuidle/ kernel_max possible uevent
enabled modalias power/ vulnerabilities/
tc@huis:/sys/devices/system/cpu$ cd cpufreq
tc@huis:/sys/devices/system/cpu/cpufreq$ ls
tc@huis:/sys/devices/system/cpu/cpufreq$sudo modprobe acpi-cpufreq.ko.gz
sudo modprobe p4-clockmod.ko.gzThen check for a governor again.tce-load -wi util-linuxand provide the output of:lscpu
Hi StefannI will do,
Try loading these 2 drivers:Code: [Select]sudo modprobe acpi-cpufreq.ko.gzThen check for a governor again.
sudo modprobe p4-clockmod.ko.gz
Also:Code: [Select]tce-load -wi util-linuxand provide the output of:Code: [Select]lscpu
tc@hp510:/lib/modules/6.18.35-tinycore/kernel/drivers/cpufreq$ ls
acpi-cpufreq.ko.gz longrun.ko.gz
amd_freq_sensitivity.ko.gz p4-clockmod.ko.gz
cpufreq-nforce2.ko.gz powernow-k6.ko.gz
cpufreq_conservative.ko.gz powernow-k7.ko.gz
cpufreq_powersave.ko.gz powernow-k8.ko.gz
cpufreq_userspace.ko.gz speedstep-ich.ko.gz
gx-suspmod.ko.gz speedstep-lib.ko.gz
longhaul.ko.gz speedstep-smi.ko.gz
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-clockmo
d.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$ Any clues???tc@hp510:~$ sudo modprobe acpi-cpufreq.ko.gz
....
tc@hp510:/sys/devices/system/cpu/cpu0/cpufreq$ cat scaling_available_governors
userspace conservative powersave ondemand performance schedutil
....
tc@hp510:/sys/devices/system/cpu/cpu0/cpufreq$ cat scaling_governor
schedutiltc@hp510:/sys/devices/system/cpu/cpu0/cpufreq$ tce-load -wi util-linux
util-linux.tcz.dep OK
Downloading: util-linux.tcz
Connecting to repo.tinycorelinux.net (128.127.66.77:80)
saving to 'util-linux.tcz'
util-linux.tcz 100% |********************************************************************************************| 1684k 0:00:00 ETA
'util-linux.tcz' saved
util-linux.tcz: OK
tc@hp510:/sys/devices/system/cpu/cpu0/cpufreq$ lscpu
Architecture: i686
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 36 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Vendor ID: CentaurHauls
Model name: VIA Eden X2 U4200 @ 1.0+ GHz
CPU family: 6
Model: 15
Thread(s) per core: 1
Core(s) per socket: 2
Socket(s): 1
Stepping: 13
Frequency boost: enabled
CPU(s) scaling MHz: 90%
CPU max MHz: 1000.0000
CPU min MHz: 800.0000
BogoMIPS: 2000.40
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht tm sysca
ll nx lm constant_tsc arch_perfmon rep_good cpuid pni monitor vmx est tm2 ssse3 cx16 xtpr sse4_1 popcnt rng rng
_en ace ace_en ace2 phe phe_en pmm pmm_en lahf_lm tpr_shadow vpid ida vnmi
Virtualization features:
Virtualization: VT-x
Caches (sum of all):
L1d: 128 KiB (2 instances)
L1i: 128 KiB (2 instances)
L2: 2 MiB (2 instances)
Vulnerabilities:
Gather data sampling: Not affected
Ghostwrite: Not affected
Indirect target selection: Not affected
Itlb multihit: KVM: Mitigation: VMX disabled
L1tf: Vulnerable
Mds: Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled
Meltdown: Vulnerable
Mmio stale data: Not affected
Old microcode: Not affected
Reg file data sampling: Not affected
Retbleed: Not affected
Spec rstack overflow: Not affected
Spec store bypass: Vulnerable
Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Spectre v2: Mitigation; Retpolines; STIBP disabled; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected
Srbds: Not affected
Tsa: Not affected
Tsx async abort: Not affected
Vmscape: Not affected...It should either try to load (full path):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 -----
/lib/modules/6.18.35-tinycore/kernel/drivers/cpufreq/p4-clockmod.ko.gzor in this case (current directory):./p4-clockmod.ko.gzsudo /sbin/depmod -a
sudo /sbin/udevadm trigger
sudo modprobe p4-clockmod.ko.gzsudo modprobe /lib/modules/6.18.35-tinycore/kernel/drivers/cpufreq/p4-clockmod.ko.gzsudo modprobe /lib/modules/$(uname -r)/kernel/drivers/cpufreq/p4-clockmod.ko.gz
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.gzls -l /lib/modules/$(uname -r)/modules.dep
grep "p4-clockmod" /lib/modules/$(uname -r)/modules.dep
Hi StefannNote, system still running. No crash in 4.5 day.
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
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:~$ 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:~$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)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.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 as5.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)... - +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.
Hi StefannAh.. yes… that makes an enormous amount of sense.... - +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.
... 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
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.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 theTrigger - 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...definitely remember those mechanical "crackling" contacts/switches/etc. and the "tv tuner" we always carried on all the service calls.
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.
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
... The triggering went on continuously, was not able to stop it. ...That could be due to the scopes trigger circuitry itself.
... 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
... Indeed not a storage scope. ...But it is a dual beam oscilloscope, which is not very common.
@Stefann, oops...apologies from all of _us_ who already had our fingers crossed. ha!Ha Ha Ha...
Hi StefannPfew... Happy about that.
No, I was not offended. :)
int Stress()
{ int i;
float d1[200], d2[200];
while (1)
{ for (i=0; i<100; i++)
{ d1[i] = 1.111*i; }
for (i=0; i<100; i++)
{ d2[i] = d1[i]/ 1.111; }
for (i=0; i<100; i++)
{ d1[i] = d2[i] * 1.111; }
}
return 1;
}
... any suggestions how I can drive higher power use? ...Maybe try the SimplePi script I created:
... - some mod (Rich? you can?) to update title with [solved] label. ...Done. :)