cvs commit: src/sys/dev/bge if_bge.c

[Nate Lawson]

Pawel Jakub Dawidek wrote:
> On Wed, Sep 28, 2005 at 12:31:14PM -0700, Nate Lawson wrote:
> +> Pawel Jakub Dawidek wrote:
> +> >pjd         2005-09-28 19:20:49 UTC
> +> >  FreeBSD src repository
> +> >  Modified files:
> +> >    sys/dev/bge          if_bge.c   Log:
> +> >  Implement suspend/resume methods to be more ACPI friendly.
> +> >  I'm able to suspend/resume my laptop without this change, but then I need
> +> >  to wait for the watchdog to reset the card.
> +> >  With this change, it is ready immediately.
> +> >    Glanced at by:  glebius
> +> >    Revision  Changes    Path
> +> >  1.96      +36 -0     src/sys/dev/bge/if_bge.c
> +> 
> +> Great, thanks!  To other developers with hardware that doesn't work for suspend/resume, this is the area that needs the most improvement.  There are known cases of at least 
> +> agp and apic breaking resume.
> 
> On my ThinkPad t43 suspend/resume works just fine in most cases, but
> sometimes (once every ~20 suspends) it stops before turning off LCD -
> the moon-led is turned on, but LCD is on as well and system freeze
> hard.
> What kind of debug can I add to track down the problem?
> Can we printf some steps done on suspend (which device's suspend method
> is called, etc.)?

I've heard disabling apic helps T42s, otherwise they get a hard hang. 
It's difficult to print the driver progress while suspending because the 
function call stack is recursive, not iterative.  For example, 
root_suspend -> pci_suspend -> fxp_suspend -> mii_suspend (if that 
exists).  You'd have to add a printf in every driver and bus.  A better 
way might be to add printf or KTR to bus_generic_suspend() to print the 
device name before calling its method.

BTW, I'm working on committing a patch that adds KTR to acpi so we can 
track down issues like this although the device suspending stuff should 
be done separately as listed above.

-- 
Nate