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

Nate Lawson nate at
Wed Sep 28 13:36:52 PDT 2005

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.


More information about the cvs-src mailing list