Bug 131801 - mtx can no longer open /dev/sg devices
mtx can no longer open /dev/sg devices
Status: CLOSED WORKSFORME
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Doug Ledford
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-04 15:27 EDT by Dax Kelson
Modified: 2007-11-30 17:07 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-17 22:57:44 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 Dax Kelson 2004-09-04 15:27:58 EDT
Description of problem:

The mtx command is used to control the robotic arm of tape libraries.
With the U3 kernel (2.4.21-20.EL) the mtx command no longer works.

# mtx -f /dev/sg3 status
cannot open SCSI device '/dev/sg3' - No such device or address

Rolling back to the 2.4.21-15.0.3.EL kernel and it is working again.



# mtx -f /dev/sg3 status
  Storage Changer /dev/changer:2 Drives, 20 Slots ( 1 Import/Export )
Data Transfer Element 0:Full (Storage Element 4 Loaded):VolumeTag =
BLP454S
Data Transfer Element 1:Empty
      Storage Element 1:Full :VolumeTag=BLP451S
      Storage Element 2:Full :VolumeTag=BLP452S
      Storage Element 3:Full :VolumeTag=BLP453S
      Storage Element 4:Empty
      Storage Element 5:Full :VolumeTag=BLP455S
      Storage Element 6:Full :VolumeTag=BLP456S
      Storage Element 7:Full :VolumeTag=BLP457S
      Storage Element 8:Full :VolumeTag=BLP458S
      Storage Element 9:Full :VolumeTag=CLN950
      Storage Element 10:Full :VolumeTag=BLP459S
      Storage Element 11:Full :VolumeTag=BLP460S
      Storage Element 12:Full :VolumeTag=BLP461S
      Storage Element 13:Full :VolumeTag=BLP462S
      Storage Element 14:Full :VolumeTag=BLP463S
      Storage Element 15:Full :VolumeTag=BLP464S
      Storage Element 16:Full :VolumeTag=BLP465S
      Storage Element 17:Full :VolumeTag=BLP466S
      Storage Element 18:Full :VolumeTag=BLP467S
      Storage Element 19:Full :VolumeTag=BLP468S
      Storage Element 20 IMPORT/EXPORT:Full :VolumeTag=BLP450S
Comment 1 Ken Snider 2004-09-07 12:50:13 EDT
This is working for us with the new kernel, So I'd suggest that the
SCSI driver you are using is at fault. Which driver is loaded for your
library?

[root@chimera.dw root]# uname -r
2.4.21-20.EL
[root@chimera.dw root]# mtx status
  Storage Changer /dev/changer:1 Drives, 6 Slots ( 0 Import/Export )
Data Transfer Element 0:Empty
      Storage Element 1:Full
      Storage Element 2:Full
      Storage Element 3:Full
      Storage Element 4:Full
      Storage Element 5:Full
      Storage Element 6:Full
Comment 3 Dax Kelson 2004-09-07 17:12:31 EDT
Is there some sg white list in place?

Under 2.4.21-15.0.3.EL, here is what I see in dmesg:

[snip stuff]
SCSI subsystem driver Revision: 1.00
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
        <Adaptec 2940 Ultra SCSI adapter>
        aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs
 
scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
        <Adaptec 2944 Ultra SCSI adapter>
        aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs
 
blk: queue f7fd0a18, I/O limit 4095Mb (mask 0xffffffff)
(scsi0:A:2): 20.000MB/s transfers (10.000MHz, offset 8, 16bit)
  Vendor: ATL       Model: 1500              Rev: 2.00
  Type:   Medium Changer                     ANSI SCSI revision: 02
blk: queue f7fd0818, I/O limit 4095Mb (mask 0xffffffff)
(scsi0:A:3): 20.000MB/s transfers (10.000MHz, offset 8, 16bit)
  Vendor: QUANTUM   Model: DLT8000           Rev: 0250
  Type:   Sequential-Access                  ANSI SCSI revision: 02
blk: queue f7fd2c18, I/O limit 4095Mb (mask 0xffffffff)
(scsi0:A:4): 20.000MB/s transfers (10.000MHz, offset 8, 16bit)
  Vendor: QUANTUM   Model: DLT8000           Rev: 0250
  Type:   Sequential-Access                  ANSI SCSI revision: 02
blk: queue f7fd9618, I/O limit 4095Mb (mask 0xffffffff)
(scsi1:A:2): 20.000MB/s transfers (10.000MHz, offset 8, 16bit)
  Vendor: ATL       Model: 1500              Rev: 2.08
  Type:   Medium Changer                     ANSI SCSI revision: 02
blk: queue f7fd2e18, I/O limit 4095Mb (mask 0xffffffff)
(scsi1:A:3): 20.000MB/s transfers (10.000MHz, offset 8, 16bit)
  Vendor: QUANTUM   Model: DLT8000           Rev: 022B
  Type:   Sequential-Access                  ANSI SCSI revision: 02
blk: queue f7fd3418, I/O limit 4095Mb (mask 0xffffffff)
(scsi1:A:4): 20.000MB/s transfers (10.000MHz, offset 8, 16bit)
  Vendor: QUANTUM   Model: DLT8000           Rev: 022B
  Type:   Sequential-Access                  ANSI SCSI revision: 02
blk: queue f7fd3618, I/O limit 4095Mb (mask 0xffffffff)
3ware Storage Controller device driver for Linux v1.02.00.033.
scsi2 : Found a 3ware Storage Controller at 0xefa0, IRQ: 22, P-chip: 1.3
scsi2 : 3ware Storage Controller
blk: queue f7fd2818, I/O limit 4095Mb (mask 0xffffffff)
  Vendor: 3ware     Model: Logical Disk 1    Rev: 1.0
  Type:   Direct-Access                      ANSI SCSI revision: 00
blk: queue f7fd0018, I/O limit 4095Mb (mask 0xffffffff)
Attached scsi disk sda at scsi2, channel 0, id 1, lun 0
SCSI device sda: 2109898752 512-byte hdwr sectors (1080268 MB)
[snip a bunch of stuff]
Attached scsi generic sg0 at scsi0, channel 0, id 2, lun 0,  type 8
Attached scsi generic sg3 at scsi1, channel 0, id 2, lun 0,  type 8
Comment 4 Doug Ledford 2005-10-17 22:57:44 EDT
This bug has been inactive for over a year.  If the problem still exists in the
latest kernels, please reopen this report.

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