Red Hat Bugzilla – Bug 29574
SCSI - SG_SCSI_RESET - SCSI Mid Level related question
Last modified: 2007-04-18 12:31:47 EDT
From Bugzilla Helper: User-Agent: Mozilla/4.72 [en] (Windows NT 5.0; U) Under RedHat 6.2 Updates and RedHat 7.0, the 2.2.x versions of the Linux kernel had the Mid level SCSI patch from James Bottomley for SG_SCSI_RESET. Currently under Fisher, the 2.4 version of the kernel does not have this patch included. Are you planning on in-corporating this patch again in the 2.4 kernel to be part of your next release? If so, can you please give me an idea of when this will be incorporated. Thanks much for all your help. Reproducible: Always Steps to Reproduce: 1.The kernel currently lacks the patch 2. 3. Actual Results: On a machine running RedHat 7.0: grep scsi_reset_provider /proc/ksyms gives c01bca10 scsi_reset_provider_R40d88e55 On a machine Running Fisher: grep scsi_reset_provider /proc/ksyms gives nothing
The 2.4 kernel does provide SG_SCSI_RESET. What is the relation between SG_SCSI_RESET and scsi_reset_provider ?
In drivers/scsi/sg.c, the SG_SCSI_RESET function will return -EINVAL except when you request that nothing is to be reset. The patch that James Bottemly <James.Bottomley@SteelEye.com> posted to the scsi interest mailing list provides the missing functionality. In order for the reset function to be implemented, they exported the kernel symbol scsi_reset_provider. Also, this patch fixed scsi_obsolete.c where a SCSI RESERVATION conflict caused the scsi bus to be reset. This is clearly wrong and prevents one initiator from blocking access by another initiator to a SCSI device. This is essential to creating a high availability disk filesystem by preventing multiple accesses to the same disk from different systems.
We (Red Hat) should really try to resolve this before next release.
I have verified the the same bug as Steve Drum. Bug #29572. The hardware we are using is the same model (SGI 1200 == VALinux 2200). Just wanted to put this out there to cut down on confusion, I will add it to bugzilla as well. I am having a issue kickstarting wolverine on a VALinux FullOn 2x2 2200 cluster. The nodes are dual 850Mhz/2GB memory/18GB IDE drives. The install hangs trying to load the aic7xxx driver. Here is the SCSI controller the VALinux cluster is using (although I have no devices hanging off it). bigfoot1# lspci | grep SCSI 00:0c.0 SCSI storage controller: Adaptec 7896 00:0c.1 SCSI storage controller: Adaptec 7896 I had no problem kickstarting fisher on this cluster. Wolverine kickstarts work great for me for me on the IBM dual 1GHz x330s cluster I tried. The IBM cluster uses the same driver, although it is a slightly different controller and it does actually have SCSI disks hanging off the controller. cheapdisk1$ lspci | grep SCSI 01:03.0 SCSI storage controller: Adaptec 7892P (rev 02)
Doug, what do you think?
The SCSI reset patch has been integrated into our kernel tree. It will show up in the next release. (the comments about the aic7xxx driver above somehow are attached to this bug report even though they aren't relevant, so I'm not addressing those here as this bug report was about the scsi reset patch).
This kernel is now available in rawhide. Please test it and re-open this bug report if it doesn't work.