From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqP25-0003US-G3 for qemu-devel@nongnu.org; Wed, 23 Sep 2009 06:25:09 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqP1z-0003U7-NV for qemu-devel@nongnu.org; Wed, 23 Sep 2009 06:25:08 -0400 Received: from [199.232.76.173] (port=37792 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqP1z-0003U4-FN for qemu-devel@nongnu.org; Wed, 23 Sep 2009 06:25:03 -0400 Received: from mail-yw0-f199.google.com ([209.85.211.199]:53679) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MqP1z-0001PM-0j for qemu-devel@nongnu.org; Wed, 23 Sep 2009 06:25:03 -0400 Received: by ywh37 with SMTP id 37so676207ywh.4 for ; Wed, 23 Sep 2009 03:25:02 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Artyom Tarasenko Date: Wed, 23 Sep 2009 12:24:42 +0200 Message-ID: Subject: Re: [Qemu-devel] Re: sparc esp NetBSD-guest "sd3: mode sense (4) returned nonsense" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel 2009/9/19 Blue Swirl : > 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 wo= rk >>>>>>>> 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 0= x04 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 rea= son >>>>>>>> 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 geo= metry: > > 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. Downgrading the controller version didn't change anything. I also tried to boot with -M LX , to downgrade other components as well, the result was still the same. But this brings me to another question: Is there a reason for silent catching of errors produced by unimplemented features? I like the way it is implenented in hw/scsi-disk.c: along with DPRINTF for debugging there is a BADF for reporting unimplemented/unexpected cases. DPRINTFs may be turned on by a #define, and BADFs are always on. Shouldn't similar constructs were used for mmu, iommu and other units with partially implemented funcionality?