Re: [Qemu-devel] Re: sparc esp NetBSD-guest "sd3: mode sense (4) returned nonsense"

[Blue Swirl <blauwirbel@gmail.com>]

On Mon, Sep 14, 2009 at 7:47 PM, Artyom Tarasenko
<atar4qemu@googlemail.com> wrote:
> 2009/9/14 Blue Swirl <blauwirbel@gmail.com>:
>> On Mon, Sep 14, 2009 at 7:29 PM, Artyom Tarasenko
>> <atar4qemu@googlemail.com> wrote:
>>> 2009/9/14 Blue Swirl <blauwirbel@gmail.com>:
>>>> On Mon, Sep 14, 2009 at 12:32 AM, Artyom Tarasenko
>>>> <atar4qemu@googlemail.com> wrote:
>>>>> From NetBSD source, it looks like HDD geometry detection should work
>>>>> under qemu: they call "mode sense" and "read capacity", and both
>>>>> commands are implemented in qemu's hw/scsi-disk.h. It doesn't work
>>>>> though, so NetBSD has to fabricate a disk geometry.
>>>>>
>>>>> To make debugging easier I tried to boot an older version - NetBSD
>>>>> 1.3.3. And put some extra debugging in esp.c:
>>>>>
>>>>> static uint32_t get_cmd(ESPState *s, uint8_t *buf)
>>>>> {
>>>>>    uint32_t dmalen;
>>>>>    int target;
>>>>>
>>>>>    target = s->wregs[ESP_WBUSID] & BUSID_DID;
>>>>>    if (s->dma) {
>>>>>        dmalen = s->rregs[ESP_TCLO] | (s->rregs[ESP_TCMID] << 8);
>>>>>        s->dma_memory_read(s->dma_opaque, buf, dmalen);
>>>>>    } else {
>>>>>        dmalen = s->ti_size;
>>>>>        memcpy(buf, s->ti_buf, dmalen);
>>>>> printf("NON-DMA rptr %d, wptr %d %2x (0) %2x %2x %2x %2x\n",
>>>>> s->ti_rptr, s-> ti_wptr, buf[0],buf[1], buf[2],buf[3], buf[4]);
>>>>>        buf[0] = 0;
>>>>>    }
>>>>>
>>>>> qemu-system-sparc -M SS-20 -nographic  -hda ~/sparc/miniroot-133.fs -m 64
>>>>> ...
>>>>> NON-DMA rptr 0, wptr 1 c0 (0)  0  0 1a  0
>>>>> Set ATN & Stop: cmdlen 3
>>>>> scsi-disk: Command: lun=0 tag=0x0 data=0x00 0x00 0x1a 0x00 0x04 0x00
>>>>> scsi-disk: Test Unit Ready
>>>>> scsi-disk: Command complete tag=0x0 status=0 sense=0
>>>>> sd3: mode sense (4) returned nonsense; using fictitious geometry
>>>>>
>>>>>
>>>>> NetBSD sent command "0x1a" via Set ATN & Stop, but it for some reason
>>>>> the command got padded and disk got "0x0 0x0 0x1a", no wonder that its
>>>>> output looks like a non-sense to NetBSD.
>>>>>
>>>>> Any ideas why does it happen?
>>>>>
>>>>
>>>> The problem could be in the DMA (sparc32_dma.c), or incorrect
>>>> programming of DMA or IOMMU DVMA by NetBSD, (or bug in iommu.c).
>>>
>>> Why DMA? It hits the else branch of "if (s->dma)". Does the command
>>> still get in via DMA?
>>
>> Sorry, I missed that. But is the response also read without DMA?
>>
>
> You mean the disk's response? It doesn't matter, because the disk just
> doesn't get the command.

Ah, I see. What about FIFO state then, perhaps there are some leftover
bytes (0, 0 could be status + sense?) from the previous command in the
buffer before the command is written there?