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

[Nate Lawson]

[moved to acpi@]

On Thu, 15 Apr 2004, Kevin Oberman wrote:
> > 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:
> > > >   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.

Please send output of vmstat -i after a resume (but before the hang,
obviously).

> 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.)

Things have likely not changed.  This does sound like a resource issue.
Output from dmesg with it loaded at boot time and then loaded later would
help.

-Nate