From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MowfN-0000o7-NV for qemu-devel@nongnu.org; Sat, 19 Sep 2009 05:55:41 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MowfI-0000nu-Iq for qemu-devel@nongnu.org; Sat, 19 Sep 2009 05:55:40 -0400 Received: from [199.232.76.173] (port=35905 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MowfI-0000nr-9w for qemu-devel@nongnu.org; Sat, 19 Sep 2009 05:55:36 -0400 Received: from mail-fx0-f214.google.com ([209.85.220.214]:38687) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MowfH-0004ia-QE for qemu-devel@nongnu.org; Sat, 19 Sep 2009 05:55:36 -0400 Received: by fxm10 with SMTP id 10so1180088fxm.8 for ; Sat, 19 Sep 2009 02:55:35 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Blue Swirl Date: Sat, 19 Sep 2009 12:55:15 +0300 Message-ID: Subject: Re: [Qemu-devel] Re: sparc esp NetBSD-guest "sd3: mode sense (4) returned nonsense" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Artyom Tarasenko Cc: qemu-devel On Fri, Sep 18, 2009 at 8:26 PM, Artyom Tarasenko wrote: > 2009/9/14 Blue Swirl : >> On Mon, Sep 14, 2009 at 7:47 PM, Artyom Tarasenko >> wrote: >>> 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 wor= k >>>>>>> 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) >>>>>>> { >>>>>>> =C2=A0 =C2=A0uint32_t dmalen; >>>>>>> =C2=A0 =C2=A0int target; >>>>>>> >>>>>>> =C2=A0 =C2=A0target =3D s->wregs[ESP_WBUSID] & BUSID_DID; >>>>>>> =C2=A0 =C2=A0if (s->dma) { >>>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0dmalen =3D s->rregs[ESP_TCLO] | (s->rreg= s[ESP_TCMID] << 8); >>>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0s->dma_memory_read(s->dma_opaque, buf, d= malen); >>>>>>> =C2=A0 =C2=A0} else { >>>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0dmalen =3D s->ti_size; >>>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=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]); >>>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0buf[0] =3D 0; >>>>>>> =C2=A0 =C2=A0} >>>>>>> >>>>>>> qemu-system-sparc -M SS-20 -nographic =C2=A0-hda ~/sparc/miniroot-1= 33.fs -m 64 >>>>>>> ... >>>>>>> NON-DMA rptr 0, wptr 1 c0 (0) =C2=A00 =C2=A00 1a =C2=A00 >>>>>>> Set ATN & Stop: cmdlen 3 >>>>>>> scsi-disk: Command: lun=3D0 tag=3D0x0 data=3D0x00 0x00 0x1a 0x00 0x= 04 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 reas= on >>>>>>> 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 geom= etry: 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.