From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L5Seu-0004Zw-Df for qemu-devel@nongnu.org; Wed, 26 Nov 2008 17:14:56 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L5Ses-0004Yz-VF for qemu-devel@nongnu.org; Wed, 26 Nov 2008 17:14:56 -0500 Received: from [199.232.76.173] (port=43839 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L5Ses-0004Ya-5w for qemu-devel@nongnu.org; Wed, 26 Nov 2008 17:14:54 -0500 Received: from e35.co.us.ibm.com ([32.97.110.153]:53961) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1L5Ser-0006zV-Ni for qemu-devel@nongnu.org; Wed, 26 Nov 2008 17:14:53 -0500 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e35.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id mAQMDmaE029021 for ; Wed, 26 Nov 2008 15:13:48 -0700 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mAQMEpZx163318 for ; Wed, 26 Nov 2008 15:14:51 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mAQMEpvY025896 for ; Wed, 26 Nov 2008 15:14:51 -0700 Date: Wed, 26 Nov 2008 16:14:50 -0600 From: Ryan Harper Subject: Re: [Qemu-devel] [PATCH] LSI53C895A: Do not update current_dma_len with dbc in TIA mode Message-ID: <20081126221450.GP31893@us.ibm.com> References: <20081126170709.GK31893@us.ibm.com> <670324.47899.qm@web51105.mail.re2.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <670324.47899.qm@web51105.mail.re2.yahoo.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Justin Chevrier Cc: Ryan Harper , qemu-devel@nongnu.org * Justin Chevrier [2008-11-26 12:08]: > > Even in Table indirect access, we update dbc after fetching > > the transfer > > count (TC) from the table. The tech manual is unclear > > about whether or > > not dbc is updated: > > > > "For a MOVE instruction, the 24-bit byte count is > > fetched > > from system memory. Then the 32-bit physical address is > > brought into the LSI53C895A. Execution of the move > > begins at this point" - LSI53C895A Tech manual, > > page 230. > > > > However, I think in practice, it would have to do so. > > > > It is true that we update the dbc with the length acquired from the > table. Unfortunately it seems the length acquired from the table is > incorrect. Here are snippets of log from the Debian Arm target with > current head. > > We get a command complete with data ready, length 69632. > current_dma_len is updated with this value: > > lsi_scsi: MSG IN 0x80 > lsi_scsi: MSG IN 0x20 > lsi_scsi: MSG IN 0x07 > lsi_scsi: Data ready tag=0x10007 len=69632 Do you also have SCSI debug on in scsi-disk.c ? I'd really like to see the scsi command that was generating the read with lengh 69632. Actually, have you tried this since the 40 bit DMA patch was included? Also, dumping the value in ccntl1 is very useful to understand what block mode the guest is trying to use. > > Then when we issue the TIA block move command the length at the table > entry referenced is wrong (at 4096). The DBC gets updated with this > new incorrect length, which then overwrites dma_current_length and we > only transfer 4096 bytes. We should be able to determine if 4096 is the correct len given the scsi command that is triggering the DMA. > > lsi_scsi: SCRIPTS dsp=50000780 opcode 11000000 arg 000002e8 > lsi_scsi: DMA addr=0x0000c000 len=4096 > lsi_scsi: Command complete sense=0 > > With the patch sent today and how it behaved before my previous patch > the code continues to use an unaltered current_dma_len (which stays at > 69632). > > It seems that the DSA + offset is pointing to the wrong table entry. > I'm looking into this now. > > I just wanted to get this patch out to fix breakages introduced by my > original patch. Yeah, I think for now, the right thing to do is revert the old patch until we figure how to handle this correctly for both test cases. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ryanh@us.ibm.com