Re: Tiny Core v17.0 upgrade issues

[Stefann]

Question...

Brainwave....
I don't feel I can recompile the kernel

However..
- I succesfully unsquased usb-serial-6.18.2-tinycore.tcz (TC17)
- I could also unsquase usb-serial-6.12.11-tinycore.tcz (from TC16) or usb-serial-6.6.8-tinycore.tcz  (TC15)
- I could replace the TC17 usbserial.ko.gz and/or ftdi.ko.gz by the TC15 or TC16 version
- Than squase and create a custom .tcz kext for TC17.

Would that have any change to succeed??

[Paul_123]

No you cannot use old kernel modules.    I do agree, there is nothing in the specific drivers that has changed that might be related.   Getting a crash/log message is about the only thing that is going to provide any real insight as to what might be going wrong.

However a real option is to just use the improved version of your code that uses non-blocking methods......and move on.

[patrikg]

Like @Rich says, you can't take some modules from one kernel version to another.
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
 

[Stefann]

@paul_123,
Yes.. using nonblocking read seems to be a solution for me.
It’s just that “kernel crashing” is a real bad thing. It’s very likely to happen at some place at the world as well. So “finding the rootcause” is the honorable thing to do in this open source community.

Anyway… it’s running… screensaver is disabled… I now know how to get into terminal-mode from the gui… so “maybe” I get some messages at next crash. (My hopes are low as it seems to “just stall”).

[Stefann]

Like @Rich says, you can't take some modules from one kernel version to another.
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

Thanks.
Yes.. I know how to make an extension. So that part is covered
My trouble is to recompile/rebuilt the usb-serial kext with updated usb-serial.c code.
I will read and act on your posts but that will be tomorrow. Day is ending here in Europe.

[Paul_123]

What change do you want to make to the kernel module code?

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?

[Stefann]

What change do you want to make to the kernel module code?

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?

It's definitely a gamble,
But my 1st idea would be:
- replace  drivers/usb/serial/usb-serial.c from TC17 by the TC15 version
- recompile/rebuilt usb-serial-6.18.2-tinycore.tcz

Rationale:
- under TC15 my application was running multiple month without crash
- under TC17 it consistently crashes within 24h, mostly around 15hr
- when I replaced the blocking read() from data from 'serial-over-usb' port by a nonblocking read() it ran for 7days after which I manually stopped it for further investigation.

It is surely a kernel issue. System crashes and freezes completely. Not just the application,.... everything. Nothing graceful, no kernel debug-level syslog.
I would expect it to be a mishandled exception or race condition.

diff on usb-serial.c from TC15 to TC17 shows 2 suspicious changes:
- a port-closure that was protected by a "port-exist test" in TC15 towards a port-closure without that test in TC17.
- a change form spin_lock() in TC15 to guard(mutex)() in TC17 but 2x spin_unlock() in TC15 that disappear without clear TC17 alternative.

[Rich]

Hi Stefann

... 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.