Re: port-m68k/27099 (If one runs crashme on a 2.0 m68k machine, the system panics.)

["Michael L. Hitch" <mhitch%lightning.msu.montana.edu@localhost>]

The following reply was made to PR port-m68k/27099; it has been noted by GNATS.

From: "Michael L. Hitch" <mhitch%lightning.msu.montana.edu@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: port-m68k-maintainer%netbsd.org@localhost, 
netbsd-bugs%netbsd.org@localhost, 
    gnats-admin%netbsd.org@localhost, dholland%NetBSD.org@localhost, 
jklos%netbsd.org@localhost
Subject: Re: port-m68k/27099 (If one runs crashme on a 2.0 m68k machine, the
 system panics.)
Date: Thu, 10 Apr 2008 20:38:01 -0600 (MDT)

 On Thu, 10 Apr 2008, dholland%NetBSD.org@localhost wrote:
 
 > Synopsis: If one runs crashme on a 2.0 m68k machine, the system panics.
 >
 > State-Changed-From-To: feedback->open
 > State-Changed-By: dholland%NetBSD.org@localhost
 > State-Changed-When: Thu, 10 Apr 2008 01:26:42 +0000
 > State-Changed-Why:
 > Feedback timeout. Anyone have an m68k to test this?
 
    I just tried this on an Amiga 4000 with a 68060 running 4.0, and after 
 try 32, my system paniced with a memory fault.  It appears to be at 
 _060_isp_cas_restart+0x1586 on a pflush a2@ instruction with a2 containing 
 0x2b70.  That offset seems rather large, so I suspect _060_isp_cas_restart 
 isn't involved.  A binary integer kernel package follows that, and it's 
 somewhere within one of the 060 support routines.  A stack trace results 
 in another fault.  Gdb probably can't figure out how to track back through
 that code.
 
    A second attempt resulted in a kernel hang with the machine locked up.
 
 --
 Michael L. Hitch                       mhitch%montana.edu@localhost
 Computer Consultant
 Information Technology Center
 Montana State University       Bozeman, MT     USA