- 17 5月, 2007 1 次提交
-
-
由 Ed Lin 提交于
The correct internal mapping of stex controllers should be: id:0~15, lun:0~7 (st_shasta) id:0, lun:0~127 (st_yosemite) id:0~127, lun:0 (st_vsc and st_vsc1) This patch reports the internal mapping to scsi mid layer, eliminating the translation between scsi mid layer and firmware. To achieve this goal, we also need to: -- fail the REPORT_LUNS command for st_shasta because the firmware is known to not report all actual luns -- add an entry in scsi_devindo.c to force sequential lun scan (for st_shasta controllers) -- fail the REPORT_LUNS command for console device -- remove special handling of REPORT_LUNS command for st_yosemite, as there is no translation mapping now Signed-off-by: NEd Lin <ed.lin@promise.com> Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 02 10月, 2006 4 次提交
-
-
由 Mike Christie 提交于
When SCSI-2 they can support luns past 7 and sparse luns. Signed-off-by: NMike Christie <michaelc@cs.wisc.edu> Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
由 Mike Christie 提交于
support the report luns opcode . Signed-off-by: NMike Christie <michaelc@cs.wisc.edu> Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
由 Mike Christie 提交于
This is from RHEL4. I do not have any info from our bugzilla. All I could find was something like this thread http://lkml.org/lkml/2005/1/7/346 Report lun for linux does not work. It may be our lun format code or it may be the device. It is probably not worth it to add anything special for this device, so the patch just adds BLIST_NOREPORTLUN. Signed-off-by: NMike Christie <michaelc@cs.wisc.edu> Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
由 Mike Christie 提交于
This is from RHEL4. This box can support scsi2 and can also support BLIST_SPARSELUN | BLIST_LARGELUN. Signed-off-by: NMike Christie <michaelc@cs.wisc.edu> Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 26 6月, 2006 1 次提交
-
-
由 Hannes Reinecke 提交于
According to Anthony Cheung all HP XP arrays with "OPEN-" types support REPORT_LUN. So there is no reason why we shouldn't use it. Signed-off-by: NAnthony Cheung <anthony.cheung@hp.com> Signed-off-by: NHannes Reinecke <hare@suse.de> Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 20 5月, 2006 1 次提交
-
-
由 Thomas Bogendoerfer 提交于
after upgrading our SUN E250 from 2.4 to 2.6 I'm seeing following error when the HP DDS4 DAT changer gets probed: scsi: host 1 channel 0 id 5 lun16777216 has a LUN larger than allowed by the host adapter The device is connected to a symbios 875 host. I've talked to Willy about the problem, and he asked me to try to blacklist the device for reportlun. I did that with the patch below and it solved the problem. It now gets properly detected: target1:0:5: FAST-20 WIDE SCSI 40.0 MB/s ST (50 ns, offset 16) Vendor: HP Model: C5713A Rev: H307 Type: Sequential-Access ANSI SCSI revision: 03 target1:0:5: Beginning Domain Validation target1:0:5: FAST-20 SCSI 20.0 MB/s ST (50 ns, offset 16) target1:0:5: FAST-20 WIDE SCSI 40.0 MB/s ST (50 ns, offset 16) target1:0:5: Domain Validation skipping write tests target1:0:5: Ending Domain Validation Vendor: HP Model: C5713A Rev: H307 Type: Medium Changer ANSI SCSI revision: 03 Signed-off-by: tsbogend@alpha.franken.de Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 28 4月, 2006 1 次提交
-
-
由 Brian King 提交于
Some versions of the IBM 2104-DU3 disk enclosure have been observed to hang Inquiries to non zero LUNs to the SES device. This device only has LUN 0, so this patch adds it to the BLIST to prevent scsi core from scanning beyond LUN 0. Signed-off-by: NBrian King <brking@us.ibm.com> Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 15 4月, 2006 1 次提交
-
-
由 Kurt Garloff 提交于
Some devices report a peripheral qualifier of 3 for LUN 0; with the original code, we would still try a REPORT_LUNS scan (if SCSI level is >= 3 or if we have the BLIST_REPORTLUNS2 passed in), but NOT any sequential scan. Also, the device at LUN 0 (which is not connected according to the PQ) is not registered with the OS. Unfortunately, SANs exist that are SCSI-2 and do NOT support REPORT_LUNS, but report a unknown device with PQ 3 on LUN 0. We still need to scan them, and most probably we even need BLIST_SPARSELUN (and BLIST_LARGELUN). See the bug reference for an infamous example. This is patch 3/3: 3. Implement the blacklist flag BLIST_ATTACH_PQ3 that makes the scsi scanning code register PQ3 devices and continues scanning; only sg will attach thanks to scsi_bus_match(). Signed-off-by: NKurt Garloff <garloff@suse.de> Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 13 4月, 2006 1 次提交
-
-
由 James Bottomley 提交于
Original From: Ingo Flaschberger <if@xip.at> To support the RA4100 array from Compaq. This patch now correctly handles SCSI_UNKNOWN types with regard to BLIST_REPORTLUNS2 (allow it) and cdb[1] LUN inclusion (don't). It also allows a BLIST_MAX_512 flag to restrict the maximum transfer length to 512 blocks (apparently this is an RA4100 problem). Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 03 3月, 2006 1 次提交
-
-
由 Matthew Wilcox 提交于
This device spews total rubbish to a REPORT LUNS command, so avoid sending it one. Signed-off-by: NMatthew Wilcox <matthew@wil.cx> Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 14 12月, 2005 1 次提交
-
-
由 James Bottomley 提交于
Make the vendor, model and rev fields in scsi_device pointers to const and update a few prototypes of functions using them. Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 18 10月, 2005 1 次提交
-
-
由 Karl Magnus Kolstoe 提交于
The patch below should make the Pioneer DRM-624X automatically be set up with all 6 "drives". (6 slot SCSI CD changer) Signed-off-by: NKarl Magnus Kolst <karl.kolsto@uib.no> Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 13 9月, 2005 1 次提交
-
-
由 James Bottomley 提交于
They report being SCSI-3 but seem to give back rubbish to a REPORT_LUNS command. Force them to be sequentially scanned. Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 07 9月, 2005 1 次提交
-
-
由 Anton Blanchard 提交于
On Fri, Dec 13, 2002 at 12:24:39AM +1100, Anton Blanchard wrote: > We tested 2.5.51 on a ppc64 box, qlogic 2312 and a fastt700 array. I > had CONFIG_SCSI_REPORT_LUNS and unfortunately it thought the management > LUN was a disk: > > Vendor: IBM Model: Universal Xport Rev: 0520 > Type: Direct-Access ANSI SCSI revision: 03 > > ... > > SCSI device sdaj: drive cache: write through > SCSI device sdaj: 40960 512-byte hdwr sectors (21 MB) > sdaj: unknown partition table > Attached scsi disk sdaj at scsi2, channel 0, id 0, lun 31 > > ... > > end_request: I/O error, dev sdaj, sector 0 Three years later... It looks like SGI use the same FC vendor and they already have a workaround for this issue. The following patch adds the IBM version of it. Signed-off-by: NAnton Blanchard <anton@samba.org> Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 13 8月, 2005 1 次提交
-
-
由 James Bottomley 提交于
From: Steve Wilcox <spwilcox@att.com> In order to properly report LUN's > 7, the DEC HSG80 definition in scsi_devinfo.c needs to include BLIST_REPORTLUN2 rather than BLIST_SPARSELUN. I've tested this change with several HSG firmware revisions and with both Emulex and Qlogic HBA's. Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 09 8月, 2005 1 次提交
-
-
由 Dave Jones 提交于
When run on a kernel that scans all LUNs, a certain crappy scsi scanner reports the same LUN over and over.. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155457 Aparently they were so shamed by this, they chose to remain anonymous. Though it seems the blacklist code handles anonymous vendors just fine. Signed-off-by: NDave Jones <davej@redhat.com> Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-