Bug 230480 - The /dev/sg* are not being created for qla1280
The /dev/sg* are not being created for qla1280
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: hotplug (Show other bugs)
4.5
ia64 Linux
medium Severity low
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
:
Depends On: 247221
Blocks: 253738
  Show dependency treegraph
 
Reported: 2007-02-28 17:33 EST by George Beshers
Modified: 2014-03-16 23:05 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-15 09:55:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/proc/scsi/scsi (1.56 KB, application/octet-stream)
2007-08-02 12:47 EDT, George Beshers
no flags Details

  None (edit)
Description George Beshers 2007-02-28 17:33:56 EST
Description of problem:
  Booting directly after installation the /dev/sg* are not being created.
  This may be a kernel problem as I am not seeing sg in /proc/devices.


Version-Release number of selected component (if applicable):
  RHEL4.5 20070228


How reproducible:
  Everytime


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
  'MAKEDEV sg' and things work as expected.
Comment 1 Marizol Martinez 2007-04-12 12:06:11 EDT
Hey Harald -- Any further info you need on this one? Thanks!
Comment 2 Harald Hoyer 2007-04-13 04:27:51 EDT
which devices are connected to the qla1280 ?
Comment 3 RHEL Product and Program Management 2007-05-09 03:06:34 EDT
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.
Comment 6 George Beshers 2007-07-16 13:29:51 EDT
Sorry, I thought I had update this.

It is a SCSI disk vault with 8 drives in it.
Comment 8 Harald Hoyer 2007-07-18 06:25:36 EDT
Please test:
http://people.redhat.com/harald/downloads/udev/udev-039-10.18.el4
Comment 9 George Beshers 2007-07-19 18:17:39 EDT
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.
Comment 10 George Beshers 2007-07-20 11:37:24 EDT
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.
Comment 11 George Beshers 2007-07-20 14:35:20 EDT
On altix2 w/ rhel5 the /dev/sg* devices are present on boot.

Comment 12 Harald Hoyer 2007-08-01 04:36:14 EDT
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.
Comment 13 Bill Nottingham 2007-08-01 10:09:54 EDT
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.
Comment 15 Bill Nottingham 2007-08-01 11:01:11 EDT
Also, attach /proc/scsi/scsi.
Comment 17 George Beshers 2007-08-02 12:47:58 EDT
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.
Comment 18 George Beshers 2007-08-02 15:21:16 EDT
Oops, lost part of my-cut-n-paste.

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

Try 'sg_map -a'
Comment 19 Bill Nottingham 2007-08-02 15:25:45 EDT
What, specifically, do they need /dev/sg* for? They should work fine with SG_IO
on the actual scsi devices.
Comment 20 George Beshers 2007-08-08 11:09:46 EDT
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?
Comment 21 Bill Nottingham 2007-08-08 13:02:38 EDT
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.
Comment 22 George Beshers 2007-08-08 14:03:36 EDT
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.
Comment 23 Bill Nottingham 2007-08-08 14:26:50 EDT
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.
Comment 24 George Beshers 2007-08-08 15:40:56 EDT
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.
Comment 25 Bill Nottingham 2007-08-08 15:51:36 EDT
What SCSI class is the device? Judging by the prior example, it is a 'disk'
(direct-access), ergo sg is not loaded.
Comment 26 RHEL Product and Program Management 2007-11-28 23:21:47 EST
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.
Comment 27 Bill Nottingham 2008-02-12 12:24:34 EST
Any response?
Comment 28 Tim Burke 2008-02-14 22:28:31 EST
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.  
Comment 29 George Beshers 2008-02-15 09:51:12 EST
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
Comment 30 RHEL Product and Program Management 2008-02-15 09:55:19 EST
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request. 

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