Re: [hatari-devel] Falcon demos tests : part 1 -> IDE segfault

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


Le 01/11/2020 à 07:52, Thomas Huth a écrit :
Am Tue, 27 Oct 2020 22:21:10 +0100
schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:

Le 27/10/2020 à 00:12, Eero Tamminen a écrit :

Motion : no change

"Torus" works now fine.

Only "Susie" doesn't work, it's now stuck
executing these instructions:
    $00016690 : btst   #0,$fffffc00.w    50.00%
    $00016696 : beq.s  $16690            50.00%

Nicolas, any ideas what could be the problem?

Hi

when I try to test this demo, I get a segfault accessing the ide
registers.

I run :
hatari -s 4 --tos tos404.img ~/MOTION/PRECOMPI.LED/SUSIE.PRG

Then hatari crashes after TOS tests the memory at boot.

In my config, I don't have any IDE/ASCI/SCSI drive defined.

This is the backtrace from gdb :

Thread 1 "hatari" received signal SIGSEGV, Segmentation fault.
0x00000000005f6760 in Ide_Mem_bget ()
(gdb) bt
#0  0x00000000005f6760 in Ide_Mem_bget ()
#1  0x0000000000690e74 in wait_cpu_cycle_read_ce020 ()
#2  0x000000000065a487 in mem_access_delay_byte_read_ce020 ()
#3  0x000000000065836d in get_byte_dc030 ()
#4  0x0000000000b8672e in op_4a39_23_ff ()
#5  0x000000000066f5c3 in m68k_run_2ce ()
#6  0x0000000000669ab2 in m68k_go ()
#7  0x00000000005bc998 in main ()

Seems the IDE registers handling is not correctly fixed yet ?

I assume this only happened if the default machine in your hatari.cfg
was not a falcon, and Hatari prompted you with the "TOS version 4.04
is for Atari Falcon only. ==> Switching to Falcon mode now." dialog? At
least that was the only way how I could reproduce a crash with your
command line.

Hi

yes, that's the case, my config stars in STF mode.

The problem is that during the first Ide_Init(), the machine type is
still a non-Falcon machine, so Ide_Init() skips the initialization.
Then the machine type is switched to Falcon mode, but we did not call
Ide_Init() again. Fixed now, at least with a fix that should be good
enough for the next release. In the long run, we should maybe consider
to call Change_CopyChangedParamsToConfiguration() from
TOS_CheckSysConfig() instead, but that's certainly not something I want
to change at this point in time.


Indeed, I think the way some parts are initialiazed at start or when config change is not always straightforward, there can be some case of nearcly circular dependancies. Some functions should be split later to get a better way to do this.

I will try the change later today to check the crash is gone.

Nicolas




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