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

[Kevin Oberman]

> Date: Thu, 15 Apr 2004 16:20:46 -0700 (PDT)
> From: Nate Lawson <nate at root.org>
> 
> [moved to acpi@]

Sorry. I should have moved my reply here. Thanks for moving it where it
belongs. 

> 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'm unsure why you add "obviously". It's only irq11 that fails. The
system remains up and runs fine (except for the relevant
devices). vmstat -i after the irq11 failure simply shows the count for
irq11 as unchanging. That's how I determined that irq11 had died.

Here is a vmstat at the moment. The system has been suspended and
resumed. Everything working. Audio playing (so I can know immediately
when it fails). The audio makes the rate rather high. It's normally
around 2 or 3. Other interrupts look about like I'd expect.

interrupt                          total       rate
irq0: clk                         258992         99
irq1: atkbd0                        1556          0
irq8: rtc                         331508        127
irq9: acpi0                         2389          0
irq11: pcm0 cbb0+++                78521         30
irq12: psm0                        14732          5
irq13: npx0                            1          0
irq14: ata0                        15421          5
irq15: ata1                           72          0
Total                             703192        271

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

They are attached. The dmesg-with-pcm is with snd_pcm and snd_ich loaded
at boot time. Sound does not work. (I just realized that the "(no driver
attached)" message is actually from the pci driver and is for the
WinModem and not part of the problem.)

The dmesg-no-pcm is a boot without the drivers loaded. I then added
snd_pcm (which produced no messages) and snd_ich. Very different from
the probe in the first file! Then I suspended and resumed.

And now I am waiting for it to fail. Before I set hw.pci.do_powerstate
to 1, the failure was almost immediate. I don't think it ever lasted
more than 5 minutes. With do_powerstates I have had only a single
failure. That one was over an hour after the resume. So I have no idea
when (if?) it will fail this time.

When it has failed, is there anything you would like me to do?

Thanks!
-- 
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