https://bugzilla.kernel.org/show_bug.cgi?id=60758
--- Comment #43 from newbie kernel...@gmail.com ---
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:
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.
-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
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-abort_work, HZ /
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 socket
https://bugzilla.kernel.org/show_bug.cgi?id=60758
--- Comment #44 from Alan Bartlett a...@elrepo.org ---
(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
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,
+ scmd %p
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 +++---
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
+++
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 +++
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\n, scmd));
+
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,
+
12 matches
Mail list logo
