From: Artyom Tarasenko <atar4qemu@googlemail.com>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Re: sparc esp NetBSD-guest "sd3: mode sense (4) returned nonsense"
Date: Fri, 18 Sep 2009 19:26:09 +0200 [thread overview]
Message-ID: <fb8d4f70909181026q7ba29835v953534673825e2a1@mail.gmail.com> (raw)
In-Reply-To: <f43fc5580909140959h3872c424k4254ed757c4fe3bf@mail.gmail.com>
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
...
next prev parent reply other threads:[~2009-09-18 17:26 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-13 21:32 [Qemu-devel] sparc esp NetBSD-guest "sd3: mode sense (4) returned nonsense" Artyom Tarasenko
2009-09-14 15:49 ` [Qemu-devel] " Blue Swirl
2009-09-14 16:29 ` Artyom Tarasenko
2009-09-14 16:39 ` Blue Swirl
2009-09-14 16:47 ` Artyom Tarasenko
2009-09-14 16:59 ` Blue Swirl
2009-09-18 17:26 ` Artyom Tarasenko [this message]
2009-09-19 9:55 ` Blue Swirl
2009-09-23 10:24 ` Artyom Tarasenko
2009-10-08 16:14 ` Artyom Tarasenko
2009-10-12 19:36 ` Blue Swirl
2009-10-13 20:10 ` Artyom Tarasenko
2009-10-14 18:57 ` Blue Swirl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fb8d4f70909181026q7ba29835v953534673825e2a1@mail.gmail.com \
--to=atar4qemu@googlemail.com \
--cc=blauwirbel@gmail.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).