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.