aboutsummaryrefslogtreecommitdiff
path: root/drivers/scsi/scsi_devinfo.c
AgeCommit message (Collapse)Author
2005-09-06[SCSI] Universal Xport no attach blacklistAnton 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: Anton Blanchard <anton@samba.org> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2005-08-12[SCSI] Make the HSG80 a REPORTLUN2 deviceJames 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: James Bottomley <James.Bottomley@SteelEye.com>
2005-08-08[SCSI] blacklist addition.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: Dave Jones <davej@redhat.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2005-04-16Linux-2.6.12-rc2Linus 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!