Make sure to update your grub after you do. I’ve messed that one up before lol 😅
A Basil Plant
InfoSec Person | Alt-Account#2
- 1 Post
- 18 Comments
Joined 1 year ago
Cake day: September 28th, 2023
You are not logged in. If you use a Fediverse account that is able to follow users, you can follow this user.
Do you not need the
nvidia-drm.modeset=1inGRUB_CMDLINE_LINUX?https://www.if-not-true-then-false.com/2015/fedora-nvidia-guide/#262-edit-etcdefaultgrub
Could you show us the kernel command line parameters (in /etc/default/grub)? Is the modeset along with other params enabled? I’m not a fedora user, so I may not be of too much help.
https://www.linuxjournal.com/article/10754
MINIX originally was developed in 1987 by Andrew S. Tanenbaum as a teaching tool for his textbook Operating Systems Design and Implementation. Today, it is a text-oriented operating system with a kernel of less than 6,000 lines of code. MINIX’s largest claim to fame is as an example of a microkernel, in which each device driver runs as an isolated user-mode process—a structure that not only increases security but also reliability, because it means a bug in a driver cannot bring down the entire system.
In its heyday during the early 1990s, MINIX was popular among hobbyists and developers because of its inexpensive proprietary license. However, by the time it was licensed under a BSD-style license in 2000, MINIX had been overshadowed by other free-licensed operating systems.
Today, MINIX is best known as a footnote in GNU/Linux history. It inspired Linus Torvalds to develop Linux, and some of his early work was written on MINIX. Probably too, Torvalds’ early decision to support the MINIX filesystem is responsible for the Linux kernel’s support of almost every filesystem imaginable.
Later, Torvalds and Tanenbaum had a frank e-mail debate about the relative merits of macrokernels (sic) and microkernels. This early history resurfaced in 2004 when Kenneth Brown of the Alexis de Tocqueville Institution prepared a book alleging that Torvalds borrowed code from MINIX—a charge that Tanenbaum, among others, so comprehensively debunked, and the book was never actually published (see Resources).
See also: https://en.wikipedia.org/wiki/Tanenbaum–Torvalds_debate
5·5 months agoI’m glad you appreciate it! It’s always fun digging into kernel internals and learning new things :D
I’m also open to criticism about the writing if you have any.
No. Fuck this shit. Don’t do this.
It’s already bad when everyone in this community shoves their distro down potential linux-converts’ throats, thereby confusing them even more. Don’t tell (or imply to) freshly converted users that they potentially made a wrong choice.
TF do you think they’re going to do now? Move to fedora? The commenter above already stated that it was a hassle to install Ubuntu and now you’re telling them to change distros already???
Ubuntu is still great… compared to Windows. Sure. It may not hold to your ideals. Compared to other distros, canonical may make some questionable choices. BUT THEY DON’T IMPLEMENT A FUCKING RECALL. So it’s fine (for now).
Ubuntu is fine for newcomers. It has a shit ton of support online and you can easily search questions whose answers are likely to be found within the first few results.
So stop shoving distros down people’s throats, especially fresh users.
I know you said:
Sorry if I sound too hard… take it with a laugh 😁
It doesn’t come across that way. You come off as a gatekeeper.
Thank you, I’ll send you an email within a day.
Would you consider sending it to Austria? I’d pay shipping charges (if it’s within reason lol). If you are, you can send me an email at:
sneela-hwelemmy92fd [at] port87.com
Are you planning to scrap the CPU? I may be interested in it as I find faulty hardware fun to experiment on.
You haven’t given us much information about the CPU. That is very important when dealing with Machine Check Errors (MCEs).
I’ve done a bit of work with MCEs and AMD CPUs, so I’ll help with understanding what may be going wrong and what you probably can do.
I’ve done a bit of searching from the microcode & the Dell Wyse thin client that you mentioned. From what I can garner, are you using a Dell Wyse 5060 Thin Client with an AMD steppe Eagle GX-424 [1]? This is my assumption for the rest of this comment.
Machine Check Errors (MCEs) are hard to decipher find out without the right documentation. As far as I can tell from AMD’s Data Sheet for the G-Series [2], this CPU belongs to family 16H.
You have two MCEs in your image:
- CPU Core 0, Bank 4: f600000000070f0f
- CPU Core 1, Bank 1: b400000001020103
Now, you can attempt to decipher these with a tool I used some time ago, MCE-Ryzen-Decoder [4]; you may note that the name says Ryzen - this tool only decodes MCEs of Ryzen architectures. However, MCE designs may not change much between families, but I wouldn’t bank (pun not intended) on it because it seems that the G-Series are an embedded SOC compared to the Ryzen CPUs which are not. I gave it a shot and the tool spit out that you may have an issue in:
$ python3 run.py 04 f600000000070f0f Bank: Read-As-Zero (RAZ) Error: ( 0x7) $ python3 run.py 01 b400000001020103 Bank: Instruction Fetch Unit (IF) Error: IC Full Tag Parity Error (TagParity 0x2)Wouldn’t bank (pun intended this time) on it though.
What you can do is to go through the AMD Family 16H’s BIOS and Kernel Developer Guide [3] (Section 2.16.1.5 Error Code). From Section 2.16.1.1 Machine Check Registers, it looks like Bank 01 corresponds to the IC (Instruction Cache) and Bank 04 corresponds to the NB (Northbridge). This means that the CPU found issues in the NB in core 0 and the IC in core 1. You can go even further and check what those exact codes decipher to, but I wouldn’t put in that much effort - there’s not much you can do with that info (maybe the NB, but… too much effort). There are some MSRs that you can read out that correspond to errors of these banks (from Table 86: Registers Commonly Used for Diagnosis), but like I said, there’s not much you can do with this info anyway.
Okay, now that the boring part is over (it was fun for me), what can you do? It looks like the CPU is a quad core CPU. I take it to mean that it’s 4 cores * 2 SMT threads. If you have access to the linux command line parameters [5], say via GRUB for example, I would try to isolate the two faulty cores we see here: core 0 and core 1. Add
isolcpus=0,1to see the kernel boots. There’s a good chance that we see only two CPU cores failing, but others may also be faulty but the errors weren’t spit out. It’s worth a shot, but it may not work.Alternatively, you can tell the kernel to disable MCE checks entirely and continue executing; this can be done with the
mce=offcommand line parameter [6] . Beware that this means that you’re now willingly running code on a CPU with two cores that have been shown to be faulty (so far).isolcpuswill make sure that the kernel doesn’t execute any “user” code on those cores unless asked to (viatasksetfor example)Apart from this, like others have pointed out, the red dots on the screen aren’t a great sign. Maybe you can individually replace defective parts, or maybe you have to buy a new machine entirely. What I told you with this comment is to check whether your CPU still works with 2 SMT threads faulty.
Good luck and I hope you fix your server 🤞.
Edited to add: I have seen MCEs appear due to extremely low/high/fluctuating voltages. As others pointed out, your PSU or other components related to power could be busted.
[4] https://github.com/DimitriFourny/MCE-Ryzen-Decoder
[5] https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html
[6] https://elixir.bootlin.com/linux/v6.9.2/source/Documentation/arch/x86/x86_64/boot-options.rst
The debug version you compile doesn’t affect the code; it just stores more information about symbols. The whole shtick about the debugger replacing instructions with INT3 still happens.
You can validate that the code isn’t affected yourself by running objdump on two binaries, one compiled with debug symbols and one without. Otherwise if you’re lazy (like me 😄):
https://stackoverflow.com/a/8676610
And for completeness: https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Debugging-Options.html
Excellent question!
Before replacing the instruction with INT 3, the debugger keeps a note of what instruction was at that point in the code. When the CPU encounters INT 3, it hands control to the debugger.
When the debugging operations are done, the debugger replaces the INT 3 with the original instruction and makes the instruction pointer go back one step, thereby ensuring that the original instruction is executed.
https://en.wikipedia.org/wiki/INT_(x86_instruction) (scroll down to INT3)
https://stackoverflow.com/a/61946177
The TL;DR is that it’s used by debuggers to set a breakpoint in code.
For example, if you’re familiar with gdb, one of the simplest ways to make code stop executing at a particular point in the code is to add a breakpoint there.
Gdb replaces the instruction at the breakpoint with 0xCC, which happens to be the opcode for INT 3 — generate interrupt 3. When the CPU encounters the instruction, it generates interrupt 3, following which the kernel’s interrupt handler sends a signal (SIGTRAP) to the debugger. Thus, the debugger will know it’s meant to start a debugging loop there.
https://www.gimp.org/news/2024/05/05/gimp-2-10-38-released/
This (possibly last) GIMP 2 stable release brings much-requested backports from GTK3, including improved support for tablets on Windows. A number of bug fixes and minor improvements are also included in this release.
If the release says that this is possibly the last GIMP2 stable release, it feels like GIMP3 is actually on its way. I understand your cynicism, but I’d be more optimistic this time around.
In dark mode, the anchor tags are difficult to read. They’re dark blue on a dark background. Perhaps consider something with a much higher contrast?
Apart from that, nice idea - I’m going to deploy the zipbomb today!
Surprised no one’s mentioned HTTP Cats yet:
Personally, HTTP 405 (Method not allowed) is my favorite:
Hurd-ng is on its way: https://www.gnu.org/software/hurd/hurd/ng.html
Ah if you messed it up, you can press “e” on the grub entry and edit the command line parameters to remove the thing that messes it up. Good luck with your fresh install [and use Debian this time… jk :)]