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.
Have they tried using SG_IO on the actual device node?
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"
(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?
(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.
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.
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.
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.
(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.
Red Hat assumes Dell will test this during RHEL4.5 beta.
Yes, Dell will test this during 4.5 Beta. This event sent from IssueTracker by ltroan issue 97824
please let dell test http://people.redhat.com/harald/downloads/udev/udev-039-10.16.EL4/
ping?
(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?
Best solution: add to /etc/modprobe.conf.dist: install st /sbin/modprobe --ignore-install st && /sbin/modprobe sg
(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.
(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.
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