From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L9prZ-0001UY-HU for qemu-devel@nongnu.org; Mon, 08 Dec 2008 18:50:05 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L9prX-0001TW-W9 for qemu-devel@nongnu.org; Mon, 08 Dec 2008 18:50:04 -0500 Received: from [199.232.76.173] (port=60923 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L9prX-0001TS-QY for qemu-devel@nongnu.org; Mon, 08 Dec 2008 18:50:03 -0500 Received: from e8.ny.us.ibm.com ([32.97.182.138]:56425) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1L9prX-0006cd-BY for qemu-devel@nongnu.org; Mon, 08 Dec 2008 18:50:03 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e8.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id mB8Nj5oI008056 for ; Mon, 8 Dec 2008 18:45:05 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mB8Nnn3p193224 for ; Mon, 8 Dec 2008 18:49:49 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mB90nxIM010593 for ; Mon, 8 Dec 2008 19:49:59 -0500 Date: Mon, 8 Dec 2008 17:49:44 -0600 From: Ryan Harper Subject: Re: [Qemu-devel] [PATCH 3/4] LSI53C895A: Implement TARGET RESET message Message-ID: <20081208234944.GM13481@us.ibm.com> References: <1228759670-31113-1-git-send-email-ryanh@us.ibm.com> <200812081838.23464.paul@codesourcery.com> <20081208185827.GL13481@us.ibm.com> <200812082336.34006.paul@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200812082336.34006.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Ryan Harper , qemu-devel@nongnu.org, kvm@vger.kernel.org * Paul Brook [2008-12-08 17:37]: > > > Which I figured was because lsi_soft_reset doesn't initialize > > current_dma_len. I added current_dma_len to soft_reset and now we can > > probe with out failing, and existing partitions on the device show up, > > but any further use of the device results in broken behavior. > >... > > Because the driver is issueing bus resets, we're clobbering the scratch > > registers. > > In that case I'm still very suspicious of your parch. Why are you clearing > some of the scratch registers? It sounds like you need to separate a bus > reset from a hard reset. Well, what linux calls bus reset is what is currently wired up to lsi_soft_reset: if (val & LSI_ISTAT0_SRST) { lsi_soft_reset(s); } That's the only caller of lsi_soft_reset() besides device init. I am digging deep trying to find out why linux does a bus reset. It happens after handling a REPORT LUNS command, which if I'm reading scsi-disk.c right, we return just LUN0 in the list. Linux then walks the results of the REPORT LUNS command sending inquiry commands to each one. Since I don't have this pinned down as well as I thought I did, I'd appreciate any comments on the first 2 patches. The last two patches are to address a rather uncommon mode of the linux driver so, if the first two patches are acceptable, I'd like to see those go in. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ryanh@us.ibm.com