On 11/06/2013 06:23 PM, Mike Christie wrote:
> On 11/05/2013 10:48 PM, Hannes Reinecke wrote:
>> On 11/05/2013 08:19 PM, Mike Christie wrote:
>>> On 11/04/2013 11:05 PM, Hannes Reinecke wrote:
+
+ scmd->eh_eflags |= SCSI_EH_ABORT_SCHEDULED;
+ SCSI_LOG_ERROR_RECOVERY(3,
+
On 11/06/2013 03:47 PM, Christoph Hellwig wrote:
> On Tue, Nov 05, 2013 at 11:19:27AM -0800, Mike Christie wrote:
>>> + scmd->eh_eflags |= SCSI_EH_ABORT_SCHEDULED;
>>> + SCSI_LOG_ERROR_RECOVERY(3,
>>> + scmd_printk(KERN_INFO, scmd,
>>> + "scmd %p abort scheduled\
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
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.
-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
Hello Hannes,
Any updates on this series..?
I'd really like to get the -v2 of this included for v3.13, along with
the initial Referrals bits.
--nab
On Wed, 2013-10-16 at 09:20 +0200, Hannes Reinecke wrote:
> Hi Nic,
>
> here are some updates to TCM ALUA handling. Apart from some
> minor fixes
On 13-11-06 10:50 AM, Christoph Hellwig wrote:
On Thu, Oct 31, 2013 at 03:20:32PM -0400, Douglas Gilbert wrote:
Yes, it is being used as a mutex. However looking at
their semantics (mutex.h versus semaphore.h), a mutex
takes into account the task owner. If the user space
wants to pass around a s
On 11/05/2013 10:48 PM, Hannes Reinecke wrote:
> On 11/05/2013 08:19 PM, Mike Christie wrote:
>> On 11/04/2013 11:05 PM, Hannes Reinecke wrote:
>>> +
>>> + scmd->eh_eflags |= SCSI_EH_ABORT_SCHEDULED;
>>> + SCSI_LOG_ERROR_RECOVERY(3,
>>> + scmd_printk(KERN_INFO, scmd,
>>> +
https://bugzilla.kernel.org/show_bug.cgi?id=60758
--- Comment #44 from Alan Bartlett ---
(In reply to newbie from comment #43)
> 3.10.18 still show one line
>
> FATAL: Module scsi_wait_scan not found
>
> but boot ok.
That is not a message output by the kernel but is the result of line number
On Thu, Oct 31, 2013 at 03:20:32PM -0400, Douglas Gilbert wrote:
> Yes, it is being used as a mutex. However looking at
> their semantics (mutex.h versus semaphore.h), a mutex
> takes into account the task owner. If the user space
> wants to pass around a sg file descriptor in a Unix
> domain socke
On Tue, Nov 05, 2013 at 11:19:27AM -0800, Mike Christie wrote:
> > + scmd->eh_eflags |= SCSI_EH_ABORT_SCHEDULED;
> > + SCSI_LOG_ERROR_RECOVERY(3,
> > + scmd_printk(KERN_INFO, scmd,
> > + "scmd %p abort scheduled\n", scmd));
> > + schedule_delayed_work(&scmd->ab
-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
Hi,
This question is related to scsi_transport_fc layer.
Background:
When new LUNs are added to a target, the target can send check condition
with SK/ASC/ASCQ indicating that the reported LUNS data has changed. Then the
initiator can send the report LUNs command to discover the changes. But
https://bugzilla.kernel.org/show_bug.cgi?id=60758
--- Comment #43 from newbie ---
3.10.18 still show one line
FATAL: Module scsi_wait_scan not found
but boot ok.
--
You are receiving this mail because:
You are the assignee for the bug.--
To unsubscribe from this list: send the line "unsubscr
15 matches
Mail list logo