From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Mmwgz-0003dA-DU
	for qemu-devel@nongnu.org; Sun, 13 Sep 2009 17:33:05 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Mmwgu-0003cv-S5
	for qemu-devel@nongnu.org; Sun, 13 Sep 2009 17:33:04 -0400
Received: from [199.232.76.173] (port=36439 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Mmwgu-0003cs-ND
	for qemu-devel@nongnu.org; Sun, 13 Sep 2009 17:33:00 -0400
Received: from mail-yw0-f203.google.com ([209.85.211.203]:47296)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <atar4qemu@googlemail.com>) id 1Mmwgu-0005yU-Ee
	for qemu-devel@nongnu.org; Sun, 13 Sep 2009 17:33:00 -0400
Received: by ywh41 with SMTP id 41so3419511ywh.19
	for <qemu-devel@nongnu.org>; Sun, 13 Sep 2009 14:32:59 -0700 (PDT)
MIME-Version: 1.0
From: Artyom Tarasenko <atar4qemu@googlemail.com>
Date: Sun, 13 Sep 2009 23:32:39 +0200
Message-ID: <fb8d4f70909131432w58d65cf1mb4631211fcf982b2@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Subject: [Qemu-devel] sparc esp NetBSD-guest "sd3: mode sense (4) returned
	nonsense"
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel <qemu-devel@nongnu.org>, Blue Swirl <blauwirbel@gmail.com>

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