andrewt@cs.su.oz (Andrew Taylor) (08/17/90)
In article <40885@mips.mips.COM> rogerk@mips.COM (Roger B.A. Klorese) writes: >> OK. Here is a quick summary of the HOW TO CRASH A RISC machine from >> a USER-MODE program test. Reports have arrived that all of these machines >> can be crashed using CRASHME.C: >> IBM RT, MIPS, DECSTATION 5000, SPARC. > >Prove it. My Mips RS2030 RISCstation cruised through it, repeatedly, and >kept running fine. Caught every bogus instruction... Either you have upgraded from RISC/os 4.5 or you weren't trying hard enough. Both our R2000 and R3000 based machines can be "crashed" by the execute random data program. A panic is caused by an illegal floating-point instruction in the delay slot of an illegal branch (instruction codes 0x07CB0D69, 0x46A7CC7D will do). The fp instruction traps and goes into a routine which sees the branch and wants to know where it will go. The routine called to calculate this realises the branch is illegal but does the wrong thing and calls panic. Trivial to fix. The original poster asserted that the program causes no problems on a SUN-3. It does cause problems on our Sun-3/50 runing SunOS 4.1. It can produce a cpu-bound process which can not be killed. The only way we've found to remove it is reboot. Various people have posted that machine X or operating system Y can't be crashed. What they really mean is they tried a few random instructions and they didn't cause problems. From our experience trying a bit harder could produce a different result. Seems like implementors could usefully use this program for crude testing. Andrew Taylor
vladan@idt.UUCP (Vladan Djakovic) (08/17/90)
In article <1150@cluster.cs.su.oz>, andrewt@cs.su.oz (Andrew Taylor) writes: > >Prove it. My Mips RS2030 RISCstation cruised through it, repeatedly, and > >kept running fine. Caught every bogus instruction... > > Either you have upgraded from RISC/os 4.5 or you weren't trying hard enough. > Both our R2000 and R3000 based machines can be "crashed" by the execute random ... M-120 running UMIPS 4.0 did not crash after 50+ runs with different seeds. If anybody ever managed to actually crash R[2|3]000 please post exact parameters given to crash. Any other arguments are immaterial. -- ############################################################################ # Vladan Djakovic, IDT (Integrated Device Technology), Santa Clara, CA # # ... uunet!idt!vladan (All opinions are mine. Whose else?) # ############################################################################
andrewt@cs.su.oz (Andrew Taylor) (08/20/90)
In article <186@idt.UUCP> vladan@idt.UUCP (Vladan Djakovic) writes: >M-120 running UMIPS 4.0 did not crash after 50+ runs with different seeds. >If anybody ever managed to actually crash R[2|3]000 please post exact parameters >given to crash. Any other arguments are immaterial. Well giving the exact instructions and explanation of why it causes a panic seems very material to me. If you must see with your own eyes to be convinced try "./crashme 8 6710 1".
vladan@idt.UUCP (Vladan Djakovic) (08/21/90)
In article <1153@cluster.cs.su.oz>, andrewt@cs.su.oz (Andrew Taylor) writes: > Well giving the exact instructions and explanation of why it causes a panic > seems very material to me. If you must see with your own eyes to be > convinced try "./crashme 8 6710 1". My mistake I did not make my comment and question more specific. Sequence 0x07cb0d69, 0x46a7cc5d crashes the system due to the software error. As noted, kernel makes mistake when preparing to return to user program after processing illegal FP instruction exception. I also happen to know several other ways to crash MIPS UNIX from user mode without any C programming. These are familiar everyday software errors. I am interested if somebody managed to drive R[2|3]000 into undocumented state by executing noise, as stated in the original posting. The kind of state causing crash that cannot be prevented by a bug-free kernel. -- ############################################################################ # Vladan Djakovic, IDT (Integrated Device Technology), Santa Clara, CA # # ... uunet!idt!vladan (All opinions are mine. Whose else?) # ############################################################################