From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 Description of problem: This devices supports large and sparse LUNs. The INQUIRY data reported is: Host: scsi0 Channel: 00 Id: 01 Lun: 00 Vendor: IBM Model: 1722-600 Rev: 0610 Type: Direct-Access ANSI SCSI revision: 03 Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: Try to attach LUNS of IBM FAStT600. Actual Results: Only LUN 0 is scanned successfully. Expected Results: All LUNs should be detected. Additional info: Similar issue as reported for other device in bz 106392.
Martin, I assume that any Model: 1722* will support large and sparse LUNs. Okay? Does this device have any parallel SCSI ports, and if so, do they support packetized SCSI? There are some buggy drivers that are probing large LUNs on non-packetized SCSI. Turning on SPARSELUNs enables this bug. Just checking. Tom
Tom, can't acknowledge the 1722* assumption for the time being. I have scanned data sheets of other FAStT models that we don't have available in our lab. They do not explicitely state what the INQUIRY data is. But there are indications that it deviates from 1722*. Besides, I am not yet sure what else might be sold as 1722* by IBM. It would be best to stick to 1722-600 and to add other entries or modify this entry as we learn more about it. I have contacted a storage guy at IBM. Hope to get more information this way. I will relay your SPI related questions. My current understanding is that FAStT only attaches via FC, while it internally holds either FC or S-ATA devices. -martin PS: http://www.storage.ibm.com/disk/fastt/fast600/datasheet.pdf
Here is the information regarding the other FAStT models from FAStT land. Hope that is the right format or can be transformed as such ? DS4300 (formerly FAStT600) Vendor: IBM Model: 1722-600 Rev: 0610 DS4400 (formerly FAStT700) Vendor: IBM Model: 1742 Rev: 0520 DS4500 (formerly FAStT900) Vendor: IBM Model: 1742-900 Rev: 0520 DS4100 (Formerly FAStT100) Vendor: IBM Model: 1724-100 Rev: 0542
this is actually impacting our device qualifiacations I see the need to change the priority to high to enable test to progress and met targets Would you please help as only reporter or owner can do that ? Thanks Georg
Arnold, Peter, added you to cc: Martin the bug 130874 seems to report the same problem. Again this is not a normal, but high Priority bug, as test is blocked and cannot meet targets
Well, lets close one of the bugs as duplicate, then. Though 130874 is older, I suggest to close it, because this bz covers a more complete set of FAStT models.
answers from Brian J. Countryman at IBM > I assume that any Model: 1722* will support large and sparse LUNs. Okay? Yes > Does this device have any parallel SCSI ports No
*** Bug 130874 has been marked as a duplicate of this bug. ***
A fix for this problem has just been committed to the RHEL3 U4 patch pool this evening (in kernel version 2.4.21-22.EL).
Ernie, could you attach RH's patch, please? I double-checked with Brian Countryman (IBM). He got back to me with another FAStT box (FAStT600 SCU single controller unit): Vendor: IBM Model: 1722-F60LR
The patch is attached. Any model beginning with "1722" will match.
Created attachment 105516 [details] whitelist patch, checked in.
An errata 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-2004-550.html