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

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

[Artyom Tarasenko]

>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?

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

[Blue Swirl]

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). All
my NetBSD <4.0 boot CDs crash because of a NMI from IOMMU (DMA tries
to access a page not in IOMMU tables). The changes in NetBSD
Sparc/ESP/DMA/IOMMU code from 3.x to 4.0 could be enlightening.

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

[Artyom Tarasenko]

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?

> All
> my NetBSD <4.0 boot CDs crash because of a NMI from IOMMU (DMA tries
> to access a page not in IOMMU tables). The changes in NetBSD
> Sparc/ESP/DMA/IOMMU code from 3.x to 4.0 could be enlightening.

Only indirect, because capacity reading doesn't work with NetBSD 4 as well.

BTW is esp also used in non-sparc systems? AFAIR NCR53C9x chip was
also used on some apple machines?
One possibility to exclude esp from suspects would be to boot the same
version of NetBSD on other qemu-guest arch.

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

[Blue Swirl]

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?

>> All
>> my NetBSD <4.0 boot CDs crash because of a NMI from IOMMU (DMA tries
>> to access a page not in IOMMU tables). The changes in NetBSD
>> Sparc/ESP/DMA/IOMMU code from 3.x to 4.0 could be enlightening.
>
> Only indirect, because capacity reading doesn't work with NetBSD 4 as well.
>
> BTW is esp also used in non-sparc systems? AFAIR NCR53C9x chip was
> also used on some apple machines?
> One possibility to exclude esp from suspects would be to boot the same
> version of NetBSD on other qemu-guest arch.

At least MIPS Jazz machines use it.

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

[Artyom Tarasenko]

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.

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

[Blue Swirl]

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?

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

[Artyom Tarasenko]

2009/9/14 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?

You were right, it was FIFO, but I ran the tests in a wrong qemu
branch. It's sort of funny, because the bug was fixed in the HEAD by
my own patch (the "Message accepted" patch).

Now the disk gets commands properly, but NetBSD still complains about
getting nonsense.

One of the reasons is, the disk's geometry has to be explicitly
specified via -hdachs , but

> But is the response also read without DMA?

you are right about this one too. It is read via DMA, and it seems
that the response gets shifted by -8 bytes:
the follofing hack in hw/sparc32_dma.c makes NetBSD to recognize the geometry:

--- a/hw/sparc32_dma.c
+++ b/hw/sparc32_dma.c
@@ -150,6 +150,9 @@ void espdma_memory_write(void *opaque, uint8_t
*buf, int len)
 {
     DMAState *s = opaque;

+if(s->dmaregs[1]==0xfc000d58)
+  s->dmaregs[1]=0xfc000d60;
+
     DPRINTF("DMA write, direction: %c, addr 0x%8.8x\n",
             s->dmaregs[0] & DMA_WRITE_MEM ? 'w': 'r', s->dmaregs[1]);
     sparc_iommu_memory_write(s->iommu, s->dmaregs[1], buf, len);

qemu-system-sparc -M SS-20 -nographic  -hda ~/sparc/miniroot-133.fs
-hdachs 64,6,32 -m 64 -cpu "TI SuperSparc 50"
...
esp0 at dma0 slot 0xf offset 0x800000 pri 4: ESP200, 40MHz, SCSI ID 7
scsibus0 at esp0: 8 targets
DMA write, direction: w, addr 0xfc000c90
sd3 at scsibus0 targ 0 lun 0: <QEMU, QEMU HARDDISK, 0.11> SCSI3
0/direct fixed
sd3: Mode Sense (page 4, len 32)
DMA write, direction: w, addr 0xfc000d60
DMA write, direction: w, addr 0xfc000ce8
6MB, 64 cyl, 6 head, 32 sec, 512 bytes/sect x 12288 sectors
...

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

[Blue Swirl]

On Fri, Sep 18, 2009 at 8:26 PM, Artyom Tarasenko
<atar4qemu@googlemail.com> wrote:
> 2009/9/14 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?
>
> You were right, it was FIFO, but I ran the tests in a wrong qemu
> branch. It's sort of funny, because the bug was fixed in the HEAD by
> my own patch (the "Message accepted" patch).
>
> Now the disk gets commands properly, but NetBSD still complains about
> getting nonsense.
>
> One of the reasons is, the disk's geometry has to be explicitly
> specified via -hdachs , but
>
>> But is the response also read without DMA?
>
> you are right about this one too. It is read via DMA, and it seems
> that the response gets shifted by -8 bytes:
> the follofing hack in hw/sparc32_dma.c makes NetBSD to recognize the geometry:

Could be a bug in the DMA controller. For example, the feature for
automatic load of next address is not implemented. IIRC it's not
available in all versions, so downgrading the controller version may
help.

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

[Artyom Tarasenko]

2009/9/19 Blue Swirl <blauwirbel@gmail.com>:
> On Fri, Sep 18, 2009 at 8:26 PM, Artyom Tarasenko
> <atar4qemu@googlemail.com> wrote:
>> 2009/9/14 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?
>>
>> You were right, it was FIFO, but I ran the tests in a wrong qemu
>> branch. It's sort of funny, because the bug was fixed in the HEAD by
>> my own patch (the "Message accepted" patch).
>>
>> Now the disk gets commands properly, but NetBSD still complains about
>> getting nonsense.
>>
>> One of the reasons is, the disk's geometry has to be explicitly
>> specified via -hdachs , but
>>
>>> But is the response also read without DMA?
>>
>> you are right about this one too. It is read via DMA, and it seems
>> that the response gets shifted by -8 bytes:
>> the follofing hack in hw/sparc32_dma.c makes NetBSD to recognize the geometry:
>
> Could be a bug in the DMA controller. For example, the feature for
> automatic load of next address is not implemented. IIRC it's not
> available in all versions, so downgrading the controller version may
> help.

Downgrading the controller version didn't change anything. I also
tried to boot with -M LX , to downgrade other components as well, the
result was still the same.

But this brings me to another question: Is there a reason for silent
catching of errors produced by unimplemented features?

I like the way it is implenented in hw/scsi-disk.c: along with DPRINTF
for debugging there is a BADF for reporting unimplemented/unexpected
cases. DPRINTFs may be turned on by a #define, and BADFs are always
on. Shouldn't similar constructs were used for mmu, iommu and other
units with partially implemented funcionality?

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

[Artyom Tarasenko]

2009/9/23 Artyom Tarasenko <atar4qemu@googlemail.com>:
> 2009/9/19 Blue Swirl <blauwirbel@gmail.com>:
>> On Fri, Sep 18, 2009 at 8:26 PM, Artyom Tarasenko
>> <atar4qemu@googlemail.com> wrote:
>>> 2009/9/14 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?
>>>
>>> You were right, it was FIFO, but I ran the tests in a wrong qemu
>>> branch. It's sort of funny, because the bug was fixed in the HEAD by
>>> my own patch (the "Message accepted" patch).
>>>
>>> Now the disk gets commands properly, but NetBSD still complains about
>>> getting nonsense.
>>>
>>> One of the reasons is, the disk's geometry has to be explicitly
>>> specified via -hdachs , but
>>>
>>>> But is the response also read without DMA?
>>>
>>> you are right about this one too. It is read via DMA, and it seems
>>> that the response gets shifted by -8 bytes:
>>> the follofing hack in hw/sparc32_dma.c makes NetBSD to recognize the geometry:
>>
>> Could be a bug in the DMA controller. For example, the feature for
>> automatic load of next address is not implemented. IIRC it's not
>> available in all versions, so downgrading the controller version may
>> help.
>
> Downgrading the controller version didn't change anything. I also
> tried to boot with -M LX , to downgrade other components as well, the
> result was still the same.
>
> But this brings me to another question: Is there a reason for silent
> catching of errors produced by unimplemented features?
>
> I like the way it is implenented in hw/scsi-disk.c: along with DPRINTF
> for debugging there is a BADF for reporting unimplemented/unexpected
> cases. DPRINTFs may be turned on by a #define, and BADFs are always
> on. Shouldn't similar constructs were used for mmu, iommu and other
> units with partially implemented funcionality?


Actually, scsi-disk.c doesn't implement block descriptor for mode
pages. The SCSI-2 documentation suggests, that although the block
descriptor is optional for an arbitrary SCSI-2 device (chapter 8.2.10,
http://ldkelley.com/SCSI2/SCSI2/SCSI2/SCSI2/SCSI2-08.html ) it is
mandatory for a disk: chapters 9.1.2, 9.3.3 (
http://ldkelley.com/SCSI2/SCSI2/SCSI2/SCSI2-09.html ) don't say
"optional" any more, just "The block descriptor in the MODE SENSE data
describes the block lengths that are used on the medium."

NetBSD expects that the block descriptor is always there:
sd.c:

struct scsi_mode_sense_data {
        struct scsi_mode_header header;
        struct scsi_blk_desc blk_desc;
        union scsi_disk_pages pages;
};

Shall we implement the block descriptor? We can start with the
following, which fixes NetBSD geometry detection. Shall I post it as a
patch?

And there is one more problem regarding the disk geometry. The
"-hdachs" command line switch's sanity check seems to be IDE-specific:
for instance it doesn't accept "-hdachs 6,64,32". Is there an
alternative way to specify the SCSI disk geometry?


Signed-off-by: Artyom Tarasenko <atar4qemu@gmail.com>
---
diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index 3940726..9041902 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -624,7 +624,9 @@ static int32_t scsi_send_command(SCSIDevice *d,
uint32_t tag,
         {
             uint8_t *p;
             int page;
-
+            int dbd;
+
+            dbd = buf[1]  & 0x8;
             page = buf[2] & 0x3f;
             DPRINTF("Mode Sense (page %d, len %d)\n", page, len);
             p = outbuf;
@@ -635,7 +637,25 @@ static int32_t scsi_send_command(SCSIDevice *d,
uint32_t tag,
                 outbuf[2] = 0x80; /* Readonly.  */
             }
             p += 4;
-            if (page == 4) {
+            bdrv_get_geometry(s->dinfo->bdrv, &nb_sectors);
+            if ((~dbd) & nb_sectors) {
+                nb_sectors /= s->cluster_size;
+                if (nb_sectors > UINT32_MAX)
+                   nb_sectors = UINT32_MAX;
+                nb_sectors--;
+                outbuf[3] = 8; /* Block descriptor length.  */
+                p[0] = 0;
+                p[1] = (nb_sectors >> 16) & 0xff;
+                p[2] = (nb_sectors >> 8) & 0xff;
+                p[3] = nb_sectors & 0xff;
+                p[4] = 0;  /* reserved */
+                p[5] = 0; /* bytes 5-7 are the sector size in bytes */
+                p[6] = s->cluster_size * 2;
+                p[7] = 0;
+                p += 8;
+            }
+
+            if (page == 4 ) {

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

[Blue Swirl]

On Thu, Oct 8, 2009 at 7:14 PM, Artyom Tarasenko
<atar4qemu@googlemail.com> wrote:
> 2009/9/23 Artyom Tarasenko <atar4qemu@googlemail.com>:
>> 2009/9/19 Blue Swirl <blauwirbel@gmail.com>:
>>> On Fri, Sep 18, 2009 at 8:26 PM, Artyom Tarasenko
>>> <atar4qemu@googlemail.com> wrote:
>>>> 2009/9/14 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?
>>>>
>>>> You were right, it was FIFO, but I ran the tests in a wrong qemu
>>>> branch. It's sort of funny, because the bug was fixed in the HEAD by
>>>> my own patch (the "Message accepted" patch).
>>>>
>>>> Now the disk gets commands properly, but NetBSD still complains about
>>>> getting nonsense.
>>>>
>>>> One of the reasons is, the disk's geometry has to be explicitly
>>>> specified via -hdachs , but
>>>>
>>>>> But is the response also read without DMA?
>>>>
>>>> you are right about this one too. It is read via DMA, and it seems
>>>> that the response gets shifted by -8 bytes:
>>>> the follofing hack in hw/sparc32_dma.c makes NetBSD to recognize the geometry:
>>>
>>> Could be a bug in the DMA controller. For example, the feature for
>>> automatic load of next address is not implemented. IIRC it's not
>>> available in all versions, so downgrading the controller version may
>>> help.
>>
>> Downgrading the controller version didn't change anything. I also
>> tried to boot with -M LX , to downgrade other components as well, the
>> result was still the same.
>>
>> But this brings me to another question: Is there a reason for silent
>> catching of errors produced by unimplemented features?
>>
>> I like the way it is implenented in hw/scsi-disk.c: along with DPRINTF
>> for debugging there is a BADF for reporting unimplemented/unexpected
>> cases. DPRINTFs may be turned on by a #define, and BADFs are always
>> on. Shouldn't similar constructs were used for mmu, iommu and other
>> units with partially implemented funcionality?
>
>
> Actually, scsi-disk.c doesn't implement block descriptor for mode
> pages. The SCSI-2 documentation suggests, that although the block
> descriptor is optional for an arbitrary SCSI-2 device (chapter 8.2.10,
> http://ldkelley.com/SCSI2/SCSI2/SCSI2/SCSI2/SCSI2-08.html ) it is
> mandatory for a disk: chapters 9.1.2, 9.3.3 (
> http://ldkelley.com/SCSI2/SCSI2/SCSI2/SCSI2-09.html ) don't say
> "optional" any more, just "The block descriptor in the MODE SENSE data
> describes the block lengths that are used on the medium."

I agree.

> NetBSD expects that the block descriptor is always there:
> sd.c:
>
> struct scsi_mode_sense_data {
>        struct scsi_mode_header header;
>        struct scsi_blk_desc blk_desc;
>        union scsi_disk_pages pages;
> };
>
> Shall we implement the block descriptor? We can start with the
> following, which fixes NetBSD geometry detection. Shall I post it as a
> patch?

Yes, please. I did not see any difference with NetBSD (2.1, 3.0 or
4.0) Sparc32 guest, though.

> And there is one more problem regarding the disk geometry. The
> "-hdachs" command line switch's sanity check seems to be IDE-specific:
> for instance it doesn't accept "-hdachs 6,64,32". Is there an
> alternative way to specify the SCSI disk geometry?

I haven't tried, but does -drive handle cyls= etc?

> +                if (nb_sectors > UINT32_MAX)
> +                   nb_sectors = UINT32_MAX;

Here the indentation was off by one.

> +                nb_sectors--;
> +                outbuf[3] = 8; /* Block descriptor length.  */
> +                p[0] = 0;

This is density code (add comment?), but it looks like only some weird
optical devices could have nonzero values.

> +                p[1] = (nb_sectors >> 16) & 0xff;
> +                p[2] = (nb_sectors >> 8) & 0xff;
> +                p[3] = nb_sectors & 0xff;
> +                p[4] = 0;  /* reserved */
> +                p[5] = 0; /* bytes 5-7 are the sector size in bytes */
> +                p[6] = s->cluster_size * 2;
> +                p[7] = 0;
> +                p += 8;
> +            }
> +
> +            if (page == 4 ) {

Extra space after 4.

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

[Artyom Tarasenko]

2009/10/12 Blue Swirl <blauwirbel@gmail.com>:
> On Thu, Oct 8, 2009 at 7:14 PM, Artyom Tarasenko
> <atar4qemu@googlemail.com> wrote:
>> 2009/9/23 Artyom Tarasenko <atar4qemu@googlemail.com>:
>>> 2009/9/19 Blue Swirl <blauwirbel@gmail.com>:
>>>> On Fri, Sep 18, 2009 at 8:26 PM, Artyom Tarasenko
>>>> <atar4qemu@googlemail.com> wrote:
>>>>> 2009/9/14 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?
>>>>>
>>>>> You were right, it was FIFO, but I ran the tests in a wrong qemu
>>>>> branch. It's sort of funny, because the bug was fixed in the HEAD by
>>>>> my own patch (the "Message accepted" patch).
>>>>>
>>>>> Now the disk gets commands properly, but NetBSD still complains about
>>>>> getting nonsense.
>>>>>
>>>>> One of the reasons is, the disk's geometry has to be explicitly
>>>>> specified via -hdachs , but
>>>>>
>>>>>> But is the response also read without DMA?
>>>>>
>>>>> you are right about this one too. It is read via DMA, and it seems
>>>>> that the response gets shifted by -8 bytes:
>>>>> the follofing hack in hw/sparc32_dma.c makes NetBSD to recognize the geometry:
>>>>
>>>> Could be a bug in the DMA controller. For example, the feature for
>>>> automatic load of next address is not implemented. IIRC it's not
>>>> available in all versions, so downgrading the controller version may
>>>> help.
>>>
>>> Downgrading the controller version didn't change anything. I also
>>> tried to boot with -M LX , to downgrade other components as well, the
>>> result was still the same.
>>>
>>> But this brings me to another question: Is there a reason for silent
>>> catching of errors produced by unimplemented features?
>>>
>>> I like the way it is implenented in hw/scsi-disk.c: along with DPRINTF
>>> for debugging there is a BADF for reporting unimplemented/unexpected
>>> cases. DPRINTFs may be turned on by a #define, and BADFs are always
>>> on. Shouldn't similar constructs were used for mmu, iommu and other
>>> units with partially implemented funcionality?
>>
>>
>> Actually, scsi-disk.c doesn't implement block descriptor for mode
>> pages. The SCSI-2 documentation suggests, that although the block
>> descriptor is optional for an arbitrary SCSI-2 device (chapter 8.2.10,
>> http://ldkelley.com/SCSI2/SCSI2/SCSI2/SCSI2/SCSI2-08.html ) it is
>> mandatory for a disk: chapters 9.1.2, 9.3.3 (
>> http://ldkelley.com/SCSI2/SCSI2/SCSI2/SCSI2-09.html ) don't say
>> "optional" any more, just "The block descriptor in the MODE SENSE data
>> describes the block lengths that are used on the medium."
>
> I agree.
>
>> NetBSD expects that the block descriptor is always there:
>> sd.c:
>>
>> struct scsi_mode_sense_data {
>>        struct scsi_mode_header header;
>>        struct scsi_blk_desc blk_desc;
>>        union scsi_disk_pages pages;
>> };
>>
>> Shall we implement the block descriptor? We can start with the
>> following, which fixes NetBSD geometry detection. Shall I post it as a
>> patch?
>
> Yes, please. I did not see any difference with NetBSD (2.1, 3.0 or
> 4.0) Sparc32 guest, though.

Just tested with 4.0.1 and it worked.

Did you specify -hdachs? Although the docu says "Usually QEMU can
guess all those parameters.", I don't observe this actually happening.
What is probably meant here "Usually a guest OS can guess all those
parameters."

>> And there is one more problem regarding the disk geometry. The
>> "-hdachs" command line switch's sanity check seems to be IDE-specific:
>> for instance it doesn't accept "-hdachs 6,64,32". Is there an
>> alternative way to specify the SCSI disk geometry?
>
> I haven't tried, but does -drive handle cyls= etc?

Yes, but it seems to have the same limitation:

qemu-system-sparc -nographic  -drive
file=NetBSD-4.0.1-miniroot,cyls=8,heads=64,secs=32,media=disk -m 64 -M
SS-20
qemu: '(null)' invalid physical heads number

> Extra space after 4.

Fixed.

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

[Blue Swirl]

[-- Attachment #1: Type: text/plain, Size: 7424 bytes --]

On Tue, Oct 13, 2009 at 11:10 PM, Artyom Tarasenko
<atar4qemu@googlemail.com> wrote:
> 2009/10/12 Blue Swirl <blauwirbel@gmail.com>:
>> On Thu, Oct 8, 2009 at 7:14 PM, Artyom Tarasenko
>> <atar4qemu@googlemail.com> wrote:
>>> 2009/9/23 Artyom Tarasenko <atar4qemu@googlemail.com>:
>>>> 2009/9/19 Blue Swirl <blauwirbel@gmail.com>:
>>>>> On Fri, Sep 18, 2009 at 8:26 PM, Artyom Tarasenko
>>>>> <atar4qemu@googlemail.com> wrote:
>>>>>> 2009/9/14 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?
>>>>>>
>>>>>> You were right, it was FIFO, but I ran the tests in a wrong qemu
>>>>>> branch. It's sort of funny, because the bug was fixed in the HEAD by
>>>>>> my own patch (the "Message accepted" patch).
>>>>>>
>>>>>> Now the disk gets commands properly, but NetBSD still complains about
>>>>>> getting nonsense.
>>>>>>
>>>>>> One of the reasons is, the disk's geometry has to be explicitly
>>>>>> specified via -hdachs , but
>>>>>>
>>>>>>> But is the response also read without DMA?
>>>>>>
>>>>>> you are right about this one too. It is read via DMA, and it seems
>>>>>> that the response gets shifted by -8 bytes:
>>>>>> the follofing hack in hw/sparc32_dma.c makes NetBSD to recognize the geometry:
>>>>>
>>>>> Could be a bug in the DMA controller. For example, the feature for
>>>>> automatic load of next address is not implemented. IIRC it's not
>>>>> available in all versions, so downgrading the controller version may
>>>>> help.
>>>>
>>>> Downgrading the controller version didn't change anything. I also
>>>> tried to boot with -M LX , to downgrade other components as well, the
>>>> result was still the same.
>>>>
>>>> But this brings me to another question: Is there a reason for silent
>>>> catching of errors produced by unimplemented features?
>>>>
>>>> I like the way it is implenented in hw/scsi-disk.c: along with DPRINTF
>>>> for debugging there is a BADF for reporting unimplemented/unexpected
>>>> cases. DPRINTFs may be turned on by a #define, and BADFs are always
>>>> on. Shouldn't similar constructs were used for mmu, iommu and other
>>>> units with partially implemented funcionality?
>>>
>>>
>>> Actually, scsi-disk.c doesn't implement block descriptor for mode
>>> pages. The SCSI-2 documentation suggests, that although the block
>>> descriptor is optional for an arbitrary SCSI-2 device (chapter 8.2.10,
>>> http://ldkelley.com/SCSI2/SCSI2/SCSI2/SCSI2/SCSI2-08.html ) it is
>>> mandatory for a disk: chapters 9.1.2, 9.3.3 (
>>> http://ldkelley.com/SCSI2/SCSI2/SCSI2/SCSI2-09.html ) don't say
>>> "optional" any more, just "The block descriptor in the MODE SENSE data
>>> describes the block lengths that are used on the medium."
>>
>> I agree.
>>
>>> NetBSD expects that the block descriptor is always there:
>>> sd.c:
>>>
>>> struct scsi_mode_sense_data {
>>>        struct scsi_mode_header header;
>>>        struct scsi_blk_desc blk_desc;
>>>        union scsi_disk_pages pages;
>>> };
>>>
>>> Shall we implement the block descriptor? We can start with the
>>> following, which fixes NetBSD geometry detection. Shall I post it as a
>>> patch?
>>
>> Yes, please. I did not see any difference with NetBSD (2.1, 3.0 or
>> 4.0) Sparc32 guest, though.
>
> Just tested with 4.0.1 and it worked.
>
> Did you specify -hdachs? Although the docu says "Usually QEMU can
> guess all those parameters.", I don't observe this actually happening.
> What is probably meant here "Usually a guest OS can guess all those
> parameters."
>
>>> And there is one more problem regarding the disk geometry. The
>>> "-hdachs" command line switch's sanity check seems to be IDE-specific:
>>> for instance it doesn't accept "-hdachs 6,64,32". Is there an
>>> alternative way to specify the SCSI disk geometry?
>>
>> I haven't tried, but does -drive handle cyls= etc?
>
> Yes, but it seems to have the same limitation:
>
> qemu-system-sparc -nographic  -drive
> file=NetBSD-4.0.1-miniroot,cyls=8,heads=64,secs=32,media=disk -m 64 -M
> SS-20
> qemu: '(null)' invalid physical heads number

This patch should help. I think only IDE needs the CHS limits.

>> Extra space after 4.
>
> Fixed.

Thanks, applied.

[-- Attachment #2: 0001-Only-IDE-needs-limits-for-CHS-configuration.patch --]
[-- Type: application/x-patch, Size: 1152 bytes --]