Bug 197112 - FEAT:Need SCSI generic module loaded for tape firmware update to work.
FEAT:Need SCSI generic module loaded for tape firmware update to work.
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: module-init-tools (Show other bugs)
4.5
All Linux
high Severity high
: ---
: ---
Assigned To: Jon Masters
:
Depends On:
Blocks: 190484 225073
  Show dependency treegraph
 
Reported: 2006-06-28 12:50 EDT by Sandeep K. Shandilya
Modified: 2010-10-22 01:20 EDT (History)
4 users (show)

See Also:
Fixed In Version: RHBA-2007-0265
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-01 18:51:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Sandeep K. Shandilya 2006-06-28 12:50:56 EDT
Description of problem:
Utilities that flash firmware to tape drives etc... need to access the device
through the SCSI pass through (SCSI generic). The firmware flash utility tries
to open /dev/sg? and fails because sg.ko is not loaded and the open() fails. The
firmware utility aborts saying it did not find the tape drive.

Version-Release number of selected component (if applicable):
observed on RHEL 4 update 3

How reproducible:
always

Steps to Reproduce:
1. download the DFU utility from 
http://www.quantum.com/ServiceandSupport/SoftwareandDocumentationDownloads/DAT72Drives/Index.aspx#Firmware
2. connect a tape drive (DAT 72) to a SCSI card
3. Run the utility and scan for any SCSI tape drives.
  
Actual results:
The scan fails.
Now run modprobe sg and run the utility again. The Scan succeeds.

Expected results:
The utility should be able to the scan the tape drive and flash the firmware on
it without doing a modprobe sg manually.

Additional info:
The sg module needs to be loaded beforehand through initscripts.
The strace output of the DFU utility is also attached.
Comment 1 Bill Nottingham 2006-06-29 01:13:06 EDT
Have they tried using SG_IO on the actual device node?
Comment 2 Bill Nottingham 2006-06-29 01:14:11 EDT
Assigning to udev; this is probably best handled there. For example, in current
Fedora releases we have:

ACTION=="add", SUBSYSTEM=="scsi_device" RUN+="/sbin/modprobe sg"
Comment 3 Sandeep K. Shandilya 2006-06-29 02:19:23 EDT
(In reply to comment #2)
> Assigning to udev; this is probably best handled there. For example, in 
current
> Fedora releases we have:
> ACTION=="add", SUBSYSTEM=="scsi_device" RUN+="/sbin/modprobe sg"

The application is just calling the open("/dev/sg0",....). I dont think that 
udev should be responsible to load a module at this time?


Comment 4 Sandeep K. Shandilya 2006-06-29 06:40:49 EDT
(In reply to comment #2)
> Assigning to udev; this is probably best handled there. For example, in 
current
> Fedora releases we have:
> ACTION=="add", SUBSYSTEM=="scsi_device" RUN+="/sbin/modprobe sg"

I tried the same on fc5 and the module get autoloaded. I will try the same on 
RHEL 4 by adding the line you have mentioned above.
Comment 5 Sandeep K. Shandilya 2006-06-29 10:46:48 EDT
Can this fix make it to RHEL4 update4? If there is patch that you want me to 
check out I could help. I am setting up a test to make changes to udev.rules to 
try this out.
Comment 6 Bill Nottingham 2006-06-29 12:51:51 EDT
While I'm not the udev maintainer, it is very late in the update cycle for U4;
we've well passed the content definition process.
Comment 7 Larry Troan 2006-07-20 10:50:11 EDT
This request is too late for RHEL4 Update4 -- it's closed and due out by the end
of the month.

RHEL4.5 is also closed for feature requests. If this is critical, we can
escalate it for late consideration. I will need a business case and Dell's
agreement to escalate. In the meantime, I've put it on the RHEL4.6 list for
consideration. Though there's no schedule yet, GA will likely be in the summer
of '07.
Comment 8 Sandeep K. Shandilya 2006-07-26 04:21:54 EDT
(In reply to comment #7)
> This request is too late for RHEL4 Update4 -- it's closed and due out by the end
> of the month.
> 
> RHEL4.5 is also closed for feature requests. If this is critical, we can
> escalate it for late consideration. I will need a business case and Dell's
> agreement to escalate. In the meantime, I've put it on the RHEL4.6 list for
> consideration. Though there's no schedule yet, GA will likely be in the summer
> of '07.

Yes this is critical because the DAT72 is a low end SCSI tape drive. These are
used in the small and medium Buisness and are sold in large quantities. Moreover
none of the other tape management commands (eject, forward, rewind etc...)work
because all of them require the /dev/sg? nodes to be present. In all the above
cases manual intervention to load sg is required.
Customers are very likely to call Dell support if they observe that thier drive
is not working as expected and they are not aware about the sg module.
Comment 15 Larry Troan 2006-09-26 08:42:16 EDT
Red Hat assumes Dell will test this during RHEL4.5 beta.
Comment 16 Issue Tracker 2006-09-27 17:13:18 EDT
Yes, Dell will test this during 4.5 Beta.


This event sent from IssueTracker by ltroan 
 issue 97824
Comment 17 Harald Hoyer 2006-12-15 06:39:28 EST
please let dell test
http://people.redhat.com/harald/downloads/udev/udev-039-10.16.EL4/
Comment 18 Harald Hoyer 2006-12-20 10:04:33 EST
ping?
Comment 19 Sandeep K. Shandilya 2006-12-22 08:14:52 EST
(In reply to comment #18)
> ping?

No the module does not autoload with this rule. I could attach some logs to the
defect, what will you need. I can think starting udevd with log level set to
LOG_DEBUG?
Comment 20 Harald Hoyer 2007-01-22 06:01:44 EST
Best solution:
add to /etc/modprobe.conf.dist:
install st /sbin/modprobe --ignore-install st && /sbin/modprobe sg
Comment 24 Sandeep K. Shandilya 2007-01-29 05:09:47 EST
(In reply to comment #20)
> Best solution:
> add to /etc/modprobe.conf.dist:
> install st /sbin/modprobe --ignore-install st && /sbin/modprobe sg
> 

It works okay now.
Comment 25 Sandeep K. Shandilya 2007-01-29 06:34:20 EST
(In reply to comment #20)
> Best solution:
> add to /etc/modprobe.conf.dist:
> install st /sbin/modprobe --ignore-install st && /sbin/modprobe sg
> 

(In reply to comment #24)
> (In reply to comment #20)
> > Best solution:
> > add to /etc/modprobe.conf.dist:
> > install st /sbin/modprobe --ignore-install st && /sbin/modprobe sg
> > 
> 
> It works okay now.
> 
I presume that it will be available in the next update of RHEL4.[56]'s
module-init-tools package.
Comment 29 Red Hat Bugzilla 2007-05-01 18:51:11 EDT
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 the 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-2007-0265.html

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