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.