From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MnERK-00013I-L5 for qemu-devel@nongnu.org; Mon, 14 Sep 2009 12:30:06 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MnERF-00012i-B3 for qemu-devel@nongnu.org; Mon, 14 Sep 2009 12:30:05 -0400 Received: from [199.232.76.173] (port=44239 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MnERF-00012f-5l for qemu-devel@nongnu.org; Mon, 14 Sep 2009 12:30:01 -0400 Received: from mail-yx0-f201.google.com ([209.85.210.201]:40581) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MnERE-0005Vr-T9 for qemu-devel@nongnu.org; Mon, 14 Sep 2009 12:30:01 -0400 Received: by yxe39 with SMTP id 39so4040592yxe.18 for ; Mon, 14 Sep 2009 09:30:00 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Artyom Tarasenko Date: Mon, 14 Sep 2009 18:29:38 +0200 Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Re: sparc esp NetBSD-guest "sd3: mode sense (4) returned nonsense" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel 2009/9/14 Blue Swirl : > On Mon, Sep 14, 2009 at 12:32 AM, Artyom Tarasenko > 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) >> { >> =A0 =A0uint32_t dmalen; >> =A0 =A0int target; >> >> =A0 =A0target =3D s->wregs[ESP_WBUSID] & BUSID_DID; >> =A0 =A0if (s->dma) { >> =A0 =A0 =A0 =A0dmalen =3D s->rregs[ESP_TCLO] | (s->rregs[ESP_TCMID] << 8= ); >> =A0 =A0 =A0 =A0s->dma_memory_read(s->dma_opaque, buf, dmalen); >> =A0 =A0} else { >> =A0 =A0 =A0 =A0dmalen =3D s->ti_size; >> =A0 =A0 =A0 =A0memcpy(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]); >> =A0 =A0 =A0 =A0buf[0] =3D 0; >> =A0 =A0} >> >> qemu-system-sparc -M SS-20 -nographic =A0-hda ~/sparc/miniroot-133.fs -m= 64 >> ... >> NON-DMA rptr 0, wptr 1 c0 (0) =A00 =A00 1a =A00 >> Set ATN & Stop: cmdlen 3 >> scsi-disk: Command: lun=3D0 tag=3D0x0 data=3D0x00 0x00 0x1a 0x00 0x04 0x= 00 >> scsi-disk: Test Unit Ready >> scsi-disk: Command complete tag=3D0x0 status=3D0 sense=3D0 >> 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.