From owner-cvs-src@FreeBSD.ORG Thu Apr 15 08:13:26 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A0CC516A4CE; Thu, 15 Apr 2004 08:13:26 -0700 (PDT) Received: from postal3.es.net (postal3.es.net [198.128.3.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A37B43D31; Thu, 15 Apr 2004 08:13:26 -0700 (PDT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id IBA74465; Thu, 15 Apr 2004 08:13:25 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 8888A5D07; Thu, 15 Apr 2004 08:13:25 -0700 (PDT) To: Nate Lawson In-reply-to: Your message of "Wed, 14 Apr 2004 22:42:29 PDT." <20040414223743.V87135@root.org> Date: Thu, 15 Apr 2004 08:13:25 -0700 From: "Kevin Oberman" Message-Id: <20040415151325.8888A5D07@ptavv.es.net> cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/contrib/dev/acpica hwsleep.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2004 15:13:26 -0000 > Date: Wed, 14 Apr 2004 22:42:29 -0700 (PDT) > From: Nate Lawson > > 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@es.net Phone: +1 510 486-8634