From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1My93C-0001YT-5j for qemu-devel@nongnu.org; Wed, 14 Oct 2009 14:58:18 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1My937-0001W9-KX for qemu-devel@nongnu.org; Wed, 14 Oct 2009 14:58:17 -0400 Received: from [199.232.76.173] (port=58166 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1My937-0001Vv-4t for qemu-devel@nongnu.org; Wed, 14 Oct 2009 14:58:13 -0400 Received: from mail-fx0-f214.google.com ([209.85.220.214]:64148) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1My936-00073b-Cv for qemu-devel@nongnu.org; Wed, 14 Oct 2009 14:58:12 -0400 Received: by fxm10 with SMTP id 10so108912fxm.8 for ; Wed, 14 Oct 2009 11:58:10 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Blue Swirl Date: Wed, 14 Oct 2009 21:57:49 +0300 Message-ID: Subject: Re: [Qemu-devel] Re: sparc esp NetBSD-guest "sd3: mode sense (4) returned nonsense" Content-Type: multipart/mixed; boundary=0015174029f8675c4d0475e9be39 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Artyom Tarasenko Cc: qemu-devel --0015174029f8675c4d0475e9be39 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Oct 13, 2009 at 11:10 PM, Artyom Tarasenko wrote: > 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 shoul= d work >>>>>>>>>>>> under qemu: they call "mode sense" and "read capacity", and bo= th >>>>>>>>>>>> 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 - Ne= tBSD >>>>>>>>>>>> 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[ESP_TCMID] << 8); >>>>>>>>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0s->dma_memory_read(s->dma_opaque, b= uf, dmalen); >>>>>>>>>>>> =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/minir= oot-133.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 0x= 00 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 geomet= ry >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 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 comm= and >>>>>>>>>> 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 lefto= ver >>>>>>> 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 abou= t >>>>>> 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 { >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0struct scsi_mode_header header; >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0struct scsi_blk_desc blk_desc; >>> =C2=A0 =C2=A0 =C2=A0 =C2=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 =C2=A0-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 This patch should help. I think only IDE needs the CHS limits. >> Extra space after 4. > > Fixed. Thanks, applied. --0015174029f8675c4d0475e9be39 Content-Type: application/x-patch; name="0001-Only-IDE-needs-limits-for-CHS-configuration.patch" Content-Disposition: attachment; filename="0001-Only-IDE-needs-limits-for-CHS-configuration.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g0sfvhjl0 RnJvbSBhZjI4MTJjZWYwMTdhNDM0NjRkZDNmYmI4NWU4YTI4NGJlNjZmZjZiIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBCbHVlIFN3aXJsIDxibGF1d2lyYmVsQGdtYWlsLmNvbT4KRGF0 ZTogV2VkLCAxNCBPY3QgMjAwOSAxODo1MDoxMiArMDAwMApTdWJqZWN0OiBbUEFUQ0hdIE9ubHkg SURFIG5lZWRzIGxpbWl0cyBmb3IgQ0hTIGNvbmZpZ3VyYXRpb24KClNpZ25lZC1vZmYtYnk6IEJs dWUgU3dpcmwgPGJsYXV3aXJiZWxAZ21haWwuY29tPgotLS0KIHZsLmMgfCAgICA2ICsrKy0tLQog MSBmaWxlcyBjaGFuZ2VkLCAzIGluc2VydGlvbnMoKyksIDMgZGVsZXRpb25zKC0pCgpkaWZmIC0t Z2l0IGEvdmwuYyBiL3ZsLmMKaW5kZXggYWZlMDFhZi4uZTRhMWVlMSAxMDA2NDQKLS0tIGEvdmwu YworKysgYi92bC5jCkBAIC0yMDc4LDE1ICsyMDc4LDE1IEBAIERyaXZlSW5mbyAqZHJpdmVfaW5p dChRZW11T3B0cyAqb3B0cywgdm9pZCAqb3BhcXVlLAogICAgIH0KIAogICAgIGlmIChjeWxzIHx8 IGhlYWRzIHx8IHNlY3MpIHsKLSAgICAgICAgaWYgKGN5bHMgPCAxIHx8IGN5bHMgPiAxNjM4Mykg eworICAgICAgICBpZiAoY3lscyA8IDEgfHwgKHR5cGUgPT0gSUZfSURFICYmIGN5bHMgPiAxNjM4 MykpIHsKICAgICAgICAgICAgIGZwcmludGYoc3RkZXJyLCAicWVtdTogJyVzJyBpbnZhbGlkIHBo eXNpY2FsIGN5bHMgbnVtYmVyXG4iLCBidWYpOwogCSAgICByZXR1cm4gTlVMTDsKIAl9Ci0gICAg ICAgIGlmIChoZWFkcyA8IDEgfHwgaGVhZHMgPiAxNikgeworICAgICAgICBpZiAoaGVhZHMgPCAx IHx8ICh0eXBlID09IElGX0lERSAmJiBoZWFkcyA+IDE2KSkgewogICAgICAgICAgICAgZnByaW50 ZihzdGRlcnIsICJxZW11OiAnJXMnIGludmFsaWQgcGh5c2ljYWwgaGVhZHMgbnVtYmVyXG4iLCBi dWYpOwogCSAgICByZXR1cm4gTlVMTDsKIAl9Ci0gICAgICAgIGlmIChzZWNzIDwgMSB8fCBzZWNz ID4gNjMpIHsKKyAgICAgICAgaWYgKHNlY3MgPCAxIHx8ICh0eXBlID09IElGX0lERSAmJiBzZWNz ID4gNjMpKSB7CiAgICAgICAgICAgICBmcHJpbnRmKHN0ZGVyciwgInFlbXU6ICclcycgaW52YWxp ZCBwaHlzaWNhbCBzZWNzIG51bWJlclxuIiwgYnVmKTsKIAkgICAgcmV0dXJuIE5VTEw7CiAJfQot LSAKMS41LjYuNQoK --0015174029f8675c4d0475e9be39--