1. 10 10月, 2008 1 次提交
  2. 09 10月, 2008 1 次提交
  3. 04 10月, 2008 2 次提交
  4. 01 10月, 2008 14 次提交
  5. 20 9月, 2008 17 次提交
  6. 19 9月, 2008 5 次提交
    • N
      md: Don't wait UNINTERRUPTIBLE for other resync to finish · 9744197c
      NeilBrown 提交于
      When two md arrays share some block device (e.g each uses different
      partitions on the one device), a resync of one array will wait for
      the resync on the other to finish.
      
      This can be a long time and as it currently waits TASK_UNINTERRUPTIBLE,
      the softlockup code notices and complains.
      
      So use TASK_INTERRUPTIBLE instead and make sure to flush signals
      before calling schedule.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      9744197c
    • R
      e100: Use pci_pme_active to clear PME_Status and disable PME# · e7272403
      Rafael J. Wysocki 提交于
      Currently e100 uses pci_enable_wake() to clear pending wake-up events
      and disable PME# during intitialization, but that function is not
      suitable for this purpose, because it immediately returns error code
      if device_may_wakeup() returns false for given device.
      
      Make e100 use pci_pme_active(), which carries out exactly the
      required operations, instead.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      e7272403
    • C
      e1000: prevent corruption of EEPROM/NVM · 78566fec
      Christopher Li 提交于
      Andrey reports e1000 corruption, and that a patch in vmware's ESX fixed
      it.
      
      The EEPROM corruption is triggered by concurrent access of the EEPROM
      read/write. Putting a lock around it solve the problem.
      
      [akpm@linux-foundation.org: use DEFINE_SPINLOCK to avoid confusing lockdep]
      Signed-off-by: NChristopher Li <chrisl@vmware.com>
      Reported-by: NAndrey Borzenkov <arvidjaar@mail.ru>
      Cc: Zach Amsden <zach@vmware.com>
      Cc: Pratap Subrahmanyam <pratap@vmware.com>
      Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
      Cc: Bruce Allan <bruce.w.allan@intel.com>
      Cc: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
      Cc: John Ronciak <john.ronciak@intel.com>
      Cc: Jeff Garzik <jeff@garzik.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      78566fec
    • Y
      forcedeth: call restore mac addr in nv_shutdown path · f55c21fd
      Yinghai Lu 提交于
      after
      
      | commit f735a2a1
      | Author: Tobias Diedrich <ranma+kernel@tdiedrich.de>
      | Date:   Sun May 18 15:02:37 2008 +0200
      |
      |    [netdrvr] forcedeth: setup wake-on-lan before shutting down
      |
      |    When hibernating in 'shutdown' mode, after saving the image the suspend hook
      |    is not called again.
      |    However, if the device is in promiscous mode, wake-on-lan will not work.
      |    This adds a shutdown hook to setup wake-on-lan before the final shutdown.
      |
      |    Signed-off-by: Tobias Diedrich <ranma+kernel@tdiedrich.de>
      |    Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
      
      my servers with nvidia ck804 and mcp55 will reverse mac address with kexec.
      
      it turns out that we need to restore the mac addr in nv_shutdown().
      
      [akpm@linux-foundation.org: fix typo in printk]
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Cc: Tobias Diedrich <ranma+kernel@tdiedrich.de>
      Cc: Ayaz Abdulla <aabdulla@nvidia.com>
      Cc: Jeff Garzik <jeff@garzik.org>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      f55c21fd
    • B
      bnx2: Promote vector field in bnx2_irq structure from u16 to unsigned int · 27ed9ddf
      Benjamin Li 提交于
      The bnx2 driver stores/uses the irq value from the pci_dev internally.
      But when it stores the irq value, it has been performing an
      integer demotion.  Because of the recent changes made to
      arch/x86/kernel/io_apic.c, the new method in creating the irq value
      (using build_irq_for_pci_dev()) has exposed this bug on x86 systems.
      
      Because of this demotion when calling request_irq() from
      bnx2_request_irq(), the driver would get a return code of -EINVAL.
      This is because the kernel could not find the requested irq descriptor.
      By storing the irq value properly, the kernel can find the correct
      irq descriptor and the bnx2 driver can operate normally.
      Signed-off-by: NBenjamin Li <benli@broadcom.com>
      Signed-off-by: NMichael Chan <mchan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      27ed9ddf