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 i
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 structure
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 b/drivers/scsi/qedi/qedi_main.
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 struct
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 "/dev/disk/by-
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: Host
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.
> 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] 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 up
> 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 dri
- 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 Ba
11 matches
Mail list logo
