Announcement

Collapse
No announcement yet.

It Turns Out Windows Unconditionally Reserves The First 1MB Of RAM, Linux Was Just Late To Do So

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • neozeed
    replied
    Originally posted by AnAccount View Post

    The correct way would be for both Windows and Linux to refuse to boot if the BIOS corrupts the memory. That would lead to an actual fix of the root cause....
    yes always hold the user ransom for things outside of their control

    Leave a comment:


  • indepe
    replied
    I suppose it would possible to run a check after one hour of operation and test that 1 MB of memory, to identify those systems messing with memory that they shouldn't mess with (even if there may be false negatives after a single test of 1 hour).

    Leave a comment:


  • jabl
    replied
    Originally posted by Firnefex View Post
    Is it just BIOS or UEFI too?
    If the former, why not make this fix conditional?
    I would assume the people doing this know what they're doing. That being said, it's a good point: One of the big differences between classical BIOS and UEFI is that BIOS runs in real mode, which is limited to a 1 MB address space, whereas UEFI runs in protected or even long mode, so UEFI can potentially scribble over a much larger memory area. So there is a sort of logic why the 1st MB should be reserved on a BIOS system, but for UEFI there's no such logical limit at 1 MB.


    Leave a comment:


  • perpetually high
    replied
    Originally posted by AnAccount View Post

    The correct way would be for both Windows and Linux to refuse to boot if the BIOS corrupts the memory. That would lead to an actual fix of the root cause....
    Maybe the correct way, but not the best user experience. Windows I believe made the correct workaround, and Linux has now followed suit now that the issue has become apparent. It's not always best to go with the "correct" or "right" in my opinion, there's always some nuances, and I think this situation is one of them, especially when there's no standardization.

    Leave a comment:


  • onlyLinuxLuvUBack
    replied
    Originally posted by skeevy420 View Post

    I've had good results with my Gigabyte B550M DS3H. There's also an AC model with built-in wifi. I opted for the wifi free edition because I have ethernet running to my PC. Only had it for around 5 months but I've been happy with it so far.

    The problem you'll find if you ask that question enough is that everyone will report that every brand sucks so the best you can do is ask about what luck people are having with their current hardware.

    About my only complaint is on a cold boot it can be a PITA to access the UEFI....my keyboard takes for fucking ever to initialize so I have to spam whatever I'm trying to do because, on cold boot, there's a split second where both the keyboard is initialized and the initial boot screen will take input. That's not my motherboard's fault but it's an annoyance none-the-less.

    If you have an RGB keyboard that does bullshit when it initializes....well.....that might be an issue with any motherboard that initializes quickly and not just mine. I need a Goldilocks motherboard. Doesn't initialize too fast; doesn't initialize too slow; initializes just right. Or a better keyboard....
    you could build a teensy usb keyboard emulator to send the key sequence on a timer after you signal the teensy?

    Leave a comment:


  • Firnefex
    replied
    Is it just BIOS or UEFI too?
    If the former, why not make this fix conditional?


    Originally posted by sophisticles View Post
    How would you guys go about fixing a system where the BIOS corrupts the ram if both Windows and Linux refused to boot?

    And of course Windows does it better, there's a reason why MS is worth billions of dollars and one of the world's most valuable companies and there are maybe 4 Linux based companies that actually make a profit.
    If it is known that the bug corrupts different platforms then of course a generic fix should be spread to all of them!

    MS maybe does it faster if there are more people crying for a quick workaround or something, but not necessarily better.

    Leave a comment:


  • smitty3268
    replied
    Originally posted by AnAccount View Post

    The correct way would be for both Windows and Linux to refuse to boot if the BIOS corrupts the memory. That would lead to an actual fix of the root cause....
    Seems more likely this is happening on old hardware that isn't supported by the manufacturers anymore and all this would accomplish is a bunch of bug reports from users to MS and Linux about why an OS update broke their computer.

    Now if windows somehow did this for future hardware only, that might be effective.

    Leave a comment:


  • Turbine
    replied
    Originally posted by lucrus View Post
    It should have been obvious even without MS acknowledgement: that's why Windows never crashes.
    Eh? Windows has crashed for me quite a bIt in 2021. Just a lot less than LINUX.

    Leave a comment:


  • torsionbar28
    replied
    Originally posted by willmore View Post
    Once memory went over 1GB, this seems like an obvious low hanging fruit of stability.
    On the desktop, sure. But even when 1 GB desktops became commonplace, there were low memory embedded devices in use. It is only very recently that the smallest embedded x86 devices have enough RAM to not care about 1 MB.

    Leave a comment:


  • willmore
    replied
    I read the original announcement wrong, it seems. I though this change was to *eliminate* the reservation of the first MB or DRAM on x86/x86_64 (clearly not an issue on other archs). And I though "Wow, that seems like a risky bet for a tiny amount of memory. I hope this doesn't cause tons of subtle bugs due to crappy BIOS/UEFI/firmware." Glad to see I misread it. Can't believe we've been doing it this way all this time. Once memory went over 1GB, this seems like an obvious low hanging fruit of stability.

    Leave a comment:

Working...
X