Date: Fri, 16 Apr 2004 08:38:15 -0700 From: "Kevin Oberman" <oberman@es.net> To: Nate Lawson <nate@root.org> Cc: acpi@freebsd.org Subject: Re: cvs commit: src/sys/contrib/dev/acpica hwsleep.c Message-ID: <20040416153815.A0C685D07@ptavv.es.net> In-Reply-To: Your message of "Thu, 15 Apr 2004 16:20:46 PDT." <20040415161841.A92883@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Thu, 15 Apr 2004 16:20:46 -0700 (PDT) > From: Nate Lawson <nate@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@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@es.net Phone: +1 510 486-8634
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040416153815.A0C685D07>