Re: Tiny Core v17.0 upgrade issues

[Stefann]

@Zhe, Thanks! found it.
And @rich: dont worry, I appreciate all help!

Code: [Select]

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, 480M

Code: [Select]

tc@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 ttyUSB0

Code: [Select]

tc@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
Next to that....
I made some steps to set this up a bit more structural
- system is now running in fully normal state on TC17
- I disabled the syslog that @rich defined for me
- I re-enabled the rsyslog that I am usually using. Now I have my normal logging back
- I included a line for system logging. It's now logging on "notice" level:

Code: [Select]

# 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.
- proper rotation is in place.

Now... wait...

As said, by latest Monday I will revert to TC15 as I need to have a robust run between April 2-10 when I'm travelling

[Rich]

Hi Stefann
A couple of items:

...

Code: [Select]

tce-load -wi usbutils
lsusb > lsusb.txt
lsusb -t >> lsusb.txt

You forgot to run the first version of the command.
The first version shows VID and PID numbers but not how devices are connected.
The second version shows how devices are connected but not VID and PID numbers.

...

Code: [Select]

----- Snip -----

lsmod | head -n 1 > lsmod.txt
lsmod | tail -n +2 | sort >> lsmod.txt ...

These two commands were not meant to be run in isolation. When run as
shown, the resulting file contains the header immediately followed by a
sorted list of loaded modules. I corrected the result in your post to show
how it should have looked.

This would have worked too:

Code: [Select]

lsmod | head -n 1 && lsmod | tail -n +2 | sort

[Stefann]

You forgot to run the first version of the command.

oops. here you go:

Code: [Select]

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
Bus 003 Device 002: ID 0bc7:0001 X10 Wireless Technology, Inc. ActiveHome (ACPI-compliant)
This is a usb connected peripheral I control from my application with libusb

Bus 002 Device 002: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter
Also a usb connected peripheral I control from my application with libusb

Bus 002 Device 003: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
This seems to be the serial device. I don't have info. Its a black interface cable I bought 17years ago.

[Paul_123]

Well, there is alot there to unpack.  But any of that could be your issue.  But at least we have a clear understanding of drivers involved.   Could be any of them

[Rich]

Hi Stefann

...

Code: [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 ...

I don't know if it's an issue, but your peripherals appear to be plugged
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.

[Stefann]

Hi Stefann

...

Code: [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 ...

I don't know if it's an issue, but your peripherals appear to be plugged
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.

Well…it’s a low power low spec computer from 2008. 500MHz single core. So it’s definitely not fast.
There is not much choice on ports. There are only 3 on the outside and I’m using all 3.
The 480M port is NOT available on the outside. Could this be the compact flash drive?
The system does not have harddisk but a compact flash card as persistent at storage.

Speed however is not a big thing.
- the serial port reads my energy meter that spits out a data block of 500 bytes each second.
- the X10 interface controls the lights in the house. That’s blocks of about 20 bytes each time a light gets switched.
- the 1 wire is the only time critical thing. It is a constant stream of data. 1 wire protocol allows bit-length to be 75us so that is still only 13kHz. Keeping that thing at full speed is important. It currently takes 250ms to Do a “all sensor read” of the house. That should not get longer.

System still running since start yesterday afternoon.

[Stefann]

For those interested,
manual for this 18yr old computer is still online (amazing!):
https://ftp.emacinc.com/LegacyProducts/EmbeddedServers/ebox-4300/Manual/ebox_4300_manual.pdf

I have version with 1G ram.
I have it currently with 8G compact flash as persistent storage.
It runs on a low power (1 watt) 500MHz 32bit single core Via Eden  x86 based processor
I donot have the (optional) serial port

[Rich]

Hi Stefann

... 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
USB to RS-232 cable contains a transmit FIFO, so I decided to do a
little math.

Assuming:
8 data bits, 1 parity bit, 1 start bit, 2 stop bits (12 bits).
Baud  rate of 9600 (~104 uSecs/bit).
Data bursts of 500 bytes.

12 bits * 0.000104 secs = 0.001248 secs
500 bytes * 0.001248 secs = 0.624 secs

This assumes zero gap time between transmitted bytes.
The RS-232 spec does not specify min/max gap times.

[Rich]

Hi Stefann
Is the USB to RS-232 cable you are using listed here:
https://ftdichip.com/product-category/products/cables/usb-rs232-cable-series/

[Stefann]

Hi,
its difficult to say as I bought the cable 17 years ago.

I just went through my notes.
I cannot find a literal order, but my notes indicate that I was intending to buy: "FTDI TTL-232R (5V)".

From the website you shared that is close to this one:
https://ftdichip.com/products/usb-rs232-we-5000-bt_5-0/
But my usb-connector is black, not transparant.

I can see I saved screenshots from "FTDI FT prog" that configures the cable. So it looks like I kind of have that one.

For the record: it's still running. About 24hrs now.
logging is coming in. But to be honest, not much interesting. Just crontabs getting fired.
It's nice that the logging is now on a separate network connected system. That also means that in case of a crash I can check the logging before starting the crashed system.

[Stefann]

On configuration of the cable,
Probably easiest if I just share my "init code".
It's probably a bit dirty. I was learning the technology while doing the job.
It's a combination of code I grabbed from the internet with personal additions.
so.. baudrate is 11520
After this initialisation I just read the output.
The "temp" is a data structure I use for temporary results.

Code: [Select]

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;

}

[Stefann]

Update,
After 48hrs it was still running under TC17 with extra bootcode "usbcore.autosuspend=-1"
Logging at *.notice level but not much in logging. Only some application logging I made myself and some crontab-launches.

I stopped all manual.
I will be travelling April 2-10 during which period I cannot risk a crash.
So.. I reverted back to TC15 and restarted.
That gives me a few days of run hopefully without crash.
The thing did run for multipel month without crash before I started my upgrade work so in principle it should run without crash now.
However... there is always the possibility that during the upgrade I did something "TC17 unrelated" that is causing all this. So in itself this should also give confirmation that TC15 is stable.
Target to run until April 10...11.

Note...
On the positive side..
It's extremely convenient that going back to earlier release is as simple as:
- modify tce/boot/extlinux/extlinux.conf to pick the older core.gz and vmlinuz (I did not overwrite them but kept old version as core15.gz and vmlinuz15)
- rename tce/optional directory to get the previous one back (yes I made a backup :-)
- modify tce/onboot.lst to include correct kernel extension for usb-serial

try that with windows.......

unless I get a crash: dont expect to hear form me until April-11
in the mean time: any smart idea is welcome. I will not have access to my tinycore system but travel with laptop so will check this forum regularly.

[Stefann]

Hickup when I restarted on TC15,
I thought it was running (all gets started automatically all seemed up) but I noticed that the state did not change.
Better checking revealed:
- yes TC15 was running
- but my application was not

Starting it from the command line gave me:

Code: [Select]

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)
What I did:
- completely recompiled my application on TC15
- restart

now all works.

Which makes me thinking:
- I probably need to do that on TC17: "completely recompile the application"

Anyway... I now want to run the thing "crash free" for upcoming days to allow me a headache-free travel April 2-10

[Paul_123]

We update Glibc every release, For the most part Glibc is backwards compatible.  So there should be no reason to recompile when moving from 15->17.....but if you compiled under 17, then it will not work on 15.

Note that we keep referencing the Serial USB interface, but it could be any of them.  Now that you have logging figured out, it might be useful to set it so that it does crash, to hopefully verify the reason for the crash.

[Stefann]

Yes I will “set it up to crash”.
But first travel between April 2-10 running on TC15.
IF it crashes I will notice that as the system runs an Apache webserver that is available from outside.
My brother lives nearby and could than give it a manual reset.

The fricky thing is that “the full OS crashes”. No way to reset from outside.
My application has a watchdog around it. If that crashes it gets a restart after 15 minutes.

When I get back to “let it crash” I will also search my vga-monitor and keyboard that I have somewhere at the attic for exactly this reason.