Bug 605

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 ***