qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: linux-iscsi-target-dev@googlegroups.com
Cc: Kevin Wolf <kwolf@redhat.com>,
	stefanha@gmail.com, qemu-devel@nongnu.org,
	"Nicholas A. Bellinger" <nab@linux-iscsi.org>,
	kraxel@redhat.com, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] Megasas HBA emulation and SCSI update v.2
Date: Thu, 02 Dec 2010 08:51:18 +0100	[thread overview]
Message-ID: <4CF74FF6.4000105@suse.de> (raw)
In-Reply-To: <1291248853.17194.230.camel@haakon2.linux-iscsi.org>

On 12/02/2010 01:14 AM, Nicholas A. Bellinger wrote:
> On Wed, 2010-12-01 at 16:46 +0100, Hannes Reinecke wrote:
>> On 12/01/2010 03:18 PM, Hannes Reinecke wrote:
>>> Hey Nic,
>>>
>>> On 11/24/2010 10:41 AM, Nicholas A. Bellinger wrote:
>>>> On Mon, 2010-11-22 at 11:34 +0100, Hannes Reinecke wrote:
>>> [ .. ]
>>>>
>>>> Hey Hannes,
>>>>
>>>> Just a heads up, I noticed that the latest v2 megasas w/ scsi-generic ->
>>>> TCM_loop appears to be broken on a Windows7 (Build 7600) guest, which
>>>> hangs during boot -> LUN scan with the following:
>>>>
>>>> truelife:/usr/src/qemu-kvm.git# ./x86_64-softmmu/qemu-system-x86_64 -m 512 -boot c ~/windows7.img \
>>>> 		-drive if=none,id=mydisk1,file=/dev/sg4 -device megasas,id=raid
>>>> 		-device scsi-generic,bus=raid.0,scsi-id=1,drive=mydisk1
>>>>
>>>> megasas: Using 80 sges, 1000 cmds, raid mode
>>>> megasas: Reset
>>>> megasas: Mapping MMIO region 0 at f2040000
>>>> megasas: Mapping IO region 2 at 0000c200
>>>> megasas: Mapping QUEUE region 3 at f2080000
>>>> megasas: Mapping MMIO region 0 at f2040000
>>>> megasas: Mapping IO region 2 at 0000c200
>>>> megasas: Mapping QUEUE region 3 at f2080000
>>>> megasas: Mapping MMIO region 0 at f2040000
>>>> megasas: Mapping IO region 2 at 0000c200
>>>> megasas: Mapping QUEUE region 3 at f2080000
>>>> megasas: readl mmio 0xb0
>>>> megasas: writel mmio 20: 7
>>>> megasas: Reset
>>>> megasas: readl mmio 0x20
>>>> megasas: writel mmio 40: 1ff9c041
>>>> megasas: Received frame addr 1ff9c000 count 32
>>>> megasas: MFI cmd 0 context 0 count 32
>>>> megasas: Return new frame 0 cmd 0x7f7711654330
>>>> megasas: Enqueue frame 0 count 32 context 0 tail 0 busy 1
>>>> megasas: MFI init firmware: xfer len 0 pa 0
>>>> megasas: MFI init firmware: queue at f000ff53f000e2c3 len -268370093 head f000ff53f000ff53 tail f000ff53f000ff53
>>>> megasas: Complete frame context 0
>>>>
>>> Okay, it looks as if I've fixed it up.
>>> Win7 32bit works now with my megasas.v3 tree.
>>> Curiously, Win7 64bit fails; it crashes at relative address
>>> 28F4, wherever that's supposed to be.
>>> And, of course, Windows Vista with newest driver from LSI fails, too
>>> :-(.
>>> Guess I need to do some more debugging here.
>>>
>> Hmpf. Using a new vista x86 image (build 6002) with SP2 preloaded
>> megasas works, too.
>> Dodgy build I had, apparently.
>>
> 
> Thanks for the update..  After testing the lastest megasas.v3 HEAD
> at commit:
> 
> * megasas.v3 978e61e megasas: Fixup PD query return value
> 
> it appears that the same Win7 64-bit Build 7600 that is functioning with
> v0.12.5 windows7-megasas-working will now BSOD the guest.  After further checking
> it appears that this is not megasas HBA specific, and is due to your tree being
> slightly more out of date than mine.  ;)
> 
Yes, this is totally weird. AFAICS the MMIO register data is
_exactly_ identical for both, the old working one and the new
implementation. Yet Win7 is behaving differently in both cases.
So it must be indeed the qemu base which is doing odd things here.

But that's a good hint, I'll be updating my tree and see how far
I'll progress.

> But the good news is that WinXP SP2 is now working via scsi-generic ->
> TCM_Loop in megasas.v3, and even w/o the original sync ioctl patch we
> required  in v0.12.5 megasas code.  Very excellent work Hannes!
> 
> So, I will be merging the latest changes from megasas.v3 -> megasas-upstream-v1
> shortly and retesting with 64-bit Build 7600.
> 
Cool. Thanks. I'll be rebasing my patches, too. I guess it's time
for megasas.v4.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)

  reply	other threads:[~2010-12-02  7:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-22 10:15 [Qemu-devel] [PATCH] Megasas HBA emulation and SCSI update v.2 Hannes Reinecke
2010-11-22 10:34 ` Hannes Reinecke
2010-11-24  9:41   ` Nicholas A. Bellinger
2010-12-01 14:18     ` Hannes Reinecke
2010-12-01 15:46       ` Hannes Reinecke
2010-12-02  0:14         ` Nicholas A. Bellinger
2010-12-02  7:51           ` Hannes Reinecke [this message]
2010-12-02  9:16             ` Nicholas A. Bellinger

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=4CF74FF6.4000105@suse.de \
    --to=hare@suse.de \
    --cc=kraxel@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=linux-iscsi-target-dev@googlegroups.com \
    --cc=nab@linux-iscsi.org \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    /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).