Didn't Windows 95 do this too?!?

[rootwyrm@weird.autos]

@cstross (though do note that Windows 95 had it's own 'timer' in the form of registry + memory management guaranteeing that the system WOULD crash due to resource exhaustion if you tried to avoid reboots. How long depended on how many resources you had available.)

[timwardcam@c.im]

@cstross I wrote one of those once.

We built some hardware, tested it using a daughter board with a PROM chip on it running some soak test software, and sent it to the customer. Who said:

"We accept that the contract says the board has to pass the soak test for 48 hours, and it does, but we are nonetheless curious to know, if you felt like telling us, why it crashes after 63 hours 22 minutes (or whatever it was)?"

It turned out to be a 32 bit counter overflow in the soak test software. Which we'd never run for more than 48 hours, because according to the contract we didn't have to.

Another one of those I came across was more subtle. There was a cross-language call, and there was a mismatch between the calling sequences expected on either side, such that four bytes more stack was allocated on each call than was freed. After several days this filled the maximum allowed stack size and crashed (always after the same number of days, hours, minutes). Not good in a system supposed to work 24/7 on a production line.

[schrotthaufen@mastodon.social]

@cstross As someone who has to fight users to reboot their laptops for kernel updates, I view this as a feature

[darkling@mstdn.social]

@cstross Linux shook most of those bugs out fairly rapidly by simply setting the initial value of the counter to 0xffffff00, and letting it overflow in less than 5 minutes after boot...

[jwz@mastodon.social]

@cstross My various Macs currently have uptimes of 108, 94, 91, 83 and 55 days, so... no.

Using their diagnostic on the machine I am typing this from: "Time until overflow: -1412h -52m -59s" and time_wait is 26.

[etchedpixels@mastodon.social]

@rootwyrm @cstross Linux was generally 497 days or so which of course people discovered.

Windows was 10x quicker at dying but less people noticed

For a long time Linux then made sure it didn't happen again much by starting the timer close to the wrap value so it would fall over promptly.

[cinebox@masto.hackers.town]

@darkling @cstross oooh that’s a good solution I like that

[uilebheist@polyglot.city]

@cstross I had heard that about windows, but never met somebody who actually observed it (multiple days uptime? how would that happen?)

[jwz@mastodon.social]

@cstross Also the company reporting this seems to be in the business of creating AI-chatbot-to-iMessage spam firehoses, so one has to assume that their whole operation is vibe-coded...

[benjistokman@mast.benstokman.me]

@mattblaze @cstross I saw on threadiverse that hibernating the system resets the clock

[darkling@mstdn.social]

@cinebox @cstross (Of course, I've got the number wrong... that'd be 2.5 seconds at 100 Hz, or ¼s at 1kHz. The method still worked, even if I can't get that detail right.)

[rootwyrm@weird.autos]

@etchedpixels @cstross nope and nope. I'd have to go dredging archives, but Linux has fucked up multiple, multiple times. Because there's multiple timers.
Also systemd has been the root of several incidents because it is the work of complete idiots.

[mattblaze@federate.social]

@benjistokman @cstross Ah. That would explain it not affecting laptops in practice.

[nske@ravenation.club]

@cstross The System 7 Macs we used back then were doing well if they got to 49 minutes.

[oclsc@mstdn.ca]

@cstross Such bugs are far older than that.

The place I studied as an undergrad had a PDP-10 for campus-wide time sharing. ca. 1979 official IT staff (not that they were called that) moved most of their effort to getting new VAXes going as replacements. As part of that, they cancelled the weekly downtime to run diagnostics on the PDP-10.

That revealed a long-standing bug in TOP-10: some internal counter (I forget what, can't have been simple uptime in clock ticks on a system with 36-bit words) overflowed after about a month of uptime, causing havoc.

I forget whether DEC supplied a fix, IT staff (or us students helping keep the -10 running) rolled our own, or we just scheduled monthly reboots.

[cstross@wandering.shop]

@nske I *never* managed to get a Windows 95/98/98SE/ME machine to stay up for more than 36 hours without crashing hard. There's a reason I migrated to Linux back in the kernel 1.2 era (then onto Mac OSX back when it was warmed-over NeXTStep rather than whatever bizarre horror show it has evolved into today, where I remain, trapped by apathy).

[hairyvisionary@fosstodon.org]

@cstross Huh. I have got a 2008 Mac Mini running Lion (10.7) on my desk. It is reporting an uptime of 493 days 16:27. It's on the network enough to share filesystems with an adjacent newer 2020 Mini running 15.7.5, as in I just connected to it and can see the files.

[alister@hachyderm.io]

@darkling @cstross Yep, though AIR (and with some old posts that back up the numbers) the lore was that Linux crashed after 497 days - for the same reason as Windows - but that the 497 days issue was found before any windows machine had successfully made it to 49.7...

[edavies@functional.cafe]

@cstross https://www.theregister.com/2020/04/02/boeing_787_power_cycle_51_days_stale_data

[chigaze@cosocial.ca]

@cstross This is definitely not every Mac. We have a number of Macs running as servers with way more uptime than that. Plus I'd definitely have noticed if our FileMaker server that I manage was dying every month and half. Also the media server in my basement has way more uptime than that.

Edit: Seeing reports it may be Tahoe only.