From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L9kWh-0000Ub-ML for qemu-devel@nongnu.org; Mon, 08 Dec 2008 13:08:11 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L9kWe-0000SS-TN for qemu-devel@nongnu.org; Mon, 08 Dec 2008 13:08:10 -0500 Received: from [199.232.76.173] (port=41570 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L9kWe-0000SI-Fv for qemu-devel@nongnu.org; Mon, 08 Dec 2008 13:08:08 -0500 Received: from e38.co.us.ibm.com ([32.97.110.159]:38300) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1L9kWe-00036t-2g for qemu-devel@nongnu.org; Mon, 08 Dec 2008 13:08:08 -0500 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e38.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id mB8I6xiY027734 for ; Mon, 8 Dec 2008 11:06:59 -0700 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mB8I7sWC159726 for ; Mon, 8 Dec 2008 11:07:56 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mB8I7rLB004042 for ; Mon, 8 Dec 2008 11:07:53 -0700 From: Ryan Harper Date: Mon, 8 Dec 2008 12:07:50 -0600 Message-Id: <1228759670-31113-5-git-send-email-ryanh@us.ibm.com> In-Reply-To: <1228759670-31113-1-git-send-email-ryanh@us.ibm.com> References: <1228759670-31113-1-git-send-email-ryanh@us.ibm.com> Subject: [Qemu-devel] [PATCH 4/4] LSI53C895A: Don't reset scratch C-R on soft reset Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Ryan Harper , kvm@vger.kernel.org Debugging 64-bit Linux using the sym53c8xx_2/sym53c8xx.ko driver with SYM_CONF_DMA_ADDRESSING_MODE=2 which uses 64-bit Table Indirect moves, I encountered a situation where the initial probing of the scsi device succeded, but after checking other LUNs besides LUN0, the device would fail to work. This was tracked down to the fact that the Linux driver programs one of the scratch registers to contain the upper 32-bits of the target DMA address and since our emulation doesn't support more than LUN0, it resets the scsi device which results in clearing out the scratch registers. The Linux driver was written against real hardware which I think we can assume does not reset the scratch registers, otherwise this driver would fail on real hardware as well. As such, avoiding resetting scratch registers C-R (ones that can be used for Table Indirect 64-bit mode) fixes the issue for Linux. Signed-off-by: Ryan Harper diff --git a/hw/lsi53c895a.c b/hw/lsi53c895a.c index b36c08c..542d5a0 100644 --- a/hw/lsi53c895a.c +++ b/hw/lsi53c895a.c @@ -276,7 +276,11 @@ static void lsi_soft_reset(LSIState *s) s->dnad = 0; s->dbc = 0; s->temp = 0; - memset(s->scratch, 0, sizeof(s->scratch)); + /* The Linux driver (sym53c8xx) when in 64-bit mode relies on scratch regs + * C-R to not be touched. The Tech manual doesn't dictate that scratch + * registers be cleared. */ + s->scratch[0] = 0; /* reset scratchA */ + s->scratch[1] = 0; /* reset scratchB */ s->istat0 = 0; s->istat1 = 0; s->dcmd = 0;