date:20161023

Re: Kernel 4.8.4: INFO: task kworker/u16:8:289 blocked for more than 120 seconds.

2016-10-23 Thread TomK


On 10/24/2016 12:32 AM, TomK wrote:

On 10/23/2016 10:03 PM, TomK wrote:

Hey,

Has anyone seen this and could have a workaround?  Seems like it is more
Kernel related with various apps not just target apparently not but
wondering if there is an interim solution
(https://access.redhat.com/solutions/408833)

Getting this message after few minutes of usage from the QLA2xxx driver.
 This is after some activity on an ESXi server (15 VM's) that I'm
connecting to this HBA.  I've tried the following tuning parameters but
there was no change in behaviour:

vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

Details:


Oct 23 21:28:25 mbpc-pc kernel: hpet1: lost 9600 rtc interrupts
Oct 23 21:28:29 mbpc-pc kernel: ABORT_TASK: Found referenced qla2xxx
task_tag: 1128612
Oct 23 21:28:42 mbpc-pc kernel: ABORT_TASK: Sending
TMR_FUNCTION_COMPLETE for ref_tag: 1128612
Oct 23 21:28:42 mbpc-pc kernel: ABORT_TASK: Found referenced qla2xxx
task_tag: 1129116
Jan  6 23:52:00 192.168.0.2 syslog: dhcpfwd : dhcp forwarder daemon
successfully started
Oct 23 21:30:18 mbpc-pc kernel: hpet1: lost 9600 rtc interrupts
Jan  6 23:54:01 192.168.0.2 syslog: dhcpfwd : dhcp forwarder daemon
successfully started
Oct 23 21:32:16 mbpc-pc kernel: hpet1: lost 9600 rtc interrupts
Oct 23 21:32:24 mbpc-pc kernel: INFO: task kworker/u16:8:289 blocked for
more than 120 seconds.
Oct 23 21:32:24 mbpc-pc kernel:  Not tainted 4.8.4 #2
Oct 23 21:32:24 mbpc-pc kernel: "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Oct 23 21:32:24 mbpc-pc kernel: kworker/u16:8   D 8803ba18 0
  289  2 0x
Oct 23 21:32:24 mbpc-pc kernel: Workqueue: tmr-fileio target_tmr_work
[target_core_mod]
Oct 23 21:32:24 mbpc-pc kernel: 8803ba18 0400
880049e926c0 8803b998
Oct 23 21:32:24 mbpc-pc kernel: 88034600 81f99ca0
81f998ef 8801
Oct 23 21:32:24 mbpc-pc kernel: 812f27d9 
e8c9a000 8800
Oct 23 21:32:24 mbpc-pc kernel: Call Trace:
Oct 23 21:32:24 mbpc-pc kernel: [] ? number+0x2e9/0x310
Oct 23 21:32:24 mbpc-pc kernel: [] schedule+0x40/0xb0
Oct 23 21:32:24 mbpc-pc kernel: [] ?
start_flush_work+0x49/0x180
Oct 23 21:32:24 mbpc-pc kernel: []
schedule_timeout+0x9c/0xe0
Oct 23 21:32:24 mbpc-pc kernel: [] ?
flush_work+0x1a/0x40
Oct 23 21:32:24 mbpc-pc kernel: [] ?
console_unlock+0x35c/0x380
Oct 23 21:32:24 mbpc-pc kernel: []
wait_for_completion+0xc0/0xf0
Oct 23 21:32:24 mbpc-pc kernel: [] ?
try_to_wake_up+0x260/0x260
Oct 23 21:32:24 mbpc-pc kernel: []
__transport_wait_for_tasks+0xb4/0x1b0 [target_core_mod]
Oct 23 21:32:24 mbpc-pc kernel: [] ?
vprintk_default+0x1f/0x30
Oct 23 21:32:24 mbpc-pc kernel: [] ? printk+0x46/0x48
Oct 23 21:32:24 mbpc-pc kernel: []
transport_wait_for_tasks+0x44/0x60 [target_core_mod]
Oct 23 21:32:24 mbpc-pc kernel: []
core_tmr_abort_task+0xf2/0x160 [target_core_mod]
Oct 23 21:32:24 mbpc-pc kernel: []
target_tmr_work+0x154/0x160 [target_core_mod]
Oct 23 21:32:24 mbpc-pc kernel: []
process_one_work+0x189/0x4e0
Oct 23 21:32:24 mbpc-pc kernel: [] ? schedule+0x40/0xb0
Oct 23 21:32:24 mbpc-pc kernel: []
worker_thread+0x16d/0x520
Oct 23 21:32:24 mbpc-pc kernel: [] ?
default_wake_function+0x12/0x20
Oct 23 21:32:24 mbpc-pc kernel: [] ?
__wake_up_common+0x56/0x90
Oct 23 21:32:24 mbpc-pc kernel: [] ?
maybe_create_worker+0x110/0x110
Oct 23 21:32:24 mbpc-pc kernel: [] ? schedule+0x40/0xb0
Oct 23 21:32:24 mbpc-pc kernel: [] ?
maybe_create_worker+0x110/0x110
Oct 23 21:32:24 mbpc-pc kernel: [] kthread+0xcc/0xf0
Oct 23 21:32:24 mbpc-pc kernel: [] ?
schedule_tail+0x1e/0xc0
Oct 23 21:32:24 mbpc-pc kernel: []
ret_from_fork+0x1f/0x40
Oct 23 21:32:24 mbpc-pc kernel: [] ?
kthread_freezable_should_stop+0x70/0x70
Oct 23 21:32:24 mbpc-pc kernel: INFO: task kworker/1:48:6089 blocked for
more than 120 seconds.
Oct 23 21:32:24 mbpc-pc kernel:  Not tainted 4.8.4 #2
Oct 23 21:32:24 mbpc-pc kernel: "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Oct 23 21:32:24 mbpc-pc kernel: kworker/1:48D 88004017f968 0
 6089  2 0x0080
Oct 23 21:32:24 mbpc-pc kernel: Workqueue: events qlt_free_session_done
[qla2xxx]
Oct 23 21:32:24 mbpc-pc kernel: 88004017f968 88004017f8f8
88011a83a300 0004
Oct 23 21:32:24 mbpc-pc kernel: 88004017a600 88004017f938
810a0bb6 8801
Oct 23 21:32:24 mbpc-pc kernel: 880110fd0840 8800
81090728 8801
Oct 23 21:32:24 mbpc-pc kernel: Call Trace:
Oct 23 21:32:24 mbpc-pc kernel: [] ?
enqueue_task_fair+0x66/0x410
Oct 23 21:32:24 mbpc-pc kernel: [] ?
check_preempt_curr+0x78/0x90
Oct 23 21:32:24 mbpc-pc kernel: [] ?
ttwu_do_wakeup+0x1d/0xf0
Oct 23 21:32:24 mbpc-pc kernel: [] schedule+0x40/0xb0
Oct 23 21:32:24 mbpc-pc kernel: [] ?
ttwu_queue+0x180/0x190
Oct 23 21:32:24 mbpc-pc kernel: []
schedule_timeout+0x9c/0xe0
Oct 23 21:32:24 mbpc-pc kernel: []
wait_for_completion+0xc0/0xf0
Oct 23 21:32:24 mbpc-pc

Re: Kernel 4.8.4: INFO: task kworker/u16:8:289 blocked for more than 120 seconds.

2016-10-23 Thread TomK


On 10/23/2016 10:03 PM, TomK wrote:

Hey,

Has anyone seen this and could have a workaround?  Seems like it is more
Kernel related with various apps not just target apparently not but
wondering if there is an interim solution
(https://access.redhat.com/solutions/408833)

Getting this message after few minutes of usage from the QLA2xxx driver.
 This is after some activity on an ESXi server (15 VM's) that I'm
connecting to this HBA.  I've tried the following tuning parameters but
there was no change in behaviour:

vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

Details:


Oct 23 21:28:25 mbpc-pc kernel: hpet1: lost 9600 rtc interrupts
Oct 23 21:28:29 mbpc-pc kernel: ABORT_TASK: Found referenced qla2xxx
task_tag: 1128612
Oct 23 21:28:42 mbpc-pc kernel: ABORT_TASK: Sending
TMR_FUNCTION_COMPLETE for ref_tag: 1128612
Oct 23 21:28:42 mbpc-pc kernel: ABORT_TASK: Found referenced qla2xxx
task_tag: 1129116
Jan  6 23:52:00 192.168.0.2 syslog: dhcpfwd : dhcp forwarder daemon
successfully started
Oct 23 21:30:18 mbpc-pc kernel: hpet1: lost 9600 rtc interrupts
Jan  6 23:54:01 192.168.0.2 syslog: dhcpfwd : dhcp forwarder daemon
successfully started
Oct 23 21:32:16 mbpc-pc kernel: hpet1: lost 9600 rtc interrupts
Oct 23 21:32:24 mbpc-pc kernel: INFO: task kworker/u16:8:289 blocked for
more than 120 seconds.
Oct 23 21:32:24 mbpc-pc kernel:  Not tainted 4.8.4 #2
Oct 23 21:32:24 mbpc-pc kernel: "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Oct 23 21:32:24 mbpc-pc kernel: kworker/u16:8   D 8803ba18 0
  289  2 0x
Oct 23 21:32:24 mbpc-pc kernel: Workqueue: tmr-fileio target_tmr_work
[target_core_mod]
Oct 23 21:32:24 mbpc-pc kernel: 8803ba18 0400
880049e926c0 8803b998
Oct 23 21:32:24 mbpc-pc kernel: 88034600 81f99ca0
81f998ef 8801
Oct 23 21:32:24 mbpc-pc kernel: 812f27d9 
e8c9a000 8800
Oct 23 21:32:24 mbpc-pc kernel: Call Trace:
Oct 23 21:32:24 mbpc-pc kernel: [] ? number+0x2e9/0x310
Oct 23 21:32:24 mbpc-pc kernel: [] schedule+0x40/0xb0
Oct 23 21:32:24 mbpc-pc kernel: [] ?
start_flush_work+0x49/0x180
Oct 23 21:32:24 mbpc-pc kernel: []
schedule_timeout+0x9c/0xe0
Oct 23 21:32:24 mbpc-pc kernel: [] ? flush_work+0x1a/0x40
Oct 23 21:32:24 mbpc-pc kernel: [] ?
console_unlock+0x35c/0x380
Oct 23 21:32:24 mbpc-pc kernel: []
wait_for_completion+0xc0/0xf0
Oct 23 21:32:24 mbpc-pc kernel: [] ?
try_to_wake_up+0x260/0x260
Oct 23 21:32:24 mbpc-pc kernel: []
__transport_wait_for_tasks+0xb4/0x1b0 [target_core_mod]
Oct 23 21:32:24 mbpc-pc kernel: [] ?
vprintk_default+0x1f/0x30
Oct 23 21:32:24 mbpc-pc kernel: [] ? printk+0x46/0x48
Oct 23 21:32:24 mbpc-pc kernel: []
transport_wait_for_tasks+0x44/0x60 [target_core_mod]
Oct 23 21:32:24 mbpc-pc kernel: []
core_tmr_abort_task+0xf2/0x160 [target_core_mod]
Oct 23 21:32:24 mbpc-pc kernel: []
target_tmr_work+0x154/0x160 [target_core_mod]
Oct 23 21:32:24 mbpc-pc kernel: []
process_one_work+0x189/0x4e0
Oct 23 21:32:24 mbpc-pc kernel: [] ? schedule+0x40/0xb0
Oct 23 21:32:24 mbpc-pc kernel: []
worker_thread+0x16d/0x520
Oct 23 21:32:24 mbpc-pc kernel: [] ?
default_wake_function+0x12/0x20
Oct 23 21:32:24 mbpc-pc kernel: [] ?
__wake_up_common+0x56/0x90
Oct 23 21:32:24 mbpc-pc kernel: [] ?
maybe_create_worker+0x110/0x110
Oct 23 21:32:24 mbpc-pc kernel: [] ? schedule+0x40/0xb0
Oct 23 21:32:24 mbpc-pc kernel: [] ?
maybe_create_worker+0x110/0x110
Oct 23 21:32:24 mbpc-pc kernel: [] kthread+0xcc/0xf0
Oct 23 21:32:24 mbpc-pc kernel: [] ?
schedule_tail+0x1e/0xc0
Oct 23 21:32:24 mbpc-pc kernel: []
ret_from_fork+0x1f/0x40
Oct 23 21:32:24 mbpc-pc kernel: [] ?
kthread_freezable_should_stop+0x70/0x70
Oct 23 21:32:24 mbpc-pc kernel: INFO: task kworker/1:48:6089 blocked for
more than 120 seconds.
Oct 23 21:32:24 mbpc-pc kernel:  Not tainted 4.8.4 #2
Oct 23 21:32:24 mbpc-pc kernel: "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Oct 23 21:32:24 mbpc-pc kernel: kworker/1:48D 88004017f968 0
 6089  2 0x0080
Oct 23 21:32:24 mbpc-pc kernel: Workqueue: events qlt_free_session_done
[qla2xxx]
Oct 23 21:32:24 mbpc-pc kernel: 88004017f968 88004017f8f8
88011a83a300 0004
Oct 23 21:32:24 mbpc-pc kernel: 88004017a600 88004017f938
810a0bb6 8801
Oct 23 21:32:24 mbpc-pc kernel: 880110fd0840 8800
81090728 8801
Oct 23 21:32:24 mbpc-pc kernel: Call Trace:
Oct 23 21:32:24 mbpc-pc kernel: [] ?
enqueue_task_fair+0x66/0x410
Oct 23 21:32:24 mbpc-pc kernel: [] ?
check_preempt_curr+0x78/0x90
Oct 23 21:32:24 mbpc-pc kernel: [] ?
ttwu_do_wakeup+0x1d/0xf0
Oct 23 21:32:24 mbpc-pc kernel: [] schedule+0x40/0xb0
Oct 23 21:32:24 mbpc-pc kernel: [] ?
ttwu_queue+0x180/0x190
Oct 23 21:32:24 mbpc-pc kernel: []
schedule_timeout+0x9c/0xe0
Oct 23 21:32:24 mbpc-pc kernel: []
wait_for_completion+0xc0/0xf0
Oct 23 21:32:24 mbpc-pc kernel: [] ?
try_to_wake_up+0x260/0x260

[PATCH v3 1/2] scsi: Handle Unit Attention when issuing SCSI command

2016-10-23 Thread Gabriel Krisman Bertazi

James,

I fixed the things you pointed out on the previous review.  As
discussed, I didn't change the code to reuse the request yet.  We can
follow up on that later.

Thanks,

>8

Usually, re-sending the SCSI command is enough to recover from a Unit
Attention (UA).  This adds a generic retry code to the SCSI command path
in case of an UA, before giving up and returning the error condition to
the caller.

I added the UA verification into scsi_execute instead of
scsi_execute_req because there are at least a few callers that invoke
scsi_execute directly and would benefit from the internal UA retry.
Also, I didn't use scsi_normalize_sense to not duplicate functionality
with scsi_execute_req_flags.  Instead, scsi_execute uses a small helper
function that verifies only the UA condition directly from the raw sense
buffer.  If this design is not OK, I can refactor to use
scsi_normalize_sense.

This prevents us from duplicating the retry code in at least a few
places.  In particular, it fixes an issue found in some IBM enclosures,
in which the device may return an Unit Attention during probe, breaking
the bind with the ses module:

scsi 1:0:7:0: Failed to get diagnostic page 0x802
scsi 1:0:7:0: Failed to bind enclosure -19

Link: https://patchwork.kernel.org/patch/9336763/
Suggested-by: Brian King 
Suggested-by: James Bottomley 
Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/scsi/scsi_lib.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index c71344aebdbb..4f6a91d6ee34 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -163,6 +163,16 @@ void scsi_queue_insert(struct scsi_cmnd *cmd, int reason)
 {
__scsi_queue_insert(cmd, reason, 1);
 }
+
+static inline bool scsi_sense_unit_attention(const char *sense)
+{
+   int resp = sense[0] & 0x7f;
+
+   return ((resp & 0x70) &&
+   ((resp >= 0x72 && (sense[1] & 0xf) == UNIT_ATTENTION) ||
+(resp < 0x72 && (sense[2] & 0xf) == UNIT_ATTENTION)));
+}
+
 /**
  * scsi_execute - insert request and wait for the result
  * @sdev:  scsi device
@@ -187,7 +197,14 @@ int scsi_execute(struct scsi_device *sdev, const unsigned 
char *cmd,
struct request *req;
int write = (data_direction == DMA_TO_DEVICE);
int ret = DRIVER_ERROR << 24;
+   unsigned char sense_buf[SCSI_SENSE_BUFFERSIZE];
 
+   if (!sense) {
+   sense = sense_buf;
+   memset(sense, 0, SCSI_SENSE_BUFFERSIZE);
+   }
+
+ retry:
req = blk_get_request(sdev->request_queue, write, __GFP_RECLAIM);
if (IS_ERR(req))
return ret;
@@ -210,6 +227,13 @@ int scsi_execute(struct scsi_device *sdev, const unsigned 
char *cmd,
 */
blk_execute_rq(req->q, NULL, req, 1);
 
+   if (scsi_sense_unit_attention(sense) && req->retries > 0) {
+   memset(sense, 0, SCSI_SENSE_BUFFERSIZE);
+   retries = req->retries - 1;
+   blk_put_request(req);
+   goto retry;
+   }
+
/*
 * Some devices (USB mass-storage in particular) may transfer
 * garbage data together with a residue indicating that the data
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/2] scsi: sr: Drop custom handling of unit attention

2016-10-23 Thread Gabriel Krisman Bertazi

These custom handling are no longer necessary, since we always retry UA
in scsi_execute now.

Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/scsi/scsi_lib.c | 21 ++---
 drivers/scsi/sr_ioctl.c |  6 ++
 2 files changed, 8 insertions(+), 19 deletions(-)

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 4f6a91d6ee34..9e62290e6136 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -2320,7 +2320,7 @@ scsi_mode_sense(struct scsi_device *sdev, int dbd, int 
modepage,
unsigned char cmd[12];
int use_10_for_ms;
int header_length;
-   int result, retry_count = retries;
+   int result;
struct scsi_sense_hdr my_sshdr;
 
memset(data, 0, sizeof(*data));
@@ -2399,11 +2399,6 @@ scsi_mode_sense(struct scsi_device *sdev, int dbd, int 
modepage,
data->block_descriptor_length = buffer[3];
}
data->header_length = header_length;
-   } else if ((status_byte(result) == CHECK_CONDITION) &&
-  scsi_sense_valid(sshdr) &&
-  sshdr->sense_key == UNIT_ATTENTION && retry_count) {
-   retry_count--;
-   goto retry;
}
 
return result;
@@ -2437,15 +2432,11 @@ scsi_test_unit_ready(struct scsi_device *sdev, int 
timeout, int retries,
else
sshdr = sshdr_external;
 
-   /* try to eat the UNIT_ATTENTION if there are enough retries */
-   do {
-   result = scsi_execute_req(sdev, cmd, DMA_NONE, NULL, 0, sshdr,
- timeout, retries, NULL);
-   if (sdev->removable && scsi_sense_valid(sshdr) &&
-   sshdr->sense_key == UNIT_ATTENTION)
-   sdev->changed = 1;
-   } while (scsi_sense_valid(sshdr) &&
-sshdr->sense_key == UNIT_ATTENTION && --retries);
+   result = scsi_execute_req(sdev, cmd, DMA_NONE, NULL, 0, sshdr,
+ timeout, retries, NULL);
+   if (sdev->removable && scsi_sense_valid(sshdr) &&
+   sshdr->sense_key == UNIT_ATTENTION)
+   sdev->changed = 1;
 
if (!sshdr_external)
kfree(sshdr);
diff --git a/drivers/scsi/sr_ioctl.c b/drivers/scsi/sr_ioctl.c
index 03054c0e7689..93b5544a5966 100644
--- a/drivers/scsi/sr_ioctl.c
+++ b/drivers/scsi/sr_ioctl.c
@@ -179,8 +179,8 @@ static int sr_play_trkind(struct cdrom_device_info *cdi,
 }
 
 /* We do our own retries because we want to know what the specific
-   error code is.  Normally the UNIT_ATTENTION code will automatically
-   clear after one error */
+   error code is.
+*/
 
 int sr_do_ioctl(Scsi_CD *cd, struct packet_command *cgc)
 {
@@ -220,8 +220,6 @@ int sr_do_ioctl(Scsi_CD *cd, struct packet_command *cgc)
if (!cgc->quiet)
sr_printk(KERN_INFO, cd,
  "disc change detected.\n");
-   if (retries++ < 10)
-   goto retry;
err = -ENOMEDIUM;
break;
case NOT_READY: /* This happens if there is no disc in drive */
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Kernel 4.8.4: INFO: task kworker/u16:8:289 blocked for more than 120 seconds.

2016-10-23 Thread TomK


Hey,

Has anyone seen this and could have a workaround?  Seems like it is more 
Kernel related with various apps not just target apparently not but 
wondering if there is an interim solution 
(https://access.redhat.com/solutions/408833)


Getting this message after few minutes of usage from the QLA2xxx driver. 
 This is after some activity on an ESXi server (15 VM's) that I'm 
connecting to this HBA.  I've tried the following tuning parameters but 
there was no change in behaviour:


vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

Details:


Oct 23 21:28:25 mbpc-pc kernel: hpet1: lost 9600 rtc interrupts
Oct 23 21:28:29 mbpc-pc kernel: ABORT_TASK: Found referenced qla2xxx 
task_tag: 1128612
Oct 23 21:28:42 mbpc-pc kernel: ABORT_TASK: Sending 
TMR_FUNCTION_COMPLETE for ref_tag: 1128612
Oct 23 21:28:42 mbpc-pc kernel: ABORT_TASK: Found referenced qla2xxx 
task_tag: 1129116
Jan  6 23:52:00 192.168.0.2 syslog: dhcpfwd : dhcp forwarder daemon 
successfully started

Oct 23 21:30:18 mbpc-pc kernel: hpet1: lost 9600 rtc interrupts
Jan  6 23:54:01 192.168.0.2 syslog: dhcpfwd : dhcp forwarder daemon 
successfully started

Oct 23 21:32:16 mbpc-pc kernel: hpet1: lost 9600 rtc interrupts
Oct 23 21:32:24 mbpc-pc kernel: INFO: task kworker/u16:8:289 blocked for 
more than 120 seconds.

Oct 23 21:32:24 mbpc-pc kernel:  Not tainted 4.8.4 #2
Oct 23 21:32:24 mbpc-pc kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Oct 23 21:32:24 mbpc-pc kernel: kworker/u16:8   D 8803ba18 0 
  289  2 0x
Oct 23 21:32:24 mbpc-pc kernel: Workqueue: tmr-fileio target_tmr_work 
[target_core_mod]
Oct 23 21:32:24 mbpc-pc kernel: 8803ba18 0400 
880049e926c0 8803b998
Oct 23 21:32:24 mbpc-pc kernel: 88034600 81f99ca0 
81f998ef 8801
Oct 23 21:32:24 mbpc-pc kernel: 812f27d9  
e8c9a000 8800

Oct 23 21:32:24 mbpc-pc kernel: Call Trace:
Oct 23 21:32:24 mbpc-pc kernel: [] ? number+0x2e9/0x310
Oct 23 21:32:24 mbpc-pc kernel: [] schedule+0x40/0xb0
Oct 23 21:32:24 mbpc-pc kernel: [] ? 
start_flush_work+0x49/0x180
Oct 23 21:32:24 mbpc-pc kernel: [] 
schedule_timeout+0x9c/0xe0

Oct 23 21:32:24 mbpc-pc kernel: [] ? flush_work+0x1a/0x40
Oct 23 21:32:24 mbpc-pc kernel: [] ? 
console_unlock+0x35c/0x380
Oct 23 21:32:24 mbpc-pc kernel: [] 
wait_for_completion+0xc0/0xf0
Oct 23 21:32:24 mbpc-pc kernel: [] ? 
try_to_wake_up+0x260/0x260
Oct 23 21:32:24 mbpc-pc kernel: [] 
__transport_wait_for_tasks+0xb4/0x1b0 [target_core_mod]
Oct 23 21:32:24 mbpc-pc kernel: [] ? 
vprintk_default+0x1f/0x30

Oct 23 21:32:24 mbpc-pc kernel: [] ? printk+0x46/0x48
Oct 23 21:32:24 mbpc-pc kernel: [] 
transport_wait_for_tasks+0x44/0x60 [target_core_mod]
Oct 23 21:32:24 mbpc-pc kernel: [] 
core_tmr_abort_task+0xf2/0x160 [target_core_mod]
Oct 23 21:32:24 mbpc-pc kernel: [] 
target_tmr_work+0x154/0x160 [target_core_mod]
Oct 23 21:32:24 mbpc-pc kernel: [] 
process_one_work+0x189/0x4e0

Oct 23 21:32:24 mbpc-pc kernel: [] ? schedule+0x40/0xb0
Oct 23 21:32:24 mbpc-pc kernel: [] 
worker_thread+0x16d/0x520
Oct 23 21:32:24 mbpc-pc kernel: [] ? 
default_wake_function+0x12/0x20
Oct 23 21:32:24 mbpc-pc kernel: [] ? 
__wake_up_common+0x56/0x90
Oct 23 21:32:24 mbpc-pc kernel: [] ? 
maybe_create_worker+0x110/0x110

Oct 23 21:32:24 mbpc-pc kernel: [] ? schedule+0x40/0xb0
Oct 23 21:32:24 mbpc-pc kernel: [] ? 
maybe_create_worker+0x110/0x110

Oct 23 21:32:24 mbpc-pc kernel: [] kthread+0xcc/0xf0
Oct 23 21:32:24 mbpc-pc kernel: [] ? 
schedule_tail+0x1e/0xc0

Oct 23 21:32:24 mbpc-pc kernel: [] ret_from_fork+0x1f/0x40
Oct 23 21:32:24 mbpc-pc kernel: [] ? 
kthread_freezable_should_stop+0x70/0x70
Oct 23 21:32:24 mbpc-pc kernel: INFO: task kworker/1:48:6089 blocked for 
more than 120 seconds.

Oct 23 21:32:24 mbpc-pc kernel:  Not tainted 4.8.4 #2
Oct 23 21:32:24 mbpc-pc kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Oct 23 21:32:24 mbpc-pc kernel: kworker/1:48D 88004017f968 0 
 6089  2 0x0080
Oct 23 21:32:24 mbpc-pc kernel: Workqueue: events qlt_free_session_done 
[qla2xxx]
Oct 23 21:32:24 mbpc-pc kernel: 88004017f968 88004017f8f8 
88011a83a300 0004
Oct 23 21:32:24 mbpc-pc kernel: 88004017a600 88004017f938 
810a0bb6 8801
Oct 23 21:32:24 mbpc-pc kernel: 880110fd0840 8800 
81090728 8801

Oct 23 21:32:24 mbpc-pc kernel: Call Trace:
Oct 23 21:32:24 mbpc-pc kernel: [] ? 
enqueue_task_fair+0x66/0x410
Oct 23 21:32:24 mbpc-pc kernel: [] ? 
check_preempt_curr+0x78/0x90
Oct 23 21:32:24 mbpc-pc kernel: [] ? 
ttwu_do_wakeup+0x1d/0xf0

Oct 23 21:32:24 mbpc-pc kernel: [] schedule+0x40/0xb0
Oct 23 21:32:24 mbpc-pc kernel: [] ? 
ttwu_queue+0x180/0x190
Oct 23 21:32:24 mbpc-pc kernel: [] 
schedule_timeout+0x9c/0xe0
Oct 23 21:32:24 mbpc-pc kernel: [] 
wait_for_completion+0xc0/0xf0
Oct 23 21:32:24 mbpc-pc kernel: [] ?

Re: [PATCH] sd: fix uninitialized variable access in error handling

2016-10-23 Thread Damien Le Moal



On 10/22/16 00:32, Arnd Bergmann wrote:
> If sd_zbc_report_zones fails, the check for 'zone_blocks == 0'
> later in the function accesses uninitialized data:
> 
> drivers/scsi/sd_zbc.c: In function ‘sd_zbc_read_zones’:
> drivers/scsi/sd_zbc.c:520:7: error: ‘zone_blocks’ may be used uninitialized 
> in this function [-Werror=maybe-uninitialized]
> 
> This sets it to zero, which has the desired effect of leaving
> the sd_zbc_read_zones successfully with sdkp->zone_blocks = 0.
> 
> Fixes: 89d947561077 ("sd: Implement support for ZBC devices")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/scsi/sd_zbc.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/sd_zbc.c b/drivers/scsi/sd_zbc.c
> index 16d3fa62d8ac..d5b3bd915d9e 100644
> --- a/drivers/scsi/sd_zbc.c
> +++ b/drivers/scsi/sd_zbc.c
> @@ -455,8 +455,10 @@ static int sd_zbc_check_zone_size(struct scsi_disk *sdkp)
>  
>   /* Do a report zone to get the same field */
>   ret = sd_zbc_report_zones(sdkp, buf, SD_ZBC_BUF_SIZE, 0);
> - if (ret)
> + if (ret) {
> + zone_blocks = 0;
>   goto out;
> + }
>  
>   same = buf[4] & 0x0f;
>   if (same > 0) {

Reviewed-by: Damien Le Moal 

-- 
Damien Le Moal, Ph.D.
Sr. Manager, System Software Research Group,
Western Digital Corporation
damien.lem...@wdc.com
(+81) 0466-98-3593 (ext. 513593)
1 kirihara-cho, Fujisawa,
Kanagawa, 252-0888 Japan
www.wdc.com, www.hgst.com
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: CONFIG_TCM_QLA2... no longer in Kernel 4.8.4 as an option.

2016-10-23 Thread TomK

What's prompting me to upgrade the kernel is these messages from the 
4.1.20 kernel (Seems this was fixed in a later kernel release):


Oct 20 11:03:44 mbpc-pc kernel: ABORT_TASK: Found referenced qla2xxx 
task_tag: 1162632
Oct 20 11:03:44 mbpc-pc kernel: ABORT_TASK: Sending 
TMR_TASK_DOES_NOT_EXIST for ref_tag: 1162632
Oct 20 11:03:44 mbpc-pc kernel: ABORT_TASK: Found referenced qla2xxx 
task_tag: 1162668
Oct 20 11:03:44 mbpc-pc kernel: ABORT_TASK: Sending 
TMR_TASK_DOES_NOT_EXIST for ref_tag: 1162668
Oct 20 11:03:57 mbpc-pc kernel: ABORT_TASK: Found referenced qla2xxx 
task_tag: 1163928
Jan  3 13:26:00 192.168.0.2 syslog: dhcpfwd : dhcp forwarder daemon 
successfully started
Oct 20 11:05:11 mbpc-pc kernel: qla2xxx [:04:00.0]-f094:21: sess 
8800048f5340 received double plogi.
Oct 20 11:05:32 mbpc-pc kernel: qla2xxx [:04:00.0]-f094:21: sess 
8800048f5340 received double plogi.
Oct 20 11:05:53 mbpc-pc kernel: qla2xxx [:04:00.0]-f094:21: sess 
8800048f5340 received double plogi.
Jan  3 13:28:00 192.168.0.2 syslog: dhcpfwd : dhcp forwarder daemon 
successfully started
Oct 20 11:06:14 mbpc-pc kernel: qla2xxx [:04:00.0]-f094:21: sess 
8800048f5340 received double plogi.
Oct 20 11:06:35 mbpc-pc kernel: qla2xxx [:04:00.0]-f094:21: sess 
8800048f5340 received double plogi.
Oct 20 11:06:56 mbpc-pc kernel: qla2xxx [:04:00.0]-f094:21: sess 
8800048f5340 received double plogi.
Oct 20 11:07:17 mbpc-pc kernel: qla2xxx [:04:00.0]-f094:21: sess 
8800048f5340 received double plogi.
Oct 20 11:07:34 mbpc-pc kernel: INFO: task kworker/u16:1:572 blocked for 
more than 120 seconds.

Oct 20 11:07:34 mbpc-pc kernel:  Not tainted 4.1.20 #2
Oct 20 11:07:34 mbpc-pc kernel: "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Oct 20 11:07:34 mbpc-pc kernel: kworker/u16:1   D 88063ba8 0 
  572  2 0x0080
Oct 20 11:07:34 mbpc-pc kernel: Workqueue: tmr-fileio target_tmr_work 
[target_core_mod]
Oct 20 11:07:34 mbpc-pc kernel: 88063ba8 880060a30310 
88011a824f40 
Oct 20 11:07:34 mbpc-pc kernel: 88060008 880003d99930 
7fff 880060a30310
Oct 20 11:07:34 mbpc-pc kernel: 7fff 88063bc8 
815d135e 81d73f01

Oct 20 11:07:34 mbpc-pc kernel: Call Trace:
Oct 20 11:07:34 mbpc-pc kernel: [] schedule+0x3e/0x90
Oct 20 11:07:34 mbpc-pc kernel: [] 
schedule_timeout+0x13d/0x1f0

Oct 20 11:07:34 mbpc-pc kernel: [] ? up+0x2f/0x50
Oct 20 11:07:34 mbpc-pc kernel: [] ? 
irq_work_queue+0xa4/0xc0
Oct 20 11:07:34 mbpc-pc kernel: [] ? 
start_flush_work+0x49/0x180
Oct 20 11:07:34 mbpc-pc kernel: [] 
wait_for_completion+0xc6/0x100
Oct 20 11:07:34 mbpc-pc kernel: [] ? 
try_to_wake_up+0x240/0x240
Oct 20 11:07:34 mbpc-pc kernel: [] 
__transport_wait_for_tasks+0xb3/0x1d0 [target_core_mod]
Oct 20 11:07:34 mbpc-pc kernel: [] ? 
vprintk_default+0x1f/0x30

Oct 20 11:07:34 mbpc-pc kernel: [] ? printk+0x46/0x48
Oct 20 11:07:34 mbpc-pc kernel: [] 
transport_wait_for_tasks+0x44/0x60 [target_core_mod]
Oct 20 11:07:34 mbpc-pc kernel: [] 
core_tmr_abort_task+0x152/0x180 [target_core_mod]
Oct 20 11:07:34 mbpc-pc kernel: [] 
target_tmr_work+0x152/0x160 [target_core_mod]
Oct 20 11:07:34 mbpc-pc kernel: [] 
process_one_work+0x14d/0x480
Oct 20 11:07:34 mbpc-pc kernel: [] 
worker_thread+0x11f/0x3d0
Oct 20 11:07:34 mbpc-pc kernel: [] ? 
__schedule+0x37b/0x810
Oct 20 11:07:34 mbpc-pc kernel: [] ? 
process_one_work+0x480/0x480
Oct 20 11:07:34 mbpc-pc kernel: [] ? 
process_one_work+0x480/0x480

Oct 20 11:07:34 mbpc-pc kernel: [] kthread+0xce/0xf0
Oct 20 11:07:34 mbpc-pc kernel: [] ? 
__do_page_fault+0x17e/0x430
Oct 20 11:07:34 mbpc-pc kernel: [] ? 
kthread_freezable_should_stop+0x70/0x70

Oct 20 11:07:34 mbpc-pc kernel: [] ret_from_fork+0x42/0x70
Oct 20 11:07:34 mbpc-pc kernel: [] ? 
kthread_freezable_should_stop+0x70/0x70
Oct 20 11:07:34 mbpc-pc kernel: INFO: task kworker/3:34:644 blocked for 
more than 120 seconds.

Oct 20 11:07:34 mbpc-pc kernel:  Not tainted 4.1.20 #2





Cheers,
Tom K.
-

Living on earth is expensive, but it includes a free trip around the sun.


On 10/23/2016 11:47 AM, TomK wrote:

Resending because the Triple X get's filtered in subjects
CONFIG_TCM_QLA2...  (Removed it from the body as well)

Basically these two options are no longer available in the latest stable
kernel.  Wondering if this option is being deprecated.

 -> QLogic QLA2XXX Fibre Channel Support (SCSI_QLA_FC [=m])
  -> [m] TCM_QLA2XXX fabric module for Qlogic 2xxx series target
mode HBAs

Cheers,
Tom K.
-


Living on earth is expensive, but it includes a free trip around the sun.


On 10/23/2016 1:05 AM, TomK wrote:

Hello,

The latest 4.8.4 kernel is missing the following kernel option
CONFIG_TCM_QLA2... .  Are there more

Re: CONFIG_TCM_QLA2... no longer in Kernel 4.8.4 as an option.

2016-10-23 Thread TomK

Resending because the Triple X get's filtered in subjects 
CONFIG_TCM_QLA2...  (Removed it from the body as well)


Basically these two options are no longer available in the latest stable 
kernel.  Wondering if this option is being deprecated.


 -> QLogic QLA2XXX Fibre Channel Support (SCSI_QLA_FC [=m])
  -> [m] TCM_QLA2XXX fabric module for Qlogic 2xxx series 
target mode HBAs


Cheers,
Tom K.
-

Living on earth is expensive, but it includes a free trip around the sun.


On 10/23/2016 1:05 AM, TomK wrote:

Hello,

The latest 4.8.4 kernel is missing the following kernel option
CONFIG_TCM_QLA2... .  Are there more recent instructions?  Or is this
option on it's way out of the kernel?

http://linux-iscsi.org/wiki/Downloads

QLogic Fibre Channel
Optionally, enable the QLogic Fibre Channel target module (qla2xxx.ko),
including its SCSI LLD:
Device Drivers --->
 SCSI device support  --->
 [*] SCSI low-level drivers  --->

 --- SCSI low-level drivers
  QLogic QLA2... Fibre Channel Support
  TCM_QLA2... fabric module for Qlogic 2xxx
series target mode HBAs


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 3/6] qedi: Add QLogic FastLinQ offload iSCSI driver framework.

2016-10-23 Thread Rangankar, Manish


On 19/10/16 3:32 PM, "Johannes Thumshirn"  wrote:

>On Wed, Oct 19, 2016 at 01:01:10AM -0400, manish.rangan...@cavium.com
>wrote:
>> From: Manish Rangankar 
>> 
>> The QLogic FastLinQ Driver for iSCSI (qedi) is the iSCSI specific module
>> for 41000 Series Converged Network Adapters by QLogic.
>> 
>> This patch consists of following changes:
>>   - MAINTAINERS Makefile and Kconfig changes for qedi,
>>   - PCI driver registration,
>>   - iSCSI host level initialization,
>>   - Debugfs and log level infrastructure.
>> 
>> Signed-off-by: Nilesh Javali 
>> Signed-off-by: Adheer Chandravanshi 
>> Signed-off-by: Chad Dupuis 
>> Signed-off-by: Saurav Kashyap 
>> Signed-off-by: Arun Easi 
>> Signed-off-by: Manish Rangankar 
>> ---
>
>[...]
>
>> +/* MSI-X fastpath handler code */
>> +static irqreturn_t qedi_msix_handler(int irq, void *dev_id)
>> +{
>> +struct qedi_fastpath *fp = dev_id;
>> +struct qedi_ctx *qedi = fp->qedi;
>> +bool wake_io_thread = true;
>> +
>> +qed_sb_ack(fp->sb_info, IGU_INT_DISABLE, 0);
>> +
>> +process_again:
>> +wake_io_thread = qedi_process_completions(fp);
>> +if (wake_io_thread) {
>> +QEDI_INFO(>dbg_ctx, QEDI_LOG_DISC,
>> +  "process already running\n");
>> +}
>> +
>> +if (qedi_fp_has_work(fp) == 0)
>> +qed_sb_update_sb_idx(fp->sb_info);
>> +
>> +/* Check for more work */
>> +rmb();
>> +
>> +if (qedi_fp_has_work(fp) == 0)
>> +qed_sb_ack(fp->sb_info, IGU_INT_ENABLE, 1);
>> +else
>> +goto process_again;
>> +
>> +return IRQ_HANDLED;
>> +}
>
>You might want to consider workqueues here.

If there is no serious objection with current per-cpu threads
implementation
then we will like to do workqueue changes just after first submission.
This is because, 
for this change we have go through complete validation cycle on our part.


Thanks,
Manish R.

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Kernel 4.8.4: INFO: task kworker/u16:8:289 blocked for more than 120 seconds.

Re: Kernel 4.8.4: INFO: task kworker/u16:8:289 blocked for more than 120 seconds.

[PATCH v3 1/2] scsi: Handle Unit Attention when issuing SCSI command

[PATCH v3 2/2] scsi: sr: Drop custom handling of unit attention

Kernel 4.8.4: INFO: task kworker/u16:8:289 blocked for more than 120 seconds.

Re: [PATCH] sd: fix uninitialized variable access in error handling

Re: CONFIG_TCM_QLA2... no longer in Kernel 4.8.4 as an option.

Re: CONFIG_TCM_QLA2... no longer in Kernel 4.8.4 as an option.

Re: [RFC 3/6] qedi: Add QLogic FastLinQ offload iSCSI driver framework.

9 matches

Site Navigation

Mail list logo

Footer information