1. 26 8月, 2013 1 次提交
  2. 22 8月, 2013 1 次提交
    • A
      [SCSI] lpfc: Don't force CONFIG_GENERIC_CSUM on · f5944daa
      Anton Blanchard 提交于
      We want ppc64 to be able to select between optimised assembly
      checksum routines in big endian and the generic lib/checksum.c
      routines in little endian.
      
      The lpfc driver is forcing CONFIG_GENERIC_CSUM on which means
      we are unable to make the decision to enable it in the arch
      Kconfig. If the option exists it is always forced on.
      
      This got introduced in 3.10 via commit 6a7252fd ([SCSI] lpfc:
      fix up Kconfig dependencies). I spoke to Randy about it and
      the original issue was with CRC_T10DIF not being defined.
      
      As such, remove the select of CONFIG_GENERIC_CSUM.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Cc: <stable@vger.kernel.org> # 3.10
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      f5944daa
  3. 03 8月, 2013 3 次提交
    • M
      [SCSI] Don't attempt to send extended INQUIRY command if skip_vpd_pages is set · 7562523e
      Martin K. Petersen 提交于
      If a device has the skip_vpd_pages flag set we should simply fail the
      scsi_get_vpd_page() call.
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Tested-by: NStuart Foster <smf.linux@ntlworld.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      7562523e
    • C
      [SCSI] fnic: BUG: sleeping function called from invalid context during probe · e09056b2
      Chris Leech 提交于
      I hit this during driver probe with the latest fnic updates (this trace
      is from a backport into a distro kernel, but the issue is the same).
      
      > BUG: sleeping function called from invalid context at mm/slab.c:3113
      > in_atomic(): 0, irqs_disabled(): 1, pid: 610, name: work_for_cpu
      > INFO: lockdep is turned off.
      > irq event stamp: 0
      > hardirqs last  enabled at (0): [<(null)>] (null)
      > hardirqs last disabled at (0): [<ffffffff81070aa5>]
      > copy_process+0x5e5/0x1670
      > softirqs last  enabled at (0): [<ffffffff81070aa5>]
      > copy_process+0x5e5/0x1670
      > softirqs last disabled at (0): [<(null)>] (null)
      > Pid: 610, comm: work_for_cpu Not tainted
      > Call Trace:
      >  [<ffffffff810b2d10>] ? print_irqtrace_events+0xd0/0xe0
      >  [<ffffffff8105c1a7>] ? __might_sleep+0xf7/0x130
      >  [<ffffffff81184efb>] ? kmem_cache_alloc_trace+0x20b/0x2d0
      >  [<ffffffff8109709e>] ? __create_workqueue_key+0x3e/0x1d0
      >  [<ffffffff8109709e>] ? __create_workqueue_key+0x3e/0x1d0
      >  [<ffffffffa00c101c>] ? fnic_probe+0x977/0x11aa [fnic]
      >  [<ffffffffa00c1048>] ? fnic_probe+0x9a3/0x11aa [fnic]
      >  [<ffffffff81096f00>] ? do_work_for_cpu+0x0/0x30
      >  [<ffffffff812c6da7>] ? local_pci_probe+0x17/0x20
      >  [<ffffffff81096f18>] ? do_work_for_cpu+0x18/0x30
      >  [<ffffffff8109cdc6>] ? kthread+0x96/0xa0
      >  [<ffffffff8100c1ca>] ? child_rip+0xa/0x20
      >  [<ffffffff81550f80>] ? _spin_unlock_irq+0x30/0x40
      >  [<ffffffff8100bb10>] ? restore_args+0x0/0x30
      >  [<ffffffff8109cd30>] ? kthread+0x0/0xa0
      >  [<ffffffff8100c1c0>] ? child_rip+0x0/0x20
      
      The problem is in this hunk of "FIP VLAN Discovery Feature Support"
      (d3c995f1)
      
      create_singlethreaded_workqueue cannot be called with irqs disabled
      
      @@ -620,7 +634,29 @@ static int __devinit fnic_probe(struct pci_dev
      *pdev,
              vnic_dev_packet_filter(fnic->vdev, 1, 1, 0, 0, 0);
              vnic_dev_add_addr(fnic->vdev, FIP_ALL_ENODE_MACS);
              vnic_dev_add_addr(fnic->vdev, fnic->ctlr.ctl_src_addr);
      +       fnic->set_vlan = fnic_set_vlan;
              fcoe_ctlr_init(&fnic->ctlr, FIP_MODE_AUTO);
      +       setup_timer(&fnic->fip_timer, fnic_fip_notify_timer,
      +                           (unsigned long)fnic);
      +       spin_lock_init(&fnic->vlans_lock);
      +       INIT_WORK(&fnic->fip_frame_work, fnic_handle_fip_frame);
      +       INIT_WORK(&fnic->event_work, fnic_handle_event);
      +       skb_queue_head_init(&fnic->fip_frame_queue);
      +       spin_lock_irqsave(&fnic_list_lock, flags);
      +       if (!fnic_fip_queue) {
      +           fnic_fip_queue =
      +               create_singlethread_workqueue("fnic_fip_q");
      +           if (!fnic_fip_queue) {
      +               spin_unlock_irqrestore(&fnic_list_lock, flags);
      +               printk(KERN_ERR PFX "fnic FIP work queue "
      +                        "create failed\n");
      +               err = -ENOMEM;
      +               goto err_out_free_max_pool;
      +           }
      +       }
      +       spin_unlock_irqrestore(&fnic_list_lock, flags);
      +       INIT_LIST_HEAD(&fnic->evlist);
      +       INIT_LIST_HEAD(&fnic->vlans);
          } else {
              shost_printk(KERN_INFO, fnic->lport->host,
                       "firmware uses non-FIP mode\n");
      
      The attempts to make fnic_fip_queue a single instance for the driver
      while it's being created in probe look awkward anyway, why is this not
      created in fnic_init_module like the event workqueue?
      Signed-off-by: NChris Leech <cleech@redhat.com>
      Tested-by: NAnantha Tungarakodi <atungara@cisco.com>
      Acked-by: NHiral Patel <hiralpat@cisco.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      e09056b2
    • S
      [SCSI] megaraid_sas: megaraid_sas driver init fails in kdump kernel · 6431f5d7
      Sumit.Saxena@lsi.com 提交于
      Problem: When Hardware IOMMU is on, megaraid_sas driver initialization fails
      in kdump kernel with LSI MegaRAID controller(device id-0x73).
      
      Actually this issue needs fix in firmware, but for firmware running in field,
      this driver fix is proposed to resolve the issue.  At firmware initialization
      time, if firmware does not come to ready state, driver will reset the adapter
      and retry for firmware transition to ready state unconditionally(not only
      executed for kdump kernel).
      Signed-off-by: NSumit Saxena <sumit.saxena@lsi.com>
      Signed-off-by: NKashyap Desai <kashyap.desai@lsi.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      6431f5d7
  4. 01 8月, 2013 1 次提交
    • A
      virtio-scsi: Fix virtqueue affinity setup · aa52aeea
      Asias He 提交于
      vscsi->num_queues counts the number of request virtqueue which does not
      include the control and event virtqueue. It is wrong to subtract
      VIRTIO_SCSI_VQ_BASE from vscsi->num_queues.
      
      This patch fixes the following panic.
      
      (qemu) device_del scsi0
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
       IP: [<ffffffff8179b29f>] __virtscsi_set_affinity+0x6f/0x120
       PGD 0
       Oops: 0000 [#1] SMP
       Modules linked in:
       CPU: 0 PID: 659 Comm: kworker/0:1 Not tainted 3.11.0-rc2+ #1172
       Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
       Workqueue: kacpi_hotplug _handle_hotplug_event_func
       task: ffff88007bee1cc0 ti: ffff88007bfe4000 task.ti: ffff88007bfe4000
       RIP: 0010:[<ffffffff8179b29f>]  [<ffffffff8179b29f>] __virtscsi_set_affinity+0x6f/0x120
       RSP: 0018:ffff88007bfe5a38  EFLAGS: 00010202
       RAX: 0000000000000010 RBX: ffff880077fd0d28 RCX: 0000000000000050
       RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000000
       RBP: ffff88007bfe5a58 R08: ffff880077f6ff00 R09: 0000000000000001
       R10: ffffffff8143e673 R11: 0000000000000001 R12: 0000000000000001
       R13: ffff880077fd0800 R14: 0000000000000000 R15: ffff88007bf489b0
       FS:  0000000000000000(0000) GS:ffff88007ea00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
       CR2: 0000000000000020 CR3: 0000000079f8b000 CR4: 00000000000006f0
       Stack:
        ffff880077fd0d28 0000000000000000 ffff880077fd0800 0000000000000008
        ffff88007bfe5a78 ffffffff8179b37d ffff88007bccc800 ffff88007bccc800
        ffff88007bfe5a98 ffffffff8179b3b6 ffff88007bccc800 ffff880077fd0d28
       Call Trace:
        [<ffffffff8179b37d>] virtscsi_set_affinity+0x2d/0x40
        [<ffffffff8179b3b6>] virtscsi_remove_vqs+0x26/0x50
        [<ffffffff8179c7d2>] virtscsi_remove+0x82/0xa0
        [<ffffffff814cb6b2>] virtio_dev_remove+0x22/0x70
        [<ffffffff8167ca49>] __device_release_driver+0x69/0xd0
        [<ffffffff8167cb9d>] device_release_driver+0x2d/0x40
        [<ffffffff8167bb96>] bus_remove_device+0x116/0x150
        [<ffffffff81679936>] device_del+0x126/0x1e0
        [<ffffffff81679a06>] device_unregister+0x16/0x30
        [<ffffffff814cb889>] unregister_virtio_device+0x19/0x30
        [<ffffffff814cdad6>] virtio_pci_remove+0x36/0x80
        [<ffffffff81464ae7>] pci_device_remove+0x37/0x70
        [<ffffffff8167ca49>] __device_release_driver+0x69/0xd0
        [<ffffffff8167cb9d>] device_release_driver+0x2d/0x40
        [<ffffffff8167bb96>] bus_remove_device+0x116/0x150
        [<ffffffff81679936>] device_del+0x126/0x1e0
        [<ffffffff8145edfc>] pci_stop_bus_device+0x9c/0xb0
        [<ffffffff8145f036>] pci_stop_and_remove_bus_device+0x16/0x30
        [<ffffffff81474a9e>] acpiphp_disable_slot+0x8e/0x150
        [<ffffffff81474f6a>] hotplug_event_func+0xba/0x1a0
        [<ffffffff814906c8>] ? acpi_os_release_object+0xe/0x12
        [<ffffffff81475911>] _handle_hotplug_event_func+0x31/0x70
        [<ffffffff810b5333>] process_one_work+0x183/0x500
        [<ffffffff810b66e2>] worker_thread+0x122/0x400
        [<ffffffff810b65c0>] ? manage_workers+0x2d0/0x2d0
        [<ffffffff810bc5de>] kthread+0xce/0xe0
        [<ffffffff810bc510>] ? kthread_freezable_should_stop+0x70/0x70
        [<ffffffff81ca045c>] ret_from_fork+0x7c/0xb0
        [<ffffffff810bc510>] ? kthread_freezable_should_stop+0x70/0x70
       Code: 01 00 00 00 74 59 45 31 e4 83 bb c8 01 00 00 02 74 46 66 2e 0f 1f 84 00 00 00 00 00 49 63 c4 48 c1 e0 04 48 8b bc 0
      3 10 02 00 00 <48> 8b 47 20 48 8b 80 d0 01 00 00 48 8b 40 50 48 85 c0 74 07 be
       RIP  [<ffffffff8179b29f>] __virtscsi_set_affinity+0x6f/0x120
        RSP <ffff88007bfe5a38>
       CR2: 0000000000000020
       ---[ end trace 99679331a3775f48 ]---
      
      CC: stable@vger.kernel.org
      Signed-off-by: NAsias He <asias@redhat.com>
      Reviewed-by: NWanlong Gao <gaowanlong@cn.fujitsu.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      aa52aeea
  5. 25 7月, 2013 1 次提交
  6. 24 7月, 2013 1 次提交
    • J
      [SCSI] mvsas: Fix kernel panic on tile due to unaligned data access · 53a983c4
      James Bottomley 提交于
      slot->response is a 64 bit quantity (and accessed as such), but its alignment
      is only 32 bits.  This doesn't cause a problem on x86, but apparently causes a
      kernel panic on Tile:
      
      Stack dump complete Kernel panic - not syncing:
       Kernel unalign fault running the idle task!
       Starting stack dump of tid 0, pid 0 (swapper) on cpu 1 at cycle 341586172541
         frame 0: 0xfffffff700140ee0 dump_stack+0x0/0x20 (sp 0xfffffe43ffedf420)
         frame 1: 0xfffffff700283270 panic+0x150/0x3a0 (sp 0xfffffe43ffedf420)
         frame 2: 0xfffffff70012bff8 jit_bundle_gen+0xfd8/0x27e0 (sp 0xfffffe43ffedf4c8)
         frame 3: 0xfffffff7003b5b68 do_unaligned+0xc0/0x5a0 (sp 0xfffffe43ffedf710)
         frame 4: 0xfffffff70044ca78 handle_interrupt+0x270/0x278 (sp 0xfffffe43ffedf840)
         <interrupt 17 while in kernel mode>
         frame 5: 0xfffffff7002ac370 mvs_slot_complete+0x5f0/0x12a0 (sp 0xfffffe43ffedfa90)
         frame 6: 0xfffffff7002abec0 mvs_slot_complete+0x140/0x12a0 (sp 0xfffffe43ffedfa90)
         frame 7: 0xfffffff7005cc840 mvs_int_rx+0x140/0x2a0 (sp 0xfffffe43ffedfb00)
         frame 8: 0xfffffff7005bbaf0 mvs_94xx_isr+0xd8/0x2b8 (sp 0xfffffe43ffedfb68)
         frame 9: 0xfffffff700658ba0 mvs_tasklet+0x128/0x1f8 (sp 0xfffffe43ffedfba8)
         frame 10: 0xfffffff7003e8230 tasklet_action+0x178/0x2c8 (sp 0xfffffe43ffedfbe0)
         frame 11: 0xfffffff700103850 __do_softirq+0x210/0x398 (sp 0xfffffe43ffedfc40)
         frame 12: 0xfffffff700180308 do_softirq+0xc8/0x140 (sp 0xfffffe43ffedfcd8)
         frame 13: 0xfffffff7000bd7f0 irq_exit+0xb0/0x158 (sp 0xfffffe43ffedfcf0)
         frame 14: 0xfffffff70013fa58 tile_dev_intr+0x1d8/0x2f0 (sp 0xfffffe43ffedfd00)
         frame 15: 0xfffffff70044ca78 handle_interrupt+0x270/0x278 (sp 0xfffffe43ffedfd40)
         <interrupt 30 while in kernel mode>
         frame 16: 0xfffffff700143e68 _cpu_idle_nap+0x0/0x18 (sp 0xfffffe43ffedffb0)
         frame 17: 0xfffffff700482480 cpu_idle+0x310/0x428 (sp 0xfffffe43ffedffb0)
      
      Since the check is just for non-zero, split it to be two 32 bit accesses
      (preserving speed in the fast path) and do a get_unaligned() in the slow path.
      
      This is a modification of a wholly get_unaligned patch submitted by Paul Guo
      Reported-by: NPaul Guo <ggang@tilera.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      53a983c4
  7. 23 7月, 2013 3 次提交
  8. 10 7月, 2013 10 次提交
  9. 09 7月, 2013 19 次提交