Didn't Windows 95 do this too?!?
-
@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...
-
RE: https://techhub.social/@rayckeith/116370449957346533
Didn't Windows 95 do this too?!?
For fuck's sake, Apple, get your shit together and stop reinventing 30 year old 32 bit Windows bugs!
@cstross I had heard that about windows, but never met somebody who actually observed it (multiple days uptime? how would that happen?)
-
@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.
@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...
-
@cstross While I can believe there is a bug somewhere in the mac network stack, it definitely doesn't always cause things to crash after 49 days all the time. The machine i'm typing this on has been up for 170 days (and is due for a software update, come to think of it).
@mattblaze @cstross I saw on threadiverse that hibernating the system resets the clock
-
-
@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 @cstross I saw on threadiverse that hibernating the system resets the clock
@benjistokman @cstross Ah. That would explain it not affecting laptops in practice.
-
RE: https://techhub.social/@rayckeith/116370449957346533
Didn't Windows 95 do this too?!?
For fuck's sake, Apple, get your shit together and stop reinventing 30 year old 32 bit Windows bugs!
@cstross The System 7 Macs we used back then were doing well if they got to 49 minutes.
-
RE: https://techhub.social/@rayckeith/116370449957346533
Didn't Windows 95 do this too?!?
For fuck's sake, Apple, get your shit together and stop reinventing 30 year old 32 bit Windows bugs!
@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 The System 7 Macs we used back then were doing well if they got to 49 minutes.
@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).
-
RE: https://techhub.social/@rayckeith/116370449957346533
Didn't Windows 95 do this too?!?
For fuck's sake, Apple, get your shit together and stop reinventing 30 year old 32 bit Windows bugs!
@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.
-
@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...
-
RE: https://techhub.social/@rayckeith/116370449957346533
Didn't Windows 95 do this too?!?
For fuck's sake, Apple, get your shit together and stop reinventing 30 year old 32 bit Windows bugs!
-
RE: https://techhub.social/@rayckeith/116370449957346533
Didn't Windows 95 do this too?!?
For fuck's sake, Apple, get your shit together and stop reinventing 30 year old 32 bit Windows bugs!
@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.
-
R relay@relay.mycrowd.ca shared this topic
-
@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.
-
RE: https://techhub.social/@rayckeith/116370449957346533
Didn't Windows 95 do this too?!?
For fuck's sake, Apple, get your shit together and stop reinventing 30 year old 32 bit Windows bugs!
@cstross There must be an accidental work around because I’ve never hit it!
-
@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.
@cstross First-gen white MacBook running Snow Leopard 10.6 (named "Tape Monitor 2" because ripping records and tapes is its primary purpose) needs a reboot every three months or so to sort out some weirdness with audio (a Griffin iMic and old version of Audacity are also involved)
-
@mattblaze @cstross I saw on threadiverse that hibernating the system resets the clock
@benjistokman @mattblaze @cstross Ah that’s probably why I have never seen it. My devices go to sleep but have wake on LAN.
-
@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.
@TimWardCam @cstross Many years ago I had a set top box which would crash regularly in the middle of the night so I used a time switch to restart it at like 04:00. Amusingly I’ve worked on a lot of STBs and Smart TVs since then and they nearly all have a middle of the night “maintenance slot” when they check for updates etc. Restarting bits of the stack is quite common!
-
@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.
