* correcting incorrect peripheral device type 0x0 @ 2019-04-02 15:05 Marc Gonzalez 2019-04-02 15:40 ` Avri Altman 2019-04-04 3:34 ` Martin K. Petersen 0 siblings, 2 replies; 6+ messages in thread From: Marc Gonzalez @ 2019-04-02 15:05 UTC (permalink / raw) To: Martin Petersen, Avri Altman, Alim Akhtar; +Cc: SCSI, LKML 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: correcting incorrect peripheral device type 0x0 2019-04-02 15:05 correcting incorrect peripheral device type 0x0 Marc Gonzalez @ 2019-04-02 15:40 ` Avri Altman 2019-04-04 3:34 ` Martin K. Petersen 1 sibling, 0 replies; 6+ messages in thread From: Avri Altman @ 2019-04-02 15:40 UTC (permalink / raw) To: Marc Gonzalez, Martin Petersen, Alim Akhtar; +Cc: SCSI, LKML 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 <marc.w.gonzalez@free.fr> > Sent: Tuesday, April 02, 2019 6:05 PM > To: Martin Petersen <martin.petersen@oracle.com>; Avri Altman > <Avri.Altman@wdc.com>; Alim Akhtar <alim.akhtar@samsung.com> > Cc: SCSI <linux-scsi@vger.kernel.org>; LKML <linux-kernel@vger.kernel.org> > 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: correcting incorrect peripheral device type 0x0 2019-04-02 15:05 correcting incorrect peripheral device type 0x0 Marc Gonzalez 2019-04-02 15:40 ` Avri Altman @ 2019-04-04 3:34 ` Martin K. Petersen 2019-04-04 4:04 ` Douglas Gilbert 2019-04-04 12:02 ` Marc Gonzalez 1 sibling, 2 replies; 6+ messages in thread From: Martin K. Petersen @ 2019-04-04 3:34 UTC (permalink / raw) To: Marc Gonzalez; +Cc: Martin Petersen, Avri Altman, Alim Akhtar, SCSI, LKML 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: correcting incorrect peripheral device type 0x0 2019-04-04 3:34 ` Martin K. Petersen @ 2019-04-04 4:04 ` Douglas Gilbert 2019-04-04 12:02 ` Marc Gonzalez 1 sibling, 0 replies; 6+ messages in thread From: Douglas Gilbert @ 2019-04-04 4:04 UTC (permalink / raw) To: Martin K. Petersen, Marc Gonzalez; +Cc: Avri Altman, Alim Akhtar, SCSI, LKML 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 ?? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: correcting incorrect peripheral device type 0x0 2019-04-04 3:34 ` Martin K. Petersen 2019-04-04 4:04 ` Douglas Gilbert @ 2019-04-04 12:02 ` Marc Gonzalez 2019-04-04 13:02 ` Avri Altman 1 sibling, 1 reply; 6+ messages in thread From: Marc Gonzalez @ 2019-04-04 12:02 UTC (permalink / raw) To: Martin K. Petersen, Douglas Gilbert; +Cc: Avri Altman, Alim Akhtar, SCSI, LKML 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; } ^ permalink raw reply related [flat|nested] 6+ messages in thread
* RE: correcting incorrect peripheral device type 0x0 2019-04-04 12:02 ` Marc Gonzalez @ 2019-04-04 13:02 ` Avri Altman 0 siblings, 0 replies; 6+ messages in thread From: Avri Altman @ 2019-04-04 13:02 UTC (permalink / raw) To: Marc Gonzalez, Martin K. Petersen, Douglas Gilbert Cc: Alim Akhtar, SCSI, LKML > > > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-04-04 13:02 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-04-02 15:05 correcting incorrect peripheral device type 0x0 Marc Gonzalez 2019-04-02 15:40 ` Avri Altman 2019-04-04 3:34 ` Martin K. Petersen 2019-04-04 4:04 ` Douglas Gilbert 2019-04-04 12:02 ` Marc Gonzalez 2019-04-04 13:02 ` Avri Altman
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.