Distribution: Debian unstable
Hardware Environment: Dell Inspiron 8000, BIOS A21
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
Apr 22 09:02:45 localhost kernel: timer_do_blank_screen from_timer_handler 1, ve
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 (==
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  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
Nov 16 01:27:56 localhost kernel: [<c01ddd72>] acpi_ut_initialize_buffer+0x4e/0
Nov 16 01:27:56 localhost kernel: [<c01d8184>] acpi_rs_create_byte_stream+0x93/
Nov 16 01:27:56 localhost kernel: [<c01dad8d>] acpi_rs_set_srs_method_data+0x44
Nov 16 01:27:56 localhost kernel: [<c01d90fe>] acpi_set_current_resources+0x67/
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
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 ***