Bug 839172 - Micron PCIe SSD devices show up as Unknown on anaconda
Micron PCIe SSD devices show up as Unknown on anaconda
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: udev (Show other bugs)
6.3
All Linux
high Severity high
: rc
: 6.6
Assigned To: Harald Hoyer
qe-baseos-daemons
: OtherQA, Reopened
Depends On:
Blocks: 947781 1056252 985469 1122165 1123495 1132250
  Show dependency treegraph
 
Reported: 2012-07-11 02:52 EDT by Asai Thambi S P
Modified: 2014-10-14 03:17 EDT (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: Harddisks connected to a Micron PCIe SSD did not get an entry in the udev database with their ID, because the device name does not trigger any persistent disk udev rule. Consequence: No symbolic link is created in /dev/disk/by-* and the device vendor and product is shown as "Unknown" in the installer. Fix: A udev rule is added to supply information gathered via ata_id. Result: A symbolic link in /dev/disk/by-id is created by udev and additional information is available in the udev database.
Story Points: ---
Clone Of:
: 839469 (view as bug list)
Environment:
Last Closed: 2014-10-14 03:17:31 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Micron device listed as "Unknown" in anaconda (101.80 KB, image/jpeg)
2012-11-19 12:59 EST, Jose De la Rosa
no flags Details
strace on scsi_id (udev utility) run for sata (3.55 KB, text/plain)
2013-12-19 03:36 EST, Lakshmi_Narayanan_Du
no flags Details
strace on scsi_id (udev utility) run for Micron SSD (2.68 KB, text/plain)
2013-12-19 03:37 EST, Lakshmi_Narayanan_Du
no flags Details
strace on ata_id (3.34 KB, text/plain)
2013-12-23 22:23 EST, Lakshmi_Narayanan_Du
no flags Details
pcie ssd details (874 bytes, text/plain)
2014-01-28 06:59 EST, Lakshmi_Narayanan_Du
no flags Details
sda details (852 bytes, text/plain)
2014-01-28 07:01 EST, Lakshmi_Narayanan_Du
no flags Details
vendor name missing (40.29 KB, image/png)
2014-01-28 07:03 EST, Lakshmi_Narayanan_Du
no flags Details
tmp log (62.75 KB, application/x-gzip-compressed)
2014-06-12 09:19 EDT, Lakshmi_Narayanan_Du
no flags Details
screen shot (1.50 MB, image/bmp)
2014-06-12 09:20 EDT, Lakshmi_Narayanan_Du
no flags Details

  None (edit)
Description Asai Thambi S P 2012-07-11 02:52:31 EDT
Description of problem:
lspci output will display  device id in 'lspci' output

Version-Release number of selected component (if applicable):
NA

How reproducible:
100%

Steps to Reproduce:
1. lspci command
  
Actual results:
lspci command output for Micron P320h device:
01:00.0 Mass storage controller: Micron Technology Inc Device 5150 (rev 03)

Expected results:
lspci command output for Micron P320h device:
01:00.0 Mass storage controller: Micron Technology Inc RealSSD P320h (rev 03)

Additional info:
Micron added new device ids to pci.ids database. hwdata need to sync with pci.ids database to get the new ids.

Question:
Will anaconda get the new pci.ids when hwdata is updated or should I open a separate bug for updating pci.ids in anaconda?
Comment 2 Karsten Hopp 2012-07-11 05:07:09 EDT
anaconda uses pci.ids from the hwdata package, you don't need to open another bugzilla.
Comment 3 Karsten Hopp 2012-07-11 05:12:35 EDT
I've seen a list of Micron device ids that were supposed to be added upstream.
0x5152 was one of them, but hasn't been submitted upstream, is that intentional ?
Comment 5 Asai Thambi S P 2012-07-11 06:34:56 EDT
I will be adding support for new devices in the next upstream kernel release. I believe lack of driver support should not affect updating pci.ids, as it is only for hardware identification. Please confirm.
Comment 6 Karsten Hopp 2012-07-11 07:58:43 EDT
That's correct, the pci.ids file is just for getting some descriptive text with lspci, kernel support for the device id isn't required at all.
Comment 7 Asai Thambi S P 2012-07-12 00:12:47 EDT
Just added two more device ids. Please get the latest list.
Comment 8 Shyam Iyer 2012-07-12 16:04:44 EDT
Asai/Sam I am just closing this as duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=830253.
I have added you folks to the BZ. Please add the upstream submission of the pci.ids to that BZ as I believe that is an approved Dell request.

*** This bug has been marked as a duplicate of bug 830253 ***
Comment 9 Jose De la Rosa 2012-11-19 12:58:12 EST
Re-opening.

Using RHEL 6 SP4 alpha 1, I noticed that anaconda uses sub-device and sub-vendor ids when listing available data storage devices, where as 'lspci' uses device and vendor IDs.

The Micron devices do not have sub-device and sub-vendor IDs, and thus are displayed as "Unknown" devices in anaconda. This is not optimal customer experience.
Comment 10 Jose De la Rosa 2012-11-19 12:59:27 EST
Created attachment 647917 [details]
Micron device listed as "Unknown" in anaconda
Comment 11 Jose De la Rosa 2012-11-19 13:08:05 EST
Karsten,

The title of this bug doesn't adequately describe the issue here. Let me know if we need to open a new one. Thanks.
Comment 13 Michal Minar 2013-06-27 04:11:50 EDT
sub-device and sub-vendor fields are optional. This should be handled by anaconda. Reassigning.
Comment 14 David Cantrell 2013-07-11 09:59:12 EDT
Anaconda does not carry hardware-specific details like sub-device and sub-vendor.  A long long time ago we did, but that quickly became unmaintainable.  We use the pci.ids database as provided by the system and information passed to us via udev.

Unless this information is added to the pci.ids database or provided somehow by the kernel, it will continue to show up as Unknown.  We cannot get in to a position where anaconda needs to supplement the hardware device information or provide our own modified pci.ids file.

I am reassigning this back to hwdata.  If you feel it is still inappropriate for hwdata, please close it.  We cannot address this problem in anaconda.
Comment 15 Charles Rose 2013-12-18 22:58:00 EST
(In reply to Jose De la Rosa from comment #9)
> Re-opening.
...
> displayed as "Unknown" devices in anaconda. This is not optimal customer

This might be an issue with 60-persistent-storage.rules where micron devices, named 'rssd' instead of 'sda' might be skipped. We have a similar issue with other SSD devices that do not have the "sd*" names.
Comment 16 Lakshmi_Narayanan_Du 2013-12-19 03:18:47 EST
In case of other ssds(sata) when the scsi_id(udev utility) hooks the driver ioctl (to inquire)  the data is populated by the driver properly. So adding a rule of scsi_id in 60-persistent-storage alone might fix the issue.

On the other hand in case of Micron when the scsi_id (udev utility)hooks the ioctl (to inquire) the driver FAILS to populate the data only.
So to fit to the normal flow of other SSD's we may need a fix from driver end first to populate the data and then adding a rule of scsi_id in 60-persistent-storage .
Basically the driver fails to fill the data in case of Micron

Experiments made:
CASE 1 : 
Command for[SDA] : Strace –o scsi_id_op_for_sda.txt scsi_id --whitelisted –p0x80 –d /dev/sda
Output : SDELLPERC H710
Observation form log: Able to see that the IOCTL is hooked and the vendor and model listed

CASE 2 :Micron SSD
Command for[rssda] : Strace –o /home/scsi_id_op_for_rssda.txt scsi_id --whitelisted –p0x80 –d /dev/rssda
Output  : NO  OUTPUT
Observation form log: Able to see that the IOCTL is hooked but  the vendor and model not populated by driver

Attaching the logs of strace on scsi_id (udev utility) run for sata and micron ssd
Comment 17 Lakshmi_Narayanan_Du 2013-12-19 03:36:33 EST
Created attachment 838815 [details]
strace on scsi_id (udev utility) run for sata

Attaching the logs of strace on scsi_id (udev utility) run for sata
Comment 18 Lakshmi_Narayanan_Du 2013-12-19 03:37:29 EST
Created attachment 838816 [details]
strace on scsi_id (udev utility) run for Micron SSD

Attaching the logs of strace on scsi_id (udev utility) run for Micron SSD
Comment 19 Asai Thambi S P 2013-12-19 14:13:24 EST
(In reply to Lakshmi_Narayanan_Du from comment #16)
> In case of other ssds(sata) when the scsi_id(udev utility) hooks the driver
> ioctl (to inquire)  the data is populated by the driver properly. So adding
> a rule of scsi_id in 60-persistent-storage alone might fix the issue.
> 
> On the other hand in case of Micron when the scsi_id (udev utility)hooks the
> ioctl (to inquire) the driver FAILS to populate the data only.
> So to fit to the normal flow of other SSD's we may need a fix from driver
> end first to populate the data and then adding a rule of scsi_id in
> 60-persistent-storage .
> Basically the driver fails to fill the data in case of Micron
> 
> Experiments made:
> CASE 1 : 
> Command for[SDA] : Strace –o scsi_id_op_for_sda.txt scsi_id --whitelisted
> –p0x80 –d /dev/sda
> Output : SDELLPERC H710
> Observation form log: Able to see that the IOCTL is hooked and the vendor
> and model listed
> 
> CASE 2 :Micron SSD
> Command for[rssda] : Strace –o /home/scsi_id_op_for_rssda.txt scsi_id
> --whitelisted –p0x80 –d /dev/rssda
> Output  : NO  OUTPUT
> Observation form log: Able to see that the IOCTL is hooked but  the vendor
> and model not populated by driver
> 
> Attaching the logs of strace on scsi_id (udev utility) run for sata and
> micron ssd

Micron PCIe SSD is an AHCI based but not fully complaint. Micron driver is a block driver and not a SCSI driver.

To create by-id paths for Micron PCIe SSDs, need to add below rules in 60-persistent-storage.rules

# by-id (hardware serial number) for Micron PCIe SSDs
KERNEL=="rssd*[!0-9]", IMPORT{program}="ata_id --export $tempnode"
KERNEL=="rssd*[!0-9]", ENV{ID_SERIAL_SHORT}=="?*", SYMLINK+="disk/by-id/ata-$env{ID_SERIAL_SHORT}"
KERNEL=="rssd*[0-9]", ENV{ID_SERIAL_SHORT}=="?*", SYMLINK+="disk/by-id/ata-$env{ID_SERIAL_SHORT}-part%n"

Depending on how RH and Dell want the path to be, could use ID_SERIAL or ID_SERIAL_SHORT
Comment 20 Asai Thambi S P 2013-12-19 14:17:57 EST
Try the below command to see what values are being exported by ata_id

/lib/udev/ata_id --export /dev/rssda
Comment 21 Lakshmi_Narayanan_Du 2013-12-23 21:07:48 EST
Able to get the Vendor name from the driver (HDIO_GET_IDENTITY)
for the following run of ata_id

[root@localhost udev]#./ata_id /dev/rssda
DELL_P320h-MTFDGAL175SAH_00000000132202053655
Comment 22 Lakshmi_Narayanan_Du 2013-12-23 22:22:38 EST
Attaching strace for the ata_id run on /dev/rssda .
Able to see the SG_IO ioctl hooked and the vendor 
"DELL_P320h-MTFDGAL175SAH_00000000132202053655" displayed properly
Comment 23 Lakshmi_Narayanan_Du 2013-12-23 22:23:48 EST
Created attachment 841037 [details]
strace on ata_id
Comment 24 Lakshmi_Narayanan_Du 2014-01-28 06:56:02 EST
Hi,

When the rules in the comment 16 is added to 60-persistent-storage.rules
we don't get the Vendor name but only the model name filled in the 
udev db.(/dev/.udev/db/block\:rssda) from which the installer is reading to fill the device tree of UI

Attaching the cat /dev/.udev/db/block\:rssda output as the file 
rssda_details.txt.The output does not have the vendor name it has only the model name.(ID_VENDOR and ID_VENDOR_ENC) are missing ,only (ID_MODEL and ID_MODEL_ENC) are filled.

Attaching the cat /dev/.udev/db/block\:sda output as the file sda_details.txt

Attaching Vendor_name_missing.png as the difference of sda and rssda on the missing fields
----------------------
Both vendor and model name are NOT visible on the installer GUI for the following reasons
 
1)Vendor name missing: the rule in comment 16 does NOT FILL the vendor name(ID_VENDOR and ID_VENDOR_ENC) in /dev/.udev/db/block\:rssda 

2) Model name missing: though the rule in comment 16 FILLS the model name
 (ID_MODEL and ID_MODEL_ENC)in /dev/.udev/db/block\:rssda ,seems 
 INSTALLER FAILS to read it from this point and fill the GUI  
-----------------------
Thanks,
LN
Comment 25 Lakshmi_Narayanan_Du 2014-01-28 06:59:10 EST
Created attachment 856536 [details]
pcie ssd details

pcie ssd details in the path /dev/.udev/db/block\:rssda
Comment 26 Lakshmi_Narayanan_Du 2014-01-28 07:01:08 EST
Created attachment 856537 [details]
sda details

 sda details in the path /dev/.udev/db/block\:sda
Comment 27 Lakshmi_Narayanan_Du 2014-01-28 07:03:12 EST
Created attachment 856538 [details]
vendor name missing

vendor name missing - screenshot
Comment 28 Asai Thambi S P 2014-01-28 15:28:22 EST
(In reply to Lakshmi_Narayanan_Du from comment #24)
> Hi,
> 
> When the rules in the comment 16 is added to 60-persistent-storage.rules
> we don't get the Vendor name but only the model name filled in the 
> udev db.(/dev/.udev/db/block\:rssda) from which the installer is reading to
> fill the device tree of UI
> 

ATA device doesn't export vendor name explicitly in IDENTIFY DEVICE DATA (equivalent of INQUIRY DATA in SCSI). Mostly ATA model number is prefixed with Vendor name or vendor code, but not mandatory.

Model number of Micron PCIe SSDs start with "Dell" or "Micron" depending on the drive.

Could you brief UI device tree requirements and how it is done? Let me try if I can suggest an alternative from ATA perspective
Comment 29 Lakshmi_Narayanan_Du 2014-01-29 01:28:22 EST
We have debugged on the udev and not on any installer python scripts.

Based on my understanding on a quick walk through the devicetree code is there  in devicetree.py in the path /usr/lib/anaconda/storage/

I request Rhel team to comment and take it furhter on this anaconda installer 
debugging part.

Thanks,
LN
Comment 32 Harald Hoyer 2014-05-28 07:38:00 EDT
so, unless there is a method found to get the vendor, I will add at least the symlinks

# by-id (hardware serial number) for Micron PCIe SSDs
KERNEL=="rssd*[!0-9]", IMPORT{program}="ata_id --export $tempnode"
KERNEL=="rssd*[!0-9]", ENV{ID_SERIAL_SHORT}=="?*", SYMLINK+="disk/by-id/ata-$env{ID_SERIAL_SHORT}"
KERNEL=="rssd*[0-9]", ENV{ID_SERIAL_SHORT}=="?*", SYMLINK+="disk/by-id/ata-$env{ID_SERIAL_SHORT}-part%n"
Comment 33 Harald Hoyer 2014-06-06 10:25:43 EDT
Please test http://people.redhat.com/harald/downloads/udev/udev-147-2.53.el6/
Comment 35 Lakshmi_Narayanan_Du 2014-06-12 09:17:54 EDT
Summary:
--------
In case of Micron PCIe SSD we are NOT able to see BOTH the "vendor name" and the "model name" - Please find attached the screenshot for the same.Also find attached the "/tmp" logs 
---------------------------------------------------------------------
Steps:
------
Following are steps I have followed .I faced an issue in creating initrd and 
made minor change.Please see the steps I have done and confirm its correctness well

1) Built the  source RPM downloaded from http://people.redhat.com/harald/downloads/udev/udev-147-2.53.el6/

 Command : rpmbuild -bb
2) Got output rpms udev-147-2.53.el6.x86_64.rpm  and libudev-147-2.53.el6.x86_64.rpm

3) Extract the initrd

4) Extracted the rmps in step 2 and placed in the extracted initrd in step 3

5) Packed the initrd and started the pxe install

   PROBLEM I FACED HERE:
 [A] When the 60-persistent-storage.rules (with the applied patch) is placed in the path /etc/udev/rules.d/ and initrd packed then it seems to work fine .During installation when we switch to ctl + Alt +f2 and check the  
/etc/udev/rules.d/60-persistent-storage.rules the applied patch is  reflected

 [B] But When the 60-persistent-storage.rules (with the applied patch) is placed in the path /lib/udev/rules.d/ and initrd packed then it doesn't work fine .During installation when we switch to ctl + Alt +f2 and check the  
/lib/udev/rules.d/60-persistent-storage.rules the applied patch is  NOT GETTING reflected

 "So here I have moved the 60-persistent-storage.rules to etc like [A]"

6) Proceed and reach the "device tree" in the installer
Comment 36 Lakshmi_Narayanan_Du 2014-06-12 09:19:10 EDT
Created attachment 908126 [details]
tmp log
Comment 37 Lakshmi_Narayanan_Du 2014-06-12 09:20:30 EDT
Created attachment 908128 [details]
screen shot
Comment 39 Ben Hutchings 2014-06-13 18:36:45 EDT
I recently came across this problem while working with Micron on the mtip32xx driver.  There is a related bug in ata_id and I'm not sure whether it belongs in this report or in a separate report, but I'll just briefly describe it.

The main() function duplicates the identity information in an array of 512 bytes (identity), and a structure with named fields (id), and then reads from both seemingly at random.  However, if it falls back to the HDIO_GET_IDENTITY ioctl - as it will for any non-libata driver - only the structure is filled and any fields looked up in the array read back as all zeroes.

In RHEL 6, this causes the ID_ATA_SATA, ID_ATA_SATA_SIGNAL_RATE_GEN{1,2}, ID_ATA_ROTATION_RATE_RPM, ID_WWN and ID_WWN_WITH_EXTENSION variables not to be set.  It would be desirable to have the WWN available as well as the serial number in future.

(I believe this bug is still present in current udev/systemd so I would expect to have to get it fixed there first.)
Comment 42 errata-xmlrpc 2014-10-14 03:17:31 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1524.html

Note You need to log in before you can comment on or make changes to this bug.