Bios Rom Seems Corrupted Msi

[Vickiana Sconyers]

Im getting the exact same message from both the installed and the live OS. The 2014.11.01 ISO image I'm using is not corrupted, the MD5 checks out. I've copied the ISO to the USB stick via dd as per instruction on the wiki.

I googled around a bit, and it seams this can occur when the BIOS is using the first x number of bytes of the memory for something. The kernel checks if that is the case for the first 64KB. The size it will check can be set using the memory_corruption check_size kernel setting at boot. I tried setting it to 128K, but it didn't help, I still got the error.

In case someone else comes across that type of error:

The problem is a poorly designed BIOS that uses parts of RAM that it shouldn't. The kernel checks for those BIOSes and reports the "Corrupted low memory" message. The kernel then ignores that part of the memory and proceeds with system startup. The system will start and work just fine.

If you want to get rid of that annoying message, you can explicitly tell the kernel to ignore the first 64KB of memory (which is the part the BIOS might use) with the memmap boot option. Then the kernel no longer needs to check for memory corruption since it won't use that part of the memory anymore. You do that with the memory_corruption_check option. For details see mich41's post.

Low memory was that memory below 1M. It was an old specification still being used for backwards compatibility from the DOS days. Ol' Gates said we'd never need more than 640k. The kernel usually frees the memory when it gets done loading the kernel, but for the most part, it uses everything above the 1M boundary.

It looks like if you use x86_reserve_low 640 it might clear things up for a corrupted area instead of using mmap. I flashed an AWARD BIOS one time to put gpxe on it. I had to take something else out or reduce the size of the gpxe payload because it would corrupt it to the point that gpxe wouldn't work. Turns out it had a BIOS function for something that wasn't present on the board and thus able to keep memory in check.

The point is, the BIOS is not supposed to be using that memory without letting other things know. A popular OS from the US Pacific Northwest does not use that memory, so lazy BIOS developers use that space without bothering to do it the right way. Other operating systems, like Linux, might try to use that space and the invisible hand of the BIOS reaches out and corrupts what is in that space. The linux developers are aware of these quirks and have to work around them, This message means that they caught the brain dead BIOS changing that memory red-handed, As there is nothing they can do about it, they set a flag that tells them to ignore that corruptible memory, and it posts a message to the owner of the machine in the hopes they will write a strongly worded letter to the chuckleheads that market buggy hardware.

Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday

Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing

---

How to Ask Questions the Smart Way

The BIOS is poorly designed and uses memory resources it isn't supposed to touch in the first place. The kernel sees this and reports it with the aforementioned message, then completely ignores the first 64K bytes of memory.

Now, if I tell the kernel not to check for bios memory corruption (memory_corruption_check=0), won't that make the kernel use that potentially corrupted memory? Is the default behavior for low memory "It's probably used by the BIOS, ignore it" or will the kernel use it if it doesn't check first?

For the little time that I've researched about the error, the first message [Firmware Bug]: the BIOS has corrupted hw-PMU seems to be related to HP hardware (I have a printer connected to my computer). The problem is that my CentOS 7 is not booting anymore. I guess that the problem might be because of the following message: Corruption of in-memory data detected. Shutting down filesystem. I'm also asking this question on the same desktop computer using Windows on a dual boot.

When I try to boot into CentOS, it displays me the same lines shown in the image (the ones starting with [ 2.0XXXXX] XFS (dm-1) ... and then it enters in emergency mode. It then tells me that there's a log file at /run/initramfs/rdsosreport.txt. I wanted to copy that file to a USB drive so that I could share the error log, but apparently I can't mount it.

Using dmesg I can see that my pendrive is detected, but no name is associated to it in the dev directory. I've tried formatting my pendrive to ext2 but I still have the same problem. Is there anything I'm missing here?

It turned out that I had my root filesystem currupted by the crash, as stated in the comments. I followed shodanshok's suggestion and booted a live CentOS image on my USB stick, then I went to Troubleshooting and selected the option to rescue an existing installation of CentOS.

Funnily enough, the live image stated that no Linux installation were found on my hard drive, so I didn't know what to do again. I returned to Google to search for a solution and found this blog post. The guy there apparently had the same problem, and he solved it using this command: xfs_repair -L /dev/mapper/centos-root.

I returned to my live USB boot and selected the rescue option. The live system couldn't find my Linux installation as before. That time I entered the shell and ran fdisk -l to see if I could manually find and mount my system partition. fdisk showed me the existence of a 50Gb sized /dev/mapper/cl-root. I wasn't able to mount it. I then ran the command xfs_repair -L /dev/mapper/cl-root to see what would happen. When the process ended, I rebooted my computer and CentOS is now starting without errors.

Something caused a memory corruption, which was propagated to the root filesystem (to its journal, to be precise). So XFS shutdown itself down. To correct the issue, boot from a live CentOS disk and execute xfs_repair.

Someone told me the problem is that some DOS programs use bitmaps stored in the video BIOS to render fonts and those on most newer cards are not there of not correct. It doesn't matter if the program is run from a DOS bootdisk or in a DOS window in Win 9x/2000/XP.

What the people were talking about: Newer VGA cards often remove the 8x14 font from the ROM to make more space for advanced features. If a program requests the 8x14 font, it will get the 8x16 font instead. All characters of that font will be garbled, mostly containing vertically shifted version of other characters. Your symptom looks clearly different, though: Some characters look fine, and other characters of the same size are completely broken. So it seems like there is a partial font in the ROM, maybe they left some characters in the ROM to get some specific program to work. The font used by that application might indeed be the 8x14 BIOS font.

Edit: I have a wild guess were the problem might come from - the BIOS splash screen / boot screen.

Some later PC BIOSes used custom text glyphs to draw GUI elements in text-mode (like a Windows-like mouse cursor or a hour glass on DOS) or for displaying a logo.

Like that Energy Star logo. It usually is assembled out of a dozen of individual text characters that are being custom/modified.

And maybe the standard VGA font wasn't being properly restored after the POST screen was shown for whatever reason.

Anyway, it's just a wild guess. The chance is low that this is really the case. It's just a possibility that crossed my mind. ?

This program uses graphics mode, and seemigly only some of its own fonts, expecting others to be readable out from video BIOS in designated locations (which most BIOSes try to follow from what I see), where stuff seems not to be found on this particular card. There isn't any TSR that can fix this problem when the program goes directly hunting for the character data, only way is patching the video BIOS shadow but then where will all the code that lives in place of the character data go... ?

The problem with programs hunting for font data at fixed hardcoded addresses ist mostly limited to CGA/MDA applications, trying to find the 8x8 font in the main board BIOS (which only contains basic ASCII, i.e. character codes 0-127).

EGA/VGA introduced an API to retrieve the address of all ROM fonts which is generally used by applications. The TSR program will hook that API and return the 8x14 font from that TSR instead of a crippled or missing 8x14 font in the BIOS. This kind of TSR is known to actually fix most problems with BIOSes lacking an 8x14 font. As EGA introduced an API for retrieving the font addresses, and because applications generally use this API, there is no generally accepted fixed location of these fonts in the video BIOS, so using fixed addresses will fail on a lot of hardware.

In this case, we see some characters (letters) of the font being drawn correctly, whereas other characters of the same font (digits) are random garbage. If the program was expecting the font (8x14 or 8x16) at a address that's not valid on the video BIOS of that system, all characters would display incorrectly. So I am confident that the "bad fixed address" theory does not apply in this case.

Ok, this is good to know. I have been slowly gathering some info about related matters since in my todo list there's to make an actual all new video card and a lot of stuff seems to have to stay in specific locations or compatibility gets harmed and this was the first thought I had. Do you happen to have or point to some more info etc.

3a8082e126