Re: ACPI problem

On  9 Dec, Nate Lawson wrote:
> Suspend/resume will continue to be a problem area for some time.  Perhaps
> I should put up a FAQ about this.
> 
> 1. Try different states (S1-S4) and see if one of them works.

My laptop only supports S3 and S4 and since we're missing the code to
handle S4 in the non-S4BIOS case ...

> 2. Try tunable/sysctl hw.acpi.reset_video=0
> 
> 3. Try tunable/sysctl hw.syscons.sc_no_suspend_vtswitch=1
> 
> 4. Try sysctl hw.acpi.sleep_delay=0
> 
> 5. Try the most recent Linux beta kernel with acpi configured.  If it
> works, then perhaps we can find why.  Since we share the ACPI-CA
> interpreter with Linux, it's likely that they have similar problems.
> 
> 6. Try disabling drivers that may break resume.  In particular, uhci
> doesn't work right after resume.

Resuming from S3 provokes "fatal error" type complaints from the fire
wire driver.  It also turns on my "an" device, even if it was off
before.  I think the latter is expected based on what Warner said the
other day about the state of the power control code.  The box locks up
pretty quickly after it resumes and displays the command prompt.

If I have some time, I'll try disabling stuff.

> 7. Try building the acpi kernel module with options ACPI_DEBUG, then
> setting debug.acpi.layer and debug.acpi.level sysctls to various levels of
> verbosity right before suspending/resuming.  Use a serial console to log
> the output.  Here are some proposed settings:
> 
>     debug.acpi.layer="ACPI_ALL_DRIVERS ACPI_ALL_COMPONENTS"
>     debug.acpi.level="ACPI_LV_IO"
> 
> -Nate
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"