cvs commit: src/sys/contrib/dev/acpica hwsleep.c

[Kevin Oberman]

> Date: Wed, 14 Apr 2004 22:42:29 -0700 (PDT)
> From: Nate Lawson <nate at root.org>
> 
> On Wed, 14 Apr 2004, Kevin Oberman wrote:
> > > njl         2004/04/14 09:52:19 PDT
> > >
> > >   FreeBSD src repository
> > >
> > >   Modified files:
> > >     sys/contrib/dev/acpica hwsleep.c
> > >   Log:
> > >   Even though the patch has been submitted to the vendor, this file is off
> > >   the vendor branch.  Once more, with feeling!
> >
> > Boy, my timing suck of late. I just rebuilt my system to see if
> > unloading and loading the sound driver would fix my
> > sound-too-fast-after-resume problem. To my amazement, using the loadable
> > drivers I no longer had the problem. I did all sorts of testing to try
> > to figure out why this would make a difference. Then I decided to catch
> > up on cvs-all.
> >
> > Thanks, Nate. This fixes the sound problem on my T30. My only remaining
> > issue is turning off the @#$% back-light! (Not that there might not be
> > other issues I have not hit.)
> 
> I can't see how this commit fixes your sound problem.  Are you
> loading/unloading the device drivers (i.e. via /etc/rc.suspend,resume)?
> I could see that helping.  Or is the problem fixed even without doing
> that?

It is fixed WITHOUT doing that.

I built a new kernel without "device pcm" and manually loaded the
driver.  I then suspended and resumed. Prior to you last round of
updates (and one patch from Warner that did not appear to be related to
this), the sound would work after the system resumed, but would run at
about 52K, it's raw speed, rather than at the desired 48K.

Now the sound works fine after a resume.

Unfortunately, after I sent this message and over an hour after the
system had been resumed, irq11 failed again. All devices using irq11
simply stopped working including the network and sound devices. This
delay completely baffles me. I can see why there might be interrupt
issues after a resume, but I can't imagine why interrupts would work for
an hour and then fail. 

And only irq11. All other interrupts are fine. That does kind of make
sense as that irq is the one shared by multiple devices.

I also now see that if I either load the driver at boot time (from
loader.conf) or build it into the kernel, the driver fails to
attach. The probe returns "(no driver attached)". I think this is
attributable to Warner's last PCI patch. Perhaps that is responsible for
the change in the sound behavior, as well. (Noto Bene! When I say his last
patch, I refer to the one late yesterday morning. I have not cvsuped
today and have not checked out either current@ or cvs-all@, so things
may have changed by now.)

> > First rule of troubleshooting...change only one variable at a time!
> > Learned that over 30 year ago, but still ignore it too often.
> 
> It's often difficult to sit down and come up with the optimal test plan
> (for instance, binary search) and then stick to it.  Usually after a
> while, the temptation is too great to just try what you think will fix it
> and then get lost in random, duplicative tests.  I think this is related
> to the high we get from succeeding in record time due to intuition.  Of
> course, we don't later remember the hours spent pursuing unfruitful
> intuitions and compare, we only remember the good ones.  :-)

Exactly!

Thanks again for all of your help.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634