| Re: [hatari-devel] Issues after recent WinUAE CPU core changes |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
On 6/2/20 8:59 PM, Toni Wilen wrote:
If you enable MMU logging (mmu_common.h and cpummu030.h) and check the
log, do you see bus error from address that ends to FFC before it
crashes? (la=c0007ffc etc, it also probably have "ffff ILLEGAL._" at the
end of line which means prefetch bus error)
With:
#define MMU030_DEBUG 1
#define MMUDEBUG 1
#define MMUINSDEBUG 1
#define MMUDEBUGMISC 1
I get:
------------------------------------------
....
DEBUG: Your Atari program just did something terribly stupid:
dummy_xlate($800dd468)
DEBUG: MMU: 0b la=8003FDF8 SSW=5042 read=1 size=4 fc=2 pc=800dc2dc
ob=800dc2e2
DEBUG: 61ff BSR.L
DEBUG:
DEBUG: MMU: 0b la=8003FDF8 SSW=5042 read=1 size=4 fc=2 pc=8003fdf8
ob=800dc2e2
DEBUG: ffff ILLEGAL._
DEBUG:
DEBUG: Your Atari program just did something terribly stupid:
dummy_xlate($8003fe2a)
DEBUG: Your Atari program just did something terribly stupid:
dummy_xlate($8001b650)
DEBUG: Your Atari program just did something terribly stupid:
dummy_xlate($8001b6be)
DEBUG: Your Atari program just did something terribly stupid:
dummy_xlate($80019bcc)
DEBUG: MMU: 0a la=8017CADC SSW=0301 read=0 size=4 fc=1 pc=8001a78a
ob=0001f529
DEBUG: 2143 MOVE.L
DEBUG:
DEBUG: Your Atari program just did something terribly stupid:
dummy_xlate($8001b6d2)
***lots of dummy_xlate warnings*** (as earlier)
DEBUG: Your Atari program just did something terribly stupid:
dummy_xlate($800294a0)
DEBUG: MMU: 0a la=EFDD3A8C SSW=0301 read=0 size=4 fc=1 pc=800294e2
ob=00000002
DEBUG: 4878 PEA.L
DEBUG:
DEBUG: MMU: 0b la=8017796C SSW=0381 read=0 size=4 fc=1 pc=800464d4
ob=00000000
DEBUG: 0ef9 CAS.L
DEBUG:
DEBUG: MMU: 0b la=720166F6 SSW=03c1 read=1 size=4 fc=1 pc=800464d4
ob=00000000
DEBUG: 0ef9 CAS.L
DEBUG:
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
------------------------------------------
If yes, below patch improved prefetch handling after branch to address
space that generates bus error. Previously it partially reloaded already
prefetched data after RTE, now it does not but it seems there is some
bug or MMUSR flags are not right in this situation.
Patch seems to be missing?
I tried few different Amiga Linux variants (some ancient Debian) and one
of them does not crash but generates unexpected line-F because of above
prefetch fault.
I remember few mystery random line-F errors
happening in some cases earlier, where they
shouldn't have.
- Eero
Commit regressing this is:
-------------------------
commit 759d60f9dcf3f2971aabd905adb3d7404e8d3b19 (HEAD, refs/bisect/bad)
Author: Nicolas Pomarede <npomarede@xxxxxxxxxxxx>
Date: Thu May 21 22:10:15 2020 +0200
68030 MMU fixes. Software fixed pipeline stage fixes and more
compatible (prefetch) locked rmw and mmufixup fix (from WinUAE 4.4.0
beta3+ 2020/05/21)
-------------------------
See:
https://git.tuxfamily.org/hatari/hatari.git/commit/?id=759d60f9dcf3f2971aabd905adb3d7404e8d3b19
- Eero
On 6/2/20 5:37 PM, Eero Tamminen wrote:
On 6/1/20 7:49 PM, Toni Wilen wrote:
Issue goes away only when I disable *both* 030 cache emulation and
prefetch with:
--cpu-exact off --compatible off
Disabling just one of them isn't enough.
68030 + MMU + prefetch has been broken for long time
MMU support is not that old, 030 MMU + cache
support was added some time in 2017, and many bugs
were still fixed in 2018.
Do you remember how long ago the above combo was
fully working (in winAUE CPU core version)?
> (It might have accidentally worked in some
> situations)
There were quite a lot of mystery crashes on user-
space entry / exit also earlier, so I'm not too
surprised about that. :-)
It was fixed (at least Amix boots again) only 1-2 weeks ago.
I was testing Hatari version that had Nicolas' CPU core updates from
yesterday.
I'll hope to have time to bisect it this evening.
Happily it's fully reproducible.