41–50 of 55 posts
This is deep nostalgia for me. A bootloader and a toy ... kernel ... were the first things I ever wrote after leaving Apple II BASIC behind. The local library had no books on anything other than BASIC and assembler. I didn't know what a higher-level language was - never even heard of C or Pascal or anything - I just knew that I didn't seem to be able to do a lot of stuff in BASIC. After a few hours at the library, I…
> QEMU is great because you don’t have to worry about accidentally destroying your hardware with badly written OS code Is that actually possible?
The only times I've heard of destroying hardware with software have been: 1) stopping the ray in a CRT monitor through special purpose registers and using it to burn through the phosphorous. 2) Early floppy drives where you could position the head to an impossible position causing the servo to burn. Haven't heard of anything like what he is describing the last 20 years. Perhaps you can overheat some stuff - but most…
I was trying to find some information to back up my story, but I can't find anything that does. So I'll describe what I experienced, and maybe someone will have an idea.
Around 1999, my father gave me the first computer that was "mine" (previous ones having been "family computers"). I was inexperienced and 15 years old, with access to filesharing platforms, and learned the hard way about *.jpg.exe files.
The hard drive started making rhythmic sounds as soon as the OS was booted. A couple days later, the OS wouldn't boot. A reinstall worked for a short time (but the drive still did its odd sound). We had some bootable disk scanning utilities from the drive vendor. They identified the drive as having 100% bad sectors.
I've always assumed that a virus was crashing or misaligning the read heads somehow. That was reinforced when the second drive that I got met the same fate. Although, I guess it's more likely that they were 2 drives from the same shipment that met early deaths due to manufacturing defects.
Last line in this article mentions a Part 2, which will cover getting into Protected Mode. Which implies that x86 boxen are still to this day are POSTing in 16-bit real mode What I'm wondering, is whether this is because of the design of the firmware, hardware or both. Back when protected mode was the new hotness, it made sense for the CPU to power on in real mode, for backwards compatibilty. But back-compat w/ DOS i…
UEFI boot handles the real->protected (and ->long) transitions, so it's no longer necessary for the OS to handle it. EFI executables run in protected mode, with a memory mapping set up by the runtime. > Another thing I wonder about, is if it's possible to have the CPU come online directly in protected mode or long mode after POWER_OK has settled and the motherboard releases the reset line. No. The BIOS needs to perfo…
I don't feel like the person you're responding to suggested that the OS should be responsible for it; he/she just wondered if it is possible to have the CPU not have to jump through 16-bit real mode and 32-bit protected mode just to get to 64-bit.
I see no fundamental reason why it should be impossible for the BIOS to do its initialization work in 64-bit mode. There's the issue of paging and the page-table perhaps, but it seems trivial enough to suggest that the CPU could initialize with a very basic 1:1 mapping between virtual memory and RAM.
That said, I don't know if such a thing would ever actually happen, since I imagine that it would suggest re-writing a lot of code.
Earlier quoted context omitted.
The only times I've heard of destroying hardware with software have been: 1) stopping the ray in a CRT monitor through special purpose registers and using it to burn through the phosphorous. 2) Early floppy drives where you could position the head to an impossible position causing the servo to burn. Haven't heard of anything like what he is describing the last 20 years. Perhaps you can overheat some stuff - but most…
> The only times I've heard of destroying hardware with software have been I was trying to find some information to back up my story, but I can't find anything that does. So I'll describe what I experienced, and maybe someone will have an idea. Around 1999, my father gave me the first computer that was "mine" (previous ones having been "family computers"). I was inexperienced and 15 years old, with access to fileshar…
Earlier quoted context omitted.
> The only times I've heard of destroying hardware with software have been I was trying to find some information to back up my story, but I can't find anything that does. So I'll describe what I experienced, and maybe someone will have an idea. Around 1999, my father gave me the first computer that was "mine" (previous ones having been "family computers"). I was inexperienced and 15 years old, with access to fileshar…
Given the year, that sounds suspiciously like the IBM 75gxp Deathstar fiasco. It probably wasn’t your fault at all.
Earlier quoted context omitted.
> The only times I've heard of destroying hardware with software have been I was trying to find some information to back up my story, but I can't find anything that does. So I'll describe what I experienced, and maybe someone will have an idea. Around 1999, my father gave me the first computer that was "mine" (previous ones having been "family computers"). I was inexperienced and 15 years old, with access to fileshar…
Given the year, that sounds suspiciously like the IBM 75gxp Deathstar fiasco. It probably wasn’t your fault at all.
Earlier quoted context omitted.
Not quite right. The documented interface that was used for firmware control on BIOS systems generated errors if you poked it on UEFI systems, and the kernel logged those errors into UEFI variables. If the UEFI variable storage filled up, the machine stopped booting. It was possible to trigger the failure by filling the variable store, even under Windows. The workaround was to reserve some variable storage space at a…
I love this comment, in part because it's totally outside my area of knowledge but I can still picture the battles and dead ends you must have worked through to make it stable. Did you kill a lot of hardware figuring it out? What was the purpose of poking that caused the underlying issue?
Earlier quoted context omitted.
I love this comment, in part because it's totally outside my area of knowledge but I can still picture the battles and dead ends you must have worked through to make it stable. Did you kill a lot of hardware figuring it out? What was the purpose of poking that caused the underlying issue?
I only killed one laptop in the end, the rest of the testing was done with VMs and a system that had a hardware EFI variable reset button. The issue that was triggering it on Samsungs was the driver that supported backlight control - it worked by writing a value to an address which triggered some system management mode code in the firmware, but that code only worked properly in BIOS mode. In EFI mode it generated mac…
Ooh, that sounds useful for hardware hackers. What was this?
Earlier quoted context omitted.
The only times I've heard of destroying hardware with software have been: 1) stopping the ray in a CRT monitor through special purpose registers and using it to burn through the phosphorous. 2) Early floppy drives where you could position the head to an impossible position causing the servo to burn. Haven't heard of anything like what he is describing the last 20 years. Perhaps you can overheat some stuff - but most…
> The only times I've heard of destroying hardware with software have been I was trying to find some information to back up my story, but I can't find anything that does. So I'll describe what I experienced, and maybe someone will have an idea. Around 1999, my father gave me the first computer that was "mine" (previous ones having been "family computers"). I was inexperienced and 15 years old, with access to fileshar…
This virus loaded itself somehow at early bootup (maybe even launched via an altered bootloader) and then sequentially accessed every single sector on the disk and deliberately marked it as bad at either the FAT32 or ATA (hardware) level.
The bustlework involved with actually issuing tons of such ATA commands could explain the thrashing.
Ref/inspiration for this theory: ^F for "--make-bad-sector" in https://linux.die.net/man/8/hdparm
(Just to be redundantly, obsessively clear, this parameter is several orders of magnitude more dangerous than "rm -rf --no-preserve-root", as hdparm will use ATA/SCSI commands that will be preserved by the hardware across infinite reboots until exactly the right --repair-sector command is issued.)
And FWIW, I do see a lot of holes in this (very simplistic) interpretation, and would be genuinely stunned if this is what actually happened.