Bug 230480

Hey Harald -- Any further info you need on this one? Thanks!

which devices are connected to the qla1280 ?

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Sorry, I thought I had update this.

It is a SCSI disk vault with 8 drives in it.

Please test:
http://people.redhat.com/harald/downloads/udev/udev-039-10.18.el4

I tried this on altix2 (350 that is leaving) which has
an a different SCSI controller:

    LSI53C1030, FwRev=01030f00h

and also on "altix6" which has a SAS interface:

    LSISAS1068, FwRev=01100000h,

In both cases the /dev/sg* are there for rhel5 (nightly)
but not for rhel4 (nightly) with the new udev.

I will investigate more tomorrow.

I tried loading the rhel5.1 udev (compiled without selinux support) and that
also failed to generate the /dev/sg* on altix2.

I am going to verify that rhel5.1 does generate the /dev/sg* as the next step.

On altix2 w/ rhel5 the /dev/sg* devices are present on boot.

hmm, this is more a hotplug problem on rhel4
/etc/hotplug/scsi.agent should be modified to load the sg module on any scsi
device then.

What specifically do you need the /dev/sg modules for? I suspect hotplug is
actually the wrong place, as these devices aren't hotplugged on boot.

Also, attach /proc/scsi/scsi.

Created attachment 160537 [details]
/proc/scsi/scsi

The disk vault is turned on.  Note that you may need to turn
the disk vault off to install rhel and then turn it back on
again.	The reason is that the order in which disk drivers
are discovered and labeled is non-deterministic --- unless
the partitions are labeled at which point udev can figure
things out.

Oops, lost part of my-cut-n-paste.

The applications that use /dev/sg* are from the sg3_utils package.

Try 'sg_map -a'

What, specifically, do they need /dev/sg* for? They should work fine with SG_IO
on the actual scsi devices.

What this really comes down to is doing 'modprobe sg' when a disk vault
is present --- that is all that is required to fix the problem.

The primary concern are the tools for mapping LUNs to a disk vault and
other multi-path related activities still expect that the /dev/sg*
devices are present.

I am unclear what the concern is behind your questions.  Since the /dev/sg*
exist on Rhel5.0 and Rhel5.1-beta it seems that it is not RedHat policy
that they be deprecated at this time.  Since one of the packages which
is broken without the /dev/sg* is sg3_utils which is shipped by
RedHat under both Rhel4.5/4.6 and Rhel5.0/5.1 it would seem reasonable
that the need was recognized within RedHat.

Can you clarify what RH's position?
If sg_map is deprecated what tool you feel should be used in its place?

sg is already loaded for non disk/CD/tape devices. I'm just curious what
specific functionality you need that requires /dev/sg access rather than SG_IO
on /dev/sdX.

sg_map is circular reasoning; if you use SG_IO on the devices, you don't need
the mapping. If you need host/channel/id/lun, that's also available from HAL.

It's not that it can't be fixed, but we want to know what's using it so we can
get *those* programs fixed, sg3_utils included.

Ah, we have been talking at cross purposes --- at least to some extent.

The programs that I am concerned about are those that provide
in-band control of disk vaults (storage area network solutions)
like the SGI IS220.  I have not taken the time to see if they
can easily be switched to using SG_IO but as soon as regressions
for 5.1 and 4.6 are covered I will take a look at that.

I don't agree that sg_map is circular reasoning --- is is a broken
RedHat app in 4.6 --- period.

Still, your fundamental point is valid that /dev/sg* is being
replaced.  Will they be present and supported in Rhel 5.2 or
should I warn my management?

In any case, it is worth holding this bug open as a reminder to
me to look at moving /dev/sg* to SG_IO.

Oh, /dev/sg* will be there in 5.2. As for the disk vaults, if they show up as a
separate SCSI host/channel/id/lun, sg should already be loaded for them - is it not?

We just don't load sg for disk/CD/tape devices by default.

On 5.1 yes, on 4.6 no --- otherwise I never would have filed the bug :-).

Note: if you want to verify this on an altix system one needs to
do an install and then reboot with the disk vault attached.

Trying to get anaconda to understand the difference between system
disks and a vault is not a fun experience.

What SCSI class is the device? Judging by the prior example, it is a 'disk'
(direct-access), ergo sg is not loaded.

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Any response?

We are concluding the planning phase for 4.7 tomorrow. This issue has been in
needinfo for months.  Obviously we can not commit to providing this fix in the
absence of the needinfo.  So, given where we are in the release cycle and lack
of response, we have no alternative but to devel-nak.  

Sorry, this has been a low priority.

At this point I believe the only package broken is sg3_utils,
specifically sg_map, which is an RH not an SGI package.

We are not seeing new RHEL4 sales and the /dev/sg* are created
in RHEL5.1-ga so feel free to won't fix this.

George

Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.