From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MnEaO-0004Q6-BY for qemu-devel@nongnu.org; Mon, 14 Sep 2009 12:39:28 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MnEaN-0004Ph-TI for qemu-devel@nongnu.org; Mon, 14 Sep 2009 12:39:27 -0400 Received: from [199.232.76.173] (port=42772 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MnEaN-0004Pe-Je for qemu-devel@nongnu.org; Mon, 14 Sep 2009 12:39:27 -0400 Received: from ey-out-1920.google.com ([74.125.78.147]:5632) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MnEaM-00086M-Vx for qemu-devel@nongnu.org; Mon, 14 Sep 2009 12:39:27 -0400 Received: by ey-out-1920.google.com with SMTP id 13so745085eye.14 for ; Mon, 14 Sep 2009 09:39:26 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Blue Swirl Date: Mon, 14 Sep 2009 19:39:05 +0300 Message-ID: Content-Type: text/plain; charset=UTF-8 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: Artyom Tarasenko Cc: qemu-devel 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) >>> { >>> =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->rregs[ES= P_TCMID] << 8); >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0s->dma_memory_read(s->dma_opaque, buf, dmale= n); >>> =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-133.f= s -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 0x04 0= x00 >>> 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? >> 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 wel= l. > > 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. At least MIPS Jazz machines use it.