From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Description of problem: The description of a high-LUN SCSI device in /proc/scsi/scsi is mangled. I have an autoloader on the SCSI bus (see below for more info). Then: $ mt -f /dev/st0 status SCSI 2 tape drive: File number=0, block number=0, partition=0. Tape block size 0 bytes. Density code 0x40 (DLT1 40 GB, or Ultrium). Soft error count since last status=0 General status bits on (41010000): BOT ONLINE IM_REP_EN $ mtx -f /dev/sg0 inquiry Product Type: Tape Drive Vendor ID: 'HP ' Product ID: 'C9264CB-VS80 ' Revision: '5032' Attached Changer: No But: $ cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 06 Lun: 01 Vendor: 000 3 Model: 8HP C9264 Rev: CB-V Type: Direct-Access ANSI SCSI revision: 01 Host: scsi0 Channel: 00 Id: 06 Lun: 00 Vendor: HP Model: C9264CB-VS80 Rev: 5032 Type: Sequential-Access ANSI SCSI revision: 02 Note the mangled representation of the device on LUN 1. It seems shifted to the right or something. Version-Release number of selected component (if applicable): How reproducible: Didn't try Steps to Reproduce: I have not really tried to reproduce it with a reboot. However, repeatedly scanning the SCSI bus yields the above. Will check what happens after the next reboot. Additional info: a) I'm not a SCSI guru b) The kernel is a monolithic recompiled kernel (i.e no module support) based on 2.4.20-20.9 with multiple LUN and SCSI tape support enabled. c) SCSI controller is an Adaptec 29160 SCSI card. d) The Autoloader is a HP DLT-VS80 C9264CB And now for the special "Toon hardware setup". It should not have an impact on the above. And it seems not to work, too (should it?): The SCSI bus contains a second 29160 controller commandeered by a RedHat 7.3 stock kernel. I thought that the tape drive could be accessed from that second machine, too, like this: [Machine RH9.0]--------+ +------------[Machine RH7.3] | | [ Autoloader ] But apparently not, the RH9.0 machine could not find the SCSI tape device at all if the RH7.3 machine had the aic7xxx module loaded. The bug report applies to the case where the aic7xxx module on the RH7.3 machine was NOT loaded. (If anyone can give a hint about whether this *could* work in principle, please feel free)
I have had an unvoluntary reboot this night...great stuff (The server was just sitting there, switched on, in catatonic mode. No lines in the kernel log to indicate what was wrong. Duh!) So here is what /proc/scsi/scsi looks like after reboot: $ cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 06 Lun: 00 Vendor: 8HP Model: C9264CB-VS80 Rev: 503 Type: Sequential-Access ANSI SCSI revision: ffffffff This is looking ok, but high-LUNs have not been scanned (ok I guess), so I do this using a little script (rescan-scsi-bus.sh), and after that: $ cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 06 Lun: 00 Vendor: 8HP Model: C9264CB-VS80 Rev: 503 Type: Sequential-Access ANSI SCSI revision: ffffffff Host: scsi0 Channel: 00 Id: 06 Lun: 01 Vendor: 8HP Model: C9264CB-VS80 Rev: 503 Type: Medium Changer ANSI SCSI revision: ffffffff Hmmm...so this does not look so bad, even though it's NOT what was indicated before reboot. But now: $ mtx status illegal Element Type Code 54 reported $ mt -f /dev/st0 ...never returns Bad news in the kernel log: (scsi0:A:6:0): data overrun detected in Data-in phase. Tag == 0x2. (scsi0:A:6:0): Have seen Data Phase. Length = 56. NumSGs = 1. sg[0] - Addr 0x01bc28000 : Length 56 Ok, so there is definitely something wrong with the bus, I will change the geometry and be back.
Changed geometry. Tape autoloader is now exclusively attached to the RedHat 9.0 machine. After a SCSI bus rescan: $ cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 06 Lun: 00 Vendor: HP Model: C9264CB-VS80 Rev: 5032 Type: Sequential-Access ANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 06 Lun: 01 Vendor: HP Model: C9264CB-VS80 Rev: 5032 Type: Medium Changer ANSI SCSI revision: 02 ...so this looks better and better, the ANSI SCSI revision now actually makes sense. $ mtx status Storage Changer /dev/changer:1 Drives, 8 Slots ( 0 Import/Export ) Data Transfer Element 0:Full (Storage Element 4 Loaded) Storage Element 1:Full Storage Element 2:Full Storage Element 3:Full Storage Element 4:Empty Storage Element 5:Full Storage Element 6:Full Storage Element 7:Full Storage Element 8:Full $ mt -f /dev/st0 status SCSI 2 tape drive: File number=-1, block number=-1, partition=0. Tape block size 0 bytes. Density code 0x40 (DLT1 40 GB, or Ultrium). Soft error count since last status=0 General status bits on (1010000): ONLINE IM_REP_EN All right! So it looks like I shot myself in the foot by trying to be too clever by half?
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/