Bug 839172

anaconda uses pci.ids from the hwdata package, you don't need to open another bugzilla.

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 ?

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.

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.

Just added two more device ids. Please get the latest list.

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 ***

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.

Created attachment 647917 [details]
Micron device listed as "Unknown" in anaconda

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.

sub-device and sub-vendor fields are optional. This should be handled by anaconda. Reassigning.

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.

(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.

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

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

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

(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

Try the below command to see what values are being exported by ata_id

/lib/udev/ata_id --export /dev/rssda

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

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

Created attachment 841037 [details]
strace on ata_id

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

Created attachment 856536 [details]
pcie ssd details

pcie ssd details in the path /dev/.udev/db/block\:rssda

Created attachment 856537 [details]
sda details

 sda details in the path /dev/.udev/db/block\:sda

Created attachment 856538 [details]
vendor name missing

vendor name missing - screenshot

(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

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

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"

Please test http://people.redhat.com/harald/downloads/udev/udev-147-2.53.el6/

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

Created attachment 908126 [details]
tmp log

Created attachment 908128 [details]
screen shot

https://bugzilla.redhat.com/show_bug.cgi?id=1020856#c25

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.)

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