1. 18 5月, 2011 9 次提交
    • R
      PM / Hibernate: Add sysfs knob to control size of memory for drivers · ddeb6487
      Rafael J. Wysocki 提交于
      Martin reports that on his system hibernation occasionally fails due
      to the lack of memory, because the radeon driver apparently allocates
      too much of it during the device freeze stage.  It turns out that the
      amount of memory allocated by radeon during hibernation (and
      presumably during system suspend too) depends on the utilization of
      the GPU (e.g. hibernating while there are two KDE 4 sessions with
      compositing enabled causes radeon to allocate more memory than for
      one KDE 4 session).
      
      In principle it should be possible to use image_size to make the
      memory preallocation mechanism free enough memory for the radeon
      driver, but in practice it is not easy to guess the right value
      because of the way the preallocation code uses image_size.  For this
      reason, it seems reasonable to allow users to control the amount of
      memory reserved for driver allocations made after the hibernate
      preallocation, which currently is constant and amounts to 1 MB.
      
      Introduce a new sysfs file, /sys/power/reserved_size, whose value
      will be used as the amount of memory to reserve for the
      post-preallocation reservations made by device drivers, in bytes.
      For backwards compatibility, set its default (and initial) value to
      the currently used number (1 MB).
      
      References: https://bugzilla.kernel.org/show_bug.cgi?id=34102Reported-and-tested-by: NMartin Steigerwald <Martin@Lichtvoll.de>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      ddeb6487
    • E
      PM / Wakeup: Remove useless synchronize_rcu() call · 13e38136
      Eric Dumazet 提交于
      wakeup_source_add() adds an item into wakeup_sources list.
      
      There is no need to call synchronize_rcu() at this point.
      
      Its only needed in wakeup_source_remove()
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      13e38136
    • K
      kmod: always provide usermodehelper_disable() · 13d53f87
      Kay Sievers 提交于
      We need to prevent kernel-forked processes during system poweroff.
      Such processes try to access the filesystem whose disks we are
      trying to shutdown at the same time. This causes delays and exceptions
      in the storage drivers.
      
      A follow-up patch will add these calls and need usermodehelper_disable()
      also on systems without suspend support.
      Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      13d53f87
    • A
      PM / ACPI: Remove acpi_sleep=s4_nonvs · c3b0795c
      Amerigo Wang 提交于
      acpi_sleep=s4_nonvs is superseded by acpi_sleep=nonvs, so remove it.
      Signed-off-by: NWANG Cong <amwang@redhat.com>
      Acked-by: NPavel Machek <pavel@ucw.cz>
      Acked-by: NLen Brown <lenb@kernel.org>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      c3b0795c
    • R
      PM / Wakeup: Fix build warning related to the "wakeup" sysfs file · e762318b
      Rafael J. Wysocki 提交于
      The "wakeup" device sysfs file is only created if CONFIG_PM_SLEEP
      is set, so put it under CONFIG_PM_SLEEP and make a build warning
      related to it go away.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      e762318b
    • R
      PM: Print a warning if firmware is requested when tasks are frozen · a144c6a6
      Rafael J. Wysocki 提交于
      Some drivers erroneously use request_firmware() from their ->resume()
      (or ->thaw(), or ->restore()) callbacks, which is not going to work
      unless the firmware has been built in.  This causes system resume to
      stall until the firmware-loading timeout expires, which makes users
      think that the resume has failed and reboot their machines
      unnecessarily.  For this reason, make _request_firmware() print a
      warning and return immediately with error code if it has been called
      when tasks are frozen and it's impossible to start any new usermode
      helpers.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Reviewed-by: NValdis Kletnieks <valdis.kletnieks@vt.edu>
      a144c6a6
    • R
      PM / Runtime: Rework runtime PM handling during driver removal · e1866b33
      Rafael J. Wysocki 提交于
      The driver core tries to prevent race conditions between runtime PM
      and driver removal from happening by incrementing the runtime PM
      usage counter of the device and executing pm_runtime_barrier() before
      running the bus notifier and the ->remove() callbacks provided by the
      device's subsystem or driver.  This guarantees that, if a future
      runtime suspend of the device has been scheduled or a runtime resume
      or idle request has been queued up right before the driver removal,
      it will be canceled or waited for to complete and no other
      asynchronous runtime suspend or idle requests for the device will be
      put into the PM workqueue until the ->remove() callback returns.
      However, it doesn't prevent resume requests from being queued up
      after pm_runtime_barrier() has been called and it doesn't prevent
      pm_runtime_resume() from executing the device subsystem's runtime
      resume callback.  Morever, it prevents the device's subsystem or
      driver from putting the device into the suspended state by calling
      pm_runtime_suspend() from its ->remove() routine.  This turns out to
      be a major inconvenience for some subsystems and drivers that want to
      leave the devices they handle in the suspended state.
      
      To really prevent runtime PM callbacks from racing with the bus
      notifier callback in __device_release_driver(), which is necessary,
      because the notifier is used by some subsystems to carry out
      operations affecting the runtime PM functionality, use
      pm_runtime_get_sync() instead of the combination of
      pm_runtime_get_noresume() and pm_runtime_barrier().  This will resume
      the device if it's in the suspended state and will prevent it from
      being suspended again until pm_runtime_put_*() is called.
      
      To allow subsystems and drivers to put devices into the suspended
      state by calling pm_runtime_suspend() from their ->remove() routines,
      execute pm_runtime_put_sync() after running the bus notifier in
      __device_release_driver().  This will require subsystems and drivers
      to make their ->remove() callbacks avoid races with runtime PM
      directly, but it will allow of more flexibility in the handling of
      devices during the removal of their drivers.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      e1866b33
    • M
      Freezer: Use SMP barriers · ee940d8d
      Mike Frysinger 提交于
      The freezer processes are dealing with multiple threads running
      simultaneously, and on a UP system, the memory reads/writes do
      not need barriers to keep things in sync.  These are only needed
      on SMP systems, so use SMP barriers instead.
      Signed-off-by: NMike Frysinger <vapier@gentoo.org>
      Acked-by: NPavel Machek <pavel@ucw.cz>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      ee940d8d
    • M
      PM / Suspend: Do not ignore error codes returned by suspend_enter() · 3c431936
      MyungJoo Ham 提交于
      The current implementation of suspend-to-RAM returns 0 if there is an
      error from suspend_enter(), because suspend_devices_and_enter() ignores
      the return value from suspend_enter().  This patch addresses this issue
      and properly keep the error return from suspend_enter() and let
      suspend_devices_and_enter relay the error return.
      Signed-off-by: NMyungJoo Ham <myungjoo.ham@samsung.com>
      Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      3c431936
  2. 17 5月, 2011 7 次提交
    • L
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6 · c1d10d18
      Linus Torvalds 提交于
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6:
        net: Change netdev_fix_features messages loglevel
        vmxnet3: Fix inconsistent LRO state after initialization
        sfc: Fix oops in register dump after mapping change
        IPVS: fix netns if reading ip_vs_* procfs entries
        bridge: fix forwarding of IPv6
      c1d10d18
    • L
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc · 477de0de
      Linus Torvalds 提交于
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc:
        Revert "mmc: fix a race between card-detect rescan and clock-gate work instances"
      477de0de
    • R
      mm: fix kernel-doc warning in page_alloc.c · b5e6ab58
      Randy Dunlap 提交于
      Fix new kernel-doc warning in mm/page_alloc.c:
      
        Warning(mm/page_alloc.c:2370): No description found for parameter 'nid'
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b5e6ab58
    • Y
      PCI: Clear bridge resource flags if requested size is 0 · 93d2175d
      Yinghai Lu 提交于
      During pci remove/rescan testing found:
      
        pci 0000:c0:03.0: PCI bridge to [bus c4-c9]
        pci 0000:c0:03.0:   bridge window [io  0x1000-0x0fff]
        pci 0000:c0:03.0:   bridge window [mem 0xf0000000-0xf00fffff]
        pci 0000:c0:03.0:   bridge window [mem 0xfc180000000-0xfc197ffffff 64bit pref]
        pci 0000:c0:03.0: device not available (can't reserve [io  0x1000-0x0fff])
        pci 0000:c0:03.0: Error enabling bridge (-22), continuing
        pci 0000:c0:03.0: enabling bus mastering
        pci 0000:c0:03.0: setting latency timer to 64
        pcieport 0000:c0:03.0: device not available (can't reserve [io  0x1000-0x0fff])
        pcieport: probe of 0000:c0:03.0 failed with error -22
      
      This bug was caused by commit c8adf9a3 ("PCI: pre-allocate
      additional resources to devices only after successful allocation of
      essential resources.")
      
      After that commit, pci_hotplug_io_size is changed to additional_io_size
      from minium size.  So it will not go through resource_size(res) != 0
      path, and will not be reset.
      
      The root cause is: pci_bridge_check_ranges will set RESOURCE_IO flag for
      pci bridge, and later if children do not need IO resource.  those bridge
      resources will not need to be allocated.  but flags is still there.
      that will confuse the the pci_enable_bridges later.
      
      related code:
      
         static void assign_requested_resources_sorted(struct resource_list *head,
                                          struct resource_list_x *fail_head)
         {
                 struct resource *res;
                 struct resource_list *list;
                 int idx;
      
                 for (list = head->next; list; list = list->next) {
                         res = list->res;
                         idx = res - &list->dev->resource[0];
                         if (resource_size(res) && pci_assign_resource(list->dev, idx)) {
         ...
                                 reset_resource(res);
                         }
                 }
         }
      
      At last, We have to clear the flags in pbus_size_mem/io when requested
      size == 0 and !add_head.  becasue this case it will not go through
      adjust_resources_sorted().
      
      Just make size1 = size0 when !add_head. it will make flags get cleared.
      
      At the same time when requested size == 0, add_size != 0, will still
      have in head and add_list.  because we do not clear the flags for it.
      
      After this, we will get right result:
      
        pci 0000:c0:03.0: PCI bridge to [bus c4-c9]
        pci 0000:c0:03.0:   bridge window [io  disabled]
        pci 0000:c0:03.0:   bridge window [mem 0xf0000000-0xf00fffff]
        pci 0000:c0:03.0:   bridge window [mem 0xfc180000000-0xfc197ffffff 64bit pref]
        pci 0000:c0:03.0: enabling bus mastering
        pci 0000:c0:03.0: setting latency timer to 64
        pcieport 0000:c0:03.0: setting latency timer to 64
        pcieport 0000:c0:03.0: irq 160 for MSI/MSI-X
        pcieport 0000:c0:03.0: Signaling PME through PCIe PME interrupt
        pci 0000:c4:00.0: Signaling PME through PCIe PME interrupt
        pcie_pme 0000:c0:03.0:pcie01: service driver pcie_pme loaded
        aer 0000:c0:03.0:pcie02: service driver aer loaded
        pciehp 0000:c0:03.0:pcie04: Hotplug Controller:
      
      v3: more simple fix. also fix one typo in pbus_size_mem
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Reviewed-by: NRam Pai <linuxram@us.ibm.com>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      93d2175d
    • M
      net: Change netdev_fix_features messages loglevel · 6f404e44
      Michał Mirosław 提交于
      Those reduced to DEBUG can possibly be triggered by unprivileged processes
      and are nothing exceptional. Illegal checksum combinations can only be
      caused by driver bug, so promote those messages to WARN.
      
      Since GSO without SG will now only cause DEBUG message from
      netdev_fix_features(), remove the workaround from register_netdevice().
      Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6f404e44
    • T
      vmxnet3: Fix inconsistent LRO state after initialization · ebde6f8a
      Thomas Jarosch 提交于
      During initialization of vmxnet3, the state of LRO
      gets out of sync with netdev->features.
      
      This leads to very poor TCP performance in a IP forwarding
      setup and is hitting many VMware users.
      
      Simplified call sequence:
      1. vmxnet3_declare_features() initializes "adapter->lro" to true.
      
      2. The kernel automatically disables LRO if IP forwarding is enabled,
      so vmxnet3_set_flags() gets called. This also updates netdev->features.
      
      3. Now vmxnet3_setup_driver_shared() is called. "adapter->lro" is still
      set to true and LRO gets enabled again, even though
      netdev->features shows it's disabled.
      
      Fix it by updating "adapter->lro", too.
      
      The private vmxnet3 adapter flags are scheduled for removal
      in net-next, see commit a0d2730c
      "net: vmxnet3: convert to hw_features".
      
      Patch applies to 2.6.37 / 2.6.38 and 2.6.39-rc6.
      
      Please CC: comments.
      Signed-off-by: NThomas Jarosch <thomas.jarosch@intra2net.com>
      Acked-by: NStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ebde6f8a
    • B
      sfc: Fix oops in register dump after mapping change · 867955f5
      Ben Hutchings 提交于
      Commit 747df225 ('sfc: Always map MCDI
      shared memory as uncacheable') introduced a separate mapping for the
      MCDI shared memory (MC_TREG_SMEM).  This means we can no longer easily
      include it in the register dump.  Since it is not particularly useful
      in debugging, substitute a recognisable dummy value.
      Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      867955f5
  3. 16 5月, 2011 8 次提交
  4. 15 5月, 2011 15 次提交
  5. 14 5月, 2011 1 次提交