Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 4 年多

通知 15
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 05 12月, 2009 1 次提交
  3. 21 6月, 2009 1 次提交
    • J
      enhance device info matching for multiple tables · 598fa4b7
      由 James Bottomley 提交于 
      The current scsi_devinfo.c matching routines use a single table for
the global blacklist.  However, we're developing a need to blacklist
from specific transports too (notably some tape drives using SPI which
don't respond well to high speed protocols).  Instead of developing
separate blacklist matching for each transport class needing it,
enhance the current list matching to permit multiple lists.
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      598fa4b7
  5. 15 6月, 2009 1 次提交
  7. 31 3月, 2009 1 次提交
    • A
      proc 2/2: remove struct proc_dir_entry::owner · 99b76233
      由 Alexey Dobriyan 提交于 
      Setting ->owner as done currently (pde->owner = THIS_MODULE) is racy
as correctly noted at bug #12454. Someone can lookup entry with NULL
->owner, thus not pinning enything, and release it later resulting
in module refcount underflow.

We can keep ->owner and supply it at registration time like ->proc_fops
and ->data.

But this leaves ->owner as easy-manipulative field (just one C assignment)
and somebody will forget to unpin previous/pin current module when
switching ->owner. ->proc_fops is declared as "const" which should give
some thoughts.

->read_proc/->write_proc were just fixed to not require ->owner for
protection.

rmmod'ed directories will be empty and return "." and ".." -- no harm.
And directories with tricky enough readdir and lookup shouldn't be modular.
We definitely don't want such modular code.

Removing ->owner will also make PDE smaller.

So, let's nuke it.

Kudos to Jeff Layton for reminding about this, let's say, oversight.

http://bugzilla.kernel.org/show_bug.cgi?id=12454Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      99b76233
  9. 14 1月, 2009 1 次提交
    • I
      [SCSI] Add SUN Universal Xport to no attach blacklist · debf4777
      由 ILLES, Marton 提交于 
      I was using a Sun ST2510 device (iSCSI) and a special "block device"
appeared which is used by SUN Common Array Manager in-band management.

However it also appeared as a block device and caused some IO error:

[  716.868000] scsi 15:0:0:31: Direct-Access     SUN      Universal Xport  0735 PQ: 0 ANSI: 5
[  716.868000] qla4xxx 0000:04:01.1: scsi(15:0:0:31): Enabled tagged queuing, queue depth 32.
[  716.868000] sd 15:0:0:31: [sdf] 40960 512-byte hardware sectors (21 MB)
[  716.868000] sd 15:0:0:31: [sdf] Write Protect is off
[  716.868000] sd 15:0:0:31: [sdf] Mode Sense: 77 00 10 08
[  716.868000] sd 15:0:0:31: [sdf] Write cache: disabled, read cache: enabled, supports DPO and FUA
[  716.868000] sd 15:0:0:31: [sdf] 40960 512-byte hardware sectors (21 MB)
[  716.868000] sd 15:0:0:31: [sdf] Write Protect is off
[  716.868000] sd 15:0:0:31: [sdf] Mode Sense: 77 00 10 08
[  716.872000] sd 15:0:0:31: [sdf] Write cache: disabled, read cache: enabled, supports DPO and FUA
[  716.872000]  sdf: unknown partition table
[  716.932000] sd 15:0:0:31: [sdf] Attached SCSI disk
[  716.932000] sd 15:0:0:31: Attached scsi generic sg6 type 0
[  717.412000] end_request: I/O error, dev sdf, sector 40
[  717.412000] Buffer I/O error on device sdf, logical block 5
[  717.412000] Buffer I/O error on device sdf, logical block 6
[  717.412000] Buffer I/O error on device sdf, logical block 7
[  717.412000] Buffer I/O error on device sdf, logical block 8
[  717.412000] Buffer I/O error on device sdf, logical block 9
[  717.412000] Buffer I/O error on device sdf, logical block 10
[  717.412000] Buffer I/O error on device sdf, logical block 11
[  717.412000] Buffer I/O error on device sdf, logical block 12
[  717.412000] Buffer I/O error on device sdf, logical block 13
[  717.412000] Buffer I/O error on device sdf, logical block 14

After some googling it appeared that similar issue has been solved for
SGI/IBM devices in 48690405, so here is
the patch for SUN, please apply.
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      debf4777
  11. 27 7月, 2008 1 次提交
  13. 29 4月, 2008 1 次提交
  15. 12 1月, 2008 2 次提交
  17. 13 10月, 2007 1 次提交
  19. 28 7月, 2007 1 次提交
  21. 15 7月, 2007 1 次提交
  23. 17 5月, 2007 1 次提交
    • E
      [SCSI] stex: fix id mapping issue · e0b2e597
      由 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>
      e0b2e597
  25. 02 10月, 2006 4 次提交
  27. 26 6月, 2006 1 次提交
  29. 20 5月, 2006 1 次提交
    • T
      [SCSI] Blacklist entry for HP dat changer · c3d83368
      由 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>
      c3d83368
  31. 28 4月, 2006 1 次提交
  33. 15 4月, 2006 1 次提交
    • K
      [SCSI] BLIST_ATTACH_PQ3 flags · 13f7e5ac
      由 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>
      13f7e5ac
  35. 13 4月, 2006 1 次提交
  37. 03 3月, 2006 1 次提交
  39. 14 12月, 2005 1 次提交
  41. 18 10月, 2005 1 次提交
  43. 13 9月, 2005 1 次提交
  45. 07 9月, 2005 1 次提交
    • A
      [SCSI] Universal Xport no attach blacklist · 48690405
      由 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>
      48690405
  47. 13 8月, 2005 1 次提交
  49. 09 8月, 2005 1 次提交
  51. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      由 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!
      1da177e4