Re: [hatari-devel] Potential 68040 CPU/MMU fail with MOVES

[Andreas Grabher <andreas_g86@xxxxxxxxxx>]

That happens! But I still think the code could use some cleaning. I am glad we were able to find the issue so quickly.

History of the special  function code handling code would be interesting. Did you maybe test this on real hardware at some point?

Am 12.02.2024 um 19:34 schrieb Toni Wilen <twilen@xxxxxxxxxx>:



Thanks. I got both almost correct but still they were also stupidly wrong..

---

From: Andreas Grabher <andreas_g86@xxxxxxxxxx>
Sent: 12 February 2024 19:42
To: Hatari devel list <hatari-devel@xxxxxxxxxxxxxxxxxxx>; Toni Wilen <twilen@xxxxxxxxxx>
Subject: Re: [hatari-devel] Potential 68040 CPU/MMU fail with MOVES

 

I was able to fix the problem and yet another issue regarding MOVES. A patch is appended (please do not modify). The patch fixes three issues:

Issue 1:

The "ismoves" flag got stuck if a page fault occurred during an access via MOVES on 68040. Subsequent instructions used a wrong function code in certain circumstances.

Issue 2:

The special handling of the function codes regarding MOVES on 68040 produced wrong results. It should translate 2 -> 1 and 6 -> 5 but did 2 -> 0 and 6 -> 4. 

Issue 3:

The debugging message regarding special function code handling on 68040 printed the function code value passed to the function instead of the one loaded from the SFC or DFC register.

Also included is some minor improvement of the special function code handling (now exactly matches the values of Table 3-2 in M68040 User’s Manual) and a fixed comment.

Am 12.02.2024 um 08:44 schrieb Andreas Grabher <andreas_g86@xxxxxxxxxx>:

I think I got it. It seems the variable  "ismoves" gets stuck after a page fault and subsequent instructions use the wrong function code. I can‘t test it right now but will do so in the evening. Fixing this might be a bit complicated due to fundamental structural issues in the code (which are also responsible for such oversights). At least all unaligned MOVES access functions need to be fixed too. 

Am 11.02.2024 um 20:52 schrieb Andreas Grabher <andreas_g86@xxxxxxxxxx>:



I will check the instructions tomorrow. 

What is confusing me: It seems the special functionality is respected while creating exception stack frames but not while creating or searching ATC entries. But maybe I misunderstand the code.

Am 11.02.2024 um 18:04 schrieb Toni Wilen <twilen@xxxxxxxxxx>:



Hi

68040 MOVES special cases are emulated (instruction space becomes data space in bus errors but I don't think network drivers directly write to instruction space. "MOVES special behavior" comment in bus error code).

Probably reason is some (rare) bus error condition that gets restarted incorrectly or something similar. It can't be something too common because 68040 unix ports use MOVES to transfer data between supervisor (kernel) space and user space and these are known to work.

Could you check which kinds of MOVES instructions it uses and if they generate bus errors regularly? (Is it just MOVES.X Dn,(An)+ or MOVES.X (An)+,Dn or some more complex addressing mode)

---

From: Andreas Grabher <andreas_g86@xxxxxxxxxx>
Sent: 11 February 2024 16:30
To: Toni Wilen <twilen@xxxxxxxxxx>; Hatari devel list <hatari-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Potential 68040 CPU/MMU fail with MOVES

 

Hello Toni,

I got an issue here. While copying files from an NFS share to a SCSI disk image the system is very unstable and I regularly get kernel panics. The suspicious thing: This only happens during network transfers and on 68040. It does not happen on 68030 with everything else being the same. Therefore I suspect a CPU issue. During networking NeXTstep makes heavy use of MOVES instructions, which is unique to networking. Probably this is the root cause of the issue. M68000PRM shows some differences for MOVES between 68030 and 68040.

Any idea what might be wrong here?

Best wishes,
Andreas