Re: Tiny Core v17.0 upgrade issues

[Stefann]

Boring update...
it still runs..

Code: [Select]

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

[Stefann]

Bingo! crashed!
After 45 hours
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.

I just restart without too much intelligence for reason I need the automizations that my application is running.
I will think of proper followup later, no time now.
I will anyways start it in text mode. "maybe console shows more clues when crashing in text mode"

But.... this is first time I was able to get TC17 crashing with a very simple isolated "crash testcase program" (as published few posts back).
==> I would say... "this is definitely a kext usb-serial-6.18.2-tinycore.tcz TC17 issue"

Any advice is welcome

Code: [Select]

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

[Rich]

Hi Stefann

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

[Stefann]

Hi Stefann

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

Ah.. no..
And I rebooted already.
I did not really have time to explore a lot.

Anyway..
It’s now running in textmode. Maybe it will crash as well.
At least “getting it to crash” is kind of predictable.
Both my application and this isolated crash program crashed after about 45 hrs.
I keep it running for 48 hrs again. If it does not crash I try again with gui and take your inputs.

Progress is slow but steady.

At some point I will also test TC16 to see whether it did break with TC16 or TC17

[Stefann]

boring update... its still running..

Code: [Select]

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 loops
Its now running significantly longer than previous run that crashed after about 414k loops.

Configuration changes are:
- I removed the "interrupt stress inducing lines" from the code because that did not seem to add much. It crashed after 45hours while "with the read() as part of my application" without additional stress it also crashed after 45hrs
- I now booted into text mode instead of GUI

So...
- either its natural variation
- or the lower stress increases the "time to crash" (maybe to indefinite)

I leave it running for an other day. If it did not crash by than I bring it back to previous configuration and try to crash it and look into console using the CTR-ALT-F1 & F2 keys.
Note,... It would have been much handier to keep the system in crashed state and await suggestions on this forum BUT the system is actively running my home automation. The home automation crashes it goes into all kind of "safe fallback modes" but I donot want to have it stalled for to long time. Also depends on my agenda. If I'm home I can afford it to be down better than when I'm not home.