qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [5706] Implement LSI53C895A quirks exposed by OpenServe


From: Ryan Harper
Subject: Re: [Qemu-devel] [5706] Implement LSI53C895A quirks exposed by OpenServer (Justin Chevrier).
Date: Mon, 24 Nov 2008 17:51:20 -0600
User-agent: Mutt/1.5.6+20040907i

* Ryan Harper <address@hidden> [2008-11-24 17:19]:
> * Ryan Harper <address@hidden> [2008-11-24 17:12]:
> > * Andrzej Zaborowski <address@hidden> [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.
> > 
> > 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'd like to understand what's going on here before commiting a fix just
yet.  Maybe revert the patch and dig in a bit because I believe your
observation about the len seems accurate, but it certainly causes issues
for XP SP3 installs.  

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]