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