1. 19 Aug, 2006 6 commits
    • dave wysochanski's avatar
      [SCSI] Don't add scsi_device for devices that return PQ=1, PDT=0x1f · 84961f28
      dave wysochanski authored
      Some targets may return slight variations of PQ and PDT to indicate
      no LUN mapped.  USB UFI setting PDT=0x1f but having reserved bits for
      PQ is one example, and NetApp targets returning PQ=1 and PDT=0x1f is
      another.  Both instances seem like reasonable responses according to
      SPC-3 and UFI specs.
      
      The current scsi_probe_and_add_lun() code adds a scsi_device
      for targets that return PQ=1 and PDT=0x1f.  This causes LUNs of type
      "UNKNOWN" to show up in /proc/scsi/scsi when no LUNs are mapped.
      In addition, subsequent rescans fail to recognize LUNs that may be
      added on the target, unless preceded by a write to the delete attribute
      of the "UNKNOWN" LUN.
      
      This patch addresses this problem by skipping over the scsi_add_lun()
      when PQ=1,PDT=0x1f is encountered, and just returns
      SCSI_SCAN_TARGET_PRESENT.
      Signed-off-by: default avatarDave Wysochanski <davidw@netapp.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      84961f28
    • Mark Haverkamp's avatar
      [SCSI] aacraid: Reset adapter in recovery timeout · 8c867b25
      Mark Haverkamp authored
      Received from Mark Salyzyn
      
      If the adapter is in blinkled (Firmware Assert) when error recovery
      timeout actions have been triggered, perform an adapter warm reset and
      restart the initialization.
      Signed-off-by: default avatarMark Haverkamp <markh@osdl.org>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      8c867b25
    • Mark Haverkamp's avatar
      [SCSI] aacraid: Check for unlikely errors · 90ee3466
      Mark Haverkamp authored
      Received from Mark Salyzyn
      
      The enclosed patch cleans up some code fragments, adds some paranoia
      (unproven causes of potential driver failures).
      Signed-off-by: default avatarMark Haverkamp <markh@osdl.org>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      90ee3466
    • Mark Haverkamp's avatar
      [SCSI] aacraid: Restart adapter on firmware assert (Update 2) · 8c23cd74
      Mark Haverkamp authored
      Received from Mark Salyzyn
      
      If the adapter should be in a blinkled (Firmware Assert) state when the
      driver loads, we will perform a warm restart of the Adapter Firmware to
      see if we can rescue the adapter. Possible causes of a blinkled can
      occur on some early release motherboard BIOSes, transitory PCI bus
      problems on embedded systems or non-x86 based architectures, transitory
      startup failures of early release drives or transitory hardware
      failures; some of which can bite the adapter later at runtime. Future
      enhancements will include recovery during runtime.
      
      Fixed extra whitespace space issue.
      Signed-off-by: default avatarMark Haverkamp <markh@osdl.org>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      8c23cd74
    • Mark Haverkamp's avatar
      [SCSI] aacraid: interruptible ioctl · c8f7b073
      Mark Haverkamp authored
      Received from Mark Salyzyn
      
      This patch allows the FSACTL_SEND_LARGE_FIB, FSACTL_SENDFIB and
      FSACTL_SEND_RAW_SRB ioctl calls into the aacraid driver to be
      interruptible. Only necessary if the adapter and/or the management
      software has gone into some sort of misbehavior and the system is being
      rebooted, thus permitting the user management software applications to
      be killed relatively cleanly. The FIB queue resource is held out of the
      free queue until the adapter finally, if ever, completes the command.
      Signed-off-by: default avatarMark Haverkamp <markh@osdl.org>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      c8f7b073
    • Andreas Herrmann's avatar
      [SCSI] limit recursion when flushing shost->starved_list · 04846f25
      Andreas Herrmann authored
      Attached is a patch that should limit a possible recursion that can
      lead to a stack overflow like follows:
      
      Kernel stack overflow.
      CPU:    3    Not tainted
      Process zfcperp0.0.d819
      (pid: 13897, task: 000000003e0d8cc8, ksp: 000000003499dbb8)
      Krnl PSW : 0404000180000000 000000000030f8b2 (get_device+0x12/0x48)
      Krnl GPRS: 00000000135a1980 000000000030f758 000000003ed6c1e8 0000000000000005
                 0000000000000000 000000000044a780 000000003dbf7000 0000000034e15800
                 000000003621c048 070000003499c108 000000003499c1a0 000000003ed6c000
                 0000000040895000 00000000408ab630 000000003499c0a0 000000003499c0a0
      Krnl Code: a7 fb ff e8 a7 19 00 00 b9 02 00 22 e3 e0 f0 98 00 24 a7 84
      Call Trace:
      ([<000000004089edc2>] scsi_request_fn+0x13e/0x650 [scsi_mod])
       [<00000000002c5ff4>] blk_run_queue+0xd4/0x1a4
       [<000000004089ff8c>] scsi_queue_insert+0x22c/0x2a4 [scsi_mod]
       [<000000004089779a>] scsi_dispatch_cmd+0x8a/0x3d0 [scsi_mod]
       [<000000004089f1ec>] scsi_request_fn+0x568/0x650 [scsi_mod]
      ...
       [<000000004089f1ec>] scsi_request_fn+0x568/0x650 [scsi_mod]
       [<00000000002c5ff4>] blk_run_queue+0xd4/0x1a4
       [<000000004089ff8c>] scsi_queue_insert+0x22c/0x2a4 [scsi_mod]
       [<000000004089779a>] scsi_dispatch_cmd+0x8a/0x3d0 [scsi_mod]
       [<000000004089f1ec>] scsi_request_fn+0x568/0x650 [scsi_mod]
       [<00000000002c5ff4>] blk_run_queue+0xd4/0x1a4
       [<000000004089fa9e>] scsi_run_host_queues+0x196/0x230 [scsi_mod]
       [<00000000409eba28>] zfcp_erp_thread+0x2638/0x3080 [zfcp]
       [<0000000000107462>] kernel_thread_starter+0x6/0xc
       [<000000000010745c>] kernel_thread_starter+0x0/0xc
      <0>Kernel panic - not syncing: Corrupt kernel stack, can't continue.
      
      This stack overflow occurred during tests on s390 using zfcp.
      Recursion depth for this panic was 19.
      
      Usually recursion between blk_run_queue and a request_fn is avoided
      using QUEUE_FLAG_REENTER. But this does not help if the scsi stack
      tries to flush the starved_list of a scsi_host.
      
      Limit recursion depth when flushing the starved_list
      of a scsi_host.
      Signed-off-by: default avatarAndreas Herrmann <aherrman@de.ibm.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      04846f25
  2. 06 Aug, 2006 10 commits
  3. 04 Aug, 2006 2 commits
  4. 02 Aug, 2006 2 commits
  5. 28 Jul, 2006 3 commits
  6. 26 Jul, 2006 5 commits
    • Christoph Hellwig's avatar
      [PATCH] fix compile regression for a few scsi drivers · 64821324
      Christoph Hellwig authored
      This fixes three drivers to compile again after my patch that removes
      the data_cmnd member from struct scsi_cmnd.
      
      The fas216 change is trivial, it should have been using ->cmnd all the
      time.
      
      NCR53C9 (which seem to be mostly duplicate driver with esp.c!) is doing
      something odd, it should only have looked at ->cmnd before not the saved
      copy that is kept for the error handlers sake.  Note that it really
      should deal with the sync setting themselves but use the generic domain
      validation code that get this right - but that's for later let's push
      this simple compile fix for now.
      
      And sorry for the late fix for this, I have been busy with OLS and
      associated activities last week.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      64821324
    • Linus Torvalds's avatar
      Merge master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6 · dab5025c
      Linus Torvalds authored
      * master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6:
        [SCSI] esp: Fix build.
        [SPARC]: Fix SA_STATIC_ALLOC value.
        [SPARC64]: Explicitly print return PC when the kernel fault PC is bogus.
      dab5025c
    • Linus Torvalds's avatar
      Merge master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 · 761a1260
      Linus Torvalds authored
      * master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6:
        [IPV4/IPV6]: Setting 0 for unused port field in RAW IP recvmsg().
        [IPV4] ipmr: ip multicast route bug fix.
        [TG3]: Update version and reldate
        [TG3]: Handle tg3_init_rings() failures
        [TG3]: Add tg3_restart_hw()
        [IPV4]: Clear the whole IPCB, this clears also IPCB(skb)->flags.
        [IPV6]: Clean skb cb on IPv6 input.
        [NETFILTER]: Demote xt_sctp to EXPERIMENTAL
        [NETFILTER]: bridge netfilter: add deferred output hooks to feature-removal-schedule
        [NETFILTER]: xt_pkttype: fix mismatches on locally generated packets
        [NETFILTER]: SNMP NAT: fix byteorder confusion
        [NETFILTER]: conntrack: fix SYSCTL=n compile
        [NETFILTER]: nf_queue: handle NF_STOP and unknown verdicts in nf_reinject
        [NETFILTER]: H.323 helper: fix possible NULL-ptr dereference
      761a1260
    • Arjan van de Ven's avatar
      [PATCH] Reorganize the cpufreq cpu hotplug locking to not be totally bizare · 153d7f3f
      Arjan van de Ven authored
      The patch below moves the cpu hotplugging higher up in the cpufreq
      layering; this is needed to avoid recursive taking of the cpu hotplug
      lock and to otherwise detangle the mess.
      
      The new rules are:
      1. you must do lock_cpu_hotplug() around the following functions:
         __cpufreq_driver_target
         __cpufreq_governor (for CPUFREQ_GOV_LIMITS operation only)
         __cpufreq_set_policy
      2. governer methods (.governer) must NOT take the lock_cpu_hotplug()
         lock in any way; they are called with the lock taken already
      3. if your governer spawns a thread that does things, like calling
         __cpufreq_driver_target, your thread must honor rule #1.
      4. the policy lock and other cpufreq internal locks nest within
         the lock_cpu_hotplug() lock.
      
      I'm not entirely happy about how the __cpufreq_governor rule ended up
      (conditional locking rule depending on the argument) but basically all
      callers pass this as a constant so it's not too horrible.
      
      The patch also removes the cpufreq_governor() function since during the
      locking audit it turned out to be entirely unused (so no need to fix it)
      
      The patch works on my testbox, but it could use more testing
      (otoh... it can't be much worse than the current code)
      Signed-off-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      153d7f3f
    • Tetsuo Handa's avatar
      [IPV4/IPV6]: Setting 0 for unused port field in RAW IP recvmsg(). · f59fc7f3
      Tetsuo Handa authored
      From: Tetsuo Handa from-linux-kernel@i-love.sakura.ne.jp
      
      The recvmsg() for raw socket seems to return random u16 value
      from the kernel stack memory since port field is not initialized.
      But I'm not sure this patch is correct.
      Does raw socket return any information stored in port field?
      
      [ BSD defines RAW IP recvmsg to return a sin_port value of zero.
        This is described in Steven's TCP/IP Illustrated Volume 2 on
        page 1055, which is discussing the BSD rip_input() implementation. ]
      Acked-by: default avatarYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f59fc7f3
  7. 25 Jul, 2006 12 commits