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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

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