-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I have been trying out the new block layer runtime pm, and run into a
problem: udisks keeps waking up the disk. Every 10 minutes it tries
to poll the SMART status of the drive, but it does first issue an ata
CHECK POWER command to see if it is in st
The ATA SLEEP mode saves some more power than SUSPEND, and
has basically the same recovery time, so use it instead.
Signed-off-by: Phillip Susi
---
drivers/ata/libata-scsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata
they
are awake or not before trying to read their smart status.
Signed-off-by: Phillip Susi
---
drivers/ata/libata-core.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 83b1a9f..573d151 100644
--- a/drivers/ata/libata-core.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I can not figure out what is waking up disks on resume from suspend.
I thought it was sd.c, and setting manage_start_stop = 0 should stop
that. It does stop the message printed saying it is being started,
yet the disk is still started, and this make
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/04/2013 09:23 PM, Aaron Lu wrote:
> I suppose this is mainly for runtime PM? Since for system
> suspend/hibernation, the disk and its controller will be powered
> off anyway.
Yes, or the second patch also helps when one manually issues hdparm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/04/2013 09:39 PM, Aaron Lu wrote:
> If the disk entered sleep mode due to runtime PM, then udisks can
> easily tell by checking the device's runtime status and not send
> out the query.
>
> But if the disk entered sleep mode due to other reaso
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/5/2013 4:05 AM, Aaron Lu wrote:
>> Are you using an ATA drive? Last time I checked, the spin up
>> actually happened while the ata port is resumed(when it will be
>> reset): https://lkml.org/lkml/2013/2/4/361
Why does resetting the port spin up
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/5/2013 10:56 AM, Douglas Gilbert wrote:
> I think that you might find that almost any SCSI command
> (translated to its ATA equivalent command) will wake up a SATA
> disk. Perhaps just this sequence: fd = open() ;
> close(fd) ; is sufficient.
No
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/5/2013 4:05 AM, Aaron Lu wrote:
> Are you using an ATA drive? Last time I checked, the spin up
> actually happened while the ata port is resumed(when it will be
> reset): https://lkml.org/lkml/2013/2/4/361
Is there a reason these patches weren't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I found the culprit. It seems that ata_port_reset identifies the
device, and if it has power up in standby enabled, and requires the
SET FEATURES command to spin up, issues the command right away. I wonder:
1) If the spinup command can't be delay
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/6/2013 12:49 AM, Aaron Lu wrote:
> Todd has been optimising system resume for SATA drives without
> touching runtime PM:
> http://www.spinics.net/lists/linux-scsi/msg69532.html You may want
> to take a look.
Thanks for the pointer, but is there
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 10/17/2013 03:33 PM, Todd E Brandt wrote:
> The essential issue behind hard disks' lengthy resume time is the
> ata port driver blocking until the ATA port hardware is finished
> coming online. So the kernel isn't really doing anything during all
Don't bother forcing disks to spin up on resume, as they
will do so automatically when accessed, and forcing them
to spin up slows down the resume. Add a second bit to the
manage_start_stop flag to restore the previous behavior.
---
drivers/scsi/sd.c | 6 +++---
include/scsi/scsi_device.
Don't block the resume path waiting for the disk to
spin up.
---
drivers/ata/libata-core.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 573d151..16f45dc 100644
--- a/drivers/ata/libata-core.c
+++ b/driver
Disks with Power Up In Standby enabled that required the
SET FEATURES command to start up were being issued the
command during resume. Suppress this until the disk
is actually accessed.
---
drivers/ata/libata-core.c | 10 +++---
drivers/ata/libata-eh.c | 11 +++
drivers/ata/libata.h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/7/2013 1:21 PM, Douglas Gilbert wrote:
> On 13-11-06 08:57 PM, Phillip Susi wrote:
>> Don't bother forcing disks to spin up on resume, as they will do
>> so automatically when accessed, and forcing them to spin up slows
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/08/2013 08:20 PM, Todd E Brandt wrote:
> I tested your patches and they do function. We tried a similar
> approach a few months back where instead of waking the scsi disks
> we just set them all to runtime_suspended and skipped the resume.
> Th
The ATA SLEEP mode saves some more power than SUSPEND, and
has basically the same recovery time, so use it instead.
---
drivers/ata/libata-scsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 97a0cef..79b75fd 100
would like to just have return the
cached identify block, but am not sure how to get from the
qc's scattergather list to a memory pointer I can memcpy to.
Phillip Susi (6):
libata: use sleep instead of standby command
libata: avoid waking disk to check power
sd: don't bother spinn
When a disk is in SLEEP mode it can not respond to commands,
including the CHECK POWER command. Instead of waking up the
sleeping disk, fake the reply to the CHECK POWER command to
indicate the disk is in standby mode. This prevents udisks
from waking up sleeping disks when it polls to see if the
The sd driver issues a flush cache when suspending, and this was causing
a sleeping drive to wake up for no reason. Another sleep or standby
command when the drive is already sleeping obviously should also not cause
the disk to spin up.
---
drivers/ata/libata-core.c | 6 +-
1 file changed, 5
Don't bother forcing disks to spin up on resume, as they
will do so automatically when accessed, and forcing them
to spin up slows down the resume. Add a second bit to the
manage_start_stop flag to restore the previous behavior.
---
drivers/scsi/sd.c | 6 +++---
include/scsi/scsi_device.
Don't block the resume path waiting for the disk to
spin up.
---
drivers/ata/libata-core.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 686c441..128ce0d 100644
--- a/drivers/ata/libata-core.c
+++ b/driver
Disks with Power Up In Standby enabled that required the
SET FEATURES command to start up were being issued the
command during resume. Suppress this until the disk
is actually accessed.
---
drivers/ata/libata-core.c | 12 ++--
drivers/ata/libata-eh.c | 10 --
drivers/ata/libata.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/11/2013 8:08 AM, Sergei Shtylyov wrote:
>> -unsigned manage_start_stop:1;/* Let HLD (sd) manage
>> start/stop */ +unsigned manage_start_stop:2;/* Let HLD
>> (sd) manage start/stop */
>
> I think you should better document this 2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/11/2013 11:59 AM, Todd E Brandt wrote:
> 500ms is actually quite alot when you compare it with android or
> iOS, or even with other subsystems like USB. USB is the second
> worst offender after SATA disks and it tends to take around 600ms
> for m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/16/2013 12:23 AM, Mark Lord wrote:
> Ditto for many SATA disks with "power up in standby" enabled.
Ditto for my previous response; the kernel ( in this case the libata
layer ) notices this and takes care of starting it. The third patch I
post
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/16/2013 01:20 PM, James Bottomley wrote:
> No disk does, neither SCSI nor ATA. The error handler is not
> automatically activated for a not ready/initializing command
> required because of multi-path. We override the default behaviour
> via
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/17/2013 01:43 AM, James Bottomley wrote:
> OK, so three people have now told you that's not how the code
> works. Why don't you just read it? because there's not really much
> point us reading your patches until you do.
I have, which is why I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/17/2013 06:54 PM, Douglas Gilbert wrote:
> Even if the SCSI EH code does spin-up the disk, it is inefficient
> and undesirable to send a device into EH for what is a normal,
> predictable situation (i.e. that a SCSI disk will need a START STOP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/17/2013 07:09 PM, James Bottomley wrote:
> Because you don't damn well listen. Two emails ago I said:
>
> The error handler is not automatically activated for a not
> ready/initializing command required because of multi-path
And I replied t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/17/2013 8:06 PM, Phillip Susi wrote:
> I don't see anything particularly inefficient about issuing the
> command in the eh path ( in fact, libata always uses the eh path to
> handle power management ). You can of c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/20/2013 9:23 AM, Mark Lord wrote:
> Yeah, solve that, and you're golden. I totally understand the
> motivation for this patch, and would love to have it working on my
> machines here too.
>
> But it may have to be some kind of sysfs optional set
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/17/2013 3:33 PM, Todd E Brandt wrote:
> sd_resume patch (2/2):
>
> On resume, the SD driver currently waits until the block driver
> finishes executing a disk start command with blk_execute_rq. This
> patch changes the sd_resume callback to us
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/20/2013 09:48 AM, Phillip Susi wrote:
> My original idea was actually to just have the system resume force
> the runtime pm status to suspended, then it will take care of
> calling the runtime resume which can easily start the dri
the
REQ_PM flag should make the command process even though the queue is
RPM_SUSPENDING, but it doesn't seem to work. Anyone have any idea why?
Phillip Susi (6):
libata: use sleep instead of standby command
libata: avoid waking disk for several commands
libata: resume in the backg
Don't block the resume path waiting for the disk to
spin up.
---
drivers/ata/libata-core.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 8f856bb..4a28caf 100644
--- a/drivers/ata/libata-core.c
+++ b/driver
Disks with Power Up In Standby enabled that required the
SET FEATURES command to start up were being issued the
command during resume. Suppress this until the disk
is actually accessed.
---
drivers/ata/libata-core.c | 12 ++--
drivers/ata/libata-eh.c | 10 --
drivers/ata/libata.
The ATA SLEEP mode saves some more power than SUSPEND, and
has basically the same recovery time, so use it instead.
---
drivers/ata/libata-scsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index db6dfcf..f92eb21 100
When a disk is in SLEEP mode it can not respond to any
commands. Instead of waking up the sleeping disk, fake the
commands. The commands include:
CHECK POWER
FLUSH CACHE
SLEEP
STANDBY IMMEDIATE
IDENTIFY
If we konw the disk is sleeping, we don't need to wake it up
to to find out if it is in stan
Instead of forcing a disk to start up with the START STOP UNIT
command when the system resumes, let it stay asleep if runtime
pm is enabled, and it will start the drive when it is accessed.
Query the drive to see if it starts up on its own ( like most
ATA disks do ) and update the runtime pm status
SAT-3 says REQUEST SENSE should issue CHECK POWER and return
a sense status indicating the drive's power status.
---
drivers/ata/libata-scsi.c | 40 ++--
1 file changed, 34 insertions(+), 6 deletions(-)
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/17/2013 7:15 AM, Tejun Heo wrote:
> On Mon, Nov 11, 2013 at 12:08:49PM -0500, Phillip Susi wrote:
>> No, I did not tune my system; I fixed the kernel so that
>> userspace's activities do not start those disks.
>
> So
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/17/2013 1:43 AM, James Bottomley wrote:
>> -static int sd_resume(struct device *dev) +static int
>> sd_resume_runtime(struct device *dev) { struct scsi_disk *sdkp =
>> scsi_disk_get_from_dev(dev); int ret = 0;
>>
>> -if (!sdkp->device->mana
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/17/2013 12:48 PM, James Bottomley wrote:
> Yes, they say that in sd_resume, if we're managing the disk start
> stop, spin it up. Removing them spins everything up
> unconditionally.
Ahh, right, I got rid of the manage_start_stop check. Probabl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/17/2013 1:02 PM, Sergei Shtylyov wrote:
> Isn't it an optional command, belonging to the power management
> feature set?
Seems to be required. ATA-8 section 4.16 says:
"A General feature set device shall implement power management"
-BEG
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 12/16/2013 06:30 PM, Phillip Susi wrote:
> For some reason, the system hangs on resume if I issue the REQUEST
> SENSE command after blk_pre_runtime_suspend. My understanding is
> that the REQ_PM flag should make the command process ev
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/6/2014 4:15 AM, Aaron Lu wrote:
> My guess why it doesn't work for you is that, when you call
> blk_pre_runtime_suspend in sd_resume_work, there are requests left
> in the queue so that call will simply fail, it's not meant to be
> used that way.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/06/2014 10:38 AM, Alan Stern wrote:
> Indeed. I can't see any place where the SCSI or block layers
> would stop the queue of a device when it gets runtime suspended.
> Maybe some other layer is doing this.
So I've stepped through it in qemu a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/7/2014 2:49 AM, Aaron Lu wrote:
> We can modify the device's system resume callback. To better
> illustrate the idea, I just made two patches to do this and I did
> some quick tests and didn't find anything wrong.
That misses one key aspect I was
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/7/2014 10:20 AM, Alan Stern wrote:
> This raises two questions:
>
> Should the host's resume be allowed to complete while the host is
> still in error recovery? Wouldn't it be better to wait until the
> recovery is finished?
Ahh, right, my othe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/7/2014 10:25 AM, Alan Stern wrote:
> This doesn't seem like a good idea. The way to speed up resumes is
> to allow sd's resume routine to return while the disk is still
> spinning up (i.e., make the spin-up asynchronous). There already
> have be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/7/2014 11:08 AM, Alan Stern wrote:
> Okay, that's a different matter. There's a much simpler way to
> accomplish this. The patch below will avoid spinning up drives
> that were already in runtime suspend when the system sleep started.
> (If a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/7/2014 1:05 PM, Alan Stern wrote:
> I disagree with your argument. If you aren't using autosuspend at
> all then you don't mind having your disks spin all the time.
> Therefore you don't mind if the disks spin up during system
> resume.
I prefer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/07/2014 02:18 PM, Alan Stern wrote:
> I don't know how you manually spin down your disk, but one
> reasonable way to do it is to set the autosuspend timeout to 0. If
> you use this approach and apply my patch, the disk should remain
> spun dow
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/07/2014 08:03 PM, Aaron Lu wrote:
> You mean you want to leave the disk runtime suspended after a
> system resume and in the meantime make sure the disk is indeed not
> spun up?
Yep. If it is spun up, then the runtime status should be updated
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/07/2014 08:32 PM, Aaron Lu wrote:
> The ATA and SCSI devices are all resumed in my patches, notice
> there is a single pm_request_resume call in both ATA and SCSI's
> system resume callback, so the runtime status and the disk's state
> is synce
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/07/2014 09:11 PM, Aaron Lu wrote:
> I thought that feature is used to control if a disk should be spun
> up once powered from the host side.
That *is* what it sounds like, only ATA disks either spin up as soon
as power is applied, or wait for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/07/2014 09:36 PM, Aaron Lu wrote:
> I think the host controller can decide not to power all its ports,
> only when a specific reg in the port's memory range is set, it will
> give power to that port and thus spin up the drive. Makes sense?
The
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/8/2014 2:00 AM, Aaron Lu wrote:
> Then I would say we just keep the pm_request_resume call in their
> system resume callback. For drives that have that cool feature
> turned on, it will be in runtime active state while it's actually
> in standby m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/8/2014 12:46 PM, Alan Stern wrote:
> I/O _was_ done. To spin up the disk requires sending it a START
> command. That's I/O.
Yes, currently, but that's exactly what I'm trying to get rid of.
> In essence, you want your disk's state to move dir
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/8/2014 4:21 PM, Alan Stern wrote:
> I never saw your patches. Where were they posted?
Higher up in this thread on linux-ide and linux-scsi. Subject was Let
sleeping disks lie.
> If you issue the REQUEST SENSE command in the usual way (going
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/9/2014 10:40 AM, Alan Stern wrote:
> We should change the code in the block layer. blk_pm_peek_request
> should allow requests with REQ_PM set to go through, no matter
> what the rpm_status is. Then the disk driver could query the disk
> (to se
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/9/2014 11:14 AM, Alan Stern wrote:
> That's true, but it isn't a problem. We know that requests with
> REQ_PM are sent only at certain, controlled times. In particular,
> the only time such a request would be sent while the disk is
> RPM_SUSPEND
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/7/2014 7:56 PM, Todd E Brandt wrote:
> On resume, the ATA port driver currently waits until the AHCI
> controller finishes executing the port wakeup command. This patch
> changes the ata_port_resume callback to issue the wakeup and then
> return i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/9/2014 1:29 PM, Douglas Gilbert wrote:
> When REQUEST SENSE had its original semantics, TEST UNIT READY was
> the only game in town for monitoring power management. From my
> reading of spc4r36n.pdf section 5.1.2 "Important commands for all
> SCS
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/10/2014 12:23 AM, Douglas Gilbert wrote:
> It is a command in the "Sense Data Reporting feature set" which is
> optional for ATA devices and "P" as in "Prohibited" for ATAPI
> devices. See the Feature set summary table.
Oops, you're right.
> You
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/10/2014 06:11 PM, Brandt, Todd E wrote:
> Yes yours is simpler, but it also opens a potential memory issue
> by passing a static int as the return location for the error value.
> I think it's just safer to tell the callback to attempt no return
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/10/2014 05:26 PM, Dan Williams wrote:
> I was going to comment that this leaves us open to a race to
> submit new i/o before recovery starts, but scsi_schedule_eh already
> blocks new i/o, so I think we're good. I think it deserves a
> comment
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/16/2014 1:04 PM, Todd E Brandt wrote:
> Both approaches employ non-blocking resume of the scsi disks so why
> don't we treat these two patch sets as parts one and two. My patch
> just spins everything up but sets everything to non-blocking, so it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/16/2014 11:59 AM, Alan Stern wrote:
> Since the START-STOP and TEST UNIT READY (or REQUEST SENSE or
> whatever) commands are likely to take a long time, they should all
> be carried out asynchronously with respect to the resume procedure.
> I don'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/17/2014 2:31 PM, Dan Williams wrote:
> Once dpm_resume of the disk is asynchronous, is there much
> incremental gain by further deferring spin up? The drawback of
> doing on-demand resume of the disk is that you incur the full
> resume latency ri
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/17/2014 3:24 PM, Tejun Heo wrote:
> Isn't immediate spin-up trivial to implement from anywhere? I'm
> not sure whether we'll end up defaulting to the lazy behavior or
> not but if we do requiring userland to echo something to sysfs to
> configure
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/17/2014 05:17 PM, Dan Williams wrote:
> Well, "at all" is overstating it. The system was idle and now
> it's being woken up to do some work. Inactivity timers are
> invalidated and now the decision becomes minimize access latency,
> or lazily
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/17/2014 08:24 PM, Todd E Brandt wrote:
> 10 seconds?! The only possible way that could happen is if the test
> unit ready SCSI command actually triggered an ata port wakeup; at
> which point you've already done the one thing you were trying not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/17/2014 08:41 PM, Alan Stern wrote:
> The intention is that this will help on systems with more than one
> disk drive. The one containing the core OS files and the journal
> will certainly spin up right away, but the others may not.
I am hop
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/20/2014 7:38 AM, CrashPlan Pro wrote:
> Dan Williams wrote at 18-01-14 05:09:
>> Larger systems are less likely to ever sleep.
>
> I have to agree with this. There is almost no storage server that
> will be suspended to sleep.
>
> Users of stora
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/21/2014 5:12 AM, Dan Williams wrote:
> The need is to avoid tying rpm and dpm ops together in surprising
> new ways that require userspace to change if it wants to keep the
> default behavior of hiding resume latency as much as possible. A
> lazy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/21/2014 11:03 AM, Alan Stern wrote:
> However, there is a compromise. The user gets to select the
> autosuspend delay. If that delay is set to a very large value, it
> will effectively prevent autosuspends from occurring, without
> causing an a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Is it possible to use the scsi_debug module to create more than one
device? It seems to me that it needs rewritten to have an interface
to dynamically create devices and set their parameters with a tool
like losetup, rather than using module parameter
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/7/2014 3:46 PM, Martin K. Petersen wrote:
> The question is how much sense it makes to invest in scsi_debug now
> that we have the LIO target in the kernel?
Thanks, I hadn't heard of this. It looks interesting, though a bit
complicated.
-B
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 03/10/2014 04:59 PM, Alan Stern wrote:
> Why? The existing code doesn't have anything like that.
The current sd code doesn't, but the libata code does use the AHCI
staggered spinup feature flag as a hint to only spin up one drive at a
time, so t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 03/05/2014 03:17 PM, Dan Williams wrote:
> From: Todd Brandt
>
> Improve overall system resume time by making libata link recovery
> actions asynchronous relative to other resume events.
>
> Link resume operations are performed using the scsi_
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 12/19/2014 06:46 PM, Phillip Susi wrote:
> I realize this is a little late but I finally started looking at
> the patch set I was working on last year again, and now that I look
> at your version that was accepted, I realize tha
84 matches
Mail list logo
