Hi TomK,
Thanks for reporting this bug. Comments inline below.
On Mon, 2016-10-24 at 00:45 -0400, TomK wrote:
> 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 rel
Apologies if I'm posting to the wrong place; this is where I was
pointed to the last time I had USB storage questions.
I have a Maxtor (Seagate) "D3 Station" USB 3.0 SATA disk (0bc2:6125).
While it appears to work completely fine, every now and then the
following are logged in dmesg:
[Oct20 01:00
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/solution
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
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 t
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
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 QL
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
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_EXIS
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 (SC
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.
>>
11 matches
Mail list logo
