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
---
Documentation/kernel-parameters.txt |3 +++
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 started */
ATA_HOST_PARALLEL_SCAN = (1 << 2
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.
From: Artur Wojcik
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 that all links should b
Reuse ata_port_{suspend|resume}_common for sas. This path is chosen
over adding coordination between ata-tranport and sas-transport because
libsas wants to revalidate the domain at resume-time at the host level.
It can not validate links have resumed properly until libata has had a
chance to perfo
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
Sorry. Sent the wrong cover letter with this patch set.
Should be:
Subject: [set5 PATCH v2 0/5] scsi, async: asynchronous probing rework
Changes since v1: http://marc.info/?l=linux-scsi&m=134034693629294&w=2
1/ rebased on scsi/for-next to pick up the scsi_wait_scan module deletion
2/ added Arja
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
Tested-by:
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
Cc: Len Brown
Cc: Rafael J. Wysocki
Cc: James Bottomley
Tested-by: Eldad Zack
Signed-o
Now that scsi registers its async scan work with the async subsystem,
wait_for_device_probe() is sufficient for ensuring all scanning is
complete.
Cc: Arjan van de Ven
Cc: Len Brown
Cc: Rafael J. Wysocki
Cc: James Bottomley
Tested-by: Eldad Zack
Signed-off-by: Dan Williams
---
drivers/scsi/
In response to an async related regression James noted:
"My theory is that this is an init problem: The assumption in a lot of
our code is that async_synchronize_full() waits for everything ... even
the domain specific async schedules, which isn't true."
...so make this assumption true.
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 dis
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
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 scs
[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
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:
> fio randrw workload | virtio-scsi-raw | vi
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
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 92
Am 10.07.2012 00:08, schrieb NeilBrown:
> On Mon, 09 Jul 2012 16:40:15 +0200 Matthias Prager
> 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 interpretation instead of the
On 12-07-09 04:29 PM, Andrew Morton wrote:
> On Thu, 05 Jul 2012 07:52:25 -0700
> Robert Love 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
On Thu, 05 Jul 2012 07:52:25 -0700
Robert Love 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 a negative value a
On 07/09/2012 04:45 PM, Darrick J. Wong wrote:
>
> I suspect that /sys/devices//manage_start_stop = 0
> for the SATA devices hanging off the SAS controller.
Yep, looks like you're right. For my system:
# cat /sys/block/sd?/device/scsi_disk/*/manage_start_stop
1
1
1
1
1
0
0
0
0
0
0
0
0
Those fir
On Mon, 09 Jul 2012 16:40:15 +0200 Matthias Prager
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 implementation.
>
> I re
On Mon, Jul 09, 2012 at 03:37:09PM -0400, Robert Trace wrote:
> > 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 t
> 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
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
runni
26 matches
Mail list logo
