NetBSD Problem Report #13078

Received: (qmail 28542 invoked from network); 1 Jun 2001 05:48:47 -0000
Message-Id: <20010601055030.1F6321110F@www.netbsd.org>
Date: Thu, 31 May 2001 22:50:30 -0700 (PDT)
From: sysadmin@alliedtours.com
Sender: nobody@netbsd.org
Reply-To: sysadmin@alliedtours.com
To: gnats-bugs@gnats.netbsd.org
Subject: Mac 68LC040 problem
X-Send-Pr-Version: www-1.0

>Number:         13078
>Category:       port-mac68k
>Synopsis:       Mac 68LC040 problem
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    nat
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jun 01 05:49:00 +0000 2001
>Closed-Date:    
>Last-Modified:  Tue Apr 22 01:42:44 +0000 2025
>Originator:     andrew
>Release:        1.5
>Organization:
>Environment:
NetBSD 1.5 NetBSD 1.5 (GENERIC) #0: Sun Nov 19 14:20:10 PST 2000 root2@c610:/usr/cvs/src/sys/arch/mac68k/compile/GENERIC mac68k
>Description:
Major problems with mac m68LC040
>How-To-Repeat:
Run NetBSD...  more specifically, "ls -la" "send-pr", some programs called by startup scripts, sometimes ifconfig crashes, just about everything does!
>Fix:
This problem was reported and supposedly fixed in the linux kernel.  Something to do with the bus.  I dont remember...
>Release-Note:
>Audit-Trail:

From: Juergen Hannken-Illjes <hannken@eis.cs.tu-bs.de>
To: sysadmin@alliedtours.com
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: port-mac68k/13078: Mac 68LC040 problem
Date: Fri, 1 Jun 2001 10:10:48 +0200 (MET DST)

 Looks like the 68LC040 F-Line error. From Motorola:

 Here is E4 for the 68LC040:

 E4-	If a write is pending on the 68LC040 and an F-line Unimplemented
 	Exception is taken, the pending write data may be lost.

 Workaround:  place a NOP before the F-line instruction

 -- 
 Juergen Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)
State-Changed-From-To: open->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 15 May 2016 21:15:24 +0000
State-Changed-Why:
15 years later, mac68k is pretty close to irrelevant, and if it hasn't worked
in all this time most certainly nobody cares. It's a marginal processor model
anyway.

Since it has no FPU (just traps for FPU emulation in software, which is what
goes wrong) the best approach is to build userland with softfloat. If anyone
has one of these things that they want to run and isn't already doing this,
try that.

If building a mac68k userland with softfloat is problematic or doesn't work,
please file a new PR.


Responsible-Changed-From-To: port-mac68k-maintainer->nat
Responsible-Changed-By: nat@NetBSD.org
Responsible-Changed-When: Sat, 30 Nov 2024 08:11:39 +0000
Responsible-Changed-Why:
Take.


State-Changed-From-To: closed->open
State-Changed-By: nat@NetBSD.org
State-Changed-When: Sat, 30 Nov 2024 08:11:39 +0000
State-Changed-Why:
I'm looking into this...


From: Nathanial Sloss <nathanialsloss@yahoo.com.au>
To: gnats-bugs@netbsd.org
Cc: netbsd-bugs@netbsd.org
Subject: Re: port-mac68k/13078 (Mac 68LC040 problem)
Date: Sat, 30 Nov 2024 19:23:30 +1100

 The submitter is indeed right adding a nop before an fpu instruction does fix
 the fpu emulation on the lc040...

 The number of failed tests for libm is the same as for an '030 with fpu 
 emulation and better than a qemu emulation of a full '040.

 The number of failed libm tests are ~15 (1 expected).

 Here is the diff to add nops for fpu instructions patching gcc / libc and 
 locore assembly stubs:

 http://ftp.netbsd.org/pub//NetBSD/misc/nat/lc040nop-fpuemul.fix.diff

 I sincerely believe that this should be the preferred option as it means no 
 special binaries just for the lc040 and uniformity amongst all m68k variants.

 Best regards,

 Nat

From: Martin Husemann <martin@duskware.de>
To: Nathanial Sloss <nathanialsloss@yahoo.com.au>
Cc: gnats-bugs@netbsd.org
Subject: Re: port-mac68k/13078 (Mac 68LC040 problem)
Date: Sat, 30 Nov 2024 13:09:32 +0100

 Impressive!

 I would suggest to split this into two parts and make them
 optional, defaulting to the broken cpu compat as in your diff in the
 official builds, but allowing other to optimize "real 040" or other
 builds w/o the penalty.

  1) gcc - this needs to be upstreamed. Make it conditional on a -f or
     -m option and use that option in our default builds for m68k.
     This option should cause an additional internal define so code
     can #ifdef on that
  2) Make all other changes conditional on the new automatic define
     if the lc040 option is used to compile something. Maybe define
     a LC040_NOP that goes away w/o that define.


 Martin

From: Nat Sloss <nathanialsloss@yahoo.com.au>
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@netbsd.org
Subject: Re: port-mac68k/13078 (Mac 68LC040 problem)
Date: Mon, 2 Dec 2024 23:51:25 +1100

 I have two simpler patches for consideration they are similar exepept one sees 
 if the assembled instruction starts with an 'f' (i would have to add 
 instructions starting with 'p' also) and the second alternatvely checks the 
 assembled opcode is a n f-line instruction and applies the fix.

 They patch sys/m68k to ensure there's a nop at the end to task switching just 
 incase it switching into an f-line instruction and patch the assembler gas to 
 add the nops before f-line instructions:

 http://ftp.netbsd.org/pub/NetBSD/misc/nat/lc040nop-fpuemul.fix-gas.diff

 http://ftp.netbsd.org/pub/NetBSD/misc/nat/lc040nop-fpuemul.fix-gas-take2.diff

 I believe take2 is the preferred one would you agree?

 These patches patch all f-line (coprocessor and fpu instructions) without 
 needing to alter the way m86k assembler is written (provided you use labels 
 and not hardcoded addresses based on instruction byte counting).

 Best regards,

 Nat

From: Nathanial Sloss <nathanialsloss@yahoo.com.au>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-mac68k/13078 (Mac 68LC040 problem)
Date: Sun, 30 Mar 2025 17:52:23 +1100

 Posting as it has seemed to be lost by gnats.

 CVS commit: src/sys/arch/m68k/m68k

 Module Name:    src
 Committed By:   nat
 Date:           Sun Mar 30 04:44:26 UTC 2025

 Modified Files:
         src/sys/arch/m68k/m68k: switch_subr.s

         Log Message:
         Sprinkle nop.

         This is the kernel part of addressing the issue with fpu emulation on 
 	lc040 cpus.

         The idea is that we might be switch from or to an f-line (MMU/FPU 
 	Trap) instruction so prepend a nop to flush the caches.

         Addresses part of PR/13078.

         The second part to this (patch to binutils/gas) has been submitted		
 	upstream
         and will be fixed when this part is reviewed and included in our local 
 	copy of binutils or (hopefully) in a later version of binutils from 
 	upstream.

         See:
         https://sourceware.org/pipermail/binutils/2025-March/140270.html


         To generate a diff of this commit:
         cvs rdiff -u -r1.38 -r1.39 src/sys/arch/m68k/m68k/switch_subr.s

         Please note that diffs are not public domain; they are subject to the
         copyright notices on the relevant files.

Responsible-Changed-From-To: nat->port-mac68k-maintainer
Responsible-Changed-By: nat@NetBSD.org
Responsible-Changed-When: Thu, 10 Apr 2025 22:12:14 +0000
Responsible-Changed-Why:
Over to port maintainer.


Responsible-Changed-From-To: port-mac68k-maintainer->nat
Responsible-Changed-By: nat@NetBSD.org
Responsible-Changed-When: Tue, 22 Apr 2025 01:42:44 +0000
Responsible-Changed-Why:
Take back.


>Unformatted:

Home	PR Database Search