From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MnEi5-0007Ie-Vf for qemu-devel@nongnu.org; Mon, 14 Sep 2009 12:47:26 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MnEi1-0007Cc-C4 for qemu-devel@nongnu.org; Mon, 14 Sep 2009 12:47:25 -0400 Received: from [199.232.76.173] (port=40448 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MnEi1-0007CS-5e for qemu-devel@nongnu.org; Mon, 14 Sep 2009 12:47:21 -0400 Received: from mail-yx0-f201.google.com ([209.85.210.201]:44220) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MnEi0-0001FK-Q4 for qemu-devel@nongnu.org; Mon, 14 Sep 2009 12:47:20 -0400 Received: by yxe39 with SMTP id 39so4059764yxe.18 for ; Mon, 14 Sep 2009 09:47:20 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Artyom Tarasenko Date: Mon, 14 Sep 2009 18:47:00 +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: , Cc: qemu-devel 2009/9/14 Blue Swirl : > On Mon, Sep 14, 2009 at 7:29 PM, Artyom Tarasenko > wrote: >> 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 = 0x00 >>>> 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? > > 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.