Talk:Killer poke

message: I have a question: How exactly did the PET poke damage the CRT monitor? --Anonymous 14:02, 28 October 2005 (UTC)
replies: text: Thanks for asking! I will describe this in detail in the PET article itself shortly. Stay tuned. :-) --Wernher 02:20, 30 October 2005 (UTC)
thread_title: Wanted: PET killer poke details

message: Could someone please add an explanation for the note ("Any system that meets Popek and Goldberg virtualization requirements is immune (or can be made immune) to any killer poke."). I don't understand, why this is the case, so I think an explanation would be useful for the readers of this article.
: I just changed it by removing the "is immune" part, and I'll add an explanation now. Rbarreira 08:13, 11 July 2006 (UTC)
thread_title: About the note...

message: It seems to me that meeting the mentioned virtualization requirements is more than is needed to protect against killer pokes. While it is true that a properly virtualizable machine can be protected from killer pokes, so can any virtual memory system with memory protection, which protects memory-mapped registers from unprivileged code, either by preventing unprivileged writes or by simply not mapping the registers into the code's virtual address space. Of course, this can be bypassed if the code is running without memory protection and outside a virtual address space (like device drivers or x86 real mode applications) or is somehow able (perhaps by mmap or a similar facility) to map the sensitive registers into its virtual memory space with privileges to write to them. Port-mapped I/O could conceivably also produce similar effects to a killer poke, but this is technically not a poke, and port-mapped I/O operations tend to be privileged anyway. —71.39.6.137 06:54, 25 August 2007 (UTC)
thread_title: Virtual memory should be enough

message: I corrected the reference to 80/40 characters to the correct values of 64/32 but the fact the original author had this bit of information incorrect makes me suspicious that he/she also has the whole thing wrong.  We used to run programs that would toggle the display (PRINT CHR$(23) if I remember correctly) and although on the Model 1 you would hear a relay chattering away I never heard of any damage on a Model 1 nor a Model III machine.
This particular problem is doubtful.
(I had heard of a program that could jack up the floppy drive by continually running the head to step up... but again... nothing ever confirmed.)
Dcsutherland (talk) 10:15, 27 June 2009 (UTC)
thread_title:  TRS-80 MODEL III 

message: The term is used especially of various fairly well-known tricks that can overload the analog electronics in the CRT monitors of computers lacking hardware sanity checking (notable examples being the IBM PC [...] ) [...].
We need proof for the IBM PC being poke killable. --Abdull (talk) 11:33, 9 December 2007 (UTC)
thread_title:  IBM PC 

message: In my computer programming class freshman year of high school (1986), we had a lab of PCjrs.  We programmed in Pascal.  Anyway, there was a "motor" command that if placed into a tight loop would make the computer emit a sound similar to placing a playing card in the spokes of a bicycle tire.  One day, I snuck into the lab and set up all the PCs to execute the loop, resulting in noise so loud it was heard outside the room.  Needless to say, I received saturday detention for this.  I think this is related to the Acorn tape thingy mentioned in the article.  Anybody else heard of this?  —Preceding unsigned comment added by Zenotek (talk • contribs) 20:59, 30 July 2008 (UTC)
replies: text: A similar concept, but not necessarily related to the Acorn tape loop and not really a killer poke. We did something similar in class with the Apple IIe where we would sit at one station and program it to start making an endless raspberry fizz-type noise after including a delay long enough to safely get away from the machine and avoid all suspicion. Twalls (talk) 22:00, 30 July 2008 (UTC)
replies: text: i remember downloading a program for my c64 back in the day that would make my 1541 floppy drive actually play a song by somehow vibrating the read/write head at different frequencies. again, not really a killer poke, but that couldn't have been good for the drive's health :) --Kvuo (talk) 04:22, 13 October 2008 (UTC)

text: the Amstrad CPC 464 8-bit computer had a built-in cassette tape drive which could be controled by turning a specific bit on an I/O port on and off. I wrote a program which did exactly that in an endless loop. It didn't take long to realize that this could damage my precious computer so I stopped :)  —Preceding unsigned comment added by 93.86.225.127 (talk) 06:24, 2 September 2009 (UTC)
thread_title:  IBM PCJR 

message: Any documentation on this? Beyond blogs?  —Preceding unsigned comment added by Otterfan (talk • contribs) 17:22, 14 June 2009 (UTC)
thread_title:  Citations please... 

message: A couple of years ago, Linux users who were using bleeding-edge kernels started seeing their Intel e1000e gigabit ethernet adapters die. Some users were able to re-flash the firmware on their adapters, but many adapters were permanently destroyed. It took a long time for kernel developers to discover the source of the problem, which is documented in this article on lwn.net: http://lwn.net/Articles/304105/
Given the profile of the problem and the scintillating complexity that caused it, I think it deserves a mention in this article. Naptastic (talk) 04:57, 15 June 2010 (UTC)
thread_title:  Linux bricking Intel network adapters 

message: What about the bug found in some Samsung Notebooks where the hardware could be destroyed by software? I guess it's an exmaple from present-day time.  — Preceding unsigned comment added by 217.247.82.17 (talk) 14:26, 20 May 2013 (UTC)
thread_title:  Samsung UEFI bug 

message: This is NOT from the real thing! Maybe it would make sense to mention this in the article? The floppy motor sounds as if it was reading a very worn-out disk. And yes, i can recall these sound samples! They were recorded by user hal from English Amiga Board and are now part of WinUAE. So if you think that's the real thing playing E.C.P., you're wrong. :) -andy 77.190.40.209 (talk) 02:50, 6 February 2014 (UTC)
thread_title:  "El Cóndor Pasa" video is from emulator :) 

message: The 1541 actually has it's own CPU and operating system (firmware).  It was the Apple 1 / Apple 2 drives of that time period that were entirely dumb.  The Commodore drive could be forced out of alignment by repeat reset commands from a host - but that's not much different than a host computer forcing a printer to jam up in some way (most printers of the era had no tray full detection/etc).
An example of how the 1541 drive can copy disks without the host computer even turned on: http://en.wikipedia.org/wiki/Fast_Hack%27em  — Preceding unsigned comment added by 97.77.97.146 (talk) 15:44, 21 August 2014 (UTC)
thread_title:  Commodore 1541 statement that it is a dumb drive is entirely false 

message: In "Game Boy" section: "The Game Boy's LCD screen can be turned off by game software. Doing so outside of the vertical blanking interval can damage the hardware.". There seems to be no confirmation of this statement outside of Pan Docs. Official Game Boy programming manual mentions that doing so (turning LCD screen off outside of the vertical blanking interval) can leave horizontal black line on the screen, but do not mentions any hardware damage.
84.244.22.100 (talk) 12:27, 17 March 2015 (UTC)
thread_title:  Game Boy section 

message: Hi there. Plenty of references out there state that the iPhone epoch hack will 'fix' itself when the battery is allowed to discharge and 'die'. I'm not about to update the article as I have a WP:COI there, but someone should look into that ... - Alison ❤ 03:25, 19 February 2016 (UTC)
thread_title:  iPhone epoch 'brick' issue 

message: Could it be considered to be another method of inducing killer pokes (i.e. on GPUs)? Well since it stresses the GPU to the point of blowing up hardware components by running intensive fur simulation stuff, one case being a certain user's GTX 295 having its VRM circuitry damaged after a stress test. Blake Gripling (talk) 06:12, 19 June 2016 (UTC)
thread_title:  FurMark? 

message: In 2017 Ubuntu 17.10 had a problem  where some sort of Intel hardware drivers caused a number of buggy Lenovo laptop models to flash their BIOS and render it nonfunctional (though UEFI still worked). Supposedly, the actual change to the bios was very small but one of the very few surefire ways to fix it was to replace the physical chip.
Would this be considered an example/notable?
SougonNaTakumi (talk) 10:47, 13 March 2018 (UTC)
thread_title:  2017 Linux bios bug 

message: Apparently on the NES title Metroid, typing the password "ENGAGE RIDLEY MOTHER FUCKER" caused a software bug that can crash the console, and in some cases, permanently damage it.  This may be worth looking into a little more
Tomrow (talk) 18:39, 25 February 2020 (UTC)
thread_title:  Metroid on NES