- separate enclosure logical identifier from the
SAS address.
The original complaint was the lsscsi -t showed the same SAS
address of the two enclosures (SEP devices). In fact the
SAS address was being set to the Enclosure Logical Identifier (ELI).
Reviewed-by: Scott Teel
Reviewed-by: Kevin
> I have already set up many drives of this size previously, using
> ASR8xx5 controllers, without any problem.
>
> On another machine with a simple 8x1TB array, it doesn't work any better,
> while
> an older kernel works perfectly fine too:
>
> 4.14.48 :
>
> [ 61.069190] Adaptec aacraid
Le Tue, 3 Jul 2018 16:59:41 +
Dave Carroll écrivait:
> Hi Emmanuel,
>
> It is curious that the FW is having outstanding commands ... I've
> created a ticket to iderntify the differences. I suspect that the
> large drive size may be related, but all options are open.
>
I have already set
> After a very long time, it finally boots up and sees the disks, but
> here's the output from dmesg | grep aacraid:
>
> [1.357760] Adaptec aacraid driver 1.2.1[50877]-custom
> [1.388119] aacraid: Comm Interface type2 enabled
> [3.405113] scsi host0: aacraid
> [ 50.156024]
Le Wed, 27 Jun 2018 18:48:56 +
Dave Carroll écrivait:
> > Is this size consistent with the 4.13 kernel? That size is greater
> > than the 64-bit LBA addressing (0x93 539F B000).
>
> Sorry, that comment was incorrect, but I would like to see if the
> size is consistent between the kernels.
Le Wed, 27 Jun 2018 18:48:56 +
Dave Carroll écrivait:
> Sorry, that comment was incorrect, but I would like to see if the
> size is consistent between the kernels.
>
I just booted the 4.16 from Debian testing, same problem, so this is
not an artefact of my custom compilation:
aacraid:
https://bugzilla.kernel.org/show_bug.cgi?id=199703
--- Comment #24 from Rich Reamer (richr...@yahoo.com) ---
UPDATE:
* found out CONFIG_BLK_CPQ_CISS_DA was removed and Replaced with HPSA driver.
* the "hpsa_allow_any=1" boot parameter does sort-of find the raid/disk -- and
creates a
On Tue, 2018-07-03 at 22:49 +0900, David Miller wrote:
> From: Sreekanth Reddy
> Date: Tue, 3 Jul 2018 17:48:49 +0530
>
> > Any suggestion/update over my previous mail. I am using 4.13
> kernel.
>
> I think the issue is that if you are reading a 32-bit word and then
> interpreting it as a
In case of iSCSI offload BFS environment, mfw requires to mark
virtual link based upon qedi load status.
Signed-off-by: Manish Rangankar
---
drivers/scsi/qedi/qedi_main.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/scsi/qedi/qedi_main.c
From: Sreekanth Reddy
Date: Tue, 3 Jul 2018 17:48:49 +0530
> Any suggestion/update over my previous mail. I am using 4.13 kernel.
I think the issue is that if you are reading a 32-bit word and then
interpreting it as a struct full of individual bytes, you have to
order the bytes in the
Hi,
Any suggestion/update over my previous mail. I am using 4.13 kernel.
Thanks,
Sreekanth
On Sat, Jun 30, 2018 at 12:34 AM, Sreekanth Reddy
wrote:
> Hi All,
>
> Here is the issue which we are observing when driver don't use
> le16_to_cpu() in below code snippet on Sparc64 machine when driver
On 07/03/2018 08:23 AM, Damien Le Moal wrote:
> Fix the description of sd_zbc_check_zone_size() to correctly explain
> that the returned value is a number of device blocks, not bytes.
> Additionally, the 32 bits "ret" variable used in this function may
> truncate the 64 bits zone_blocks variable
On Tue, Jul 3, 2018 at 2:54 PM, Johannes Thumshirn wrote:
> It has been more than one year since we tried to change the default
> from legacy to multi queue in SCSI. Back then we had to retract the
> change because of performance issues with rotating disks.
>
> In the meantime there have been a
Fix the description of sd_zbc_check_zone_size() to correctly explain
that the returned value is a number of device blocks, not bytes.
Additionally, the 32 bits "ret" variable used in this function may
truncate the 64 bits zone_blocks variable value upon return. To fix
this, change "ret" type to
14 matches
Mail list logo
