lsi53c895a assert with AmigaOS

lsi53c895a assert with AmigaOS

[BALATON Zoltan]

Hello,

AmigaOS4 also has a driver for this card so I've tried to test it but it 
trips an assert. Does anybody have an idea why and how it could be fixed? 
Sven's recent patches don't seem to have an effect on this, it still 
happens shortly after it tries to access the SCSI device with those 
patches applied. (Unfortunately AmigaOS is not freely available so it's a 
bit hard to reproduce but I can do tests if needed.) I got the following 
traces:

lsi_reg_write Write reg SIEN0 0x40 = 0x84
lsi_reg_write Write reg SIEN1 0x41 = 0x04
lsi_reg_write Write reg DIEN 0x39 = 0xff
lsi_reg_write Write reg DSP0 0x2c = 0x00
lsi_reg_write Write reg DSP1 0x2d = 0x80
lsi_reg_write Write reg DSP2 0x2e = 0x19
lsi_reg_write Write reg DSP3 0x2f = 0x00
lsi_execute_script SCRIPTS dsp=0x198000 opcode 0x7c07fe00 arg 0x0
lsi_execute_script_io_opcode Read-Modify-Write reg 0x7 AND data8=0xfe sfbr=0x01
lsi_reg_read Read reg GPREG 0x7 = 0x7f
lsi_reg_write Write reg GPREG 0x7 = 0x7e
lsi_execute_script SCRIPTS dsp=0x198008 opcode 0x60000200 arg 0x0
lsi_execute_script_io_clear Clear TM
lsi_execute_script SCRIPTS dsp=0x198010 opcode 0x40000000 arg 0x198208
lsi_execute_script_io_alreadyreselected Already reselected, jumping to alternative address
lsi_execute_script SCRIPTS dsp=0x198208 opcode 0x800a0000 arg 0x1982e0
lsi_execute_script_tc_compp Compare phase MSGIN == DOUT
lsi_execute_script_tc_cc_failed Control condition failed
lsi_execute_script SCRIPTS dsp=0x198210 opcode 0x810a0000 arg 0x198280
lsi_execute_script_tc_compp Compare phase MSGIN == DIN
lsi_execute_script_tc_cc_failed Control condition failed
lsi_execute_script SCRIPTS dsp=0x198218 opcode 0x830a0000 arg 0x198340
lsi_execute_script_tc_compp Compare phase MSGIN == STATUS
lsi_execute_script_tc_cc_failed Control condition failed
lsi_execute_script SCRIPTS dsp=0x198220 opcode 0x820a0000 arg 0x1981f8
lsi_execute_script_tc_compp Compare phase MSGIN == CMD
lsi_execute_script_tc_cc_failed Control condition failed
lsi_execute_script SCRIPTS dsp=0x198228 opcode 0x860a0000 arg 0x198060
lsi_execute_script_tc_compp Compare phase MSGIN == MSGOUT
lsi_execute_script_tc_cc_failed Control condition failed
lsi_execute_script SCRIPTS dsp=0x198230 opcode 0x870a0000 arg 0x1980c0
lsi_execute_script_tc_compp Compare phase MSGIN == MSGIN
lsi_execute_script_tc_jump Jump to 0x1980c0
lsi_execute_script SCRIPTS dsp=0x1980c0 opcode 0xf000001 arg 0x199040
lsi_do_msgin Message in len=1 2
lsi_execute_script SCRIPTS dsp=0x1980c8 opcode 0x800c0000 arg 0x198398
lsi_execute_script_tc_compd Compare data 0x0 & 0xff == 0x0
lsi_execute_script_tc_jump Jump to 0x198398
lsi_execute_script SCRIPTS dsp=0x198398 opcode 0x7c027f00 arg 0x0
lsi_execute_script_io_opcode Read-Modify-Write reg 0x2 AND data8=0x7f sfbr=0x00
lsi_reg_read Read reg SCNTL2 0x2 = 0x00
lsi_reg_write Write reg SCNTL2 0x2 = 0x00
lsi_execute_script SCRIPTS dsp=0x1983a0 opcode 0x60000048 arg 0x0
lsi_execute_script_io_clear Clear ATN ACK
lsi_execute_script SCRIPTS dsp=0x1983a8 opcode 0x48000000 arg 0x0
lsi_execute_script_io_disconnect Wait Disconnect
lsi_execute_script SCRIPTS dsp=0x1983b0 opcode 0x7a070100 arg 0x0
lsi_execute_script_io_opcode Read-Modify-Write reg 0x7 OR data8=0x01 sfbr=0x00
lsi_reg_read Read reg GPREG 0x7 = 0x7f
lsi_reg_write Write reg GPREG 0x7 = 0x7f
lsi_execute_script SCRIPTS dsp=0x1983b8 opcode 0x98080000 arg 0x10
lsi_execute_script_tc_interrupt Interrupt 0x10
lsi_script_dma_interrupt DMA Interrupt 0x4 prev 0x0
lsi_update_irq Update IRQ level 1 dstat 0x04 sist 0x000x00
lsi_execute_script_stop SCRIPTS execution stopped
lsi_reg_read Read reg ISTAT 0x14 = 0x01
lsi_update_irq Update IRQ level 0 dstat 0x00 sist 0x000x00
lsi_reg_read Read reg DSTAT 0xc = 0x84
lsi_reg_read Read reg DSPS0 0x30 = 0x10
lsi_reg_read Read reg DSPS1 0x31 = 0x00
lsi_reg_read Read reg DSPS2 0x32 = 0x00
lsi_reg_read Read reg DSPS3 0x33 = 0x00
lsi_reg_write Write reg SIEN0 0x40 = 0x84
lsi_reg_write Write reg SIEN1 0x41 = 0x04
lsi_reg_write Write reg DIEN 0x39 = 0xff
lsi_reg_write Write reg DSP0 0x2c = 0x00
lsi_reg_write Write reg DSP1 0x2d = 0x80
lsi_reg_write Write reg DSP2 0x2e = 0x19
lsi_reg_write Write reg DSP3 0x2f = 0x00
lsi_execute_script SCRIPTS dsp=0x198000 opcode 0x7c07fe00 arg 0x0
lsi_execute_script_io_opcode Read-Modify-Write reg 0x7 AND data8=0xfe sfbr=0x00
lsi_reg_read Read reg GPREG 0x7 = 0x7f
lsi_reg_write Write reg GPREG 0x7 = 0x7e
lsi_execute_script SCRIPTS dsp=0x198008 opcode 0x60000200 arg 0x0
lsi_execute_script_io_clear Clear TM
lsi_execute_script SCRIPTS dsp=0x198010 opcode 0x40000000 arg 0x198208
lsi_execute_script_io_selected Selected target 0
lsi_execute_script SCRIPTS dsp=0x198018 opcode 0x80080000 arg 0x1981f8
lsi_execute_script_tc_jump Jump to 0x1981f8
lsi_execute_script SCRIPTS dsp=0x1981f8 opcode 0xa000006 arg 0x199000
lsi_execute_script_blockmove_badphase Wrong phase got MSGOUT expected CMD
lsi_script_scsi_interrupt SCSI Interrupt 0x000x80 prev 0x000x00
lsi_update_irq Update IRQ level 1 dstat 0x00 sist 0x000x80
lsi_execute_script_stop SCRIPTS execution stopped
lsi_reg_read Read reg ISTAT 0x14 = 0x02
lsi_reg_read Read reg SIST1 0x43 = 0x00
lsi_update_irq Update IRQ level 0 dstat 0x00 sist 0x000x00
lsi_reg_read Read reg SIST0 0x42 = 0x80
lsi_reg_read Read reg DSTAT 0xc = 0x80
lsi_reg_read Read reg DBC0 0x24 = 0x06
lsi_reg_read Read reg DBC1 0x25 = 0x00
lsi_reg_read Read reg DBC2 0x26 = 0x00
lsi_reg_write Write reg DSP0 0x2c = 0x08
lsi_reg_write Write reg DSP1 0x2d = 0x82
lsi_reg_write Write reg DSP2 0x2e = 0x19
lsi_reg_write Write reg DSP3 0x2f = 0x00
lsi_execute_script SCRIPTS dsp=0x198208 opcode 0x800a0000 arg 0x1982e0
lsi_execute_script_tc_compp Compare phase MSGOUT == DOUT
lsi_execute_script_tc_cc_failed Control condition failed
lsi_execute_script SCRIPTS dsp=0x198210 opcode 0x810a0000 arg 0x198280
lsi_execute_script_tc_compp Compare phase MSGOUT == DIN
lsi_execute_script_tc_cc_failed Control condition failed
lsi_execute_script SCRIPTS dsp=0x198218 opcode 0x830a0000 arg 0x198340
lsi_execute_script_tc_compp Compare phase MSGOUT == STATUS
lsi_execute_script_tc_cc_failed Control condition failed
lsi_execute_script SCRIPTS dsp=0x198220 opcode 0x820a0000 arg 0x1981f8
lsi_execute_script_tc_compp Compare phase MSGOUT == CMD
lsi_execute_script_tc_cc_failed Control condition failed
lsi_execute_script SCRIPTS dsp=0x198228 opcode 0x860a0000 arg 0x198060
lsi_execute_script_tc_compp Compare phase MSGOUT == MSGOUT
lsi_execute_script_tc_jump Jump to 0x198060
lsi_execute_script SCRIPTS dsp=0x198060 opcode 0x9e030000 arg 0x1000000
lsi_execute_script_tc_compp Compare phase MSGOUT != MSGOUT
lsi_execute_script_tc_cc_failed Control condition failed
lsi_execute_script SCRIPTS dsp=0x198068 opcode 0xe000001 arg 0x199020
lsi_do_msgout MSG out len=1
lsi_do_msgout: msg = c0
lsi_do_msgout_select Select LUN 0
lsi_execute_script SCRIPTS dsp=0x198070 opcode 0x820b0000 arg 0x1981f8
lsi_execute_script_tc_compp Compare phase CMD == CMD
lsi_execute_script_tc_jump Jump to 0x1981f8
lsi_execute_script SCRIPTS dsp=0x1981f8 opcode 0xa000006 arg 0x199000
lsi_do_command Send command len=6
qemu-system-ppc: ../hw/scsi/lsi53c895a.c:863: lsi_do_command: Assertion `s->current == NULL' failed.

Any idea what could it be and what could be done about it?

Regards,
BALATON Zoltan

Re: lsi53c895a assert with AmigaOS

[Sven Schnelle]

BALATON Zoltan <balaton@eik.bme.hu> writes:

> AmigaOS4 also has a driver for this card so I've tried to test it but
> it trips an assert. Does anybody have an idea why and how it could be
> fixed? Sven's recent patches don't seem to have an effect on this, it
> still happens shortly after it tries to access the SCSI device with
> those patches applied. (Unfortunately AmigaOS is not freely available
> so it's a bit hard to reproduce but I can do tests if needed.) I got
> the following traces:
> [..]
> lsi_do_command Send command len=6
> qemu-system-ppc: ../hw/scsi/lsi53c895a.c:863: lsi_do_command: Assertion `s->current == NULL' failed.
>
> Any idea what could it be and what could be done about it?

I think the Host is resetting the SCSI controller while it still has
some request pending. I made a hack to work around that bug, but so
far i haven't spent the time to verify whether it's correct or whether
there are additional changes required. Here it is:

From 6a807653679fde5e3e09a7f27576c673f335fef6 Mon Sep 17 00:00:00 2001
From: Sven Schnelle <svens@stackframe.org>
Date: Sat, 3 Feb 2024 19:46:07 +0100
Subject: [PATCH] lsi53c895a: free pending requests on reset

Signed-off-by: Sven Schnelle <svens@stackframe.org>
---
 hw/scsi/lsi53c895a.c | 16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/hw/scsi/lsi53c895a.c b/hw/scsi/lsi53c895a.c
index d607a5f9fb..c6bd801a7e 100644
--- a/hw/scsi/lsi53c895a.c
+++ b/hw/scsi/lsi53c895a.c
@@ -346,6 +346,8 @@ static lsi_request *get_pending_req(LSIState *s)
 
 static void lsi_soft_reset(LSIState *s)
 {
+    lsi_request *p, *p_next;
+
     trace_lsi_reset();
     s->carry = 0;
 
@@ -413,8 +415,14 @@ static void lsi_soft_reset(LSIState *s)
     s->sbc = 0;
     s->csbc = 0;
     s->sbr = 0;
-    assert(QTAILQ_EMPTY(&s->queue));
-    assert(!s->current);
+
+    QTAILQ_FOREACH_SAFE(p, &s->queue, next, p_next) {
+        scsi_req_cancel(p->req);
+    }
+
+    if (s->current)
+        scsi_req_cancel(s->current->req);
+    s->current = NULL;
 }
 
 static int lsi_dma_40bit(LSIState *s)
@@ -860,7 +868,9 @@ static void lsi_do_command(LSIState *s)
         return;
     }
 
-    assert(s->current == NULL);
+    if (s->current)
+        scsi_req_cancel(s->current->req);
+
     s->current = g_new0(lsi_request, 1);
     s->current->tag = s->select_tag;
     s->current->req = scsi_req_new(dev, s->current->tag, s->current_lun, buf,
-- 
2.43.2

Re: lsi53c895a assert with AmigaOS

[BALATON Zoltan]

On Sun, 3 Mar 2024, Sven Schnelle wrote:
> BALATON Zoltan <balaton@eik.bme.hu> writes:
>
>> AmigaOS4 also has a driver for this card so I've tried to test it but
>> it trips an assert. Does anybody have an idea why and how it could be
>> fixed? Sven's recent patches don't seem to have an effect on this, it
>> still happens shortly after it tries to access the SCSI device with
>> those patches applied. (Unfortunately AmigaOS is not freely available
>> so it's a bit hard to reproduce but I can do tests if needed.) I got
>> the following traces:
>> [..]
>> lsi_do_command Send command len=6
>> qemu-system-ppc: ../hw/scsi/lsi53c895a.c:863: lsi_do_command: Assertion `s->current == NULL' failed.
>>
>> Any idea what could it be and what could be done about it?
>
> I think the Host is resetting the SCSI controller while it still has
> some request pending. I made a hack to work around that bug, but so
> far i haven't spent the time to verify whether it's correct or whether
> there are additional changes required. Here it is:

This does avoid the assert and now it boots but then can't read the scsi 
device. (I've tried with a scsi-cd with an iso image and it thinks it's an 
audio CD and cannot read data from it). Maybe something else is needed but 
this seems to go one step further. However I don't see "lsi_reset Reset" 
traces other than once when the driver starts so not sure it's really 
related to reset. Could it be that the driver expects it to be able to 
send commands while another one is still processing so the pending one 
would need to be put back in the queue instead of cancelling ir? But I 
don't know how to do that so cannot try unless you can give me a patch.

Regards,
BALATON Zoltan

> From 6a807653679fde5e3e09a7f27576c673f335fef6 Mon Sep 17 00:00:00 2001
> From: Sven Schnelle <svens@stackframe.org>
> Date: Sat, 3 Feb 2024 19:46:07 +0100
> Subject: [PATCH] lsi53c895a: free pending requests on reset
>
> Signed-off-by: Sven Schnelle <svens@stackframe.org>
> ---
> hw/scsi/lsi53c895a.c | 16 +++++++++++++---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/hw/scsi/lsi53c895a.c b/hw/scsi/lsi53c895a.c
> index d607a5f9fb..c6bd801a7e 100644
> --- a/hw/scsi/lsi53c895a.c
> +++ b/hw/scsi/lsi53c895a.c
> @@ -346,6 +346,8 @@ static lsi_request *get_pending_req(LSIState *s)
>
> static void lsi_soft_reset(LSIState *s)
> {
> +    lsi_request *p, *p_next;
> +
>     trace_lsi_reset();
>     s->carry = 0;
>
> @@ -413,8 +415,14 @@ static void lsi_soft_reset(LSIState *s)
>     s->sbc = 0;
>     s->csbc = 0;
>     s->sbr = 0;
> -    assert(QTAILQ_EMPTY(&s->queue));
> -    assert(!s->current);
> +
> +    QTAILQ_FOREACH_SAFE(p, &s->queue, next, p_next) {
> +        scsi_req_cancel(p->req);
> +    }
> +
> +    if (s->current)
> +        scsi_req_cancel(s->current->req);
> +    s->current = NULL;
> }
>
> static int lsi_dma_40bit(LSIState *s)
> @@ -860,7 +868,9 @@ static void lsi_do_command(LSIState *s)
>         return;
>     }
>
> -    assert(s->current == NULL);
> +    if (s->current)
> +        scsi_req_cancel(s->current->req);
> +
>     s->current = g_new0(lsi_request, 1);
>     s->current->tag = s->select_tag;
>     s->current->req = scsi_req_new(dev, s->current->tag, s->current_lun, buf,
>

Re: lsi53c895a assert with AmigaOS

[BALATON Zoltan]

On Sun, 3 Mar 2024, BALATON Zoltan wrote:
> On Sun, 3 Mar 2024, Sven Schnelle wrote:
>> BALATON Zoltan <balaton@eik.bme.hu> writes:
>> 
>>> AmigaOS4 also has a driver for this card so I've tried to test it but
>>> it trips an assert. Does anybody have an idea why and how it could be
>>> fixed? Sven's recent patches don't seem to have an effect on this, it
>>> still happens shortly after it tries to access the SCSI device with
>>> those patches applied. (Unfortunately AmigaOS is not freely available
>>> so it's a bit hard to reproduce but I can do tests if needed.) I got
>>> the following traces:
>>> [..]
>>> lsi_do_command Send command len=6
>>> qemu-system-ppc: ../hw/scsi/lsi53c895a.c:863: lsi_do_command: Assertion 
>>> `s->current == NULL' failed.
>>> 
>>> Any idea what could it be and what could be done about it?
>> 
>> I think the Host is resetting the SCSI controller while it still has
>> some request pending. I made a hack to work around that bug, but so
>> far i haven't spent the time to verify whether it's correct or whether
>> there are additional changes required. Here it is:
>
> This does avoid the assert and now it boots but then can't read the scsi 
> device. (I've tried with a scsi-cd with an iso image and it thinks it's an 
> audio CD and cannot read data from it). Maybe something else is needed but 
> this seems to go one step further. However I don't see "lsi_reset Reset" 
> traces other than once when the driver starts so not sure it's really related 
> to reset. Could it be that the driver expects it to be able to send commands 
> while another one is still processing so the pending one would need to be put 
> back in the queue instead of cancelling ir? But I don't know how to do that 
> so cannot try unless you can give me a patch.

I've tried this change:

diff --git a/hw/scsi/lsi53c895a.c b/hw/scsi/lsi53c895a.c
index f8598a17f5..6f547c0d33 100644
--- a/hw/scsi/lsi53c895a.c
+++ b/hw/scsi/lsi53c895a.c
@@ -860,7 +860,9 @@ static void lsi_do_command(LSIState *s)
          return;
      }

-    assert(s->current == NULL);
+    if (s->current) {
+        lsi_queue_command(s);
+    }
      s->current = g_new0(lsi_request, 1);
      s->current->tag = s->select_tag;
      s->current->req = scsi_req_new(dev, s->current->tag, s->current_lun, buf,

but then I get:

lsi_do_msgout MSG out len=1
lsi_do_msgout_select Select LUN 0
lsi_execute_script SCRIPTS dsp=0x198070 opcode 0x820b0000 arg 0x1981f8
lsi_execute_script_tc_compp Compare phase CMD == CMD
lsi_execute_script_tc_jump Jump to 0x1981f8
lsi_execute_script SCRIPTS dsp=0x1981f8 opcode 0xa000006 arg 0x199000
lsi_do_command Send command len=6
lsi_queue_command Queueing tag=0x0
qemu-system-ppc: ../hw/scsi/lsi53c895a.c:677: lsi_queue_command: Assertion 
`s->current->dma_len == 0' failed.

So maybe there's some transfer in progress that would need to be finished 
or what to do in this case?

Regards,
BALATON Zoltan

Re: lsi53c895a assert with AmigaOS

[Sven Schnelle]

BALATON Zoltan <balaton@eik.bme.hu> writes:

> Hello,
>
> AmigaOS4 also has a driver for this card so I've tried to test it but
> it trips an assert. Does anybody have an idea why and how it could be
> fixed? Sven's recent patches don't seem to have an effect on this, it
> still happens shortly after it tries to access the SCSI device with
> those patches applied. (Unfortunately AmigaOS is not freely available
> so it's a bit hard to reproduce but I can do tests if needed.) I got
> the following traces:
>
> lsi_reg_write Write reg SIEN0 0x40 = 0x84
> lsi_reg_write Write reg SIEN1 0x41 = 0x04
> lsi_reg_write Write reg DIEN 0x39 = 0xff
> lsi_reg_write Write reg DSP0 0x2c = 0x00
> lsi_reg_write Write reg DSP1 0x2d = 0x80
> lsi_reg_write Write reg DSP2 0x2e = 0x19
> lsi_reg_write Write reg DSP3 0x2f = 0x00
> lsi_execute_script SCRIPTS dsp=0x198000 opcode 0x7c07fe00 arg 0x0
> lsi_execute_script_io_opcode Read-Modify-Write reg 0x7 AND data8=0xfe sfbr=0x01
> lsi_reg_read Read reg GPREG 0x7 = 0x7f
> lsi_reg_write Write reg GPREG 0x7 = 0x7e
> lsi_execute_script SCRIPTS dsp=0x198008 opcode 0x60000200 arg 0x0
> lsi_execute_script_io_clear Clear TM
> lsi_execute_script SCRIPTS dsp=0x198010 opcode 0x40000000 arg 0x198208
> lsi_execute_script_io_alreadyreselected Already reselected, jumping to
> alternative address
here ---^
> lsi_do_msgout_select Select LUN 0
> lsi_execute_script SCRIPTS dsp=0x198070 opcode 0x820b0000 arg 0x1981f8
> lsi_execute_script_tc_compp Compare phase CMD == CMD
> lsi_execute_script_tc_jump Jump to 0x1981f8
> lsi_execute_script SCRIPTS dsp=0x1981f8 opcode 0xa000006 arg 0x199000
> lsi_do_command Send command len=6
> qemu-system-ppc: ../hw/scsi/lsi53c895a.c:863: lsi_do_command: Assertion `s->current == NULL' failed.
>
> Any idea what could it be and what could be done about it?

Wild guess is that this is because of the 'Already reselected' line
above. lsi_reselect() sets s->current, and later when lsi_do_command()
is called it gets confused because s->current is already set. But i
would need the whole logfile to see why this is going wrong, or even
better AmigaOS (which is not free as you already mentioned)

Sven

Re: lsi53c895a assert with AmigaOS

[BALATON Zoltan]

On Sun, 3 Mar 2024, Sven Schnelle wrote:
> BALATON Zoltan <balaton@eik.bme.hu> writes:
>
>> Hello,
>>
>> AmigaOS4 also has a driver for this card so I've tried to test it but
>> it trips an assert. Does anybody have an idea why and how it could be
>> fixed? Sven's recent patches don't seem to have an effect on this, it
>> still happens shortly after it tries to access the SCSI device with
>> those patches applied. (Unfortunately AmigaOS is not freely available
>> so it's a bit hard to reproduce but I can do tests if needed.) I got
>> the following traces:
>>
>> lsi_reg_write Write reg SIEN0 0x40 = 0x84
>> lsi_reg_write Write reg SIEN1 0x41 = 0x04
>> lsi_reg_write Write reg DIEN 0x39 = 0xff
>> lsi_reg_write Write reg DSP0 0x2c = 0x00
>> lsi_reg_write Write reg DSP1 0x2d = 0x80
>> lsi_reg_write Write reg DSP2 0x2e = 0x19
>> lsi_reg_write Write reg DSP3 0x2f = 0x00
>> lsi_execute_script SCRIPTS dsp=0x198000 opcode 0x7c07fe00 arg 0x0
>> lsi_execute_script_io_opcode Read-Modify-Write reg 0x7 AND data8=0xfe sfbr=0x01
>> lsi_reg_read Read reg GPREG 0x7 = 0x7f
>> lsi_reg_write Write reg GPREG 0x7 = 0x7e
>> lsi_execute_script SCRIPTS dsp=0x198008 opcode 0x60000200 arg 0x0
>> lsi_execute_script_io_clear Clear TM
>> lsi_execute_script SCRIPTS dsp=0x198010 opcode 0x40000000 arg 0x198208
>> lsi_execute_script_io_alreadyreselected Already reselected, jumping to
>> alternative address
> here ---^
>> lsi_do_msgout_select Select LUN 0
>> lsi_execute_script SCRIPTS dsp=0x198070 opcode 0x820b0000 arg 0x1981f8
>> lsi_execute_script_tc_compp Compare phase CMD == CMD
>> lsi_execute_script_tc_jump Jump to 0x1981f8
>> lsi_execute_script SCRIPTS dsp=0x1981f8 opcode 0xa000006 arg 0x199000
>> lsi_do_command Send command len=6
>> qemu-system-ppc: ../hw/scsi/lsi53c895a.c:863: lsi_do_command: Assertion `s->current == NULL' failed.
>>
>> Any idea what could it be and what could be done about it?
>
> Wild guess is that this is because of the 'Already reselected' line
> above. lsi_reselect() sets s->current, and later when lsi_do_command()
> is called it gets confused because s->current is already set. But i
> would need the whole logfile to see why this is going wrong, or even
> better AmigaOS (which is not free as you already mentioned)

Thanks for looking at this. I've uploaded the full log here: 
http://zero.eik.bme.hu/~balaton/qemu/aos-lsi-scsi.log.xz
but not sure you'd get more info from it as it seems to be working up to 
the error. This happens short after boot when the driver is started which 
seems to be going OK but when first accessing the device then it runs into 
the error. I don't know how this controller works so can't really tell 
what would be correct behaviour here.

Regards,
BALATON Zoltan

Re: lsi53c895a assert with AmigaOS

[BALATON Zoltan]

On Sun, 3 Mar 2024, BALATON Zoltan wrote:
> On Sun, 3 Mar 2024, Sven Schnelle wrote:
>> BALATON Zoltan <balaton@eik.bme.hu> writes:
>> 
>>> Hello,
>>> 
>>> AmigaOS4 also has a driver for this card so I've tried to test it but
>>> it trips an assert. Does anybody have an idea why and how it could be
>>> fixed? Sven's recent patches don't seem to have an effect on this, it
>>> still happens shortly after it tries to access the SCSI device with
>>> those patches applied. (Unfortunately AmigaOS is not freely available
>>> so it's a bit hard to reproduce but I can do tests if needed.) I got
>>> the following traces:
>>> 
>>> lsi_reg_write Write reg SIEN0 0x40 = 0x84
>>> lsi_reg_write Write reg SIEN1 0x41 = 0x04
>>> lsi_reg_write Write reg DIEN 0x39 = 0xff
>>> lsi_reg_write Write reg DSP0 0x2c = 0x00
>>> lsi_reg_write Write reg DSP1 0x2d = 0x80
>>> lsi_reg_write Write reg DSP2 0x2e = 0x19
>>> lsi_reg_write Write reg DSP3 0x2f = 0x00
>>> lsi_execute_script SCRIPTS dsp=0x198000 opcode 0x7c07fe00 arg 0x0
>>> lsi_execute_script_io_opcode Read-Modify-Write reg 0x7 AND data8=0xfe 
>>> sfbr=0x01
>>> lsi_reg_read Read reg GPREG 0x7 = 0x7f
>>> lsi_reg_write Write reg GPREG 0x7 = 0x7e
>>> lsi_execute_script SCRIPTS dsp=0x198008 opcode 0x60000200 arg 0x0
>>> lsi_execute_script_io_clear Clear TM
>>> lsi_execute_script SCRIPTS dsp=0x198010 opcode 0x40000000 arg 0x198208
>>> lsi_execute_script_io_alreadyreselected Already reselected, jumping to
>>> alternative address
>> here ---^
>>> lsi_do_msgout_select Select LUN 0
>>> lsi_execute_script SCRIPTS dsp=0x198070 opcode 0x820b0000 arg 0x1981f8
>>> lsi_execute_script_tc_compp Compare phase CMD == CMD
>>> lsi_execute_script_tc_jump Jump to 0x1981f8
>>> lsi_execute_script SCRIPTS dsp=0x1981f8 opcode 0xa000006 arg 0x199000
>>> lsi_do_command Send command len=6
>>> qemu-system-ppc: ../hw/scsi/lsi53c895a.c:863: lsi_do_command: Assertion 
>>> `s->current == NULL' failed.
>>> 
>>> Any idea what could it be and what could be done about it?
>> 
>> Wild guess is that this is because of the 'Already reselected' line
>> above. lsi_reselect() sets s->current, and later when lsi_do_command()
>> is called it gets confused because s->current is already set. But i
>> would need the whole logfile to see why this is going wrong, or even
>> better AmigaOS (which is not free as you already mentioned)
>
> Thanks for looking at this. I've uploaded the full log here: 
> http://zero.eik.bme.hu/~balaton/qemu/aos-lsi-scsi.log.xz
> but not sure you'd get more info from it as it seems to be working up to the 
> error. This happens short after boot when the driver is started which seems 
> to be going OK but when first accessing the device then it runs into the 
> error. I don't know how this controller works so can't really tell what would 
> be correct behaviour here.

AFAIU this log it tries to read a sector which completes on the drive side 
but I can't see where this read finishes and maybe the guest tries to send 
another command while it's still running? The read is here:

lsi_execute_script SCRIPTS dsp=0x1981f8 opcode 0xa00000a arg 0x199000
lsi_do_command Send command len=10
scsi_req_parsed target 0 lun 0 tag 0 command 40 dir 1 length 2048
scsi_req_parsed_lba target 0 lun 0 tag 0 command 40 lba 16
scsi_req_alloc target 0 lun 0 tag 0
scsi_disk_new_request Command: lun=0 tag=0x0 data= 0x28 0x00 0x00 0x00 0x00 0x10 0x00 0x00 0x01 0x00
scsi_disk_dma_command_READ Read (sector 16, count 1)
scsi_req_continue target 0 lun 0 tag 0
scsi_disk_read_data_count Read sector_count=4
lsi_add_msg_byte MSG IN 0x02
lsi_add_msg_byte MSG IN 0x04
lsi_queue_command Queueing tag=0x0
lsi_execute_script SCRIPTS dsp=0x198200 opcode 0x870b0000 arg 0x1980c0
lsi_execute_script_tc_compp Compare phase MSGIN == MSGIN
lsi_execute_script_tc_jump Jump to 0x1980c0
lsi_execute_script SCRIPTS dsp=0x1980c0 opcode 0xf000001 arg 0x199040
lsi_do_msgin Message in len=1 2
lsi_execute_script SCRIPTS dsp=0x1980c8 opcode 0x800c0000 arg 0x198398
lsi_execute_script_tc_compd Compare data 0x2 & 0xff == 0x0
lsi_execute_script_tc_cc_failed Control condition failed
lsi_execute_script SCRIPTS dsp=0x1980d0 opcode 0x800c0004 arg 0x198398
lsi_execute_script_tc_compd Compare data 0x2 & 0xff == 0x4
lsi_execute_script_tc_cc_failed Control condition failed
lsi_execute_script SCRIPTS dsp=0x1980d8 opcode 0x800c0002 arg 0x198398
lsi_execute_script_tc_compd Compare data 0x2 & 0xff == 0x2
lsi_execute_script_tc_jump Jump to 0x198398
lsi_execute_script SCRIPTS dsp=0x198398 opcode 0x7c027f00 arg 0x0
lsi_execute_script_io_opcode Read-Modify-Write reg 0x2 AND data8=0x7f sfbr=0x02
lsi_reg_read Read reg SCNTL2 0x2 = 0x00
lsi_reg_write Write reg SCNTL2 0x2 = 0x00
lsi_execute_script SCRIPTS dsp=0x1983a0 opcode 0x60000048 arg 0x0
lsi_execute_script_io_clear Clear ATN ACK
lsi_execute_script SCRIPTS dsp=0x1983a8 opcode 0x48000000 arg 0x0
lsi_execute_script_io_disconnect Wait Disconnect
lsi_execute_script SCRIPTS dsp=0x1983b0 opcode 0x7a070100 arg 0x0
lsi_execute_script_io_opcode Read-Modify-Write reg 0x7 OR data8=0x01 sfbr=0x02
lsi_reg_read Read reg GPREG 0x7 = 0x7f
lsi_reg_write Write reg GPREG 0x7 = 0x7f
lsi_execute_script SCRIPTS dsp=0x1983b8 opcode 0x98080000 arg 0x10
lsi_execute_script_tc_interrupt Interrupt 0x10
lsi_script_dma_interrupt DMA Interrupt 0x4 prev 0x0
lsi_update_irq Update IRQ level 1 dstat 0x04 sist 0x000x00
lsi_execute_script_stop SCRIPTS execution stopped
lsi_reg_read Read reg ISTAT 0x14 = 0x01
lsi_update_irq Update IRQ level 0 dstat 0x00 sist 0x000x00
lsi_reg_read Read reg DSTAT 0xc = 0x84
lsi_reg_read Read reg DSPS0 0x30 = 0x10
lsi_reg_read Read reg DSPS1 0x31 = 0x00
lsi_reg_read Read reg DSPS2 0x32 = 0x00
lsi_reg_read Read reg DSPS3 0x33 = 0x00
scsi_disk_read_complete Data ready tag=0x0 len=2048
scsi_req_data target 0 lun 0 tag 0 len 2048
lsi_queue_req Queueing IO tag=0x0

but I don't see if the guest got the results. How should this transfer end 
and why it does not seem to have reached the guest? After this the guest 
seems to send another command:

lsi_do_command Send command len=6
scsi_req_parsed target 0 lun 0 tag 0 command 0 dir 0 length 0
scsi_req_parsed_lba target 0 lun 0 tag 0 command 0 lba 0
scsi_req_alloc target 0 lun 0 tag 0
scsi_disk_new_request Command: lun=0 tag=0x0 data= 0x00 0x00 0x00 0x00 0x00 0x00
scsi_test_unit_ready target 0 lun 0 tag 0
scsi_req_dequeue target 0 lun 0 tag 0
lsi_command_complete Command complete status=0

which then completes;

lsi_execute_script SCRIPTS dsp=0x1983a0 opcode 0x60000048 arg 0x0
lsi_execute_script_io_clear Clear ATN ACK
lsi_execute_script SCRIPTS dsp=0x1983a8 opcode 0x48000000 arg 0x0
lsi_execute_script_io_disconnect Wait Disconnect
lsi_reselect Reselected target 0
lsi_add_msg_byte MSG IN 0x80

and when it tries to send another command it sees the reselected target:

lsi_execute_script SCRIPTS dsp=0x198008 opcode 0x60000200 arg 0x0
lsi_execute_script_io_clear Clear TM
lsi_execute_script SCRIPTS dsp=0x198010 opcode 0x40000000 arg 0x198208
lsi_execute_script_io_alreadyreselected Already reselected, jumping to alternative address

but this does not yet cause an error, it ends here:

lsi_execute_script SCRIPTS dsp=0x1983a0 opcode 0x60000048 arg 0x0
lsi_execute_script_io_clear Clear ATN ACK
lsi_execute_script SCRIPTS dsp=0x1983a8 opcode 0x48000000 arg 0x0
lsi_execute_script_io_disconnect Wait Disconnect

When the next command is sent it starts normally:

lsi_execute_script SCRIPTS dsp=0x198008 opcode 0x60000200 arg 0x0
lsi_execute_script_io_clear Clear TM
lsi_execute_script SCRIPTS dsp=0x198010 opcode 0x40000000 arg 0x198208
lsi_execute_script_io_selected Selected target 0

but when trying to send the command it gets the assertion. I think the 
first read above should somehow be finished which I don't see in this log 
so it may still be queued at this point. Does this make sense to anybody?

Regards,
BALATON Zoltan