qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [patch] fix scsi-generic


From: adq
Subject: [Qemu-devel] Re: [patch] fix scsi-generic
Date: Sat, 7 Aug 2010 03:03:39 +0100

On 7 August 2010 02:50, adq <address@hidden> wrote:
> On 7 August 2010 01:55, adq <address@hidden> wrote:
>> Hi, I've been tracking down why scsi generic devices (using SG_IO)
>> don't work any more. After adding debug, I can see that it actually
>> submits the scsi CDB in hw/scsi-generic.c/execute_command(), but that
>> the hw/scsi-generic.c/scsi_read_complete() callback is never called.
>>
>> This is because these are done with ioctls, and the posix async ioctl
>> code is, I think, broken right now. Some more debugging, led me to
>> posix-aio-compat.c/posix_aio_process_queue():
>>
>>            if (acb->async_context_id != async_context_id) {
>>
>> The async_context_ids don't match, so the request is never handled.
>> This is because the acb->async_context_id field is not initialised in
>> posix-aio-compat.c/paio_ioctl() (compare with
>> posix-aio-compat.c/paio_submit()). The attached patch adds the missing
>> line in.
>>
>> This seems to fix the problem. Of course, /now/ I'm getting other
>> weird problems (as I'm trying to see if I can get slysoft anydvd
>> working in a KVM winXP vm), but they need further investigation and
>> likely other fixes.
>>
>> Please forgive me if I'm mistaken in this, I've only just started
>> looking at the qemu code.
>
> Hi, after further investigation, I can generate the "weird problem"
> just from vanilla winxp. I'm using an lsi53c895a virtual SCSI device
> BTW.
>
> You can generate it by setting up a scsi generic cdrom, right clicking
> on the cd/dvd device in winxp, click properties, hardware, select the
> device from the list, and then choose Properties. Qemu will crash
> instantly with the following debug from the emulated LSI code:
>
> [snip]
> lsi_scsi: Compare phase 1 == 7
> lsi_scsi: Control condition failed
> lsi_scsi: SCRIPTS dsp=f2022658 opcode 80880000 arg 00000414
> lsi_scsi: Jump to 0xf2022a74
> lsi_scsi: SCRIPTS dsp=f2022a74 opcode 58000008 arg 00000000
> lsi_scsi: Set ATN
> lsi_scsi: SCRIPTS dsp=f2022a7c opcode 60000040 arg 00000000
> lsi_scsi: Clear ACK
> lsi_scsi: SCRIPTS dsp=f2022a84 opcode 9e030000 arg 0000ff08
> lsi_scsi: Compare phase 6 != 6
> lsi_scsi: Control condition failed
> lsi_scsi: SCRIPTS dsp=f2022a8c opcode 7c027f00 arg 00000000
> lsi_scsi: Read-Modify-Write reg 0x2 AND data8=0x7f sfbr=0x00
> lsi_scsi: Read reg 2
> lsi_scsi: Write reg 2 = 00
> lsi_scsi: SCRIPTS dsp=f2022a94 opcode 0e000001 arg f2022cc0
> lsi_scsi: MSG out len=1
> lsi_scsi: error: Unimplemented message 0x0c
>
> At this point it crashes.
>
> 0xc seems to be the SCSI BUS DEVICE RESET message.. can anyone shed
> any light on what is going wrong here?
>

Ah, just spotted that when you enable LSI_DEBUG, the BADF() macro has
an implicit exit() in it. Ok, disabling that, gives me the real cause
of the crash I'm seeing:

lsi_scsi: SCRIPTS dsp=f20229bc opcode 60000048 arg 00000000
lsi_scsi: Clear ATN ACK
lsi_scsi: SCRIPTS dsp=f20229c4 opcode 818b0000 arg fffffc4c
lsi_scsi: Compare phase 2 == 1
lsi_scsi: Control condition failed
lsi_scsi: SCRIPTS dsp=f20229cc opcode 808a0000 arg fffffc44
lsi_scsi: Compare phase 2 == 0
lsi_scsi: Control condition failed
lsi_scsi: SCRIPTS dsp=f20229d4 opcode 828a0000 arg fffffc0c
lsi_scsi: Compare phase 2 == 2
lsi_scsi: Jump to 0xf20225e8
lsi_scsi: SCRIPTS dsp=f20225e8 opcode 1a000000 arg 00000020
lsi_scsi: Send command len=524288
qemu: /root/qemu-kvm/src/qemu-kvm-0.12.5/hw/lsi53c895a.c:713:
lsi_do_command: Assertion `s->current == ((void *)0)' failed.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]