1. 15 Aug, 2013 9 commits
    • Michael Neuling's avatar
      powerpc/tm: Fix context switching TAR, PPR and DSCR SPRs · ab953057
      Michael Neuling authored
      commit 28e61cc4 upstream.
      
      If a transaction is rolled back, the Target Address Register (TAR), Processor
      Priority Register (PPR) and Data Stream Control Register (DSCR) should be
      restored to the checkpointed values before the transaction began.  Any changes
      to these SPRs inside the transaction should not be visible in the abort
      handler.
      
      Currently Linux doesn't save or restore the checkpointed TAR, PPR or DSCR.  If
      we preempt a processes inside a transaction which has modified any of these, on
      process restore, that same transaction may be aborted we but we won't see the
      checkpointed versions of these SPRs.
      
      This adds checkpointed versions of these SPRs to the thread_struct and adds the
      save/restore of these three SPRs to the treclaim/trechkpt code.
      
      Without this if any of these SPRs are modified during a transaction, users may
      incorrectly see a speculated SPR value even if the transaction is aborted.
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ab953057
    • Michael Neuling's avatar
      powerpc: Save the TAR register earlier · 80737512
      Michael Neuling authored
      commit c2d52644 upstream.
      
      This moves us to save the Target Address Register (TAR) a earlier in
      __switch_to.  It introduces a new function save_tar() to do this.
      
      We need to save the TAR earlier as we will overwrite it in the transactional
      memory reclaim/recheckpoint path.  We are going to do this in a subsequent
      patch which will fix saving the TAR register when it's modified inside a
      transaction.
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      80737512
    • Michael Neuling's avatar
      powerpc: Fix context switch DSCR on POWER8 · 734ce4ea
      Michael Neuling authored
      commit 2517617e upstream.
      
      POWER8 allows the DSCR to be accessed directly from userspace via a new SPR
      number 0x3 (Rather than 0x11.  DSCR SPR number 0x11 is still used on POWER8 but
      like POWER7, is only accessible in HV and OS modes).  Currently, we allow this
      by setting H/FSCR DSCR bit on boot.
      
      Unfortunately this doesn't work, as the kernel needs to see the DSCR change so
      that it knows to no longer restore the system wide version of DSCR on context
      switch (ie. to set thread.dscr_inherit).
      
      This clears the H/FSCR DSCR bit initially.  If a process then accesses the DSCR
      (via SPR 0x3), it'll trap into the kernel where we set thread.dscr_inherit in
      facility_unavailable_exception().
      
      We also change _switch() so that we set or clear the H/FSCR DSCR bit based on
      the thread.dscr_inherit.
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      734ce4ea
    • Michael Neuling's avatar
      powerpc: Rework setting up H/FSCR bit definitions · f60232be
      Michael Neuling authored
      commit 74e400ce upstream.
      
      This reworks the Facility Status and Control Regsiter (FSCR) config bit
      definitions so that we can access the bit numbers.  This is needed for a
      subsequent patch to fix the userspace DSCR handling.
      
      HFSCR and FSCR bit definitions are the same, so reuse them.
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f60232be
    • Michael Neuling's avatar
      powerpc: Fix hypervisor facility unavaliable vector number · 7ab7de87
      Michael Neuling authored
      commit 88f09412 upstream.
      
      Currently if we take hypervisor facility unavaliable (from 0xf80/0x4f80) we
      mark it as an OS facility unavaliable (0xf60) as the two share the same code
      path.
      
      The becomes a problem in facility_unavailable_exception() as we aren't able to
      see the hypervisor facility unavailable exceptions.
      
      Below fixes this by duplication the required macros.
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7ab7de87
    • Anton Blanchard's avatar
      powerpc: On POWERNV enable PPC_DENORMALISATION by default · 70aabee4
      Anton Blanchard authored
      commit 4e90a2a7 upstream.
      
      We want PPC_DENORMALISATION enabled when POWERNV is enabled,
      so update the Kconfig.
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Acked-by: default avatarMichael Neuling <mikey@neuling.org>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      70aabee4
    • Asias He's avatar
      virtio-scsi: Fix virtqueue affinity setup · 96e9cd3d
      Asias He authored
      commit aa52aeea upstream.
      
      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 ]---
      Signed-off-by: default avatarAsias He <asias@redhat.com>
      Reviewed-by: default avatarWanlong Gao <gaowanlong@cn.fujitsu.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      96e9cd3d
    • Sumit.Saxena@lsi.com's avatar
      SCSI: megaraid_sas: megaraid_sas driver init fails in kdump kernel · e842dbeb
      Sumit.Saxena@lsi.com authored
      commit 6431f5d7 upstream.
      
      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: default avatarSumit Saxena <sumit.saxena@lsi.com>
      Signed-off-by: default avatarKashyap Desai <kashyap.desai@lsi.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e842dbeb
    • Martin K. Petersen's avatar
      SCSI: Don't attempt to send extended INQUIRY command if skip_vpd_pages is set · 0ac10bd0
      Martin K. Petersen authored
      commit 7562523e upstream.
      
      If a device has the skip_vpd_pages flag set we should simply fail the
      scsi_get_vpd_page() call.
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Tested-by: default avatarStuart Foster <smf.linux@ntlworld.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0ac10bd0
  2. 12 Aug, 2013 31 commits