On 08/29/12 05:12, Dan Williams wrote:
> John reports:
> BUG: soft lockup - CPU#2 stuck for 23s! [kworker/u:8:2202]
> [..]
> Call Trace:
> [] scsi_remove_target+0xda/0x1f0
> [] sas_rphy_remove+0x55/0x60
> [] sas_rphy_delete+0x11/0x20
> [] sas_port_delete+0x25/0x160
> [] mptsas_del_end_
John reports:
BUG: soft lockup - CPU#2 stuck for 23s! [kworker/u:8:2202]
[..]
Call Trace:
[] scsi_remove_target+0xda/0x1f0
[] sas_rphy_remove+0x55/0x60
[] sas_rphy_delete+0x11/0x20
[] sas_port_delete+0x25/0x160
[] mptsas_del_end_device+0x183/0x270
...introduced by commit 3b661a9 "[SCS
Hi Dan,
This fix should go into stable tree too, as I know several stable tree
already include commit 3b661a9. Maybe James can add stable cc.
Best regards!
Jack
> John reports:
> BUG: soft lockup - CPU#2 stuck for 23s! [kworker/u:8:2202]
> [..]
> Call Trace:
> [] scsi_remove_target+0xda/0x1
John reports:
BUG: soft lockup - CPU#2 stuck for 23s! [kworker/u:8:2202]
[..]
Call Trace:
[] scsi_remove_target+0xda/0x1f0
[] sas_rphy_remove+0x55/0x60
[] sas_rphy_delete+0x11/0x20
[] sas_port_delete+0x25/0x160
[] mptsas_del_end_device+0x183/0x270
...introduced by commit 3b661a9 "[SCS
From: "Martin K. Petersen"
Add a parameter that allows the host protection capabilities mask to be
provided at module load time.
Signed-off-by: Martin K. Petersen
Cc: nagalakshmi.nandig...@lsi.com
Cc: eric.mo...@lsi.com
---
drivers/scsi/mpt2sas/mpt2sas_scsih.c | 15 +--
1 files c
From: "Martin K. Petersen"
Only a target device should return ABORTED COMMAND when a PI error is
discovered. The HBA should always set the sense key to ILLEGAL REQUEST.
Signed-off-by: Martin K. Petersen
Cc: nagalakshmi.nandig...@lsi.com
Cc: eric.mo...@lsi.com
---
drivers/scsi/mpt2sas/mpt2sas_s
From: "Martin K. Petersen"
Hitachi Ultrastar 15K300 is quirky. Disable T10 PI (DIF).
Signed-off-by: Martin K. Petersen
---
drivers/scsi/scsi_devinfo.c |1 +
drivers/scsi/scsi_scan.c|3 +++
include/scsi/scsi_device.h |4
include/scsi/scsi_devinfo.h |1 +
4 files change
From: "Martin K. Petersen"
We have encountered a few devices that misbehaved when operating in T10
PI mode. Allow T10 PI protection type to be overridden from userland.
Signed-off-by: Martin K. Petersen
---
drivers/scsi/sd.c | 25 -
1 files changed, 24 insertions(+),
From: "Martin K. Petersen"
It does not make sense to translate ref tags with unexpected values.
Instead we simply ignore them and let the upper layers catch the
problem. Ref tags that contain the expected value are still remapped.
Signed-off-by: Martin K. Petersen
---
drivers/scsi/sd.c |
As an aid to users with 512e drives and disk arrays we now keep track of
whether submitted I/O requests are aligned to the block sizes contained
in the queue limits. We record whether each request is a properly
aligned multiple of the optimal, minumum, physical and logical block
sizes respectively
Export rq_timeout in sysfs for block devices since it is a request_queue
property. Until now it has only been possible to explicitly set this for
SCSI class devices.
Also introduce eh_timeout which can be used for error handling
purposes. This was previously hardcoded to 10 seconds in the SCSI er
>> [ 174.758218] scsi_remove_target[0]: reap 0:0 state: 2 reap: 1 dev_del: 1
>
> Thanks! Does the attached patch fix the issue for you?
>
That worked!
[ 169.402990] netconsole: network logging started
[ 200.903700] mptbase: ioc0: LogInfo(0x31110d00): Originator={PL},
Code={Reset}, SubCode(0x0
On Tue, 2012-08-28 at 10:03 -0400, John Drescher wrote:
> > I wonder if we are preventing scsi_device_dev_release_usercontext() from
> > making forward progress?
> >
> > ...the attached patch should confirm this or give more info otherwise.
> >
>
> [ 174.758218] scsi_remove_target[0]: reap 0:0 st
If state is NON_BLOCKING and mutex_trylock is succeed,
the control flow goes to mutex_lock_interruptible() that is a deadlock.
The previous version of the patch becomes obsolete after
code movement in commit 913809f6.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by:
Il 28/08/2012 16:07, Sasha Levin ha scritto:
>> > - num_targets = sh->max_id;
>> > - for (i = 0; i < num_targets; i++) {
>> > - kfree(vscsi->tgt[i]);
>> > - vscsi->tgt[i] = NULL;
>> > + if (vscsi->tgt) {
>> > + num_targets = sh->max_id;
>> > + for (i = 0; i <
On 08/28/2012 01:54 PM, Paolo Bonzini wrote:
> We will place the request virtqueues in the flexible array member.
>
> Refining the virtqueue API would let us drop the sglist copy, at
> which point the pointer-to-array-of-pointers can become a simple
> pointer-to-array. It would both simplify the
> I wonder if we are preventing scsi_device_dev_release_usercontext() from
> making forward progress?
>
> ...the attached patch should confirm this or give more info otherwise.
>
[ 148.960318] console [netcon0] enabled
[ 148.960363] netconsole: network logging started
[ 170.415487] mptbase: ioc
On 08/28/12 12:25, Dongsu Park wrote:
> By the way, as long as I've observed today, the crash occurs only if
> rport_dev_loss_timedout() is called. It means, without device loss,
> a simple rport_delete does not make any crash.
>
> Is that probably because arguments to pr_err() are accessing to in
Hi Bart,
On 28.08.2012 10:04, Bart Van Assche wrote:
> On 08/27/12 18:37, Dongsu Park wrote:
> > while testing ib_srp based on your srp-ha,
> > we sometimes hit kernel crashes with the call trace below.
> >
> > How to reproduce:
> >
> > 0. Kernel 3.2.15 with SCST v4193 on the target,
> >Kern
From: Richard W.M. Jones
The sg struct for events is used without being initialized. This
triggers a BUG_ON if CONFIG_DEBUG_SG is defined.
This was reported at https://bugzilla.redhat.com/show_bug.cgi?id=847548.
Signed-off-by: Richard W.M. Jones
Signed-off-by: Paolo Bonzini
---
drivers/scsi
James,
here are three important bugfixes for virtio-scsi. All three have been
on the list for a while, I'm grouping them in this post to ease your
processing.
Two of them are also marked for stable branches.
Paolo
Paolo Bonzini (1):
virtio-scsi: fix LUNs greater than 255
Richard W.M. Jones
This patch adds queue steering to virtio-scsi. When a target is sent
multiple requests, we always drive them to the same queue so that FIFO
processing order is kept. However, if a target was idle, we can choose
a queue arbitrarily. In this case the queue is chosen according to the
current VCPU,
This will be needed soon in order to retrieve the per-target
struct.
Signed-off-by: Paolo Bonzini
---
drivers/scsi/virtio_scsi.c | 17 +
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 62fec04..6414ea0
We will place the request virtqueues in the flexible array member.
Refining the virtqueue API would let us drop the sglist copy, at
which point the pointer-to-array-of-pointers can become a simple
pointer-to-array. It would both simplify the allocation and remove a
dereference in several hot path
From: Jason Wang
Instead of storing the queue index in transport-specific virtio structs,
this patch moves them to vring_virtqueue and introduces an helper to get
the value. This lets drivers simplify their management and tracing of
virtqueues.
Signed-off-by: Jason Wang
Signed-off-by: Paolo Bo
From: Jason Wang
Sometimes, virtio device need to configure irq affinity hint to maximize the
performance. Instead of just exposing the irq of a virtqueue, this patch
introduce an API to set the affinity for a virtqueue.
The api is best-effort, the affinity hint may not be set as expected due to
Hi all,
this series adds multiqueue support to the virtio-scsi driver, based
on Jason Wang's work on virtio-net. It uses a simple queue steering
algorithm that expects one queue per CPU. LUNs in the same target always
use the same queue (so that commands are not reordered); queue switching
occur
Il 01/08/2012 17:53, Paolo Bonzini ha scritto:
> Il 20/07/2012 18:30, Paolo Bonzini ha scritto:
>> These commands cannot be issued right now without giving CAP_SYS_RAWIO to
>> the process who wishes to send them. These commands can be useful also to
>> non-privileged programs who have access to th
On 08/27/12 18:37, Dongsu Park wrote:
> while testing ib_srp based on your srp-ha,
> we sometimes hit kernel crashes with the call trace below.
>
> How to reproduce:
>
> 0. Kernel 3.2.15 with SCST v4193 on the target,
>Kernel 3.2.8 with ib_srp-ha on the initiator.
> 1. Configure 500+ vdisks o
Add a new flag may_power_off to scsi_device to let user decide if they
want the scsi device to be powered off when runtime suspended.
For ODD, if the ODD is capable of zero power, a device attribute file
will be created for user to control the value.
And if user sets 0 to may_power_off, we will d
30 matches
Mail list logo
