From mboxrd@z Thu Jan  1 00:00:00 1970
From: Hannes Reinecke <hare@suse.de>
Subject: Re: [RFC] [PATCH] SCSI passthrough for virtio-blk
Date: Fri, 29 Aug 2008 14:04:01 +0200
Message-ID: <48B7E5B1.2070204@suse.de>
References: <48B7C159.5010800@suse.de> <200808291301.44242.borntraeger@de.ibm.com> <48B7E1D6.4020500@suse.de> <200808291400.47247.borntraeger@de.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15;
	format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: virtualization@lists.linux-foundation.org, kvm@vger.kernel.org
To: Christian Borntraeger <borntraeger@de.ibm.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx2.suse.de ([195.135.220.15]:38606 "EHLO mx2.suse.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1753362AbYH2MED (ORCPT <rfc822;kvm@vger.kernel.org>);
	Fri, 29 Aug 2008 08:04:03 -0400
In-Reply-To: <200808291400.47247.borntraeger@de.ibm.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

Hi Christian,

Christian Borntraeger wrote:
> Am Freitag, 29. August 2008 schrieb Hannes Reinecke:
>> Hmm. Works here, using an unpatched kvm-73.
>> Which version did you use?
>=20
> I use the s390 userspace prototype kuli which uses an virtio transpor=
t similar=20
> to lguest.
>=20
> I retried and it seems to race. Most of the time it works fine, but s=
ometimes=20
> sdparm hangs. I will have a 2nd look.=20
>=20
> sysrq-t gives me the following trace:
>=20
> Call Trace:
> ([<040000000755bc78>] 0x40000000755bc78)
> sdparm        D 000000000043659e     0  2493      1
> 000000000012004a 000000000744f740 000000000744f778 001896469fd23785
>        000000000744f778 00000000009e5500 000000000043f230 00000000001=
20130
>        000000000744f778 0000000006d39400 0000000006d39f80 00000000000=
00001
>        00000000009e6f00 00000000076bf8e8 000000000744f7c8 00000000075=
30670
>        000000000043f610 0000000000435e66 000000000744f7c8 00000000074=
4f868
> Call Trace:
> ([<0000000000435e66>] schedule+0x32e/0x7ec)
>  [<000000000043659e>] schedule_timeout+0xba/0x10c
>  [<00000000004358da>] wait_for_common+0xbe/0x1a8
>  [<000000000027ec3e>] blk_execute_rq+0x86/0xc4
>  [<0000000000282768>] sg_io+0x1a4/0x360
>  [<0000000000282f8c>] scsi_cmd_ioctl+0x2bc/0x3f0
>  [<00000000002c3108>] virtblk_ioctl+0x44/0x58
>  [<000000000027ff18>] blkdev_driver_ioctl+0x98/0xa4
>  [<000000000027ffd8>] blkdev_ioctl+0xb4/0x7f8
>  [<00000000001e1572>] block_ioctl+0x3a/0x48
>  [<00000000001bca0a>] vfs_ioctl+0x52/0xdc
>  [<00000000001bcb0a>] do_vfs_ioctl+0x76/0x350
>  [<00000000001bce6e>] sys_ioctl+0x8a/0xa0
>  [<000000000011282c>] sysc_tracego+0xe/0x14
>  [<0000020000114286>] 0x20000114286

I'm tempted to say 'not my fault'; the submitted SCSI request on
the _host_ hangs and doesn't come back.
Looks more like a SCSI problem on the host ...

Cheers,

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