Find cause for crashes on my VIA EDEN 500MHz 1core 32bit cpu

[Stefann]

back from vacation and an update.
Summary:
- the good thing: no crash over 8 days
- the bad thing: I made a mistake with configurations... It's now unclear again.

In detail:
I reverted the Realtek 8139 driver patch ands did rebuilt bzImage (vmlinuz)
However... I did not realize that the driver is not part of bzImage but part of modules.gz
So... today I found out that bzImage (vmlinuz) was never updated, I effectively tested with the one I built on august-22 as described this post: https://forum.tinycorelinux.net/index.php?topic=28078.msg183601#msg183601
Basically TC17.1 source from TC site:

Code: [Select]

-rw-r--r--    1 tc       staff    159566696 Aug 21 16:54 linux-6.18.35-patched.tar.xzCustom built vmlinuz with 1 modification: "include serial usb driver"

I need to recheck things a bit to be absolutely sure but it looks like I now have:

TC17.1 custom built vmlinuz:

Code: [Select]

-rw-r--r--    1 tc       staff      6128128 Aug 22 14:19 bzImage- crashing within 1 or 2 days when using usb-serial and/or select() statements (tested august-22)
- stable over 8+ days after NOT using usb-serial and after code simplification to not use select() and have write() catch all errors

TC17.1 downloaded vmlinuz:

Code: [Select]

-rw-rw-r--    1 tc       staff      6115840 Aug 23 14:21 vmlinuz171C- crashing within 2 hours after code simplification to not use select() but have write() catch all errors, even without using usb-serial

Damn... "why is this all so vague....."

Anyway... not sure how to proceed.
I think I will:
- keep current 6.1.35 built directory as that "apparently" has something good.
- redownload linux-6.18.35-patched.tar.xz and built vmlinuz without any modification
- test whether that new vmlinuz is stable as well

either its stable --> which make one wonder why the downloaded vmlinuz is not
or it isn't --> which urges  to search for differences with the stable built

To keep things simple I will test without usb-serial and without select() but only write() that now has proper error-handling.

There is actually still a possibility the issue is in the Realtek 8139 driver. It may be a rare race-condition that gets triggered by minute timing differences resulting form "quite unrelated built differences". On the one hand thats a bit unlikely, but on the other hand the whole thing is quite mysterious.

[Stefann]

4days since I last posted, time for an update. I'll keep it summarized:

- no crash with customer built kernel with intended network driver fix over 8 days, but the driver fix was not in the kernel (its part of modules) so no fix
- same kernel did crash in 18 hrs when I used "ignore pipe event" in application
- so: although crash frequency varies between minutes and weeks, it seems all configurations I have tested ultimately fail.

Conclusions I tend to get:
- the crash mechanism is extremely sensitive to minute config changes. It's very likely a race condition.
- As my 2nd system is also running TC17 without any crash over  past 8 month I generally I feel TC17 is absolutely fine also on my ancient VIA EDEN processors
- I expect some very specific HW configuration to be the rootcause
- And on that aspect the network driver is my highest suspect candidate: it's an old Realtek chip using old 8139too.c driver

I'm now using chatGPT to help me. On "logic of doing things" I often have a different opinion, but its actually a great help for reason that its knowledge about syntax is very superior to mine and it has access to all linux sources and can quickly find fix-history.

At this moment I'm running a self built kernel including an updated 8139too.c driver that now includes lots of pr_emerg() logging. I have also installed persistent ram that hopefully survives a crash. That part is not fully working yet though.

An other path I'm exploring is to install a watchdog such that at least my system reboots on crash. I found watchdog-6.18.35-tynicore.tcz that should do that.