Linux Kernel Would Randomly Explode In The Past

Hinzugefügt: 2026-05-06

[00:00:00]Nowadays, when you buy a computer, you can be reasonably sure it's going to behave the way you expect it to behave.

[00:00:06]If you have an x8664 CPU, it's going to behave like an x8664 CPU and nothing weird's going to happen. Yes, there are sometimes weird manufacturing defects and things like that, but long gone are the days of regular consumers buying clones of more expensive chips. For example, you may have heard of the Linux kernel dropping support for i486 CPU support. This is the Intel 486. Now, back in the days of chips like this, the Intel version often times was really, really expensive. So what ended up happening is there was a bunch of companies that came along, some of them having fab, some of them not, who went and sold clones of these chips at considerably cheaper prices.

[00:00:58]But to make a clone, and to make it cheaper, that meant you had to cut costs somewhere along the line. Sometimes that meant intentional missing functionality, sometimes it meant poor QC. And this resulted in possibly bugs in many cases unexpected bugs. As such, there was this well-known law around software and notably around the Linux kernel that sometimes when you're compiling software, even though the software is totally fine, it just doesn't compile. Signal 11 while compiling the kernel. Signal 11 or officially known as a segmentation fault means the program accessed a memory location that was not assigned. That's usually a bug in the program. So if you're writing your own program, that's most likely the cause. However, this FAQ will concentrate on the possibilities besides that because when we're talking about something like the Linux kernel or various other big projects, you would never expect Torva to just release a broken build. Like, if it's not compiling and it's compiling for everybody else, that's probably not an issue with the software, that's probably an issue with your system. This can absolutely still be a problem today, but is exceedingly rare compared to the way things used to be compared to when people were running these weird kind of half implemented clones of more expensive CPUs. But if you know you're in the market for a 30-year-old CPU, this is something you still have to consider. Even though a lot of this isn't super relevant today and a lot of the examples in here are set like 20 plus years ago, I still thought it'd be fun to go back and look at some ancient Linux law, something that people really understood at one point in time. And as things have improved, as things have changed, people have pretty much just forgotten about it. Okay, it may not be the software. How do I know for sure?

[00:03:08]First, let's make sure it is the hardware that is causing your trouble.

[00:03:12]When the make stops, simply type make again. If it compiles a few more files before stopping, it must be the hardware that's causing you troubles. If it immediately stops again, i.e. scans a few directories with nothing to be done before bombing at the exact same place.

[00:03:26]Try this DD command. Now, DD commands are very important to make sure you run correctly. Otherwise, you can do things very bad to your drive and you don't want that. Change the hard disk obviously to the disc you're using and then megs to the amount of system memory you have. This will cause the first few megabytes of your hard drive to be read from disk, forcing the C source files in the GCC binary to be reread from disk the next time you run it. Now type make again if it still stops in the same place. I'm starting to wonder if you're reading the right FAQ as it is starting to look like a software problem after all. If without this DD command, the compiler keeps stopping in the same place but moves to another place after you use the DD, you definitely have a discto RAM transfer problem, what does it really mean? Are you sure it's a hardware problem? Nobody wants to acknowledge it's a hardware problem even back then. Because even when hardware was cheaper, you don't want to spend money if you don't have to. Granted, depending on the time frame when specific parts of this were written, it is possible that the hardware actually was more expensive. During that like early 2000's period, there was definitely a dip in hardware cost. We've kind of just returned to where we were in like the 80s and '9s where consumer PCs are really just not affordable for most people. Well, the compiler access memory outside its memory range. If this happens on working hardware, it's a programming error inside the compiler.

[00:04:51]That's why it says internal compiler error. However, when the hardware occasionally flips a bit, GCC uses so many pointers that it is likely end up accessing something outside of its addressing range. It seems that nowadays everybody with signal 11 problems gets directed to this page. Nowadays, uh, as I'm recording this, nobody even knows this page exists anymore, except I've seen my, uh, my demographics. I'm sure that some of you here have been sent to this page and are very aware of it and have read through it many, many times before. If you're developing your own software or have software that hasn't been debugged quite enough, a seg fault, very possible hint that you've done something wrong. Only when a program like GCC that works for almost everybody has a crash on a data set like the Linux kernel that has also been well tested, then it becomes a hint that there is something wrong with your hardware. If some software component like a hardware driver in your system is broken, it could cause symptoms that are very close to a hardware failure. However, when a driver is faulty, it is more likely to cause serious trouble inside the kernel than just causing the compiler to crash.

[00:05:56]This would be a very niche sort of driver issue, and it's definitely possible, but exceedingly unlikely. If it is a hardware problem, what may the problem be? And now we get into a lot of examples of really old hardware with really old hardware problems. The memory speed might be too slow. Increase the number of weight states in the BIOS.

[00:06:24]This could be caused by Ammy Bios's autoconfig option. It may only know about 486s running up to 80 megahertz, whereas you currently buy the new 100 megahertz version. Ooh, wow. 100 megahertz. That's That's so many megahertz. The memory speed might be slow. Get faster DRAM. SIMs, not DIMs.

[00:06:47]Okay, you might think of DIM as just a generic term for a RAM module, but a SIM and a DIM are different types of RAM technology. For example, current ASUS motherboards require 69 seconds RAM if you have 100 or 130 oh wow 133 MHz processors. That's crazy. You might think you can run your 100 MHz SD RAMs at 100 MHz. Wrong. Links to a post here about SD RAM. Why I think this is the case. You need at least one speed grade faster than the speed they are rated for. There is a bad chip on one of the SIMs. This can happen on modern DRM DMs as well. Um, not common. DRAM's usually pretty resilient, but is an annoying problem when it happens. We handled a hard one here the last week. It turned out that all four 16 megabyte 16 16 megabyte Sims were broken in that they dropped around one bit once per hour. This was sufficient to crash the machine in about a day or crash a kernel compilation in about an hour. Compiling the kernel now doesn't even take anywhere close to an hour on any reasonably modern and reasonably fast chip. It seems that some 30 pin to 72pin converters can cause memory issues. See how old this entry is? Who remembers 30 pin SIMs? Who remembers SIMs? However, all these things hold perfectly for SIM to DIM converters. Again, another thing which you wouldn't even consider existing now. If the refresh of the DRM isn't functioning properly, the DM will slowly lose their information. Some 46 motherboards stop refreshing correctly when you turn on hidden refresh. There seems to be a program called DRM around that can also mess up your refresh to cause sig 11 issues. The number of weight states could be too low. Increase the number of waste weight states in the BIOS for a fix. All of that that was just about system memory. There's more than just that. Cache memory. The cache memory speed might be too low. Increase the number of weight states in the BIOS.

[00:08:55]The cache memory speed might be too slow. Get faster SRAM chips. there is a bad chip in your cache.

[00:09:02]The cache might be set to writeback while there is a bug in the rightback implementation to your chipset because sometimes you just had buggy chips. The motherboard may require a jumper to switch between cache on a stick and the oldfashioned dip chip cache. Now, disc transfers sometimes taking things from the drive into RAM, that can be problems. If you have this problem, you're most likely to have to do the DD command to move the problem from one place to the next. Some IDEA hard disks cannot handle IRQ unmasking option. This may only show under load and it could show as a SIG 11. Do you have a caloc 31?

[00:09:44]What? What? What is I actually didn't check this part. That is some really old drive.

[00:09:52]The first video is titled rare unreliable 105 megabyte stepper drive from 1992. So apparently these just consistently had a problem and you should not use them. Sometimes the CPU itself also just broken. Some have a higher percentage of them being bad.

[00:10:14]Some years ago the original Pentium 120s. A few years ago, the AMD K62300's 1998 produced in 34 weeks from 39 and recently AMD K62450s.

[00:10:27]Some people may say that 400 MGHertz is acceptable to them. However, this turns out to be a problem. You're entitled to a new processor. Go and exchange it where you bought it. I don't know what happened with this specific CPU, but um we've pretty much always had somewhere in history there's just been a bad line of chips. Either a bad design decision or just simply a bad batch of chips. And some batches just have a design bug. Get rid of it. Overclocking. Now, overclocking nowadays is much safer and much easier than it was back then.

[00:11:04]However, it was still a thing back then.

[00:11:07]The CirX P166 processors run at 133 MHz, not 166. This must be logical to the guys at Cirix, but nobody else. You're overclocking them if you run them at 166. Some vendors or private people think it is possible to overclock some CPUs. Some of them may work, others don't. You might want to try turning off tur You might want to try turning off turbo.

[00:11:32]Note that most Pentium motherboards no longer support a non-turbo mode and see if the problem goes away. Check the speed of your CPU compared printed on it. Carefully remove the fan if necessary with what the motherboard jumpers or BIOS settings say. CPU temperatures. A high-speed processor highspeed in the context of this period might overheat without the correct heat sink. Some things some things never change. Do you know what does change though?

[00:12:02]people overvolultting, but more commonly undervolting their CPUs. Again, something a lot more common today and something that could be done back then, but a lot of chips were a lot less stable if you undervolted them. RAM voltage. Sometimes the RAM expects to run at a specific voltage.

[00:12:25]Going above that can also cause problems. local bus overloading. At 25 MHz, you're allowed to have three Vasa local bus cards. At 33 MHz, only two. At 40 MHz, only one. And guess what? At 50, none. Now, question. What the hell is a Vasa local bus card? According to Wikipedia, like this is well before my time being involved in computing, created by Vasa, the Vasa local bus worked alongside the then dominant ISA bus. Another I know what that one is, but another thing which is well before my time to provide a standardized high-speed conduit intended to accelerate video graphics operations.

[00:13:05]Oh, so it was an alternative to Was PCI even a Yeah. Okay. This is before PCI.

[00:13:13]Okay.

[00:13:16]Right. That makes sense. Power management. Some laptops have power management features. Nowadays, it'll be all of them. These might interfere with Linux. Again, some things never change.

[00:13:28]You don't know how many cases I've seen a new CPU comes out and someone's like, "Oh, well, if you disable this power saving feature, uh, the CPU now just works properly." I believe this was a common thing with first gen Ryzen, maybe dust buildup. Some dust might conduct a bit and create a weak short. It might increase capacitances elsewhere and degrade timing characteristics. It might impede thermal flow and lead to overheating components. It might even short a jumper connection. If you're shorting jump, like if your dust is this metallic, take your PC out of the workshop. There shouldn't be that much metallic substance in your dust. I recommend that every year or so it is a good idea to open your computer and vacuum the inside. That is a very controversial recommendation today. the CPU itself.

[00:14:19]Some people are reporting they have found nothing to blame except the CPU.

[00:14:23]This could also have been incompatibility between the CPU and the motherboard. Also, again, some things never change. A wave of reports concerning Intel CPUs has passed February 1997. A new wave reports is coming blaming the Circ/ IBM 686 CPUs.

[00:14:38]The memory hole. Many modern motherboards allow you to use old ISA video Yeah.

[00:14:44]They use old ISA video cards with one or two megabytes of linear frame buffer. To achieve this, they have to map out the memory just below 16 megabytes. Nobody actually ever used this feature, but if you turn the memory hole on, your machine will certainly be flaky. And of course, microode. Since the Pentium Division disaster, Intel have the CPU field upgradeable. You can install upgraded microode, and you probably should do that. These upgrades usually come with your BIOS. Nowadays, you can install it just as a package and install your microode updates. Question: RAM timing problems. I fiddled with the BIOS settings more than a month ago. I've compiled numerous kernels since then.

[00:15:26]Surely it can't be the RAM timing then.

[00:15:28]Wrong. Do you think that RAM manufacturers have a machine that makes 60 ncond RAM and another one that makes 70 ncond RAM? Of course not. They make a bunch and then test them. Some meet the specs for 69 seconds, others don't.

[00:15:41]Those might be 61 if the manufacturer would have put a number to it. In that case, it's quite likely that it worked in your computer when, for example, the temperatures are below 40° centigrade.

[00:15:51]Chips become slower when the temperatures rise. This is why some supercomputers need so much cooling.

[00:15:57]However, the coming of summer or a long compile job may push the temperatures inside your computer over that limit. I got suckered into not buying ECC memory because it was slightly cheaper. I feel like a fool. I should have bought more expensive ECC memory, right? ECC memory does deal with some problems.

[00:16:18]But if you have broken hardware, if the hardware is not behaving like it should, no amount of ECC is going to save you. Memory problems. My BIOS tests my memory and tells me it's okay. I have this fancy DOSS program that tells me my memory is okay. Surely can't be the memory, right? Wrong. The memory test in the BIOS is utterly useless. It may even occasionally okay more memory than is actually available, let alone test whether it is good or not. However, with that being the case, if you happen to know somebody who uh who trusts the memory test in the BIOS, hey, you have somebody you can sell the memory to. And of course, it's not necessarily just going to happen with the kernel. It can happen with other things, whether you're compiling software or just general other things you might be doing. Nothing crashes on NT, Windows 95, OS2, or DOSs. It must be something Linux specific.

[00:17:20]If it is, which it's probably not, um, you can just sell it to a Windows user.

[00:17:26]First of all, Linux stress your hardware more than all of the above. Some OS like the Microsoft name ones above crash in unfricted ways anyway. Nobody's going to call Microsoft and say, "Hey, my Windows box crashed today." If you do anyway, they will tell you the user made an error. Unless, you know, you're a big company. you probably don't even have a good way to contact Microsoft. And now if you try to contact them, it's like, uh, here's this AI chat that's going to direct you to some documentation that's probably not very useful. Whilst this entire post was about Signal 11 segmentation fault, that's not the only thing can go wrong. There is a bunch of other errors that can also be happening.

[00:18:06]Some of them for similar reasons, others because broken hardware just does weird broken things. And that's not the end of it. A bunch of other random things can be happening as well.

[00:18:19]There's a lot of other weird just specific possibilities that if you want to read for yourself, I'll probably leave linked down below. So, this is one of those things where nowadays you probably don't really need to think about it that much. Maybe there's some problem that happens, but for the most part, things behave in a more sensible way. But this is something that a lot of people using Linux at the time understood was a problem and knew about this page and contributed to this page.

[00:18:50]So, I hope you learned something about the history of Linux and what things were like when computers were far less stable. So, if you were around at the time, um, let me know your experience from back then. If not, let me know your thoughts down below. If you like the video, like the video. Subscribe as well. And if you really like the video and you want to become one of these amazing people over here, check out the Patreon scribes deli barrap linked in the description down below. That's going to be it for me and watch this video seg.

[00:19:30]If it don't involve money then I don't accept something like this.