From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MxniQ-00084V-1b for qemu-devel@nongnu.org; Tue, 13 Oct 2009 16:11:26 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MxniL-00082H-94 for qemu-devel@nongnu.org; Tue, 13 Oct 2009 16:11:25 -0400 Received: from [199.232.76.173] (port=39195 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MxniL-00082E-6J for qemu-devel@nongnu.org; Tue, 13 Oct 2009 16:11:21 -0400 Received: from mail-yw0-f176.google.com ([209.85.211.176]:55672) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MxniK-0006qS-Pl for qemu-devel@nongnu.org; Tue, 13 Oct 2009 16:11:21 -0400 Received: by ywh6 with SMTP id 6so9341503ywh.4 for ; Tue, 13 Oct 2009 13:11:19 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Artyom Tarasenko Date: Tue, 13 Oct 2009 22:10:59 +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/10/12 Blue Swirl : > On Thu, Oct 8, 2009 at 7:14 PM, Artyom Tarasenko > wrote: >> 2009/9/23 Artyom Tarasenko : >>> 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= work >>>>>>>>>>> under qemu: they call "mode sense" and "read capacity", and bot= h >>>>>>>>>>> commands are implemented in qemu's hw/scsi-disk.h. It doesn't w= ork >>>>>>>>>>> though, so NetBSD has to fabricate a disk geometry. >>>>>>>>>>> >>>>>>>>>>> To make debugging easier I tried to boot an older version - Net= BSD >>>>>>>>>>> 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_TC= MID] << 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 0x0= 0 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 geometr= y >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 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 t= hat 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 comma= nd >>>>>>>>> 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 j= ust >>>>>>> doesn't get the command. >>>>>> >>>>>> Ah, I see. What about FIFO state then, perhaps there are some leftov= er >>>>>> bytes (0, 0 could be status + sense?) from the previous command in t= he >>>>>> 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 = geometry: >>>> >>>> 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? >> >> >> Actually, scsi-disk.c doesn't implement block descriptor for mode >> pages. The SCSI-2 documentation suggests, that although the block >> descriptor is optional for an arbitrary SCSI-2 device (chapter 8.2.10, >> http://ldkelley.com/SCSI2/SCSI2/SCSI2/SCSI2/SCSI2-08.html ) it is >> mandatory for a disk: chapters 9.1.2, 9.3.3 ( >> http://ldkelley.com/SCSI2/SCSI2/SCSI2/SCSI2-09.html ) don't say >> "optional" any more, just "The block descriptor in the MODE SENSE data >> describes the block lengths that are used on the medium." > > I agree. > >> NetBSD expects that the block descriptor is always there: >> sd.c: >> >> struct scsi_mode_sense_data { >> =A0 =A0 =A0 =A0struct scsi_mode_header header; >> =A0 =A0 =A0 =A0struct scsi_blk_desc blk_desc; >> =A0 =A0 =A0 =A0union scsi_disk_pages pages; >> }; >> >> Shall we implement the block descriptor? We can start with the >> following, which fixes NetBSD geometry detection. Shall I post it as a >> patch? > > Yes, please. I did not see any difference with NetBSD (2.1, 3.0 or > 4.0) Sparc32 guest, though. Just tested with 4.0.1 and it worked. Did you specify -hdachs? Although the docu says "Usually QEMU can guess all those parameters.", I don't observe this actually happening. What is probably meant here "Usually a guest OS can guess all those parameters." >> And there is one more problem regarding the disk geometry. The >> "-hdachs" command line switch's sanity check seems to be IDE-specific: >> for instance it doesn't accept "-hdachs 6,64,32". Is there an >> alternative way to specify the SCSI disk geometry? > > I haven't tried, but does -drive handle cyls=3D etc? Yes, but it seems to have the same limitation: qemu-system-sparc -nographic -drive file=3DNetBSD-4.0.1-miniroot,cyls=3D8,heads=3D64,secs=3D32,media=3Ddisk -m = 64 -M SS-20 qemu: '(null)' invalid physical heads number > Extra space after 4. Fixed.