From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L4lk4-0000tb-6w for qemu-devel@nongnu.org; Mon, 24 Nov 2008 19:25:24 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L4lk2-0000tP-MB for qemu-devel@nongnu.org; Mon, 24 Nov 2008 19:25:22 -0500 Received: from [199.232.76.173] (port=32885 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L4lk2-0000tM-Jl for qemu-devel@nongnu.org; Mon, 24 Nov 2008 19:25:22 -0500 Received: from rv-out-0708.google.com ([209.85.198.245]:38498) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L4lk2-00021f-5k for qemu-devel@nongnu.org; Mon, 24 Nov 2008 19:25:22 -0500 Received: by rv-out-0708.google.com with SMTP id f25so2174721rvb.22 for ; Mon, 24 Nov 2008 16:25:20 -0800 (PST) Message-ID: Date: Tue, 25 Nov 2008 01:25:20 +0100 From: "andrzej zaborowski" Subject: Re: [Qemu-devel] [5706] Implement LSI53C895A quirks exposed by OpenServer (Justin Chevrier). In-Reply-To: <20081124235120.GG31893@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081124231051.GE31893@us.ibm.com> <20081124231857.GF31893@us.ibm.com> <20081124235120.GG31893@us.ibm.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ryan Harper Cc: qemu-devel@nongnu.org Hi, 2008/11/25 Ryan Harper : > * Ryan Harper [2008-11-24 17:19]: >> * Ryan Harper [2008-11-24 17:12]: >> > * Andrzej Zaborowski [2008-11-12 10:50]: >> > > Revision: 5706 >> > > http://svn.sv.gnu.org/viewvc/?view=rev&root=qemu&revision=5706 >> > > Author: balrog >> > > Date: 2008-11-12 16:41:32 +0000 (Wed, 12 Nov 2008) >> > > >> > > Log Message: >> > > ----------- >> > > Implement LSI53C895A quirks exposed by OpenServer (Justin Chevrier). >> > > >> > > After going through the debug log and scratching my head for quite some >> > > time. I found the following: >> > > >> > > The problem was with this block move: >> > > >> > > lsi_scsi: SCRIPTS dsp=0fae8e50 opcode 01000028 arg 00f63c40 >> > > lsi_scsi: DMA addr=0x00f63c40 len=36 >> > > >> > > The number of bytes to be transferred (len) should be 40 which corresponds >> > > to the block transfer of length 0x28 (from opcode 01000028). Instead we >> > > have a length of 36 (0x24). The code responsible for this is (in >> > > 'lsi_do_dma'): >> > > >> > > if (count > s->current_dma_len) >> > > count = s->current_dma_len; >> > > >> > > Basically we're overwriting the length 40 with the value 36 which I >> > > think we just left over in that variable from an earlier transfer. In my >> > > patch below I initialize s->current_dma_len to s->dbc before we begin >> > > the DMA transfer during Data In phase. >> > > >> > > The attached patch gets Openserver 5.0.5 past the hardware detection >> > > (and it lists the hard drive to boot, woohoo). It appears to stop a >> > > little while later (doesn't seem SCSI related), but it's been so long since >> > > I've booted Openserver I'm not sure what's supposted to happen after the HW >> > > detection using the boot/root disks. >> > > >> > > Props go to Craig Ringer for the initial post and the code that he posted >> > > some of which is in this patch. >> > >> > This patch breaks WinXP SP3 32-bit install to scsi device. After >> > attempting to format a partition on the scsi device, Windows says there >> > is an error formating the partition. If I revert the patch, formating >> > and installation to a scsi disk works ok. Laurent Desnogues also found an issue with SCSI under versatilepb (ARM) and narrowed it down to the addition of the line s->current_dma_len = s->dbc; He let me know about it on IRC, sorry for not telling the list until now. I haven't yet had time to dig into the problem but I emailed the author of the patch and he found something interesting, see below. >> > >> > I haven't dug into what part of the patch is breaking it just yet, but >> > plan to do so. >> >> Looks like dropping this line gets the install working again: > > That isn't it. Actually, dropping the dma len update fixes it 100% of > the time. > > - s->current_dma_len = s->dbc; I'm afraid that works because it largely nullifies the effect of the patch, so it's like reverting it. Justin Chevrier who came up with the original patch, also looked into the issue with versatilepb and proposed the following temporary workaround: --- hw/lsi53c895a.c (revision 5781) +++ hw/lsi53c895a.c (working copy) @@ -920,7 +920,8 @@ break; case PHASE_DI: s->waiting = 2; - s->current_dma_len = s->dbc; + if (!(insn & (1 << 28))) /* TIA Hack */ + s->current_dma_len = s->dbc; lsi_do_dma(s, 0); if (s->waiting) s->waiting = 3; He noticed that the patch uncovered an endiannes issue somewhere in lsi53c895a.c due to which the comparison that we added doesn't work on some target/host pairs. This is the issue that should be fixed next. Cheers