When using the commands below to write some data to a virtio-scsi LUN of the
QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will crash.
# sudo mkfs.ext4 /dev/sdb (/dev/sdb is the virtio-scsi LUN.)
# sudo mount /dev/sdb /mnt
# dd if=/dev/zero of=/mnt/fi
Il 25/07/2012 10:29, Wang Sen ha scritto:
> When using the commands below to write some data to a virtio-scsi LUN of the
> QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will crash.
>
> # sudo mkfs.ext4 /dev/sdb (/dev/sdb is the virtio-scsi LUN.)
> # sudo mount /d
On 07/25/2012 11:44 AM, Paolo Bonzini wrote:
> Il 25/07/2012 10:29, Wang Sen ha scritto:
>> When using the commands below to write some data to a virtio-scsi LUN of the
>> QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will
>> crash.
>>
>> # sudo mkfs.ext4 /dev/sdb (/de
Il 25/07/2012 11:22, Boaz Harrosh ha scritto:
>>> >> for_each_sg(table->sgl, sg_elem, table->nents, i)
>>> >> -sg_set_buf(&sg[idx++], sg_virt(sg_elem),
>>> >> sg_elem->length);
>>> >> +sg_set_page(&sg[idx++], sg_page(sg_elem),
>>> >> sg_elem->length,
>>> >
Am 25.07.2012 10:29, schrieb Wang Sen:
When using the commands below to write some data to a virtio-scsi LUN
of the
QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu
will crash.
# sudo mkfs.ext4 /dev/sdb (/dev/sdb is the virtio-scsi LUN.)
# sudo mount /dev/sdb
On Wed, Jul 25, 2012 at 04:00:19PM +0800, Wang Sen wrote:
> When using the commands below to write some data to a virtio-scsi LUN of the
> QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will crash.
>
> # sudo mkfs.ext4 /dev/sdb (/dev/sdb is the virtio-scsi LUN.)
>
Hi,
We have done some analysis on this issue. From our analysis we observed that,
this issue is reproducible on kernel 3.1.10 onwards but in 3.0.36 this issue is
not reproducible. So, we have taken the mpt2sas code from 3.1.10 kernel and
compiled and run it on 3.0.36 kernel. Here this issue is
On Wed, Jul 25, 2012 at 10:44:14AM +0200, Paolo Bonzini wrote:
> Il 25/07/2012 10:29, Wang Sen ha scritto:
> > When using the commands below to write some data to a virtio-scsi LUN of
> > the
> > QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will
> > crash.
> >
> > # su
2012/7/25 Paolo Bonzini :
> Il 25/07/2012 10:29, Wang Sen ha scritto:
>> When using the commands below to write some data to a virtio-scsi LUN of the
>> QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will
>> crash.
>>
>> # sudo mkfs.ext4 /dev/sdb (/dev/sdb is the virtio-
2012/7/25 Rolf Eike Beer :
> Am 25.07.2012 10:29, schrieb Wang Sen:
>
>> When using the commands below to write some data to a virtio-scsi LUN of
>> the
>> QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu
>> will crash.
>>
>> # sudo mkfs.ext4 /dev/sdb (/dev/sdb is the vir
2012/7/25 Stefan Hajnoczi :
> On Wed, Jul 25, 2012 at 10:44:14AM +0200, Paolo Bonzini wrote:
>> Il 25/07/2012 10:29, Wang Sen ha scritto:
>> > When using the commands below to write some data to a virtio-scsi LUN of
>> > the
>> > QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu w
On Tue, Jul 24, 2012 at 01:45:24PM -0700, Nicholas A. Bellinger wrote:
> On Mon, 2012-07-23 at 18:56 -0700, Greg Kroah-Hartman wrote:
> > On Tue, Jul 24, 2012 at 01:26:20AM +, Nicholas A. Bellinger wrote:
> > > From: Nicholas Bellinger
> > >
> > > As requested by Anthony, here is a patch agai
On 07/11/2012 05:18 PM, Alasdair G Kergon wrote:
> On Tue, Jun 26, 2012 at 02:32:05PM -0400, Mike Snitzer wrote:
>> The new 'no_partitions' feature serves as a notifier to kpartx to _not_
>> create partitions on these multipath devices.
>
> This isn't really multipath-specific so doesn't belong i
On 07/17/2012 11:11 AM, James Bottomley wrote:
> On Tue, 2012-07-17 at 10:54 +0200, Paolo Bonzini wrote:
>> Il 17/07/2012 10:40, James Bottomley ha scritto:
>
> It's not specific to virtio-scsi, in fact I expect that virtio-scsi will
> be almost always used with non-removable disks.
>>>
When using the commands below to write some data to a virtio-scsi LUN of the
QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will crash.
# sudo mkfs.ext4 /dev/sdb (/dev/sdb is the virtio-scsi LUN.)
# sudo mount /dev/sdb /mnt
# dd if=/dev/zero of=/mnt/fil
On Wed, 2012-07-25 at 20:13 +0800, Wang Sen wrote:
> When using the commands below to write some data to a virtio-scsi LUN of the
> QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will crash.
>
> # sudo mkfs.ext4 /dev/sdb (/dev/sdb is the virtio-scsi LUN.)
> # s
Il 25/07/2012 14:13, Wang Sen ha scritto:
> When using the commands below to write some data to a virtio-scsi LUN of the
> QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will crash.
>
> # sudo mkfs.ext4 /dev/sdb (/dev/sdb is the virtio-scsi LUN.)
> # sudo mount
On 07/25/2012 12:41 PM, Paolo Bonzini wrote:
> Il 25/07/2012 11:22, Boaz Harrosh ha scritto:
>> for_each_sg(table->sgl, sg_elem, table->nents, i)
>> -sg_set_buf(&sg[idx++], sg_virt(sg_elem),
>> sg_elem->length);
>> +sg_set_page(&sg[idx++],
On 07/25/2012 02:44 PM, Sen Wang wrote:
> 2012/7/25 Paolo Bonzini :
>> Il 25/07/2012 10:29, Wang Sen ha scritto:
>>> When using the commands below to write some data to a virtio-scsi LUN of the
>>> QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will
>>> crash.
>>>
>>> #
On 07/25/2012 03:34 PM, Paolo Bonzini wrote:
> Il 25/07/2012 14:13, Wang Sen ha scritto:
>> When using the commands below to write some data to a virtio-scsi LUN of the
>> QEMU guest(32-bit) with 1G physical memory(qemu -m 1024), the qemu will
>> crash.
>>
>> # sudo mkfs.ext4 /dev/sdb (/
Il 25/07/2012 14:34, Boaz Harrosh ha scritto:
>>> for_each_sg(table->sgl, sg_elem, table->nents, i)
>>> - sg_set_buf(&sg[idx++], sg_virt(sg_elem),
>>> sg_elem->length);
>>> + sg_set_page(&sg[idx++], sg_page(sg_elem),
>>> sg_elem->length,
>>>
Il 25/07/2012 14:47, Boaz Harrosh ha scritto:
>
> NACK-by: Boaz Harrosh
>
>
> Apart from the HighMem pages problem, where in previous sg_set_buf()
> code was the marker copied? It was not because it is not needed because
> the allocation of sg took care of that. For example in 64bit the is no
>
On 07/24/2012 11:45 PM, Nicholas A. Bellinger wrote:
>> > diff --git a/drivers/vhost/tcm_vhost.h b/drivers/vhost/tcm_vhost.h
>> > index e942df9..3d5378f 100644
>> > --- a/drivers/vhost/tcm_vhost.h
>> > +++ b/drivers/vhost/tcm_vhost.h
>> > @@ -80,7 +80,17 @@ struct tcm_vhost_tport {
>> >
>> > #i
On 07/25/2012 03:49 PM, Paolo Bonzini wrote:
>
> Except here the destination array has to be given to virtio, which
> doesn't (yet) understand chaining. I'm using for_each_sg rather than a
> simple memcpy exactly because I want to flatten the input scatterlist
> onto consecutive scatterlist entr
Il 25/07/2012 15:26, Boaz Harrosh ha scritto:
> On 07/25/2012 03:49 PM, Paolo Bonzini wrote:
>
>>
>> Except here the destination array has to be given to virtio, which
>> doesn't (yet) understand chaining. I'm using for_each_sg rather than a
>> simple memcpy exactly because I want to flatten the
Il 25/07/2012 15:26, Boaz Harrosh ha scritto:
>>> In SCSI land most LLDs should support chaining just by virtu of using the
>>> for_each_sg macro. That all it takes. Your code above does support it.
>>
>> Yes, it supports it but still has to undo them before passing to virtio.
>>
>> What my LLD doe
On Sun, 2012-07-22 at 10:31 -0700, Tejun Heo wrote:
> Hello,
>
> On Sat, Jul 21, 2012 at 02:15:56PM +0200, Matthias Prager wrote:
> > Now I'm not sure this isn't taping over another bug. Which leads me to
> > my question: What is the correct behavior?
> >
> > #1 Issuing a separate spin-up command
On 07/25/2012 04:36 PM, Paolo Bonzini wrote:
> Il 25/07/2012 15:26, Boaz Harrosh ha scritto:
>> On 07/25/2012 03:49 PM, Paolo Bonzini wrote:
>>
>>>
>>> Except here the destination array has to be given to virtio, which
>>> doesn't (yet) understand chaining. I'm using for_each_sg rather than a
>>>
Il 25/07/2012 16:36, Boaz Harrosh ha scritto:
>> >
>> > I did test the patch with value-assignment.
>> >
>
> Still you should use the sg_set_page()!!
> 1. It is not allowed to directly manipulate sg entries. One should always
>use the proper accessor. Even if open coding does work and is not
Il 25/07/2012 17:09, Paolo Bonzini ha scritto:
> Il 25/07/2012 16:36, Boaz Harrosh ha scritto:
I did test the patch with value-assignment.
>>
>> Still you should use the sg_set_page()!!
>> 1. It is not allowed to directly manipulate sg entries. One should always
>>use the proper
On 07/25/2012 05:17 PM, Paolo Bonzini wrote:
> Il 25/07/2012 15:26, Boaz Harrosh ha scritto:
In SCSI land most LLDs should support chaining just by virtu of using the
for_each_sg macro. That all it takes. Your code above does support it.
>>>
>>> Yes, it supports it but still has to undo
Hello
I have a setup with a 12 daisy chained EXP3000 enclosures connected to
a server such that each of the disks are accessible via two paths
through multiple sas expanders. The server has 2 dual ported HBAs. I'm
running 2.6.32 kernel variant based on RHEL 6.0. I have seen this on
2.6.31 as well
Hello, James.
On Wed, Jul 25, 2012 at 06:19:13PM +0400, James Bottomley wrote:
> > I haven't consulted SAT but it seems like a bug in SAS driver or
> > firmware. If it's a driver bug, we better fix it there. If a
> > firmware bug, working around those is one of major roles of drivers,
> > so I t
Il 25/07/2012 17:28, Boaz Harrosh ha scritto:
>> 1) what I get is a scsi_cmnd which contains an N-element scatterlist.
>>
>> 2) virtio-scsi has to build the "packet" that is passed to the hardware
>> (it does not matter that the hardware is virtual). This packet (per
>> virtio-scsi spec) has an N+
The following v3.4-rc1 commit unmasked an existing bug in
scsi_io_completion's SG_IO error handling:
47ac56d [SCSI] scsi_error: classify some ILLEGAL_REQUEST sense as a permanent
TARGET_ERROR
Given that certain ILLEGAL_REQUEST are now properly categorized as
TARGET_ERROR the host_byte is being se
On 07/10/2012 12:06 AM, Dan Williams wrote:
libsas and ipr pass flags to ata_host_init that are meant for the port.
ata_host flags:
ATA_HOST_SIMPLEX= (1 << 0), /* Host is simplex, one DMA
channel per host only */
ATA_HOST_STARTED= (1 << 1), /* Host st
On 07/25/2012 08:43 PM, Paolo Bonzini wrote:
> Il 25/07/2012 17:28, Boaz Harrosh ha scritto:
>>> 1) what I get is a scsi_cmnd which contains an N-element scatterlist.
>>>
>>> 2) virtio-scsi has to build the "packet" that is passed to the hardware
>>> (it does not matter that the hardware is virtua
On Wed, 2012-07-25 at 10:17 -0700, Tejun Heo wrote:
> Hello, James.
>
> On Wed, Jul 25, 2012 at 06:19:13PM +0400, James Bottomley wrote:
> > > I haven't consulted SAT but it seems like a bug in SAS driver or
> > > firmware. If it's a driver bug, we better fix it there. If a
> > > firmware bug, w
Il 25/07/2012 21:16, Boaz Harrosh ha scritto:
> The picture confused me. It looked like the first element is the
> virtio_scsi_cmd_req
> not an sgilist-element that points to the struct's buffer.
>
> In that case then yes your plan of making a two-elements fragment that points
> to the
> origina
On 07/09/2012 11:06 PM, Dan Williams wrote:
> libsas and ipr pass flags to ata_host_init that are meant for the port.
>
> ata_host flags:
> ATA_HOST_SIMPLEX= (1 << 0), /* Host is simplex, one DMA
> channel per host only */
> ATA_HOST_STARTED= (1 << 1), /* Host
On Tue, 24 July 2012 09:01:41 +0400, James Bottomley wrote:
> On Mon, 2012-07-23 at 15:24 -0400, Jörn Engel wrote:
> > On Mon, 23 July 2012 23:45:55 +0400, James Bottomley wrote:
> > >
> > > Have you checked this with the patches in scsi-misc? There's a series
> > > of patches in there that alter
On Wed, Jul 25, 2012 at 04:35:51PM -0400, Jeff Garzik wrote:
> Please pull 641589bff714f39b33ef1d7f02eaa009f2993b64 from
> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
> tags/upstream
>
Oh, I forgot to point out the merge commit, making my HEAD more recent
than might be e
On 07/25/2012 11:06 PM, Paolo Bonzini wrote:
> Il 25/07/2012 21:16, Boaz Harrosh ha scritto:
>> The picture confused me. It looked like the first element is the
>> virtio_scsi_cmd_req
>> not an sgilist-element that points to the struct's buffer.
>>
>> In that case then yes your plan of making a t
On Wed, 2012-07-25 at 16:10 +0300, Avi Kivity wrote:
> On 07/24/2012 11:45 PM, Nicholas A. Bellinger wrote:
>
> >> > diff --git a/drivers/vhost/tcm_vhost.h b/drivers/vhost/tcm_vhost.h
> >> > index e942df9..3d5378f 100644
> >> > --- a/drivers/vhost/tcm_vhost.h
> >> > +++ b/drivers/vhost/tcm_vhost.h
On Wed, 2012-07-25 at 12:55 +0100, Stefan Hajnoczi wrote:
> On Tue, Jul 24, 2012 at 01:45:24PM -0700, Nicholas A. Bellinger wrote:
> > On Mon, 2012-07-23 at 18:56 -0700, Greg Kroah-Hartman wrote:
> > > On Tue, Jul 24, 2012 at 01:26:20AM +, Nicholas A. Bellinger wrote:
> > > > From: Nicholas Bel
On 07/25/2012 04:35 PM, Jeff Garzik wrote:
Please pull 641589bff714f39b33ef1d7f02eaa009f2993b64 from
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
tags/upstream
(text copied from the upstream-linus tag)
Notable changes:
* Updating libata to directly bind with ACPI / run
On Wed, Jul 25, 2012 at 1:43 PM, Jeff Garzik wrote:
> On Wed, Jul 25, 2012 at 04:35:51PM -0400, Jeff Garzik wrote:
>> Please pull 641589bff714f39b33ef1d7f02eaa009f2993b64 from
>> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
>> tags/upstream
>>
>
> Oh, I forgot to point out
On 07/25/2012 06:06 PM, Linus Torvalds wrote:
On Wed, Jul 25, 2012 at 1:43 PM, Jeff Garzik wrote:
On Wed, Jul 25, 2012 at 04:35:51PM -0400, Jeff Garzik wrote:
Please pull 641589bff714f39b33ef1d7f02eaa009f2993b64 from
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
tags/up
On Wed, Jul 25, 2012 at 3:26 PM, Jeff Garzik wrote:
>
> Even so, separately, it still needed that post-merge compile fix.
And that's yet another example of how *NOT* to do things.
If the merge has errors like that, then they should be fixed up in the merge.
Please. Don't do this. Let me merge s
On Wed, Jul 25, 2012 at 02:14:50PM -0700, Nicholas A. Bellinger wrote:
> On Wed, 2012-07-25 at 12:55 +0100, Stefan Hajnoczi wrote:
> > On Tue, Jul 24, 2012 at 01:45:24PM -0700, Nicholas A. Bellinger wrote:
> > > On Mon, 2012-07-23 at 18:56 -0700, Greg Kroah-Hartman wrote:
> > > > On Tue, Jul 24, 20
Tejun Heo kernel.org> writes:
>
> Hello,
>
> On Sat, Jul 21, 2012 at 02:15:56PM +0200, Matthias Prager wrote:
> > Now I'm not sure this isn't taping over another bug. Which leads me to
> > my question: What is the correct behavior?
> >
> > #1 Issuing a separate spin-up command (START UNIT?) pr
On 07/25/2012 06:31 PM, Linus Torvalds wrote:
On Wed, Jul 25, 2012 at 3:26 PM, Jeff Garzik wrote:
Even so, separately, it still needed that post-merge compile fix.
And that's yet another example of how *NOT* to do things.
If the merge has errors like that, then they should be fixed up in th
James, is there any update available about the pull of the driver changes that
Dan mentioned? Please let me know if there is anything we need to do to assist.
Regards,
-Original Message-
From: linux-scsi-ow...@vger.kernel.org
[mailto:linux-scsi-ow...@vger.kernel.org] On Behalf Of Da
On Wed, Jul 25, 2012 at 3:58 PM, Jeff Garzik wrote:
>
> What is the right course in when a post-merge change is needed?
Just describe the issue and the required change. Than I can just do it
as part of the merge, and now the whole series is bisectable,
including the merge itself.
Here's a (fairl
Hello James,
Am 25.07.2012 21:55, schrieb James Bottomley:>
> It looks like a hack like this might be needed.
>
> James
>
I don't yet understand all the code but I'm following your discussion
with Tejun: I've set up a minimal vm running gentoo with a mpt2sas
driven controller in passthrough mod
On 07/25/2012 07:30 PM, Linus Torvalds wrote:
On Wed, Jul 25, 2012 at 3:58 PM, Jeff Garzik wrote:
What is the right course in when a post-merge change is needed?
Just describe the issue and the required change. Than I can just do it
as part of the merge, and now the whole series is bisectabl
On Wed, 2012-07-25 at 23:35 +0100, Stefan Hajnoczi wrote:
> On Wed, Jul 25, 2012 at 02:14:50PM -0700, Nicholas A. Bellinger wrote:
> > On Wed, 2012-07-25 at 12:55 +0100, Stefan Hajnoczi wrote:
> > > On Tue, Jul 24, 2012 at 01:45:24PM -0700, Nicholas A. Bellinger wrote:
> > > > On Mon, 2012-07-23 at
On 07/26/2012 05:38 AM, Jeff Garzik wrote:
On 07/25/2012 04:35 PM, Jeff Garzik wrote:
* Updating libata to directly bind with ACPI / runtime power mgmt.
This is a pre-req for SATA ZPODD (CD-ROM power management).
Touches ACPI (exports++) and SCSI in minor ways. Has been in linux-next
for weeks.
On Thu, 2012-07-26 at 12:47 +0800, Aaron Lu wrote:
> On 07/26/2012 05:38 AM, Jeff Garzik wrote:
> > On 07/25/2012 04:35 PM, Jeff Garzik wrote:
> >> * Updating libata to directly bind with ACPI / runtime power mgmt.
> >> This is a pre-req for SATA ZPODD (CD-ROM power management).
> >>
> >> Touches A
On Wed, 2012-07-25 at 23:08 +, Skirvin, Jeffrey D wrote:
> James, is there any update available about the pull of the driver changes that
> Dan mentioned? Please let me know if there is anything we need to do to
> assist.
Oh, oops. When I had to rebase the branches to accommodate Linus' fix
On 07/26/2012 01:05 PM, James Bottomley wrote:
On Thu, 2012-07-26 at 12:47 +0800, Aaron Lu wrote:
On 07/26/2012 05:38 AM, Jeff Garzik wrote:
On 07/25/2012 04:35 PM, Jeff Garzik wrote:
* Updating libata to directly bind with ACPI / runtime power mgmt.
This is a pre-req for SATA ZPODD (CD-ROM po
61 matches
Mail list logo
