Distribution: Debian unstable Hardware Environment: Dell Inspiron 8000, BIOS A21 Software Environment: Problem Description: Doing echo "1" >/proc/acpi/sleep puts some nice messages about sleep state to the screen, but the screen doesn't get shut off. Instead the screen blanks *after* the sleep state (sleeping IS working, other than that), when resuming. This can be very annoying, of course ;) The only way to get back a working screen is to start X11. But the only way to regain a working console screen is to have X11 started *before* doing the sleep. Otherwise X11 won't have stored the working console screen backlight state and thus won't restore the enabled text console backlight.
Even the console ACPI screen blanking is broken: when the screen is supposed to blank, the screen content gets erased, but the backlight doesn't get switched off, resulting in a strange "brightened" pattern on the screen. Hitting a key unblanks the screen properly. So screen blanking in general seems to be broken; I'll try to find out about it.
OK, after some poking around, it seems like ACPI display suspend simply isn't working properly. Apr 22 09:02:45 localhost kernel: timer_do_blank_screen from_timer_handler 1, ve sa_off_interval 60000 Apr 22 09:02:45 localhost kernel: vgacon_blank 1 Apr 22 09:02:45 localhost kernel: VESA blank mode 1 Apr 22 09:02:45 localhost kernel: vgacon_blank 2 Apr 22 09:03:45 localhost kernel: VESA down Apr 22 09:03:45 localhost kernel: vgacon_blank 4 Apr 22 09:04:03 localhost kernel: unblank console_blanked 10, blankinterval 6000 0, console_blank_hook 00000000 Apr 22 09:04:03 localhost kernel: vgacon_blank 0 This indicates that after timer expire, it blanks the screen (vgacon_blank 1), then it does a VESA_VSYNC_SUSPEND (vgacon_blank 2), and finally after another minute it calls vesa_powerdown() and thus vga_vesa_blank() with 3 (== VESA_VSYNC_SUSPEND|VESA_HSYNC_SUSPEND). Why my notebook doesn't switch off the backlight when both HSYNC and VSYNC is missing is beyond me, though. Hmm, I guess I might have to take some VGA register samples in Win98...
After talking to some people about how Windows does this, I believe that ACPI is not responsible for turning off the backlight -- the gfx driver is.
Please try the tools in bug 3670.
YES! That did it!! (together with choosing 2.6.10-rc2, since it didn't work with a slightly earlier version, 2.6.10-rc1-mm5, perhaps due to the virt<->phys resume vector fix that got included recently and which I had found and reported to an ACPI developer about one year earlier with no useful reaction :-\) Thanks for such useful tools! Now I'm having severe issues with harddisk DMA setup: I can only resume successfully with multi-sector access disabled (hdparm -m0), and on resume hdparm -d shows that DMA got disabled (by the kernel! no user request! unless acpid did that, but there doesn't seem to be any acpid event script registered for that...). Redoing -m16 after resume works ok, but -d1 causes DMA errors which even **COMPLETELY** hang the machine: DMA error 0x21, then "DMA timeout error" - in this very moment BOOM, nothing works, not even SysRq, only 100% CPU: cooling fan activating, and when going to the log console (right before the fatal DMA activation) it didn't show any additional crash entries. Conclusion: HDD suspend/resume handler broken, since it doesn't reactivate the HDD properly to work with reenabled DMA? Conclusion 2: harddisk error recovery is VERY broken, since it enters an eternal and completely fatal loop on DMA timeout error... Also, immediately after echo 3 >/proc/acpi/sleep, I get: Nov 16 01:27:56 localhost kernel: hwsleep-0312 [05] acpi_enter_sleep_state: Ent ering sleep state [S3] Nov 16 01:27:56 localhost kernel: Debug: sleeping function called from invalid c ontext at mm/slab.c:2055 Nov 16 01:27:56 localhost kernel: in_atomic():0, irqs_disabled():1 Nov 16 01:27:56 localhost kernel: [<c01035c7>] dump_stack+0x17/0x20 Nov 16 01:27:56 localhost kernel: [<c01163f6>] __might_sleep+0xb6/0xe0 Nov 16 01:27:56 localhost kernel: [<c013bdda>] __kmalloc+0x9a/0xb0 Nov 16 01:27:56 localhost kernel: [<c01ba8d8>] acpi_os_allocate+0xd/0xf Nov 16 01:27:56 localhost kernel: [<c01dded1>] acpi_ut_callocate+0x6b/0xd4 Nov 16 01:27:56 localhost kernel: [<c01ddfb3>] acpi_ut_callocate_and_track+0x1c /0x7d Nov 16 01:27:56 localhost kernel: [<c01ddd72>] acpi_ut_initialize_buffer+0x4e/0 x98 Nov 16 01:27:56 localhost kernel: [<c01d8184>] acpi_rs_create_byte_stream+0x93/ 0xfb Nov 16 01:27:56 localhost kernel: [<c01dad8d>] acpi_rs_set_srs_method_data+0x44 /0xf3 Nov 16 01:27:56 localhost kernel: [<c01d90fe>] acpi_set_current_resources+0x67/ 0x81 Nov 16 01:27:56 localhost kernel: [<c01ea616>] acpi_pci_link_set+0x187/0x2b3 Nov 16 01:27:56 localhost kernel: [<c01eac06>] acpi_pci_link_resume+0x47/0x7d Nov 16 01:27:56 localhost kernel: [<c01eac81>] irqrouter_resume+0x45/0x6d Nov 16 01:27:56 localhost kernel: [<c021b87f>] sysdev_resume+0x12f/0x134 Nov 16 01:27:56 localhost kernel: [<c021f558>] device_power_up+0x8/0xe Nov 16 01:27:56 localhost kernel: [<c0131013>] suspend_enter+0x33/0x50 Nov 16 01:27:56 localhost kernel: [<c01310bb>] enter_state+0x5b/0x90 Nov 16 01:27:56 localhost kernel: [<c01e28a6>] acpi_suspend+0x3d/0x4b Nov 16 01:27:56 localhost kernel: [<c01e2cdd>] acpi_system_write_sleep+0x64/0x7 6 Nov 16 01:27:56 localhost kernel: [<c014fa82>] vfs_write+0xa2/0x100 Nov 16 01:27:56 localhost kernel: [<c014fb91>] sys_write+0x41/0x70 Nov 16 01:27:56 localhost kernel: [<c010306b>] syscall_call+0x7/0xb Oh well, maybe this should all go into new reports... Anyway, let me know what you think of it. Thanks for all your hard work! Andreas Mohr, acx100 wireless driver developer
I'd like mark this bug as a duplicate of 3670, since the track is about video. For your HDD problem, please open a new track. For the resume oops, there is a patch in bug 3469, please try it. I'll add you in the cc list of bug 3469 (we can't mark one bug as two bugs' duplicate :-) *** This bug has been marked as a duplicate of 3670 ***