cvs commit: src/sys/dev/bge if_bge.c
nate at root.org
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
> 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