Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 230480 - The /dev/sg* are not being created for qla1280
Summary: The /dev/sg* are not being created for qla1280
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: hotplug
Version: 4.5
Hardware: ia64
OS: Linux
Target Milestone: ---
: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2007-02-28 22:33 UTC by George Beshers
Modified: 2014-03-17 03:05 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-02-15 14:55:19 UTC
Target Upstream Version:

Attachments (Terms of Use)
/proc/scsi/scsi (deleted)
2007-08-02 16:47 UTC, George Beshers
no flags Details

Description George Beshers 2007-02-28 22:33:56 UTC
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:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
  'MAKEDEV sg' and things work as expected.

Comment 1 Marizol Martinez 2007-04-12 16:06:11 UTC
Hey Harald -- Any further info you need on this one? Thanks!

Comment 2 Harald Hoyer 2007-04-13 08:27:51 UTC
which devices are connected to the qla1280 ?

Comment 3 RHEL Product and Program Management 2007-05-09 07:06:34 UTC
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

Comment 6 George Beshers 2007-07-16 17:29:51 UTC
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 10:25:36 UTC
Please test:

Comment 9 George Beshers 2007-07-19 22:17:39 UTC
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 15:37:24 UTC
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 18:35:20 UTC
On altix2 w/ rhel5 the /dev/sg* devices are present on boot.

Comment 12 Harald Hoyer 2007-08-01 08:36:14 UTC
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 14:09:54 UTC
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 15:01:11 UTC
Also, attach /proc/scsi/scsi.

Comment 17 George Beshers 2007-08-02 16:47:58 UTC
Created attachment 160537 [details]

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 19:21:16 UTC
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 19:25:45 UTC
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 15:09:46 UTC
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 17:02:38 UTC
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 18:03:36 UTC
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 18:26:50 UTC
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 19:40:56 UTC
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 19:51:36 UTC
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-29 04:21:47 UTC
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

Comment 27 Bill Nottingham 2008-02-12 17:24:34 UTC
Any response?

Comment 28 Tim Burke 2008-02-15 03:28:31 UTC
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 14:51:12 UTC
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.


Comment 30 RHEL Product and Program Management 2008-02-15 14:55:19 UTC
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.