| Re: [hatari-devel] TT emulation crashes when there is no ACSI drive |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On 8/5/19 7:24 PM, Uwe Seimet wrote:
I'm afraid I do not have enough time to check all this. Hope some of the
answers below help.
Does the issue happen even when there's no NF_SCSIDEV available?
If yes, could you provide the binary, so that we can test it too?
Note that the binary and the sources are available on
https://www.hddriver.net/en/downloads.html. Can you reproduce the issue
with it? Please also see my attached Hatari config.
I can't reproduce the crash with the options you're using,
when using latest Hatari Git version (and no SCSI devices):
-------------------------------------
../src/hatari --machine tt --tos tos306uk.img --natfeats on \
--cpu-exact off --compatible off --addr24 off -s 8 --ttram 16 \
--trace os_base,scsidrv nf_scsi.100/
....
GEMDOS 0x4B Pexec(0, "\AUTO\NF_SCSI.PRG", [0]"", 0xe00985) at PC 0xE01436
GEMDOS 0x3D Fopen("\AUTO\NF_SCSI.PRG", read-only) at PC=0xFA00FC
-> FD 64 (read-only -> read-only)
GEMDOS 0x4B Pexec(7, 0x7, 0xe00985, 0xe00985) at PC 0xFA018C
GEMDOS 0x3E Fclose(64) at PC 0xFA0256
scsidrv_interface_version: version=$0102 -> 258
scsidrv_interface_features: busName=Linux Generic SCSI, features=$0002,
transferLen=65536 -> 0
SCSI Driver for Hatari and ARAnyM V1.00
C 2016 Uwe Seimet
GEMDOS 0x31 Ptermres(0xA078, -24456) at PC 0x1001822
GEMDOS 0x4B Pexec(5, 0xe00985, 0xe00985, 0x840) at PC 0xE00938
GEMDOS 0x4B Pexec(4, 0xe00985, 0x1e80e, 0x840) at PC 0xE0095C
GEMDOS 0x4B Pexec(7, 0x7, 0x83a4, 0x0) at PC 0xE1982A
GEMDOS 0x4B Pexec(6, 0x0, 0x100a08a, 0x0) at PC 0xE19866
GEMDOS 0x3D Fopen("NEWDESK.INF", read-only) at PC=0xE25B94
-------------------------------------
Btw. Please don't disable compatible CPU option (prefetch)
unless your PC is so slow that Hatari doesn't work otherwise,
it breaks more things than just disabling cache emulation
(which is only about cycle exactness required for things
like DSP sync).
Other questions:
* What program flags (e.g. FASTLOAD) are set for NF_SCSI.PRG? [1]
This does not matter, it also crashes without the fastload bit being set.
* Does presence of TT-RAM affect the problem? [1]
Yes it does. Without TT-RAM there is no crash.
What about MMU?
* What if you start it from a floppy image instead of from GEMDOS HD?
[1]
As I can't trigger it, please check this too, to see whether
it's GEMDOS HD specific issue.
Please provide console output with tracing from the issue.
* Does the issue happen also with Falcon / TOS v4?
When I tried to switch (in the UI) to TOS 4.04 and Falcon, Hatari crashed:
LSA lib /var/tmp/portage/media-libs/alsa-lib-1.1.8/work/alsa-lib-1.1.8/src/pcm/pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib /var/tmp/portage/media-libs/alsa-lib-1.1.8/work/alsa-lib-1.1.8/src/pcm/pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib /var/tmp/portage/media-libs/alsa-lib-1.1.8/work/alsa-lib-1.1.8/src/pcm/pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib /var/tmp/portage/media-libs/alsa-lib-1.1.8/work/alsa-lib-1.1.8/src/pcm/pcm_route.c:869:(find_matching_chmap) Found no matching channel map
ALSA lib /var/tmp/portage/media-plugins/alsa-plugins-1.1.8/work/alsa-plugins-1.1.8/usb_stream/pcm_usb_stream.c:486:(_snd_pcm_usb_stream_open) Invalid type for card
ALSA lib /var/tmp/portage/media-plugins/alsa-plugins-1.1.8/work/alsa-plugins-1.1.8/usb_stream/pcm_usb_stream.c:486:(_snd_pcm_usb_stream_open) Invalid type for card
hatari: /var/tmp/portage/media-libs/portaudio-19.06.00-r1/work/portaudio/src/hostapi/alsa/pa_linux_alsa.c:3636: PaAlsaStreamComponent_BeginPolling: Assertion `ret == self->nfds' failed.
That's not a Hatari bug, but a bug in your Gentoo installation.
Having ALSA pulseaudio plugin without Pulseaudio present isn't a working
setup.
* Which TOS version you're using with TT, EmuTOS or TOS 3.x? [1]
Plain TOS 3.0.6. Also see my attached configuration.
Please try also EmuTOS. As it happens only from AUTO, it could be
something TOS version related.
- Eero
Still, with Hatari 2.2 (instead of 2.2.1) and with Aranym there is no
> such issue.
According to your earlier mail, 2.2.1 worked also fine:
"This may be due to a recent change, but the only thing I can say is
that there was no such issue with a Hatari 2.2.1 version I compiled
in February."
After 2.2.x, I think there have been only following potentially
relevant changes:
* Support FASTLOAD program flag with GEMDOS HD (Thomas) [1]
* Support for TT MFP (Nicolas)
[1] My current guess is that it's something related to FASTLOAD.
- Eero
Hi,
I can reproduce this again, I just forgot to disabled ACSI drives the
last time.
Hatari crashes with the SCSI Driver for Linux (see
https://www.hddriver.net/en/downloads.html). Note that this was not the
case with Hatari in the past, and there is also no crash with Aranym.
Take care
Uwe
Hi,
I'm afraid I could reproduce the crash this morning, but not this
afternoon :-(.
Has this issue been addresse in any way since I reported it. When I
reported it as far as I can tell, it was quite clear which changes might
have caused this issue.
Best regards
Uwe
Did you ever find out *which* of your AUTO folder programs is causing
the crash? I guess, otherwise the Hatari developers won't be able to
figure out the problem.
Regards
Christian
Uwe Seimet schrieb:
Hi all,
Any news on this?
Best regards
Uwe
Hi Thomas,
Uwe, I can not reproduce that crash here. Your crash information
contained "PC=$fa005c" ... that's in the cartridge space... Are you
using a GEMDOS drive? With AUTO folder? If so, could you temporarily
rename the AUTO folder, to see whether it makes a difference? If not,
disable the GEMDOS drive?
Or are you maybe using an extended VDI resolution? If so, does the
crash go away when you disable it?
If that all does not help, could you please send your hatari.cfg file
and the exact parameters that you use to run Hatari?
Yes, I'm using a GEMDOS drive with AUTO folder. After renaming the AUTO
folder there is no crash anymore.
Best regards
Uwe