2019-04-02 17:10:03

by Marc Gonzalez

[permalink] [raw]
Subject: correcting incorrect peripheral device type 0x0

Hello,

In my boot log, when UFS is enabled, I get the following warnings:

scsi 0:0:0:49488: scsi_add_lun: correcting incorrect peripheral device type 0x0 for W-LUN 0x c150hN
scsi 0:0:0:49488: Well-known LUN SAMSUNG KLUCG4J1EB-B0B1 0200 PQ: 0 ANSI: 6
scsi 0:0:0:49476: scsi_add_lun: correcting incorrect peripheral device type 0x0 for W-LUN 0x c144hN
scsi 0:0:0:49476: Well-known LUN SAMSUNG KLUCG4J1EB-B0B1 0200 PQ: 0 ANSI: 6
scsi 0:0:0:49456: scsi_add_lun: correcting incorrect peripheral device type 0x0 for W-LUN 0x c130hN
scsi 0:0:0:49456: Well-known LUN SAMSUNG KLUCG4J1EB-B0B1 0200 PQ: 0 ANSI: 6

Is there something I can/should do to fix these issues?
Or may they be safely ignored?

Regards.


2019-04-02 17:47:27

by Avri Altman

[permalink] [raw]
Subject: RE: correcting incorrect peripheral device type 0x0

Hi,
Looking where this warning is coming from,
Scsi is just forcing sdev->type = TYPE_WLUN for wluns.
As no other driver sets it by itself - I wouldn't lose sleep over it.
Thanks,
Avri


> -----Original Message-----
> From: Marc Gonzalez <[email protected]>
> Sent: Tuesday, April 02, 2019 6:05 PM
> To: Martin Petersen <[email protected]>; Avri Altman
> <[email protected]>; Alim Akhtar <[email protected]>
> Cc: SCSI <[email protected]>; LKML <[email protected]>
> Subject: correcting incorrect peripheral device type 0x0
>
> Hello,
>
> In my boot log, when UFS is enabled, I get the following warnings:
>
> scsi 0:0:0:49488: scsi_add_lun: correcting incorrect peripheral device type
> 0x0 for W-LUN 0x c150hN
> scsi 0:0:0:49488: Well-known LUN SAMSUNG KLUCG4J1EB-B0B1 0200 PQ:
> 0 ANSI: 6
> scsi 0:0:0:49476: scsi_add_lun: correcting incorrect peripheral device type
> 0x0 for W-LUN 0x c144hN
> scsi 0:0:0:49476: Well-known LUN SAMSUNG KLUCG4J1EB-B0B1 0200 PQ:
> 0 ANSI: 6
> scsi 0:0:0:49456: scsi_add_lun: correcting incorrect peripheral device type
> 0x0 for W-LUN 0x c130hN
> scsi 0:0:0:49456: Well-known LUN SAMSUNG KLUCG4J1EB-B0B1 0200 PQ:
> 0 ANSI: 6
>
> Is there something I can/should do to fix these issues?
> Or may they be safely ignored?
>
> Regards.

2019-04-04 03:35:15

by Martin K. Petersen

[permalink] [raw]
Subject: Re: correcting incorrect peripheral device type 0x0


Marc,

> scsi 0:0:0:49488: scsi_add_lun: correcting incorrect peripheral device type 0x0 for W-LUN 0x c150hN

^^^^^ Where do these crazy LUN numbers come from? That
looks like something which needs fixing...

--
Martin K. Petersen Oracle Linux Engineering

2019-04-04 04:11:53

by Douglas Gilbert

[permalink] [raw]
Subject: Re: correcting incorrect peripheral device type 0x0

On 2019-04-03 11:34 p.m., Martin K. Petersen wrote:
>
> Marc,
>
>> scsi 0:0:0:49488: scsi_add_lun: correcting incorrect peripheral device type 0x0 for W-LUN 0x c150hN
>
> ^^^^^ Where do these crazy LUN numbers come from? That
> looks like something which needs fixing...
>

sam6r04.pdf chapter 4.7.7.5.1 followed by Linux trying to show a byte string
as an integer. But you knew that, didn't you ??

2019-04-04 12:03:08

by Marc Gonzalez

[permalink] [raw]
Subject: Re: correcting incorrect peripheral device type 0x0

On 04/04/2019 05:34, Martin K. Petersen wrote:

> Marc wrote:
>
>> scsi 0:0:0:49488: scsi_add_lun: correcting incorrect peripheral device type 0x0 for W-LUN 0x c150hN
>
> ^^^^^ Where do these crazy LUN numbers come from? That
> looks like something which needs fixing...

sdev_printk(KERN_WARNING, sdev, "%s: correcting incorrect peripheral device type 0x%x for W-LUN 0x%16xhN\n",
__func__, sdev->type, (unsigned int)sdev->lun);

What does the "hN" suffix stand for? It seems redundant with the "0x" prefix...
(Looks like hN might be "hexadecimal Number")


scsi 0:0:0:49488 -> 0xc150
scsi 0:0:0:49476 -> 0xc144
scsi 0:0:0:49456 -> 0xc130

4.7.7.5.1 Well known logical unit addressing

Table 37 — Well known logical unit extended addressing format

Bit 7 6 5 4 3 2 1 0
ADDRESS METHOD (11b) LENGTH (00b) EXTENDED ADDRESS METHOD (1h)

1100 0001 = 0xc1

So W-LUN 0x50, 0x44, 0x30.

"The W-LUN field specifies the well known logical unit to be addressed (see SPC-4)."

Does anything seem out-of-place?


I'd change the log message like this:

diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index 53380e07b40e..d28c5a30f60a 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -820,8 +820,8 @@ static int scsi_add_lun(struct scsi_device *sdev, unsigned char *inq_result,
*/
if (scsi_is_wlun(sdev->lun) && sdev->type != TYPE_WLUN) {
sdev_printk(KERN_WARNING, sdev,
- "%s: correcting incorrect peripheral device type 0x%x for W-LUN 0x%16xhN\n",
- __func__, sdev->type, (unsigned int)sdev->lun);
+ "%s: correcting incorrect peripheral device type 0x%x for W-LUN 0x%016llx\n",
+ __func__, sdev->type, (unsigned long long)sdev->lun);
sdev->type = TYPE_WLUN;
}

2019-04-04 13:03:52

by Avri Altman

[permalink] [raw]
Subject: RE: correcting incorrect peripheral device type 0x0


>
> > Marc wrote:
> >
> >> scsi 0:0:0:49488: scsi_add_lun: correcting incorrect peripheral device type
> 0x0 for W-LUN 0x c150hN
> >
> > ^^^^^ Where do these crazy LUN numbers come from? That
> > looks like something which needs fixing...
>
> sdev_printk(KERN_WARNING, sdev, "%s: correcting incorrect
> peripheral device type 0x%x for W-LUN 0x%16xhN\n",
> __func__, sdev->type, (unsigned int)sdev->lun);
>
> What does the "hN" suffix stand for? It seems redundant with the "0x"
> prefix...
> (Looks like hN might be "hexadecimal Number")
>
>
> scsi 0:0:0:49488 -> 0xc150
> scsi 0:0:0:49476 -> 0xc144
> scsi 0:0:0:49456 -> 0xc130
Those are coming from ufshcd_scsi_add_wlus(),
In which we call __scsi_add_device() for each one of the 3 w-luns:
UFS Device - 0x50, Boot - 0x30, RPMB - 0x44.
Everything seems in order.

Thanks,
Avri