Re: Tiny Core v17.0 upgrade issues

[Stefann]

So.. still running at 15:00; that means 30hrs runtime without crash

So, to summarize....
TC15:
- including kext: usb-serial-6.6.8-tinycore.tcz
- recompile full application
- run application with "every second 812byte read from /dev/ttyUSB0; baudrate 11520"
- no crash over multiple month

TC17:
- including kext: usb-serial-6.18.2-tinycore.tcz
- recompile full application
- run application with "every second 812byte read from /dev/ttyUSB0; baudrate 11520"
- 4..6x tested, always crashes, mostly after about 15hrs; always within 24hrs

TC17:
- including kext: usb-serial-6.18.2-tinycore.tcz
- SAME application, NO recompile
- run application with disabled read from /dev/ttyUSB0 by configuration constant
- 1x tested, no crash after 30hrs

Now...
This does NOT proof that the read-action is the rootcasue because earlier experiments did show that "more general load" makes the crashing earlier.

What I now have done:
- modify application code
- same "every second 812byte read from /dev/ttyUSB0; baudrate 11520"
- but close device and re-open after every 15minutes
- started at 16:00 European time

If this keeps running than I think its demonstrated that usb-serial-6.18.2-tinycore.tcz has an issue with "reading long time without intermediate closing"

fingers crossed

[patrikg]

Have you consider the BIOS with USB energy saving.

[Stefann]

I doubt my 2008 board has that.
But..... isn't that only applicable while idle? the computer is never idle but in 24/7 use.

[Stefann]

Sad.... an other crash this night at 1:30 am; after 33.5 hours

So.....
On TC17 crash after 33.5 hours if constantly reading reading from serial-over-usb port AND close/open filedescriptor every 15mins.

But....
2 days ago I concluded that running without reading serial-over-usb was crash-free as I manually stopped after 30hr of crash-free run.
>> that conclusion may be premature

Still..
WITH constant reading of serial-over-usb crash is normally in about 15hrs, and always within 24 hours.
So... although there is variation... it still looks like "altering settings of serial-over-usb" influences the behavior.

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
I also made using read, select, 15min_close/open configurable by a runtime settable variable such that I can test different configurations without recompile (to exclude impact of compilation on results)

Started at 8:22 am:

TC17:
- including kext: usb-serial-6.18.2-tinycore.tcz
- new compiled executable with runtime configurable serial read modes
- run application with non-blocking read without SELECT
- "every second 812byte read from /dev/ttyUSB0; baudrate 11520" from /dev/ttyUSB0


Recap of results so far:

TC15:
- including kext: usb-serial-6.6.8-tinycore.tcz
- recompile full application
- run application with "every second 812byte read from /dev/ttyUSB0; baudrate 11520"
- no crash over multiple month

TC17:
- including kext: usb-serial-6.18.2-tinycore.tcz
- recompile full application
- run application with "every second 812byte read from /dev/ttyUSB0; baudrate 11520"
- 4..6x tested, always crashes, mostly after about 15hrs; always within 24hrs

TC17:
- including kext: usb-serial-6.18.2-tinycore.tcz
- SAME application, NO recompile
- run application with disabled read from /dev/ttyUSB0 by configuration constant
- 1x tested, NO CRASH after 30hrs >> I thought this was good but as next config crashed after 33.5hrs I may not have been running long enough

TC17:
- including kext: usb-serial-6.18.2-tinycore.tcz
- include every 15 minute close/open file descriptor for /dev/ttyUSB0
- recompile full application
- run application with "every second 812byte read from /dev/ttyUSB0; baudrate 11520"
- 1x tested, crash after 33.5hrs

[Zhe]

try upgrade tc 16 ,maybe can shrink this problem

[Rich]

Hi Stefann

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

You mentioned in a previous post you were opening files without
closing them. If you were using those file descriptors with select(),
that could be a problem:

Code: [Select]

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 keep
opening the same file over and over again, you will eventually reach
that limit and bad things things will happen. You can test for this fairly
easily. When you open a file for select() to monitor, compare the file
descriptor to FD_SETSIZE:

Code: [Select]

if(file_descriptor >= FD_SETSIZE)
{
     print error message
     exit program
}

[Stefann]

Hi,
I appreciate a lot that you are reading my reports, I can sure use any help I'm getting.

Yes,...
I'm opening the file descriptor at the start of my program and than never close it:

Code: [Select]

fd = open("/dev/ttyUSB0", O_RDWR);
My home automation program (originally) simply keeps reading from it.
Before each read it did checks whether there was data with a select command.
The fd remains the same, that never changes, so as far as I know nothing increments and reaches a limit

Code: [Select]

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


So.. I think in principle THIS should work, and actually it does on TC15.

However...
You are very right that "if I would open other pipes without closing" I could get in trouble.
Yes.. it's not very safely programmed, it does not include the range check.

I never intentionally keep opening files without closing when I no longer need them.
What I meant is that I open "this specific file" and keep reading without ever closing.
In itself "that is not strange", I'm actively using it.
But if "it collects some garbage over time", it never gets a fresh start.

Anyway, last experiment was to "close & reopen" every 15mins. Its seems that that about doubled the time to crash but it still crashes.

Thanks for the input, I can include a logging on number of fd's when I do a next compilation.
"never intentionally" is different from "absolutely sure I did not"
For now I keep it running. Its 13 hrs down the road now... And it's almost bedtime here. Tomorrow morning I will know whether it at least passed the "15hr average crash milestone"

[Stefann]

try upgrade tc 16 ,maybe can shrink this problem

I thought about that but that would not help me.
Just to "not have crashes" I could simply stay on TC15. But.... Than I would miss out on upgrades.
Getting upgrades is the whole point of getting to TC to begin with. I started on DSL in 2008 but DSL quickly stopped doing upgrades.
2 years ago I really had to move to a newer OS. Without upgrades I had no https and missed lots of libraries on gcc, php, python.
So... getting OS updates is important.
A stepping stone on TC16 would not give other insights.
Only when its clear which component has the error it makes sense to figure out whether that component broke from 15 to 16 or from 16 to 17.

[Paul_123]

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.