Bug 515566

On 08/04/2009 02:41 PM, Alan Pevec wrote:
> Subhendu Ghosh wrote:
>> It looks like the required kernel changes for exposing cciss to hal are
>> already in.
>>
>> The question here is does the new requirement for block.device also
>> require a
>> kernel change - I have not see any response on that.
>
> it is there afaict:
> cat /sys/block/cciss\!c0d0/dev
> 104:0
>
> [root@hp-dl380g5-01 ~]# ls -l /dev/cciss/c0d0
> brw-r----- 1 root disk 104, 0 Aug 4 09:36 /dev/cciss/c0d0
>
> If HAL can convert that to block.device, great.
> If not, I can add this special case in RHEV-H scripts.

this bug is also relevant for libvirt, which uses hal to enumerate available hardware:

# virsh nodedev-dumpxml  pci_8086_25e3_storage
<device>
 <name>pci_8086_25e3_storage</name>
 <parent>pci_103c_3230</parent>
 <capability type='storage'>
   <block>(null)</block>
   <bus>pci</bus>
   <drive_type>disk</drive_type>
   <size>293564211200</size>
 </capability>
</device>

on "normal" HBAs you get <block>/dev/sdg</block>

Is anything required from the driver side?

-- mikem

Got David to help look at this since he's local to the machines in Westford.  His comments follow:

<<<
I have now spent some time looking into this. My findings are based on
RHEL5.5 with hp-bl460cg5-01.rhts.eng.bos.redhat.com

 udev-095-14.21.el5
 kernel-2.6.18-164.el5
 hal-0.5.8.1-52.el5

To recap, the problem we are trying to solve here is that block.device
is empty for certain cciss devices. After examining the system, it
appears that 

 [root@hp-bl460cg5-01 ~]# udevinfo -q all -p /sys/block/cciss\!c0d0
 no record for '/block/cciss!c0d0' in database

fails despite the existence of /dev/cciss/c0d0. I bet that udev gets it
wrong with the special handling that is required for '!' characters.

Anyway, all this indicates that we are dealing with a udev bug. Once
this is fixed, HAL should work as expected.

Thanks,
David

[1] : Just to check the syntax is correct, note that

 [root@hp-bl460cg5-01 ~]# udevinfo -q all -p /sys/block/cciss\!c0d0/cciss\!c0d0p1
 P: /block/cciss!c0d0/cciss!c0d0p1
 N: cciss/c0d0p1
 S: disk/by-uuid/93db4871-1977-47e4-a350-85b07f5fc33e
 S: disk/by-label/boot
 E: ID_FS_USAGE=filesystem
 E: ID_FS_TYPE=ext3
 E: ID_FS_VERSION=1.0
 E: ID_FS_UUID=93db4871-1977-47e4-a350-85b07f5fc33e
 E: ID_FS_LABEL=/boot
 E: ID_FS_LABEL_SAFE=boot

works as expected.

>>>

Mike

Is there anyway to stop CCISS from generating /sys etries with "!" ?

We don't actually do the "!" from the driver. Here's what we do:

cciss_add_disk(ctlr_info_t *h, struct gendisk *disk,
                                int drv_index) {
        disk->queue = blk_init_queue(do_cciss_request, &h->lock);
        if (!disk->queue)
                goto init_queue_failure;
        sprintf(disk->disk_name, "cciss/c%dd%d", h->ctlr, drv_index); <------ here.
        disk->major = h->major;
        disk->first_minor = drv_index << NWD_SHIFT;
        disk->fops = &cciss_fops;
        if (cciss_create_ld_sysfs_entry(h, drv_index))

Something in the upper layers substitutes the slash in the path with a bang since you can't have a slash in a filename. And udev depends on that bang to figure out the cciss device nodes.

Because it has no symlinks and anything else:

udev_db_add_device: nothing interesting to store in udevdb, skip

this is udev-095, not udev-147!

# udevinfo -q all -n /dev/null
no record for 'null' in database

# udevinfo -q all -n /dev/md0
no record for 'md0' in database


udev-095 only stores entries in the database, if there is something to record!

reassigning back to hal

adding
50-udev.rules:KERNEL=="cciss?c[0-9]d[0-9]", ENV{ID_SERIAL}!="?*", IMPORT{program}="scsi_id -g -x -a -n -s %p -d $tempnode", ENV{ID_BUS}="cciss"

helps though

# udevinfo -q all -n /dev/cciss/c0d0
P: /block/cciss!c0d0
N: cciss/c0d0
E: ID_VENDOR=HP
E: ID_MODEL=LOGICAL_VOLUME
E: ID_REVISION=1.80�
E: ID_SERIAL=3600508b1001033393820202020200000
E: ID_TYPE=disk
E: ID_BUS=cciss

reassigning back to udev..

 udev-095-14.22.el5

cciss now works with scsi_id?

Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.

New Contents:
Previously, cciss devices did not have an entry in the udev database. This was caused by the fact that these devices do not provide information in the /sys file system, making it hard to create persistent symbolic links in /dev/disk. With this update, the scsi_id utility is used to query the ID of cciss devices, so that udev can create the database entries as expected.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0073.html