Xaaes crashes ( Illegal Instruction) on stock Atari ST when using CBHD driver

[EmmanuelKasper]

I am trying to build a ready to use diskimage of FreeMint for the Atari ST [1]

Using the build freemint-1-19-2a8-000-st_ste.zip, the loading of xaaes crashes with the following error, using the Video Mode 4 ( ST High)
https://pbs.twimg.com/media/EGCi0hIWsAARI0F?format=jpg

I made a copy of the disk image with dd, and it's working fine with Hatari, booting to the teradesk desktop, so I am puzzled.

A copy of the disk image used is available here:
http://www.subsole.org/static/retrocomputing/stmint-broken.zip

Any pointers of what should I investigate ?

[1] http://www.subsole.org/st_mint

[th-otto]

No idea currently. But i can confirm that the image boots normally both with Hatari and Aranym.

[vinz6751]

Hi all, I confirm I have the same problem on my STE with TOS 1.62 and 2.06 with UltraSatan, it was the same with 1.18.0. I had a look at the boot process from XAAES from 1.19 and I had the vague impression that it might not try to load the kernel module with the correct name, but I had no way to verify it. Btw oAESis is usable on the ST and compiles with PureC. Vincent Le 04/10/2019 à 16:17, Emmanuel Kasper a écrit :

…

I am trying to build a ready to use diskimage of FreeMint for the Atari ST [1] Using the build freemint-1-19-2a8-000-st_ste.zip, the loading of xaaes crashes with the following error: https://pbs.twimg.com/media/EGCi0hIWsAARI0F?format=jpg I made a copy of the disk image with dd, and it's working fine with Hatari, booting to the teradesk desktop, so I am puzzled. A copy of the disk image used is available here: http://www.subsole.org/static/retrocomputing/stmint-broken.zip Any pointers of what should I investigate ? [1] http://www.subsole.org/st_mint — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#127?email_source=notifications&email_token=ACJCL27HSO3JK3WAGXAT7ZDQM5GALA5CNFSM4I5QMGAKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HPWBGNQ>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACJCL26K655KE2WAJORSBALQM5GALANCNFSM4I5QMGAA>.

[th-otto]

First i had the same idea, that some program might have slipped in which was not compiled for plain 68k. On Aranym, you won't notice that, since it always emulates a 68040, but with Hatari you should theoretically get the same error.

Also a bit strange: in your screenshot, the reported PC is below the BP of the current process. That seems to indicate that one of the drivers causes the problem. Could you maybe try to deactive them?

[EmmanuelKasper]

@th-otto you poked it at the issue right, the CBHD hard disk driver is causing the crash.
The same Freemint install using AHDI or PP driver boots fine Xaaes and Teradesk.
Closing as we might here have a bug with Hatari, but not with Freemint.

PS:

the reported PC is below the BP of the current process.
I suppose here you're talking about the memory addresses and that means in hex, 1DA846 < 266C00 ?
What is PC actually ?
I only know high level programming languages :/

[th-otto]

Yes, PC means program-counter, the address of the instruction that caused the crash.

If you don't mind i'll forward this to the Hatari list, since it should have crashed there, too.

[EmmanuelKasper]

You're right, forwarding to the Hatari folks make sense.

[czietz]

Shouldn't this still be investigated here? I mean, obviously the crash is within the memory of the XaAES kernel module (more precisely: in its DATA segment). If it crashes on real hardware, there still might very well be an actual bug in XaAES.

That it does not crash in Hatari could be a secondary bug, but one should still find out in the first place why it does crash on real HW.

[czietz]

Preliminary result of my investigation. I'll call it a day, now. Maybe someone else wants to continue.

xaaes.km fails in this line:

freemint/xaaes/src.km/init.c

Line 438 in ec4a03b

get_drive_and_path(start_path, sizeof(start_path));

. This is because there are just 0x00 bytes at the memory location where the function get_drive_and_path is supposed to be. Therefore, the CPU executes from there until it happens to find some bytes that aren't a valid opcode. This then is in the DATA segment where you actually observe the crash.

So, xaaes.km isn't fully loaded into memory. Whether this is a bug in CBHD or in the FreeMiNT kernel I don't yet know.

[EmmanuelKasper]

Reopening the issue since it looks like there is more to say here :)
Congrats czietsz for the debugging !
Now I am wondering, could this be caused by the xhdi implementation in the cbdh driver ?
The two working disk drivers I tested with Freemint (ahdi and pp driver) do not support xhdi. Maybe the XHDI in CBHD is buggy ? I remember seeing a message like kern version rejected after Freemint has inspected the xhdi support from the hard disk driver.

[czietz]

Indeed it's CBHD that is to blame here. Further analysis shows:

• xaaes.km is quite big and FreeMinT wants to load most of it in one big chunk. This results in an XHDI read operation for over 1000 sectors. There's nothing wrong with that.
• CBHD directly translates that XHDI call into a single ACSI/SCSI READ10 command (for ICD-compatible host adapters) to read all sectors in one go, as well.
• However, CBHD does not take into account that the ST's DMA sector count register only allows for max. 255 sectors to be transferred in one DMA operation. CBHD writes the number of sectors (ca. 1000) into that register and the HW only transfers part of it.
• It works on Hatari, because Hatari uses the number of sectors specified in the ACSI/SCSI command to transfer data and does not use the DMA sector count register:
  https://git.tuxfamily.org/hatari/hatari.git/tree/src/hdc.c?id=v2.2.1#n519
  https://git.tuxfamily.org/hatari/hatari.git/tree/src/hdc.c?id=v2.2.1#n1053

I don't think a work-around in FreeMiNT (detecting CBHD and splitting XHDI calls) is sensible. Since CBHD itself is not open-source, afaik, there's no easy fix possible there, either.

Sorry, switching to another HD driver is probably the best solution here.

[vinriviere]

Brilliant.

[czietz]

PS: Another detail I found out after being asked on the Hatari list: This only happens when using XHDI, not when using the Rwabs BIOS call. If one can force either CBHD or FreeMiNT not to use XHDI, the image should work.

[czietz]

PPS: Please try this crude hack that makes CBHD create a deliberately misspelled YHDI cookie so that FreeMiNT won't use XHDI calls but BIOS calls:
CBHD-patched.zip