qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Ryan Harper <ryanh@us.ibm.com>
To: Andrzej Zaborowski <balrogg@gmail.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [5706] Implement LSI53C895A quirks exposed by OpenServer (Justin Chevrier).
Date: Mon, 24 Nov 2008 17:10:51 -0600	[thread overview]
Message-ID: <20081124231051.GE31893@us.ibm.com> (raw)
In-Reply-To: <E1L0Imb-000843-E8@cvs.savannah.gnu.org>

* Andrzej Zaborowski <balrogg@gmail.com> [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.


-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh@us.ibm.com

  reply	other threads:[~2008-11-24 23:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-12 16:41 [Qemu-devel] [5706] Implement LSI53C895A quirks exposed by OpenServer (Justin Chevrier) Andrzej Zaborowski
2008-11-24 23:10 ` Ryan Harper [this message]
2008-11-24 23:18   ` Ryan Harper
2008-11-24 23:51     ` Ryan Harper
2008-11-25  0:25       ` andrzej zaborowski
  -- strict thread matches above, loose matches on Subject: below --
2008-11-25  6:00 Justin Chevrier
2008-11-25 16:10 ` Ryan Harper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081124231051.GE31893@us.ibm.com \
    --to=ryanh@us.ibm.com \
    --cc=balrogg@gmail.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).