1. 03 9月, 2013 34 次提交
  2. 26 8月, 2013 6 次提交
    • J
      [SCSI] hpsa: fix warning with smp_processor_id() in preemptible · 804a5cb5
      John Kacur 提交于
       section Signed-off-by: John Kacur <jkacur@redhat.com>
      
      On a 3.6-rt (real-time patch) kernel we are seeing the following BUG
      However, it appears to be relevant for non-realtime (mainline) as well.
      
      [   49.688847] hpsa 0000:03:00.0: hpsa0: <0x323a> at IRQ 67 using DAC
      [   49.749928] scsi0 : hpsa
      [   49.784437] BUG: using smp_processor_id() in preemptible [00000000
      00000000] code: kworker/u:0/6
      [   49.784465] caller is enqueue_cmd_and_start_io+0x5a/0x100 [hpsa]
      [   49.784468] Pid: 6, comm: kworker/u:0 Not tainted
      3.6.11.5-rt37.52.el6rt.x86_64.debug #1
      [   49.784471] Call Trace:
      [   49.784512]  [<ffffffff812abe83>] debug_smp_processor_id+0x123/0x150
      [   49.784520]  [<ffffffffa009043a>] enqueue_cmd_and_start_io+0x5a/0x100
      [hpsa]
      [   49.784529]  [<ffffffffa00905cb>]
      hpsa_scsi_do_simple_cmd_core+0xeb/0x110 [hpsa]
      [   49.784537]  [<ffffffff812b09c8>] ? swiotlb_dma_mapping_error+0x18/0x30
      [   49.784544]  [<ffffffff812b09c8>] ? swiotlb_dma_mapping_error+0x18/0x30
      [   49.784553]  [<ffffffffa0090701>]
      hpsa_scsi_do_simple_cmd_with_retry+0x91/0x280 [hpsa]
      [   49.784562]  [<ffffffffa0093558>]
      hpsa_scsi_do_report_luns.clone.2+0xd8/0x130 [hpsa]
      [   49.784571]  [<ffffffffa00935ea>]
      hpsa_gather_lun_info.clone.3+0x3a/0x1a0 [hpsa]
      [   49.784580]  [<ffffffffa00963df>] hpsa_update_scsi_devices+0x11f/0x4f0
      [hpsa]
      [   49.784592]  [<ffffffff81592019>] ? sub_preempt_count+0xa9/0xe0
      [   49.784601]  [<ffffffffa00968ad>] hpsa_scan_start+0xfd/0x150 [hpsa]
      [   49.784613]  [<ffffffff8158cba8>] ? rt_spin_lock_slowunlock+0x78/0x90
      [   49.784626]  [<ffffffff813b04d7>] do_scsi_scan_host+0x37/0xa0
      [   49.784632]  [<ffffffff813b05da>] do_scan_async+0x1a/0x30
      [   49.784643]  [<ffffffff8107c4ab>] async_run_entry_fn+0x9b/0x1d0
      [   49.784655]  [<ffffffff8106ae92>] process_one_work+0x1f2/0x620
      [   49.784661]  [<ffffffff8106ae20>] ? process_one_work+0x180/0x620
      [   49.784668]  [<ffffffff8106d4fe>] ? worker_thread+0x5e/0x3a0
      [   49.784674]  [<ffffffff8107c410>] ? async_schedule+0x20/0x20
      [   49.784681]  [<ffffffff8106d5d3>] worker_thread+0x133/0x3a0
      [   49.784688]  [<ffffffff8106d4a0>] ? manage_workers+0x190/0x190
      [   49.784696]  [<ffffffff81073236>] kthread+0xa6/0xb0
      [   49.784707]  [<ffffffff815970a4>] kernel_thread_helper+0x4/0x10
      [   49.784715]  [<ffffffff81082a7c>] ? finish_task_switch+0x8c/0x110
      [   49.784721]  [<ffffffff8158e44b>] ? _raw_spin_unlock_irq+0x3b/0x70
      [   49.784727]  [<ffffffff8158e85d>] ? retint_restore_args+0xe/0xe
      [   49.784734]  [<ffffffff81073190>] ? kthreadd+0x1e0/0x1e0
      [   49.784739]  [<ffffffff815970a0>] ? gs_change+0xb/0xb
      
      -------------------
      
      This is caused by
      enqueue_cmd_and_start_io()->
              set_performant_mode()->
                      smp_processor_id()
      Which if you have debugging enabled calls debug_processor_id() and triggers the warning.
      
      The code here is
       c->Header.ReplyQueue = smp_processor_id() % h->nreply_queues;
      
      Since it is not critical that the code complete on the same processor,
      but the cpu is a hint used in generating the ReplyQueue and will still work if
      the cpu migrates or is preempted, it is safe to use the raw_smp_processor_id()
      to surpress the false positve warning.
      Signed-off-by: NJohn Kacur <jkacur@redhat.com>
      Acked-by: NStephen Cameron <scameron@beardog.cce.hp.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      804a5cb5
    • O
      [SCSI] IB/iser: Add Discovery support · 6a06a4b8
      Or Gerlitz 提交于
      To run discovery over iSER we need to advertize the CAP_TEXT_NEGO capability
      towards user space. Also need to make sure the login RX buffer is posted when
      SendTargets TEXT PDUs are sent. For that end, we use a setting of the
      ISCSI_PARAM_DISCOVERY_SESS iscsi param as an indication that this is
      discovery session.
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Reviewed-by: NMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      6a06a4b8
    • Y
      [SCSI] pm8001: clean up unnecessary MSI/MSI-X capability find · e1e819cc
      Yijing Wang 提交于
      PCI core will initialize device MSI/MSI-X capability in
      pci_msi_init_pci_dev(). So device driver should use
      pci_dev->msi_cap/msix_cap to determine whether the device
      support MSI/MSI-X instead of using
      pci_find_capability(pci_dev, PCI_CAP_ID_MSI/MSIX).
      Access to PCIe device config space again will consume more time.
      Signed-off-by: NYijing Wang <wangyijing@huawei.com>
      Acked-by: Nlindar_liu <lindar_liu@usish.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      e1e819cc
    • A
      [SCSI] pm80xx: Fix for 32 bit compilation warning · da1dccce
      Anand Kumar Santhanam 提交于
      Signed-off-by: Anandkumar.Santhanam@pmcs.com
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      da1dccce
    • J
      [SCSI] mpt3sas: fix cleanup on controller resource mapping failure · cf9bd21a
      Joe Lawrence 提交于
      If mpt3sas_base_map_resources takes an early error path then its
      counterpart, mpt3sas_base_free_resources needs to be careful about
      cleaning up:
      
        1 - _base_mask_interrupts and _base_make_ioc_ready require memory
            mapped I/O registers, make sure that this is true.
      
        2 - _base_free_irq iterates over the adapter's reply_queue_list, so
            move this list head initialization out of _base_enable_msix to
            _scsih_probe so this will always be safe.
      
        3 - check that the controller PCI device and its BARs have been
            enabled before disabling them.
      Signed-off-by: NJoe Lawrence <joe.lawrence@stratus.com>
      Acked-by: NSreekanth Reddy <Sreekanth.Reddy@lsi.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      cf9bd21a
    • J
      [SCSI] mpt2sas: fix cleanup on controller resource mapping failure · 3b3e6f8d
      Joe Lawrence 提交于
      If mpt2sas_base_map_resources takes an early error path then its
      counterpart, mpt2sas_base_free_resources needs to be careful about
      cleaning up:
      
        1 - _base_mask_interrupts and _base_make_ioc_ready require memory
            mapped I/O registers, make sure that this is true.
      
        2 - _base_free_irq iterates over the adapter's reply_queue_list, so
            move this list head initialization out of _base_enable_msix to
            _scsih_probe so this will always be safe.
      
        3 - check that the controller PCI device and its BARs have been
            enabled before disabling them.
      Signed-off-by: NJoe Lawrence <joe.lawrence@stratus.com>
      Acked-by: NSreekanth Reddy <Sreekanth.Reddy@lsi.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      3b3e6f8d