Bug 112585 - scsi_unique_id suspends system in rc.sysinit after installation
Summary: scsi_unique_id suspends system in rc.sysinit after installation
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: devlabel
Version: 9
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-12-23 19:28 UTC by dan clark
Modified: 2014-03-17 02:41 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2004-09-08 19:47:41 UTC

Attachments (Terms of Use)

Description dan clark 2003-12-23 19:28:05 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5)
Gecko/20031007 Firebird/0.7

Description of problem:
scsi_unique_id hangs some systems on installation of linux.  Many
older scsi deveices may not support the query for 0x83 vital data
page.  The program scsi_unique_id could be modified to query the vital
product data page to determine which inquiries the device supports
prior to attempting an inquiry which would hang the entire system.
In particular quoting from a scsi inteface product manual:
'if a device server supports any vital product data pages, it also
shall support the vital product data page for 'supported vital product

Version-Release number of selected component (if applicable):
devlabel-0.26.08-3 && devlabel-0.44.01

How reproducible:

Steps to Reproduce:
1. Attach a scsi i/o card to the system
2. Attach an older scsi drive that does not support 0x83 queries
   (for example: QUANTUM VIKING II 4.5WSE attached to a qlogics 1040)
3. install redhat 9.0.  after installation the first boot runs 
  /sbin/devlabel restart
  which hangs the system and forces a hardware reset to recover

in order to get into the system boot from the cdrom into rescue mode
cd /mnt/sysimage/etc/rc.d
remove use of /sbin/devlabel

change use of labels in /etc/fstab
for example use the partitions directly in /etc/fstab
/dev/sda2               /                       ext3    defaults   1 1
/dev/sda1               /boot                   ext3    defaults   1 2

instead of
LABEL=/                 /                       ext3    defaults  1 1
LABEL=/boot             /boot                   ext3    defaults  1 2

and reboot the system

Once the system is rebooted running the command
scsi_unique_id /dev/sda
will lock up the system every time.


Actual Results:  The system hangs every time on initial boot post
installation after the message:
Finding module dependencies

Expected Results:  The system should run "/sbin/devlabel restart"
(which in turn runs scsi_unique_id) without causing the system to lock up.

Additional info:

Based on the scsi documentation the vital product data page inquiry
provides a list of the vpdp pages which are supported by a device.  By
making this inquiry first and then only doing the sub inquiries based
on the supported pages available from the device the scsi_unique_id
program would be more robust and handle a larger number of devices. 
This would also prevent systems from locking up when using the
devlabel software on systems with older drives.

Here is an example of a rewrite taking this information into account:
Add a routine to return the vital product data information from an
inquiry command with the EVPD bit set to one and obtaining the
'supported vital product data pages'.  Then using the returned
'supported page list' each of the sub-inquiries of interest can be
made with the information from the device that the inquiry is ok to make.
 * inquire for the vital product data pages 
 * determine if 0x80 and 0x83 inquiries are supported or not
 * then make inquiry of pages that are supported by device/driver
 * 0x00 supported vital product data pages
 * 0x80 unit serial number page
 * 0x83 device identification page
do_scsi_vpdp_inquiry(int fd, int rdev)
        int len, i;
        unsigned char buf[256];
        ushort vpdp_cnt;        /* count of vpdp pages */

        memset(buf, 0, 256);
        len = generic_scsi_inquiry(fd, 1, 0, buf, 255);
        if (len < 0) return len;
        vpdp_cnt = (ushort)buf[3];
        for(i = 0; i < vpdp_cnt; i++) {
                ushort vpdp_type;
                vpdp_type = buf[4 + i];
                /* printf("0x%02x ", vpdp_type); */
                switch(vpdp_type) {
                case 0x80:
                        // Get SCSI page80 unite serial number page
                        do_scsi_80_inquiry(fd, rdev);
                case 0x83:
                        // Get SCSI page83 device identification page
                        do_scsi_83_inquiry(fd, rdev);
        /* printf("\n"); */
        return 0;

change main()
old code unconditionally reads the various mode pages which is
replaced below by routine that checks for which pages are supported 
by the devices before making the inquiry.
<        // Print out generic information about this device
<        do_scsi_info_inquiry(fd, rdev);
<        // Get SCSI page83 info
<        do_scsi_83_inquiry(fd, rdev);
<        // Get SCSI page80 info
<        do_scsi_80_inquiry(fd, rdev);
modified main uses new vpdp inquiry routine to only access supported
>        // Print out generic information about this device
>        // drive standard inquiry data
>        do_scsi_info_inquiry(fd, rdev);
>        // inquire for the optional vital product data pages 
>        do_scsi_vpdp_inquiry(fd, rdev);

Comment 1 Gary Lerhaupt 2004-01-06 17:00:10 UTC
I have included this code in devlabel-0.45.01.

See http://lerhaupt.com/devlabel
and http://www.lerhaupt.com/foo/archives/000164.html


Comment 2 Bill Nottingham 2004-09-08 19:47:41 UTC
Fixed in current releases.

Comment 3 Peter Kruty 2004-11-29 03:27:51 UTC
I just saw this problem on SMP Opteron machine with RHAS 3.0 and
2.6.9 (2.6.10-rc2 also). devlabel-0.42.05-2.1 (RPM) and devlabel-0.48.01
(TAR.GZ) both hangs the system. But _only_ when I compile kernel
with CONFIG_DEBUG_SLAB. The scsi_unique_id hangs in second ioctl call:

# strace ./scsi_unique_id /dev/sda 2>&1 | fgrep ioctl
ioctl(3, 0x5386, 0x7fbffff75c)          = 0
ioctl(3, FIBMAP, 0x502010)              = 0

without CONFIG_DEBUG_SLAB ./scsi_unique_id call runs without problems.

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