Slashdot Mirror
Samsung Laptop Bug Is Not Linux Specific
First time accepted submitter YurB writes "Matthew Garrett, a Linux kernel developer who was investigating the recent Linux-on-Samsung-in-UEFI-mode problem, has bricked a Samsung laptop using a test userspace program in Windows. The most fascinating part of the story is on what is actually causing the firmware boot failure: 'Unfortunately, it turns out that some Samsung laptops will fail to boot if too much of the [UEFI] variable storage space is used. We don't know what "too much" is yet, but writing a bunch of variables from Windows is enough to trigger it. I put some sample code here — it writes out 36 variables each containing a kilobyte of random data. I ran this as an administrator under Windows and then rebooted the system. It never came back.'"
Embrace Linux as an additional test suite for your hardware.
it writes out 36 variables each containing a kilobyte of random data
36k clearly isn't enough for anyone.
30-day hassle-free return policy.
So installing too many operating system will result in a brick, Windows in particular uses a lot of NV storage for it's boot entry, be careful when using BCDEDIT.exe...
I might be confused, but don't kernel devs normally destroy their instruments at the end of each show?
How can I believe you when you tell me what I don't want to hear?
Removing the CMOS battery didn't recover this system, which is pretty much what I'd expect - UEFI variables are typically stored in the same hardware as the firmware itself, and unplugging batteries doesn't kill your firmware.
The system doesn't fail to boot. The system doesn't even complete its power-on self checks. The screen is never turned on. It never responds to keyboard input. It's bricked. This machine's not coming back to life without an SPI programmer.
UEFI data is apparently stored in NAND. Non-volatile.
No idea if there is some way to flash it, but if it's sufficiently hardwired into the board then it's entirely possible you're SOL and have to buy new hardware. Yes, this is idiotic.
Just guessing from experience with Koreans, but... chances are they followed Microsoft or Intel specifications properly. Other companies probably just copied a binary and use it as a black box.
Alt+F4, Alt+F4, Alt+F4, Alt+F4, Alt+F4, Alt+F4, Alt+F4 ...I'm sure someone will hit it (even now :-).
Why would I want to switch to virtual desktop 4?
From the scant details, it appears Samsung didn't provide enough storage [of whatever type] to be able to store the UEFI variables that one could reasonably be expected to store. And/or when that storage ran out [or hit a percentage threshold], simply failed to prevent the bricking with a limit check and refuse to store the new information [returning an error code instead]. It's unclear what's truly happening, but it seems that the extra UEFI data goes somewhere and scribbles on some NV memory that it shouldn't [which may have nothing to do with secure boot].
Like a good neighbor, fsck is there
These steps are actually NOT supposed to brick them. It is thus a proven manufacturing defect. So Samsung is obligated to "repair or replace". An external (JTAG) reflash of the ROM should be able to fix it. Samsung should also fix it by reprogramming the ROM code to perform UEFI correctly.
now we need to go OSS in diesel cars
That's not what the OOM killer is for. Linux will allow over-commitment of memory (programs can malloc more memory (RAM plus swap) than is available). If all the malloc'ed memory is actually used, this can lead to more memory having been allocated than is available. This is when the OOM killer starts work killing tasks.
This behavior can be modified by changing the values in /proc/sys/vm/overcommit_ratio and /proc/sys/vm/overcommit_memory.
As an experiment, I wrote a little progrem that malloc'ed 200MB chunks of memory. I ran this on a Linux box with 2GB of RAM and all the SWAP disabled. The program could malloc 3GB of RAM before the allocation requests failed.
The real "Libtards" are the Libertarians!
That's often a case of running out of desktop heap rather than handles.
I might be confused, but don't kernel devs normally destroy their instruments at the end of each show?
Well, when on the Ed Sullivan Show, they have been known to pack explosives into the drum memory.
Why, without your clothes, you're naked, Miss Dudley!
You can almost certainly re-program it using a JTAG interface... Samsung can do this at the factory if you return it to them. JTAG is not intended for consumer use, though. My old university had a JTAG probe and several adapters to interface with various hardware vendors proprietary interfaces - without this we would have had several multi-thousand dollar bricks in our hardware lab :)
I would hope that Samsung would have the decency to admit a flaw in their design and provide the reprogramming free of charge, but ...
Well, yes, in a way, they are intentionally bricking their laptops. And I would hope they can get a new one under warranty.
Reason being of course that they are trying to figure out what causes Linux to brick those laptops. And to figure that out, first of all you need to figure out what triggers that bug. Unfortunately in this case the triggering of that bug means you're destroying a perfectly good piece of hardware.
Only when you know exactly what causes a bug, can you start figuring out how to fix it. The problem seemed to be Linux related - now it's proven that is not the case, the actual bug is in the UEFI. It's not a Linux bug, it can be triggered using any OS. Windows software may do this as well - and I can really think of people wanting to write data into UEFI memory, particularly those in the malware/DRM business - and as a result bricking the machine.
And now it's up to Samsung to actually fix their UEFI firmware code.
The Linux folks actually read and understand the documentation and then use the mechanisms described. The Windows-folks are usually not so capable.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.