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

[John Baldwin]

On Wednesday 28 September 2005 04:36 pm, Nate Lawson wrote:
> 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.

BTW, the issue with APIC on some systems is that when we use the APIC, the 
current code doesn't end up doing suspend/resume for the ATPIC and so it ends 
up in some random state.

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org