1. 23 4月, 2008 34 次提交
  2. 16 4月, 2008 1 次提交
  3. 09 4月, 2008 2 次提交
  4. 06 4月, 2008 1 次提交
  5. 02 4月, 2008 1 次提交
    • R
      ACPI PM: Restore the 2.6.24 suspend ordering · 7731ce63
      Rafael J. Wysocki 提交于
      Some time ago it turned out that our suspend code ordering broke some
      NVidia-based systems that hung if _PTS was executed with one of the PCI
      devices, specifically a USB controller, in a low power state.
      
      Then, it was noticed that the suspend code ordering was not compliant
      with ACPI 1.0, although it was compliant with ACPI 2.0 (and later), and
      it was argued that the code had to be changed for that reason (ref.
      http://bugzilla.kernel.org/show_bug.cgi?id=9528).
      
      So we did, but evidently we did wrong, because it's now turning out that
      some systems have been broken by this change. Refs:
      	http://bugzilla.kernel.org/show_bug.cgi?id=10340
      	https://bugzilla.novell.com/show_bug.cgi?id=374217#c16
      
      [ I said at that time that something like this might happend, but the
        majority of people involved thought that it was improbable due to the
        necessity to preserve the compliance of hardware with ACPI 1.0. ]
      
      This actually is a quite serious regression from 2.6.24.
      
      Moreover, the ACPI 1.0 ordering of suspend code introduced another issue
      that I have only noticed recently.  Namely, if the suspend of one of
      devices fails, the already suspended devices will be resumed without
      executing _WAK before, which leads to problems on some systems (for
      example, in such situations thermal management is broken on my HP
      nx6325).  Consequently, it also breaks suspend debugging on the affected
      systems.
      
      Note also, that the requirement to execute _PTS before suspending
      devices does not really make sense, because the device in question may
      be put into a low power state at run time for a reason unrelated to a
      system-wide suspend.
      
      For the reasons outlined above, the change of the suspend ordering
      should be reverted, which is done by the patch below.
      
      [ Felix Möller: "I am the reporter from the original Novell Bug:
      
      	https://bugzilla.novell.com/show_bug.cgi?id=374217
      
        I just tried current git head (two hours ago) with the patch (the one
        from the beginning of this thread) from Rafael and without it.  With
        the patch my MacBook does suspend without it does not." ]
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Tested-by: NFelix Möller <felix@derklecks.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7731ce63
  6. 29 3月, 2008 1 次提交
    • I
      revert "ACPI: drivers/acpi: elide a non-zero test on a result that is never 0" · 48d3d826
      Ingo Molnar 提交于
      Revert commit 1192aeb9 ("ACPI:
      drivers/acpi: elide a non-zero test on a result that is never 0")
      because it turns out that thermal_cooling_device_register() does
      actually return NULL if CONFIG_THERMAL is turned off (then the routine
      turns into a dummy inline routine in the header files that returns NULL
      unconditionally).
      
      This was found with randconfig testing, causing a crash during bootup:
      
        initcall 0x78878534 ran for 13 msecs: acpi_button_init+0x0/0x51()
        Calling initcall 0x78878585: acpi_fan_init+0x0/0x2c()
        BUG: unable to handle kernel NULL pointer dereference at 00000000
        IP: [<782b8ad0>] acpi_fan_add+0x7d/0xfd
        *pde = 00000000
        Oops: 0000 [#1]
        Modules linked in:
      
        Pid: 1, comm: swapper Not tainted (2.6.25-rc7-sched-devel.git-x86-latest.git #14)
        EIP: 0060:[<782b8ad0>] EFLAGS: 00010246 CPU: 0
        EIP is at acpi_fan_add+0x7d/0xfd
        EAX: b787c718 EBX: b787c400 ECX: b782ceb4 EDX: 00000007
        ESI: 00000000 EDI: b787c6f4 EBP: b782cee0 ESP: b782cecc
         DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
        Process swapper (pid: 1, ti=b782c000 task=b7846000 task.ti=b782c000)
        Stack: b787c459 00000000 b787c400 78790888 b787c60c b782cef8 782b6fb8 ffffffda
               b787c60c 00000000 78790958 b782cf0c 783005d7 b787c60c 78790958 78790584
               b782cf1c 783007f6 b782cf28 00000000 b782cf40 782ffc4a 78790958 b794d558
        Call Trace:
         [<782b6fb8>] ? acpi_device_probe+0x3e/0xdb
         [<783005d7>] ? driver_probe_device+0x82/0xfc
         [<783007f6>] ? __driver_attach+0x3a/0x70
         [<782ffc4a>] ? bus_for_each_dev+0x3e/0x60
         [<7830048c>] ? driver_attach+0x14/0x16
         [<783007bc>] ? __driver_attach+0x0/0x70
         [<7830006a>] ? bus_add_driver+0x9d/0x1b0
         [<783008c3>] ? driver_register+0x47/0xa3
         [<7813db00>] ? timespec_to_ktime+0x9/0xc
         [<782b7331>] ? acpi_bus_register_driver+0x3a/0x3c
         [<78878592>] ? acpi_fan_init+0xd/0x2c
         [<78863656>] ? kernel_init+0xac/0x1f9
         [<788635aa>] ? kernel_init+0x0/0x1f9
         [<78114563>] ? kernel_thread_helper+0x7/0x10
         =======================
        Code: 6e 78 e8 57 44 e7 ff 58 e9 93 00 00 00 8b 55 f0 8d bb f4 02 00 00 80 4b 2d 10 8b 03 e8 87 cb ff ff 8d 83 18 03 00 00 80 63 2d ef <ff> 35 00 00 00 00 50 68 e8 9c 6e 78 e8 22 44 e7 ff b9 b6 9c 6e
        EIP: [<782b8ad0>] acpi_fan_add+0x7d/0xfd SS:ESP 0068:b782cecc
        ---[ end trace 778e504de7e3b1e3 ]---
        Kernel panic - not syncing: Attempted to kill init!
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NJulia Lawall <julia@diku.dk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      48d3d826