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

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


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


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/