| Re: [hatari-devel] Issues after recent WinUAE CPU core changes |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On 6/8/20 11:13 PM, Nicolas Pomarède wrote:
Le 02/06/2020 à 20:21, Toni Wilen a écrit :
I think you forgot the patch :)
I meant patch mentioned in Eero's post.
I get:
------------------------------------------
Bleh, no FFC.. Then I am not sure what is going on. 68030 MMU is still
extremely annoying to emulate.. (mmu cpu tester would be nice but
writing one would be ultra-mega-extremely annoying to do..)
Could you compare non-prefetch mode log with prefetch mode logs? They
should be almost identical until things go wrong.
Note that opcode reads are usually word sized in non-prefetch mode and
long sized (and aligned to long word addresses) in prefetch mode. This
is normal difference.
btw, "terrible stupid" messages probably should not be logged if MMU
translation is in use.
I see you pushed some 68020/30 prefetch/MMU changes, is that supposed to
improve the issue when running linux under TT ?
In all cases, I pushed the changes to Hatari devel tree, so eero can
have a look to see if that fixes anything.
Thanks!
Unfortunately it still happens when I have
cache and/or prefetch emulation enabled:
------------------------------------------------
DEBUG: MMU: 0a la=EF86EA9C 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: 0a la=8017A068 SSW=0301 read=0 size=4 fc=1 pc=0003e69e
ob=00999fac
DEBUG: 0e90 MOVES.L
DEBUG:
DEBUG: MMU: 0b la=800294B8 SSW=5062 read=1 size=2 fc=2 pc=800294b8
ob=00999fb8
DEBUG: 4e73 RTE._
DEBUG:
DEBUG: MMU: 0b la=800294B8 SSW=5062 read=1 size=2 fc=2 pc=800294b8
ob=00999fb8
DEBUG: ffff ILLEGAL._
DEBUG: 4e73 RTE._
DEBUG:
DEBUG: MMU: 0b la=EF86EA9C SSW=0301 read=0 size=4 fc=1 pc=800294ee
ob=800294f0
DEBUG: 4e92 JSR._
DEBUG:
DEBUG: MMU: 0b la=8000247C SSW=5062 read=1 size=2 fc=2 pc=8000247c
ob=800294f0
DEBUG: 4e92 JSR._
DEBUG:
DEBUG: MMU: 0b la=8000247C SSW=5062 read=1 size=2 fc=2 pc=8000247c
ob=800294f0
DEBUG: ffff ILLEGAL._
DEBUG: 4e92 JSR._
DEBUG:
DEBUG: Your Atari program just did something terribly stupid:
dummy_xlate($800294f0)
DEBUG: MMU: 0a la=801769C8 SSW=0301 read=0 size=4 fc=1 pc=80029574
ob=00000000
DEBUG: 42b9 CLR.L
DEBUG:
DEBUG: MMU: 0b la=7201B280 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
CPU: 0 PID: 1 Comm: sh Not tainted 5.6.0hatari-g515609e7b #3
Stack from 00821de8:
00821de8 002d0816 00821e14 0002777e 0000000b 000000ff 400004d8
0002ff16
0081ea50 00820000 00824d30 00821e54 00028f82 002ca018 0000000b
0000000b
00000001 400004d8 0002ff16 0002dd80 00823af8 00821f18 00821f2c
00824d30
00000000 00000000 000000cd 00821e64 00029554 0000000b 0000000a
00821e9c
00030882 0000000b 00000000 00000002 00000000 00000000 00000000
8017705e
00821f78 00821f18 00820000 00823a30 00821f78 00821f50 000041da
00821f18
Call Trace: [<0002777e>] panic+0xc2/0x27e
[<0002ff16>] do_signal_stop+0x0/0x14c
[<00028f82>] do_exit+0x126/0x676
[<0002ff16>] do_signal_stop+0x0/0x14c
[<0002dd80>] __list_del_entry+0x0/0x2c
[<00029554>] do_group_exit+0x4c/0x84
[<00030882>] get_signal+0x104/0x464
[<000041da>] do_notify_resume+0x32/0x460
[<00005cc4>] send_fault_sig+0x28/0x8c
[<00005ec6>] do_page_fault+0x19e/0x204
[<00002ac8>] do_signal_return+0x10/0x1a
[<00020007>] _I_CALL_TOP+0x6b7/0x1900
[<0000b280>] mul_srcd+0x10/0x1c
[<00007201>] atari_mste_hwclk+0x24b/0x2ba
[<000066f6>] get_pointer_table+0x104/0x16a
------------------------------------------------
Panic when running /init directly on boot:
------------------------------------------------
Call Trace: [<0002777e>] panic+0xc2/0x27e
[<0002ff16>] do_signal_stop+0x0/0x14c
[<00028f82>] do_exit+0x126/0x676
[<0002ff16>] do_signal_stop+0x0/0x14c
[<0002dd80>] __list_del_entry+0x0/0x2c
[<00029554>] do_group_exit+0x4c/0x84
[<00030882>] get_signal+0x104/0x464
[<000041da>] do_notify_resume+0x32/0x460
[<00005cc4>] send_fault_sig+0x28/0x8c
[<00005ec6>] do_page_fault+0x19e/0x204
[<00002ac8>] do_signal_return+0x10/0x1a
[<00020007>] _I_CALL_TOP+0x6b7/0x1900
[<0000b280>] mul_srcd+0x10/0x1c
[<00007201>] atari_mste_hwclk+0x24b/0x2ba
[<000066f6>] get_pointer_table+0x104/0x16a
------------------------------------------------
mul_srcd() is odd, as it's from:
https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/tree/arch/m68k/fpsp040/res_func.S?h=for-v5.7
Although I'm running this with Falcon i.e. 030.
Hatari profiler's backtrace to panic is:
------------------------------------------------
- 1. 0x0276bc: do_exit -0x17a0 (panic +0x0)
- 2. 0x02954e: do_group_exit +0x46
- 3. 0x03087c: get_signal +0xfe
- 4. 0x0041d4: do_notify_resume +0x2c
- 5. 0x002ac2: system_call +0xaa (do_signal_return +0xa)
- 6. 0x800294b6: system_call -0x7ffd9562 (_end +0x7fce84b6)
- 7. 0x80002482: system_call +0x7ffffa6a (_end +0x7fcc1482)
....
- 96. 0x80002482: system_call +0x7ffffa6a (_end +0x7fcc1482)
- 97. 0x80002482: system_call +0x7ffffa6a (_end +0x7fcc1482)
- 98. 0x80002482: schedule +0x7fdaecce (_end +0x7fcc1482)
- 99. 0x03667e: __schedule -0x21ce7a (worker_thread +0x264)
- 100. 0x2538a2: schedule_idle +0x3a
- 101. 0x04053a: do_idle +0x38
- 102. 0x04074e: cpu_startup_entry +0x10
- 103. 0x25235e: rest_init +0x76
- 104. 0x325ed0: start_kernel -0x32 (parse_early_param +0x4a)
------------------------------------------------
Which doesn't show the page fault thing between
do_signal_return() and do_notify_resume(). This
may mean that there's some funky stack
return address manipulation which confuses Hatari
call chain tracking, like the user space system
call handling.
- Eero