From: Nicholas Bellinger n...@linux-iscsi.org
This patch converts tcm_vhost to use modern concurrency managed workqueues to
offload setup of tcm_vhost_cmd descriptors to a kworker CPU thread that is
running on the same core as the vhost thread pulling elements off the virtqueue
from within
Hello linux-scsi and linux-raid,
I did some further research regarding my problem.
It appears to me the fault does not lie with the mpt2sas driver (not
that I can definitely exclude it), but with the md implementation.
I reproduced what I think is the same issue on a different machine (also
I did some further research regarding my problem.
It appears to me the fault does not lie with the mpt2sas driver (not
that I can definitely exclude it), but with the md implementation.
I'm actually discovering some of the same issues (LSI 9211-8i w/ SATA
disks), but I've come to a slightly
On Mon, 09 Jul 2012 16:40:15 +0200 Matthias Prager li...@matthiasprager.de
wrote:
Hello linux-scsi and linux-raid,
I did some further research regarding my problem.
It appears to me the fault does not lie with the mpt2sas driver (not
that I can definitely exclude it), but with the md
On Thu, 05 Jul 2012 07:52:25 -0700
Robert Love robert.w.l...@intel.com wrote:
strtoul returns an 'unsigned long' so there is no
reason to check if the value is less than zero.
strtoul already checks for the '-' character deep
in its bowels. It will return an error if the user
has provided
On 12-07-09 04:29 PM, Andrew Morton wrote:
On Thu, 05 Jul 2012 07:52:25 -0700
Robert Loverobert.w.l...@intel.com wrote:
strtoul returns an 'unsigned long' so there is no
reason to check if the value is less than zero.
strtoul already checks for the '-' character deep
in its bowels. It
Am 10.07.2012 00:08, schrieb NeilBrown:
On Mon, 09 Jul 2012 16:40:15 +0200 Matthias Prager li...@matthiasprager.de
wrote:
Even though it says creating aborted it still created md127.
One of my pet peeves in when people interpret the observations wrongly and
then report their
Am 09.07.2012 21:37, schrieb Robert Trace:
I did some further research regarding my problem.
It appears to me the fault does not lie with the mpt2sas driver (not
that I can definitely exclude it), but with the md implementation.
I'm actually discovering some of the same issues (LSI 9211-8i
Am 10.07.2012 00:24, schrieb Robert Trace:
Also, TURs don't appear to actually wake the disk up (should they?).
The only thing I've found that'll wake the disk up is an explicit START
UNIT command.
I haven't checked the scsi logging side, but about the only commands
that wake up the disks
Hi folks,
On Wed, 2012-07-04 at 18:52 -0700, Nicholas A. Bellinger wrote:
To give an idea of how things are looking on the performance side, here
some initial numbers for small block (4k) mixed random IOPs using the
following fio test setup:
SNIP
fio randrw workload | virtio-scsi-raw |
[removed linux-raid since the md layer seems unrelated]
On 07/09/2012 08:12 PM, Matthias Prager wrote:
I've reproduced this behavior on the raw disks themselves, no MD layer
involved (although the freak-out by my MD layer is what alerted me to
this issue too... Having your entire array punted
On 07/09/2012 08:21 PM, Matthias Prager wrote:
I haven't checked the scsi logging side, but about the only commands
that wake up the disks are 'smartctl -a /dev/sda' and 'sg_start'
(smartcl maybe issuing a START UNIT command on it's own).
smartctl -a does appear to wake the disks. The scsi
Hi Jeff,
Let me know if any of these need reworking, otherwise I believe James is
waiting on your ack to take them (well, all except patch1) through scsi.git.
--
Dan
Original description:
Set4 of 5 patchsets to update scsi, libsas, and libata in
support of the isci driver.
Let libsas hook
This is in preparation for teaching async_synchronize_full() to sync all
pending async work, and not just on the async_running domain. This
conversion is functionally equivalent, just embedding the existing list
in a new async_domain type.
The .registered attribute is used in a later patch to
This is preparation to enable async_synchronize_full() to be used as a
replacement for scsi_complete_async_scans(), i.e. to stop leaking scsi
internal details where they are not needed.
Cc: Arjan van de Ven ar...@linux.intel.com
Cc: Len Brown len.br...@intel.com
Cc: Rafael J. Wysocki r...@sisk.pl
This reverts commit 43a8d39d0137612c336aa8bbb2cb886a79772ffb.
Commit 43a8d39d fixed the fact that wait_for_device_probe() was unable
to flush sd probe work. Now that sd probe work is once again flushable
via wait_for_device_probe() this workaround is no longer needed.
Cc: Meelis Roos
Hi Jeff,
Let me know if any of these need reworking, otherwise I believe James is
waiting on your ack to take them (well all except patch1) through scsi.git.
--
Dan
Original description:
Set4 of 5 patchsets to update scsi, libsas, and libata in
support of the isci driver.
Let libsas hook into
From: Artur Wojcik artur.woj...@intel.com
Provide a simple-dev-pm-ops implementation that shuts down the domain
and the device on suspend, and resumes the device and the domain on
resume. All of the mechanics of restoring domain connectivity are
handled by libsas once isci has notified libsas
libsas power management routines to suspend and recover the sas domain
based on a model where the lldd is allowed and expected to be
forgetful.
sas_suspend_ha - disable event processing allowing the lldd to take down
links without concern for causing hotplug events.
Hotplug testing with libsas currently encounters a 55 second wait for
link recovery to give up. In the case where the user trusts the
response time of their devices permit the recovery attempts to be
limited to one.
Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
20 matches
Mail list logo
