Conversation

You can’t even adjust c-states? Maybe you can find a better BIOS as it likely will be problematic regardless of this issue later. I buy PCs based around being able to run good BIOS/open source BIOS personally.

Embed this notice

Terry Hendrix II 🏹 (thendrix@social.hendrixgames.com)'s status on Thursday, 15-Feb-2024 04:22:58 JST

Terry Hendrix II 🏹

in reply to

iceloops 🚬 :love_forever_cat:

Well, it’s not unheard of for people to buy up stuff like this and modify it for use in production to shave some pennies. If you know the board/BIOS you can start by trying to at least upgrade it. Cheap shit normally has outdated BIOS causing more returns from normies.

Embed this notice

Sexy Moon (moon@shitposter.club)'s status on Thursday, 15-Feb-2024 04:22:58 JST

Sexy Moon

in reply to

@thendrix @1iceloops123 do you know any good mini pcs that run coreboot?

Embed this notice

:marseyloadingneon: m0xEE :marseyloading: (m0xee@breloma.m0xee.net)'s status on Thursday, 15-Feb-2024 04:24:46 JST

:marseyloadingneon: m0xEE :marseyloading:

in reply to

@Moon
I used to see this a lot on resuming from suspended state on one of my computers — I don't remember which one, for me it wasn't critical and didn't cause any other issues, only this log line :marseyshrug:

Sexy Moon likes this.

Embed this notice

Sexy Moon (moon@shitposter.club)'s status on Thursday, 15-Feb-2024 04:25:18 JST

Sexy Moon

in reply to

@thendrix @1iceloops123 way too expensive, looking for things for similar to raspberry pi tier stuff but x86 because dealing with Arm is a pain in the ass.

Embed this notice

Terry Hendrix II 🏹 (thendrix@social.hendrixgames.com)'s status on Thursday, 15-Feb-2024 04:25:19 JST

Terry Hendrix II 🏹

in reply to

iceloops 🚬 :love_forever_cat:

I buy stuff from places like system76 just to have them deal with this stuff at this point in my life. :3

Embed this notice

Cheetah Meld (pingviini@pleroma.shunderdo.me)'s status on Thursday, 15-Feb-2024 04:27:18 JST

Cheetah Meld

in reply to

@Moon That right there is quality code and error message prose from none other than Linus himself. First appeared in Linux 0.99, released in December 1992 (kernel/traps.c, these days lives in ./arch/x86/kernel/nmi.c).

Sexy Moon and Haelwenn /элвэн/ :triskell: like this.

Embed this notice

feld (feld@bikeshed.party)'s status on Thursday, 15-Feb-2024 04:39:57 JST

feld

in reply to

:blank:

@i @Moon sounds like a good opportunity for a bunch of young Indian compsi students to practice their pull requests on

Sexy Moon likes this.

Embed this notice

:blank: (i@declin.eu)'s status on Thursday, 15-Feb-2024 04:39:58 JST

:blank:

in reply to

feld

@feld @Moon no one's had the heart to change the message for memory parity checks failing for more than 20 years

Embed this notice

Sexy Moon (moon@shitposter.club)'s status on Thursday, 15-Feb-2024 04:47:50 JST

Sexy Moon

in reply to

feld
:blank:

@feld @i

dbus_connection_send(dbconn, bobs, NULL);

feld likes this.

Embed this notice

Cheetah Meld (pingviini@pleroma.shunderdo.me)'s status on Thursday, 15-Feb-2024 05:19:44 JST

Cheetah Meld

in reply to

Cheetah Meld

@Moon The functions for printing kernel messages to the console in Linux evolved significantly over time and the x86 NMI code also became slightly more complex.

It did not always retrieve a reason for the non-maskable interrupt - in fact Linux probably predates the registers in Intel chipsets to pull a reason for an NMI from (not too sure about this though) - Linux also definitely predates SMP for x86, so there was no code to print the exact CPU the NMI originated from.

The code that prints this message had to be rewritten several times, at one point splitting the original single line message into two separate lines.

None of these opportunities to change the wording of this message was ever taken - on the contrary, even the "Uhhuh" part has always been carefully preserved.

x86 is also the only architecture where a Linux user is likely to ever see the kernel use a literal filler word in a kernel message, other platforms that use non-maskable interrupts usually stuck to wording gleaned straight from reference documentation.

"Dazed and confused" however is a multi-platform phrase, thanks to a fan of Linus' error-message-prose adopting it and putting it into eCryptfs's kernel code.

Sexy Moon likes this.

Embed this notice

LEdoian (ledoian@pleroma.ledoian.cz)'s status on Thursday, 15-Feb-2024 05:23:47 JST

LEdoian

in reply to

@Moon This actually happens to me quite often (EeePC T101MT). For me it seems to be related to hibernation and feels quite harmless, so looking into that is very low priority.

The only annoying thing is that this message gets to all my open terminal windows.

Sexy Moon likes this.

Embed this notice

Pete Zaitcev (zaitcev@shitposter.club)'s status on Thursday, 15-Feb-2024 07:07:56 JST

Pete Zaitcev

in reply to

@Moon It is a legendary message, I remember how it first appeared. Typically it means that the kernel fails to talk to firmware. Or at least it used to mean that. IIRC it originally was associated with MCEs that Linux didn't know how to handle. It can also be triggered by a failure of communication between SMP CPUs or cores. Although, I didn't see this is in many years. Linux supported MCE and other such stuff for a long time.

Sexy Moon likes this.

Public

Notices

Feeds