1. 25 Jun, 2013 3 commits
    • Jacob Shin's avatar
      cpufreq: fix NULL pointer deference at od_set_powersave_bias() · c2837558
      Jacob Shin authored
      When initializing the default powersave_bias value, we need to first
      make sure that this policy is running the ondemand governor.
      Reported-and-tested-by: default avatarTim Gardner <tim.gardner@canonical.com>
      Signed-off-by: default avatarJacob Shin <jacob.shin@amd.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c2837558
    • Josh Durgin's avatar
      rbd: fetch object order before using it · 1617e40c
      Josh Durgin authored
      rbd_dev_v2_header_onetime() fetches striping information, and
      checks whether the image can be read by compariing the stripe unit
      to the object size. It determines the object size by shifting
      the object order, which is 0 at this point since it has not been
      read yet. Move the call to get the image size and object order
      before rbd_dev_v2_header_onetime() so it is set before use.
      Signed-off-by: default avatarJosh Durgin <josh.durgin@inktank.com>
      Reviewed-by: default avatarSage Weil <sage@inktank.com>
      1617e40c
    • Robert Love's avatar
      fcoe: Use correct API to set vlan tag for FCoE Ethertype skbs · 2884d423
      Robert Love authored
      fcoe_xmit was coded such that it would skip the vlan net device/layer
      and instead set some vlan flags and transmit on the real net device.
      The real net device has code that would add the vlan tag for fcoe skbs.
      This avoids some extra processing for data frames and provides a small
      performance improvement.
      
      Since fcoe_xmit was not using the vlan net device, __vlan_put_tag
      within the real net device's xmit routine was ultimately being
      called to set the vlan tag.
      
      With the below change the behavior of __vlan_put_tag changed slightly,
      it now sets the skb->protocol = vlan_proto. vlan_proto was not a field
      being set by fcoe_xmit, so the skb->protocol is now not being set to
      ETH_P_8021Q, as it should be.
      
      This patch converts fcoe_xmit to use the vlan_put_tag routine which
      will tag the skb and fcoe will continue to transmit fcoe skbs on the
      real net device.
      
      For reference, the below change was the one that altered the
      __vlan_put_tag behavior.
      
        commit 86a9bad3
        Author: Patrick McHardy <kaber@trash.net>
        Date:   Fri Apr 19 02:04:30 2013 +0000
      
            net: vlan: add protocol argument to packet tagging functions
      
            Add a protocol argument to the VLAN packet tagging functions. In case of HW
            tagging, we need that protocol available in the ndo_start_xmit functions,
            so it is stored in a new field in the skb. The new field fits into a hole
            (on 64 bit) and doesn't increase the sks's size.
      Signed-off-by: default avatarRobert Love <robert.w.love@intel.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Acked-by: default avatarJohn Fastabend <john.r.fastabend@intel.com>
      2884d423
  2. 24 Jun, 2013 2 commits
    • Aaron Lu's avatar
      libata-acpi: add back ACPI based hotplug functionality · 44521527
      Aaron Lu authored
      Commit 30dcf76a "libata: migrate ACPI code over to new bindings"
      mistakenly dropped the code to register hotplug notificaion handler
      for ATA port/devices, causing regression for people using ATA bay,
      as kernel bug #59871 shows.
      
      Fix this by adding back the hotplug notification handler registration
      code.  Since this code has to be run once and notification needs to
      be installed on every ATA port/devices handle no matter if there is
      actual device attached, we can't do this in binding time for ATA
      device ACPI handle, as the binding only occurs when a SCSI device is
      created, i.e. there is device attached.  So introduce the
      ata_acpi_hotplug_init() function to loop scan all ATA ACPI handles
      and if it is available, install the notificaion handler for it during
      ATA init time.
      
      With the ATA ACPI handle binding to SCSI device tree, it is possible
      now that when the SCSI hotplug work removes the SCSI device, the ACPI
      unbind function will find that the corresponding ACPI device has
      already been deleted by dock driver, causing a scaring message like:
      [  128.263966] scsi 4:0:0:0: Oops, 'acpi_handle' corrupt
      Fix this by waiting for SCSI hotplug task finish in our notificaion
      handler, so that the removal of ACPI device done in ACPI unbind
      function triggered by the removal of SCSI device is run earlier when
      ACPI device is still available.
      
      [rjw: Rebased]
      References: https://bugzilla.kernel.org/show_bug.cgi?id=59871Reported-bisected-and-tested-by: default avatarDirk Griesbach <spamthis@freenet.de>
      Signed-off-by: default avatarAaron Lu <aaron.lu@intel.com>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Cc: 3.6+ <stable@vger.kernel.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      44521527
    • Rafael J. Wysocki's avatar
      ACPI / dock / PCI: Synchronous handling of dock events for PCI devices · 21a31013
      Rafael J. Wysocki authored
      The interactions between the ACPI dock driver and the ACPI-based PCI
      hotplug (acpiphp) are currently problematic because of ordering
      issues during hot-remove operations.
      
      First of all, the current ACPI glue code expects that physical
      devices will always be deleted before deleting the companion ACPI
      device objects.  Otherwise, acpi_unbind_one() will fail with a
      warning message printed to the kernel log, for example:
      
      [  185.026073] usb usb5: Oops, 'acpi_handle' corrupt
      [  185.035150] pci 0000:1b:00.0: Oops, 'acpi_handle' corrupt
      [  185.035515] pci 0000:18:02.0: Oops, 'acpi_handle' corrupt
      [  180.013656]  port1: Oops, 'acpi_handle' corrupt
      
      This means, in particular, that struct pci_dev objects have to
      be deleted before the struct acpi_device objects they are "glued"
      with.
      
      Now, the following happens the during the undocking of an ACPI-based
      dock station:
       1) hotplug_dock_devices() invokes registered hotplug callbacks to
          destroy physical devices associated with the ACPI device objects
          depending on the dock station.  It calls dd->ops->handler() for
          each of those device objects.
       2) For PCI devices dd->ops->handler() points to
          handle_hotplug_event_func() that queues up a separate work item
          to execute _handle_hotplug_event_func() for the given device and
          returns immediately.  That work item will be executed later.
       3) hotplug_dock_devices() calls dock_remove_acpi_device() for each
          device depending on the dock station.  This runs acpi_bus_trim()
          for each of them, which causes the underlying ACPI device object
          to be destroyed, but the work items queued up by
          handle_hotplug_event_func() haven't been started yet.
       4) _handle_hotplug_event_func() queued up in step 2) are executed
          and cause the above failure to happen, because the PCI devices
          they handle do not have the companion ACPI device objects any
          more (those objects have been deleted in step 3).
      
      The possible breakage doesn't end here, though, because
      hotplug_dock_devices() may return before at least some of the
      _handle_hotplug_event_func() work items spawned by it have a
      chance to complete and then undock() will cause _DCK to be
      evaluated and that will cause the devices handled by the
      _handle_hotplug_event_func() to go away possibly while they are
      being accessed.
      
      This means that dd->ops->handler() for PCI devices should not point
      to handle_hotplug_event_func().  Instead, it should point to a
      function that will do the work of _handle_hotplug_event_func()
      synchronously.  For this reason, introduce such a function,
      hotplug_event_func(), and modity acpiphp_dock_ops to point to
      it as the handler.
      
      Unfortunately, however, this is not sufficient, because if the dock
      code were not changed further, hotplug_event_func() would now
      deadlock with hotplug_dock_devices() that called it, since it would
      run unregister_hotplug_dock_device() which in turn would attempt to
      acquire the dock station's hp_lock mutex already acquired by
      hotplug_dock_devices().
      
      To resolve that deadlock use the observation that
      unregister_hotplug_dock_device() won't need to acquire hp_lock
      if PCI bridges the devices on the dock station depend on are
      prevented from being removed prematurely while the first loop in
      hotplug_dock_devices() is in progress.
      
      To make that possible, introduce a mechanism by which the callers of
      register_hotplug_dock_device() can provide "init" and "release"
      routines that will be executed, respectively, during the addition
      and removal of the physical device object associated with the
      given ACPI device handle.  Make acpiphp use two new functions,
      acpiphp_dock_init() and acpiphp_dock_release(), that call
      get_bridge() and put_bridge(), respectively, on the acpiphp bridge
      holding the given device, for this purpose.
      
      In addition to that, remove the dock station's list of
      "hotplug devices" and make the dock code always walk the whole list
      of "dependent devices" instead in such a way that the loops in
      hotplug_dock_devices() and dock_event() (replacing the loops over
      "hotplug devices") will take references to the list entries that
      register_hotplug_dock_device() has been called for.  That prevents
      the "release" routines associated with those entries from being
      called while the given entry is being processed and for PCI
      devices this means that their bridges won't be removed (by a
      concurrent thread) while hotplug_event_func() handling them is
      being executed.
      
      This change is based on two earlier patches from Jiang Liu.
      
      References: https://bugzilla.kernel.org/show_bug.cgi?id=59501Reported-and-tested-by: default avatarAlexander E. Patrakov <patrakov@gmail.com>
      Tracked-down-by: default avatarJiang Liu <jiang.liu@huawei.com>
      Tested-by: default avatarIllya Klymov <xanf@xanf.me>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarYinghai Lu <yinghai@kernel.org>
      Cc: 3.9+ <stable@vger.kernel.org>
      21a31013
  3. 22 Jun, 2013 2 commits
    • Jiang Liu's avatar
      PCI / ACPI: Use boot-time resource allocation rules during hotplug · d66ecb72
      Jiang Liu authored
      On x86 platforms, the kernel respects PCI resource assignments from
      the BIOS and only reassigns resources for unassigned BARs at boot
      time.  However, with the ACPI-based hotplug (acpiphp), it ignores the
      BIOS' PCI resource assignments completely and reassigns all resources
      by itself.  This causes differences in PCI resource allocation
      between boot time and runtime hotplug to occur, which is generally
      undesirable and sometimes actively breaks things.
      
      Namely, if there are enough resources, reassigning all PCI resources
      during runtime hotplug should work, but it may fail if the resources
      are constrained.  This may happen, for instance, when some PCI
      devices with huge MMIO BARs are involved in the runtime hotplug
      operations, because the current PCI MMIO alignment algorithm may
      waste huge chunks of MMIO address space in those cases.
      
      On the Alexander's Sony VAIO VPCZ23A4R the BIOS allocates limited
      MMIO resources for the dock station which contains a device
      (graphics adapter) with a 256MB MMIO BAR.  An attempt to reassign
      that during runtime hotplug causes the dock station MMIO window to be
      exhausted and acpiphp fails to allocate resources for the majority
      of devices on the dock station as a result.
      
      To prevent that from happening, modify acpiphp to follow the boot
      time resources allocation behavior so that the BIOS' resource
      assignments are respected during runtime hotplug too.
      
      [rjw: Changelog]
      References: https://bugzilla.kernel.org/show_bug.cgi?id=56531Reported-and-tested-by: default avatarAlexander E. Patrakov <patrakov@gmail.com>
      Tested-by: default avatarIllya Klymov <xanf@xanf.me>
      Signed-off-by: default avatarJiang Liu <jiang.liu@huawei.com>
      Acked-by: default avatarYinghai Lu <yinghai@kernel.org>
      Cc: 3.9+ <stable@vger.kernel.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d66ecb72
    • Jiang Liu's avatar
      ACPI / dock: Initialize ACPI dock subsystem upfront · 94add0f8
      Jiang Liu authored
      Commit 3b63aaa7 (PCI: acpiphp: Do not use ACPI PCI subdriver
      mechanism) introduced an ACPI dock support regression, because it
      changed the relative initialization order of the ACPI dock subsystem
      and the ACPI-based PCI hotplug (acpiphp).
      
      Namely, the ACPI dock subsystem has to be initialized before
      acpiphp_enumerate_slots() is first run, which after commit
      3b63aaa7 happens during the initial enumeration of the PCI
      hierarchy triggered by the initial ACPI namespace scan in
      acpi_scan_init().  For this reason, the dock subsystem has to be
      initialized before the initial ACPI namespace scan in
      acpi_scan_init().
      
      To make that happen, modify the ACPI dock subsystem to be
      non-modular and add the invocation of its initialization routine,
      acpi_dock_init(), to acpi_scan_init() directly before the initial
      namespace scan.
      
      [rjw: Changelog, removal of dock_exit().]
      References: https://bugzilla.kernel.org/show_bug.cgi?id=59501Reported-and-tested-by: default avatarAlexander E. Patrakov <patrakov@gmail.com>
      Tested-by: default avatarIllya Klymov <xanf@xanf.me>
      Signed-off-by: default avatarJiang Liu <jiang.liu@huawei.com>
      Acked-by: default avatarYinghai Lu <yinghai@kernel.org>
      Cc: 3.9+ <stable@vger.kernel.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      94add0f8
  4. 21 Jun, 2013 1 commit
    • Mika Westerberg's avatar
      spi/pxa2xx: fix memory corruption due to wrong size used in devm_kzalloc() · cc0ee987
      Mika Westerberg authored
      ACPI part of the driver accidentally used sizeof(*ssp) instead of the
      correct sizeof(*pdata). This leads to nasty memory corruptions like the one
      below:
      
          BUG: unable to handle kernel paging request at 0000000749fd30b8
          IP: [<ffffffff813fe8a1>] __list_del_entry+0x31/0xd0
          PGD 0
          Oops: 0000 [#1] PREEMPT SMP
          Modules linked in:
          CPU: 0 PID: 30 Comm: kworker/0:1 Not tainted 3.10.0-rc6v3.10-rc6_sdhci_modprobe+ #443
          task: ffff8801483a0940 ti: ffff88014839e000 task.ti: ffff88014839e000
          RIP: 0010:[<ffffffff813fe8a1>]  [<ffffffff813fe8a1>] __list_del_entry+0x31/0xd0
          RSP: 0000:ffff88014839fde8  EFLAGS: 00010046
          RAX: ffff880149fd30b0 RBX: ffff880149fd3040 RCX: dead000000200200
          RDX: 0000000749fd30b0 RSI: ffff880149fd3058 RDI: ffff88014834d640
          RBP: ffff88014839fde8 R08: ffff88014834d640 R09: 0000000000000001
          R10: ffff8801483a0940 R11: 0000000000000001 R12: ffff880149fd3040
          R13: ffffffff810e0b30 R14: ffff8801483a0940 R15: ffff88014834d640
          FS:  0000000000000000(0000) GS:ffff880149e00000(0000) knlGS:0000000000000000
          CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
          CR2: 0000000000000168 CR3: 0000000001e0b000 CR4: 00000000001407f0
          DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
          DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
          Stack:
           ffff88014839fe48 ffffffff810e0baf ffffffff81120abd ffff88014839fe20
           ffff8801483a0940 ffff8801483a0940 ffff8801483a0940 ffff8801486b1c90
           ffff88014834d640 ffffffff810e0b30 0000000000000000 0000000000000000
          Call Trace:
           [<ffffffff810e0baf>] worker_thread+0x7f/0x390
           [<ffffffff81120abd>] ? trace_hardirqs_on+0xd/0x10
           [<ffffffff810e0b30>] ? manage_workers.isra.22+0x2b0/0x2b0
           [<ffffffff810e6c09>] kthread+0xd9/0xe0
           [<ffffffff810f93df>] ? local_clock+0x3f/0x50
           [<ffffffff810e6b30>] ? kthread_create_on_node+0x110/0x110
           [<ffffffff818c5dec>] ret_from_fork+0x7c/0xb0
           [<ffffffff810e6b30>] ? kthread_create_on_node+0x110/0x110
      
      Fix this by using the right structure size in devm_kzalloc().
      Reported-by: default avatarJerome Blin <jerome.blin@intel.com>
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      Cc: stable@vger.kernel.org # 3.9+
      cc0ee987
  5. 20 Jun, 2013 6 commits
    • Nicholas Bellinger's avatar
    • Andy Grover's avatar
      target/iscsi: Fix op=disable + error handling cases in np_store_iser · 58bd0c69
      Andy Grover authored
      Writing 0 when iser was not previously enabled, so succeed but do
      nothing so that user-space code doesn't need a try: catch block
      when ib_isert logic is not available.
      
      Also, return actual error from add_network_portal using PTR_ERR
      during op=enable failure.
      Signed-off-by: default avatarAndy Grover <agrover@redhat.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      58bd0c69
    • Jerome Glisse's avatar
      drm/radeon: update lockup tracking when scheduling in empty ring · 8444d5c6
      Jerome Glisse authored
      There might be issue with lockup detection when scheduling on an
      empty ring that have been sitting idle for a while. Thus update
      the lockup tracking data when scheduling new work in an empty ring.
      Signed-off-by: default avatarJerome Glisse <jglisse@redhat.com>
      Tested-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      8444d5c6
    • Mauro Carvalho Chehab's avatar
      [media] Fix build when drivers are builtin and frontend modules · bb69ee27
      Mauro Carvalho Chehab authored
      There are a large number of reports that the media build is
      not compiling when some drivers are compiled as builtin, while
      the needed frontends are compiled as module.
      
      On the last one of such reports:
      	From: kbuild test robot <fengguang.wu@intel.com>
      	Subject: saa7134-dvb.c:undefined reference to `zl10039_attach'
      
      The .config file has:
      
      	CONFIG_VIDEO_SAA7134=y
      	CONFIG_VIDEO_SAA7134_DVB=y
      	# CONFIG_MEDIA_ATTACH is not set
      	CONFIG_DVB_ZL10039=m
      
      And it produces all those errors:
      
         drivers/built-in.o: In function `set_type':
         tuner-core.c:(.text+0x2f263e): undefined reference to `tea5767_attach'
         tuner-core.c:(.text+0x2f273e): undefined reference to `tda9887_attach'
         drivers/built-in.o: In function `tuner_probe':
         tuner-core.c:(.text+0x2f2d20): undefined reference to `tea5767_autodetection'
         drivers/built-in.o: In function `av7110_attach':
         av7110.c:(.text+0x330bda): undefined reference to `ves1x93_attach'
         av7110.c:(.text+0x330bf7): undefined reference to `stv0299_attach'
         av7110.c:(.text+0x330c63): undefined reference to `tda8083_attach'
         av7110.c:(.text+0x330d09): undefined reference to `ves1x93_attach'
         av7110.c:(.text+0x330d33): undefined reference to `tda8083_attach'
         av7110.c:(.text+0x330d5d): undefined reference to `stv0297_attach'
         av7110.c:(.text+0x330dbe): undefined reference to `stv0299_attach'
         drivers/built-in.o: In function `tuner_attach_dtt7520x':
         ngene-cards.c:(.text+0x3381cb): undefined reference to `dvb_pll_attach'
         drivers/built-in.o: In function `demod_attach_lg330x':
         ngene-cards.c:(.text+0x33828a): undefined reference to `lgdt330x_attach'
         drivers/built-in.o: In function `demod_attach_stv0900':
         ngene-cards.c:(.text+0x3383d5): undefined reference to `stv090x_attach'
         drivers/built-in.o: In function `cineS2_probe':
         ngene-cards.c:(.text+0x338b7f): undefined reference to `drxk_attach'
         drivers/built-in.o: In function `configure_tda827x_fe':
         saa7134-dvb.c:(.text+0x346ae7): undefined reference to `tda10046_attach'
         drivers/built-in.o: In function `dvb_init':
         saa7134-dvb.c:(.text+0x347283): undefined reference to `mt352_attach'
         saa7134-dvb.c:(.text+0x3472cd): undefined reference to `mt352_attach'
         saa7134-dvb.c:(.text+0x34731c): undefined reference to `tda10046_attach'
         saa7134-dvb.c:(.text+0x34733c): undefined reference to `tda10046_attach'
         saa7134-dvb.c:(.text+0x34735c): undefined reference to `tda10046_attach'
         saa7134-dvb.c:(.text+0x347378): undefined reference to `tda10046_attach'
         saa7134-dvb.c:(.text+0x3473db): undefined reference to `tda10046_attach'
         drivers/built-in.o:saa7134-dvb.c:(.text+0x347502): more undefined references to `tda10046_attach' follow
         drivers/built-in.o: In function `dvb_init':
         saa7134-dvb.c:(.text+0x347812): undefined reference to `mt352_attach'
         saa7134-dvb.c:(.text+0x347951): undefined reference to `mt312_attach'
         saa7134-dvb.c:(.text+0x3479a9): undefined reference to `mt312_attach'
      >> saa7134-dvb.c:(.text+0x3479c1): undefined reference to `zl10039_attach'
      
      This is happening because a builtin module can't use directly a symbol
      found on a module. By enabling CONFIG_MEDIA_ATTACH, the configuration
      becomes valid, as dvb_attach() macro loads the module if needed, making
      the symbol available to the builtin module.
      
      While this bug started to appear after the patches that use IS_DEFINED
      macro (like changeset 7b34be71), this
      bug is a way ancient than that.
      
      The thing is that, before the IS_DEFINED() patches, the logic used to be:
      
             && defined(MODULE))
      struct dvb_frontend *zl10039_attach(struct dvb_frontend *fe,
      					u8 i2c_addr,
      					struct i2c_adapter *i2c);
      static inline struct dvb_frontend *zl10039_attach(struct dvb_frontend *fe,
      					u8 i2c_addr,
      					struct i2c_adapter *i2c)
      {
      	printk(KERN_WARNING "%s: driver disabled by Kconfig\n", __func__);
      	return NULL;
      }
      
      The above code, with the .config file used, was evoluting to FALSE
      (instead of TRUE as it should be, as CONFIG_DVB_ZL10039 is 'm'),
      and were adding the static inline code at saa7134-dvb, instead
      of the external call. So, while it weren't producing any compilation
      error, the code weren't working either.
      
      So, as the overhead for using CONFIG_MEDIA_ATTACH is minimal, just
      enable it, if MODULES is defined.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      bb69ee27
    • Shawn Guo's avatar
      irqchip: gic: call gic_cpu_init() as well in CPU_STARTING_FROZEN case · 8b6fd652
      Shawn Guo authored
      Commit c0114709 (irqchip: gic: Perform the gic_secondary_init() call via
      CPU notifier) moves gic_secondary_init() that used to be called in
      .smp_secondary_init hook into a notifier call.  But it changes the
      system behavior a little bit.  Before the commit, gic_cpu_init()
      is called not only when kernel brings up the secondary cores but also
      when system resuming procedure hot-plugs the cores back to kernel.
      While after the commit, the function will not be called in the latter
      case, where the 'action' will not be CPU_STARTING but
      CPU_STARTING_FROZEN.  This behavior difference at least causes the
      following suspend/resume regression on imx6q.
      
      $ echo mem > /sys/power/state
      PM: Syncing filesystems ... done.
      PM: Preparing system for mem sleep
      mmc1: card e624 removed
      Freezing user space processes ... (elapsed 0.01 seconds) done.
      Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
      PM: Entering mem sleep
      PM: suspend of devices complete after 5.930 msecs
      PM: suspend devices took 0.010 seconds
      PM: late suspend of devices complete after 0.343 msecs
      PM: noirq suspend of devices complete after 0.828 msecs
      Disabling non-boot CPUs ...
      CPU1: shutdown
      CPU2: shutdown
      CPU3: shutdown
      Enabling non-boot CPUs ...
      CPU1: Booted secondary processor
      INFO: rcu_sched detected stalls on CPUs/tasks: { 1 2 3} (detected by 0, t=2102 jiffies, g=4294967169, c=4294967168, q=17)
      Task dump for CPU 1:
      swapper/1       R running      0     0      1 0x00000000
      Backtrace:
      [<bf895ff4>] (0xbf895ff4) from [<00000000>] (  (null))
      Backtrace aborted due to bad frame pointer <8007ccdc>
      Task dump for CPU 2:
      swapper/2       R running      0     0      1 0x00000000
      Backtrace:
      [<8075dbdc>] (0x8075dbdc) from [<00000000>] (  (null))
      Backtrace aborted due to bad frame pointer <00000002>
      Task dump for CPU 3:
      swapper/3       R running      0     0      1 0x00000000
      Backtrace:
      [<8075dbdc>] (0x8075dbdc) from [<00000000>] (  (null))
      
      Fix the regression by checking 'action' being CPU_STARTING_FROZEN to
      have gic_cpu_init() called for secondary cores when system resumes.
      Signed-off-by: default avatarShawn Guo <shawn.guo@linaro.org>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Tested-by: default avatarJoseph Lo <josephl@nvidia.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      8b6fd652
    • Mauro Carvalho Chehab's avatar
      [media] s5p makefiles: don't override other selections on obj-[ym] · 5f63adbb
      Mauro Carvalho Chehab authored
      The $obj-m/$obj-y vars should be adding new modules to build, not
      overriding it. So, it should never use
      	$obj-y := foo.o
      instead, it should use:
      	$obj-y += foo.o
      
      Failing to do that is very bad, as it will suppress needed modules.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      5f63adbb
  6. 19 Jun, 2013 8 commits
  7. 18 Jun, 2013 5 commits
  8. 17 Jun, 2013 3 commits
  9. 16 Jun, 2013 2 commits
  10. 14 Jun, 2013 3 commits
    • Alex Deucher's avatar
      drm/radeon: fix UVD on big endian · c139b1ee
      Alex Deucher authored
      This fixes the kernel side so that the ring should come
      up and ring and IB tests should work.  The userspace
      UVD drivers will also need big endian fixes.
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      c139b1ee
    • Roland Dreier's avatar
      tcm_qla2xxx: Fix residual for underrun commands that fail · b5aff3d2
      Roland Dreier authored
      Suppose an initiator sends a DATA IN command with an allocation length
      shorter than the FC transfer length -- we get a target message like
      
          TARGET_CORE[qla2xxx]: Expected Transfer Length: 256 does not match SCSI CDB Length: 0 for SAM Opcode: 0x12
      
      In that case, the target core adjusts the data_length and sets
      se_cmd->residual_count for the underrun.  But now suppose that command
      fails and we end up in tcm_qla2xxx_queue_status() -- that function
      unconditionally overwrites residual_count with the already adjusted
      data_length, and the initiator will burp with a message like
      
          qla2xxx [0000:00:06.0]-301d:0: Dropped frame(s) detected (0x100 of 0x100 bytes).
      
      Fix this by adding on to the existing underflow residual count instead.
      Signed-off-by: default avatarRoland Dreier <roland@purestorage.com>
      Cc: Giridhar Malavali <giridhar.malavali@qlogic.com>
      Cc: Chad Dupuis <chad.dupuis@qlogic.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      b5aff3d2
    • Jörn Engel's avatar
      target/iscsi: don't corrupt bh_count in iscsit_stop_time2retain_timer() · 574780fd
      Jörn Engel authored
      Here is a fun one.  Bug seems to have been introduced by commit 140854cb,
      almost two years ago.  I have no idea why we only started seeing it now,
      but we did.
      
      Rough callgraph:
      core_tpg_set_initiator_node_queue_depth()
      `-> spin_lock_irqsave(&tpg->session_lock, flags);
      `-> lio_tpg_shutdown_session()
          `-> iscsit_stop_time2retain_timer()
              `-> spin_unlock_bh(&se_tpg->session_lock);
              `-> spin_lock_bh(&se_tpg->session_lock);
      `-> spin_unlock_irqrestore(&tpg->session_lock, flags);
      
      core_tpg_set_initiator_node_queue_depth() used to call spin_lock_bh(),
      but 140854cb changed that to spin_lock_irqsave().  However,
      lio_tpg_shutdown_session() still claims to be called with spin_lock_bh()
      held, as does iscsit_stop_time2retain_timer():
       *      Called with spin_lock_bh(&struct se_portal_group->session_lock) held
      
      Stale documentation is mostly annoying, but in this case the dropping
      the lock with the _bh variant is plain wrong.  It is also wrong to drop
      locks two functions below the lock-holder, but I will ignore that bit
      for now.
      
      After some more locking and unlocking we eventually hit this backtrace:
      ------------[ cut here ]------------
      WARNING: at kernel/softirq.c:159 local_bh_enable_ip+0xe8/0x100()
      Pid: 24645, comm: lio_helper.py Tainted: G           O 3.6.11+
      Call Trace:
       [<ffffffff8103e5ff>] warn_slowpath_common+0x7f/0xc0
       [<ffffffffa040ae37>] ? iscsit_inc_conn_usage_count+0x37/0x50 [iscsi_target_mod]
       [<ffffffff8103e65a>] warn_slowpath_null+0x1a/0x20
       [<ffffffff810472f8>] local_bh_enable_ip+0xe8/0x100
       [<ffffffff815b8365>] _raw_spin_unlock_bh+0x15/0x20
       [<ffffffffa040ae37>] iscsit_inc_conn_usage_count+0x37/0x50 [iscsi_target_mod]
       [<ffffffffa041149a>] iscsit_stop_session+0xfa/0x1c0 [iscsi_target_mod]
       [<ffffffffa0417fab>] lio_tpg_shutdown_session+0x7b/0x90 [iscsi_target_mod]
       [<ffffffffa033ede4>] core_tpg_set_initiator_node_queue_depth+0xe4/0x290 [target_core_mod]
       [<ffffffffa0409032>] iscsit_tpg_set_initiator_node_queue_depth+0x12/0x20 [iscsi_target_mod]
       [<ffffffffa0415c29>] lio_target_nacl_store_cmdsn_depth+0xa9/0x180 [iscsi_target_mod]
       [<ffffffffa0331b49>] target_fabric_nacl_base_attr_store+0x39/0x40 [target_core_mod]
       [<ffffffff811b857d>] configfs_write_file+0xbd/0x120
       [<ffffffff81148f36>] vfs_write+0xc6/0x180
       [<ffffffff81149251>] sys_write+0x51/0x90
       [<ffffffff815c0969>] system_call_fastpath+0x16/0x1b
      ---[ end trace 3747632b9b164652 ]---
      
      As a pure band-aid, this patch drops the _bh.
      Signed-off-by: default avatarJoern Engel <joern@logfs.org>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      574780fd
  11. 13 Jun, 2013 5 commits
    • Tomas Winkler's avatar
      mei: me: clear interrupts on the resume path · 42f132fe
      Tomas Winkler authored
      We need to clear pending interrupts on the resume
      path. This brings the device into defined state
      before starting the reset flow
      
      This should solve suspend/resume issues:
      
      mei_me : wait hw ready failed. status = 0x0
      mei_me : version message write failed
      Signed-off-by: default avatarTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      42f132fe
    • Tomas Winkler's avatar
      mei: nfc: fix nfc device freeing · 2753ff53
      Tomas Winkler authored
      The nfc_dev is a static variable and is not cleaned properly upon reset
      mainly ndev->cl and ndev->cl_info are not set to NULL after freeing which
      
      mei_stop:198: mei_me 0000:00:16.0: stopping the device.
      [  404.253427] general protection fault: 0000 [#2] SMP
      [  404.253437] Modules linked in: mei_me(-) binfmt_misc snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device edd af_packet cpufreq_conservative cpufreq_userspace cpufreq_powersave fuse loop dm_mod hid_generic usbhid hid coretemp acpi_cpufreq mperf kvm_intel kvm crc32c_intel ghash_clmulni_intel aesni_intel ablk_helper cryptd lrw gf128mul snd_hda_codec_hdmi glue_helper aes_x86_64 e1000e snd_hda_intel snd_hda_codec ehci_pci iTCO_wdt iTCO_vendor_support ehci_hcd snd_hwdep xhci_hcd snd_pcm usbcore ptp mei sg microcode snd_timer pps_core i2c_i801 snd pcspkr battery rtc_cmos lpc_ich mfd_core soundcore usb_common snd_page_alloc ac ext3 jbd mbcache drm_kms_helper drm intel_agp i2c_algo_bit intel_gtt i2c_core sd_mod crc_t10dif thermal fan video button processor thermal_sys hwmon ahci libahci libata scsi_mod [last unloaded: mei_me]
      [  404.253591] CPU: 0 PID: 5551 Comm: modprobe Tainted: G      D W    3.10.0-rc3 #1
      [  404.253611] task: ffff880143cd8300 ti: ffff880144a2a000 task.ti: ffff880144a2a000
      [  404.253619] RIP: 0010:[<ffffffff81334e5d>]  [<ffffffff81334e5d>] device_del+0x1d/0x1d0
      [  404.253638] RSP: 0018:ffff880144a2bcf8  EFLAGS: 00010206
      [  404.253645] RAX: 2020302e30202030 RBX: ffff880144fdb000 RCX: 0000000000000086
      [  404.253652] RDX: 0000000000000001 RSI: 0000000000000086 RDI: ffff880144fdb000
      [  404.253659] RBP: ffff880144a2bd18 R08: 0000000000000651 R09: 0000000000000006
      [  404.253666] R10: 0000000000000651 R11: 0000000000000006 R12: ffff880144fdb000
      [  404.253673] R13: ffff880149371098 R14: ffff880144482c00 R15: ffffffffa04710e0
      [  404.253681] FS:  00007f251c59a700(0000) GS:ffff88014e200000(0000) knlGS:0000000000000000
      [  404.253689] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  404.253696] CR2: ffffffffff600400 CR3: 0000000145319000 CR4: 00000000001407f0
      [  404.253703] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  404.253710] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [  404.253716] Stack:
      [  404.253720]  ffff880144fdb000 ffff880143ffe000 ffff880149371098 ffffffffa0471000
      [  404.253732]  ffff880144a2bd38 ffffffff8133502d ffff88014e20cf48 ffff880143ffe1d8
      [  404.253744]  ffff880144a2bd48 ffffffffa02a4749 ffff880144a2bd58 ffffffffa02a4ba1
      [  404.253755] Call Trace:
      [  404.253766]  [<ffffffff8133502d>] device_unregister+0x1d/0x60
      [  404.253787]  [<ffffffffa02a4749>] mei_cl_remove_device+0x9/0x10 [mei]
      [  404.253804]  [<ffffffffa02a4ba1>] mei_nfc_host_exit+0x21/0x30 [mei]
      [  404.253819]  [<ffffffffa029c2dd>] mei_stop+0x3d/0x90 [mei]
      [  404.253830]  [<ffffffffa046e220>] mei_me_remove+0x60/0xe0 [mei_me]
      [  404.253843]  [<ffffffff81278f37>] pci_device_remove+0x37/0xb0
      [  404.253855]  [<ffffffff81337c68>] __device_release_driver+0x98/0x100
      [  404.253865]  [<ffffffff81337d80>] driver_detach+0xb0/0xc0
      [  404.253876]  [<ffffffff81336b4f>] bus_remove_driver+0x8f/0x120
      [  404.253891]  [<ffffffff81075990>] ? try_to_wake_up+0x2b0/0x2b0
      [  404.253903]  [<ffffffff81338a48>] driver_unregister+0x58/0x90
      [  404.253913]  [<ffffffff8127906b>] pci_unregister_driver+0x2b/0xb0
      [  404.253924]  [<ffffffffa046f244>] mei_me_driver_exit+0x10/0xdcc [mei_me]
      [  404.253936]  [<ffffffff810a50d8>] SyS_delete_module+0x198/0x2b0
      [  404.253949]  [<ffffffff814850d9>] ? do_page_fault+0x9/0x10
      [  404.253961]  [<ffffffff81489692>] system_call_fastpath+0x16/0x1b
      [  404.253967] Code: 41 5c 41 5d 41 5e 41 5f c9 c3 0f 1f 40 00 55 48 89 e5 41 56 41 55 41 54 49 89 fc 53 48 8b 87 88 00 00 00 4c 8b 37 48 85 c0 74 18 <48> 8b 78 78 4c 89 e2 be 02 00 00 00 48 81 c7 f8 00 00 00 e8 3b
      [  404.254048] RIP  [<ffffffff81334e5d>] device_del+0x1d/0x1d0
      
      Cc: Samuel Ortiz <sameo@linux.intel.com>
      Signed-off-by: default avatarTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2753ff53
    • Samuel Ortiz's avatar
      mei: init: Flush scheduled work before resetting the device · 5e85b364
      Samuel Ortiz authored
      Flushing pending work items before resetting the device makes more
      sense than doing so afterwards. Some of them, like e.g. the NFC
      initialization one, find themselves with client IDs changed after
      the reset, eventually leading to trigger a client.c:mei_me_cl_by_id()
      warning after a few modprobe/rmmod cycles.
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
      Signed-off-by: default avatarTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5e85b364
    • Benjamin Poirier's avatar
      netiucv: Hold rtnl between name allocation and device registration. · aaf9522d
      Benjamin Poirier authored
      fixes a race condition between concurrent initializations of netiucv devices
      that try to use the same name.
      
      sysfs: cannot create duplicate filename '/devices/iucv/netiucv2'
      [...]
      Call Trace:
      ([<00000000002edea4>] sysfs_add_one+0xb0/0xdc)
       [<00000000002eecd4>] create_dir+0x80/0xfc
       [<00000000002eee38>] sysfs_create_dir+0xe8/0x118
       [<00000000003835a8>] kobject_add_internal+0x120/0x2d0
       [<00000000003839d6>] kobject_add+0x62/0x9c
       [<00000000003d9564>] device_add+0xcc/0x510
       [<000003e00212c7b4>] netiucv_register_device+0xc0/0x1ec [netiucv]
      Signed-off-by: default avatarBenjamin Poirier <bpoirier@suse.de>
      Tested-by: default avatarUrsula Braun <braunu@de.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      aaf9522d
    • Neil Horman's avatar
      tulip: Properly check dma mapping result · c9bfbb31
      Neil Horman authored
      Tulip throws an error when dma debugging is enabled, as it doesn't properly
      check dma mapping results with dma_mapping_error() durring tx ring refills.
      
      Easy fix, just add it in, and drop the frame if the mapping is bad
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      CC: Grant Grundler <grundler@parisc-linux.org>
      CC: "David S. Miller" <davem@davemloft.net>
      Reviewed-by: default avatarGrant Grundler <grundler@parisc-linux.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c9bfbb31