1. 13 Apr, 2009 17 commits
  2. 12 Apr, 2009 9 commits
  3. 11 Apr, 2009 3 commits
    • Linus Torvalds's avatar
      Revert "ACPI battery: fix async boot oops" · b0cbc861
      Linus Torvalds authored
      This reverts commit 5d38258e, since the
      underlying problem got fixed properly in the previous commit ("async:
      Fix module loading async-work regression").
      
      Cc: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com>
      Cc: Vegard Nossum <vegard.nossum@gmail.com>
      Cc: Len Brown <len.brown@intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b0cbc861
    • Linus Torvalds's avatar
      async: Fix module loading async-work regression · d6de2c80
      Linus Torvalds authored
      Several drivers use asynchronous work to do device discovery, and we
      synchronize with them in the compiled-in case before we actually try to
      mount root filesystems etc.
      
      However, when compiled as modules, that synchronization is missing - the
      module loading completes, but the driver hasn't actually finished
      probing for devices, and that means that any user mode that expects to
      use the devices after the 'insmod' is now potentially broken.
      
      We already saw one case of a similar issue in the ACPI battery code,
      where the kernel itself expected the module to be all done, and unmapped
      the init memory - but the async device discovery was still running.
      That got hacked around by just removing the "__init" (see commit
      5d38258e "ACPI battery: fix async boot
      oops"), but the real fix is to just make the module loading wait for all
      async work to be completed.
      
      It will slow down module loading, but since common devices should be
      built in anyway, and since the bug is really annoying and hard to handle
      from user space (and caused several S3 resume regressions), the simple
      fix to wait is the right one.
      
      This fixes at least
      
      	http://bugzilla.kernel.org/show_bug.cgi?id=13063
      
      but probably a few other bugzilla entries too (12936, for example), and
      is confirmed to fix Rafael's storage driver breakage after resume bug
      report (no bugzilla entry).
      
      We should also be able to now revert that ACPI battery fix.
      Reported-and-tested-by: default avatarRafael J. Wysocki <rjw@suse.com>
      Tested-by: default avatarHeinz Diehl <htd@fancy-poultry.org>
      Acked-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d6de2c80
    • David Woodhouse's avatar
      intel-iommu: Avoid panic() for DRHD at address zero. · e523b38e
      David Woodhouse authored
      If the BIOS does something obviously stupid, like claiming that the
      registers for the IOMMU are at physical address zero, then print a nasty
      message and abort, rather than trying to set up the IOMMU and then later
      panicking.
      
      It's becoming more and more obvious that trusting this stuff to the BIOS
      was a mistake.
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      e523b38e
  4. 10 Apr, 2009 11 commits