From owner-freebsd-current@FreeBSD.ORG Sat Jul 15 21:57:01 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE8FB16A4E1 for ; Sat, 15 Jul 2006 21:57:01 +0000 (UTC) (envelope-from nate@root.org) Received: from ylpvm01.prodigy.net (ylpvm01-ext.prodigy.net [207.115.57.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76B3D43D68 for ; Sat, 15 Jul 2006 21:56:59 +0000 (GMT) (envelope-from nate@root.org) X-ORBL: [71.139.3.149] Received: from [10.0.5.51] (ppp-71-139-3-149.dsl.snfc21.pacbell.net [71.139.3.149]) by ylpvm01.prodigy.net (8.13.7 out spool5000 dk/8.13.7) with ESMTP id k6FLujoF024803; Sat, 15 Jul 2006 17:56:45 -0400 Message-ID: <44B96490.9040907@root.org> Date: Sat, 15 Jul 2006 14:56:32 -0700 From: Nate Lawson User-Agent: Thunderbird 1.5.0.2 (X11/20060501) MIME-Version: 1.0 To: Sam Leffler References: <44B59A22.7000407@root.org> <44B5A2A3.2070702@errno.com> In-Reply-To: <44B5A2A3.2070702@errno.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current Subject: Re: cbb hangs during suspend if ath card active X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2006 21:57:01 -0000 Sam Leffler wrote: > Nate Lawson wrote: >> I've seen a recent regression in the past few months when suspending my >> laptop. When I have an ath0 card inserted in a cardbus slot and then >> press the sleep button, the system hangs. If I eject the card, it >> continues going into suspend and everything works as normal. > > A more likely scenario is that ath_stop is putting the card into "deep > sleep". At that point you cannot touch any of the PCI domain registers > for the card w/o bringing it out of sleep. If you do then the > pci/cardbus will hang. Ejecting the card removes the device from the > bus and allows things to continue. > > I walked through this scenario with Ed Maste when he mentioned it to me > and we tried to catch ath being entered after it set the card to sleep > but failed. Note that something as simple as checking for ath_intrpend > at the top of ath_intr can cause this but after shuffling code to ensure > this does not occur we still couldn't catch what was going on. > > My suggestion is you work under the above assumption and try to catch > entry to the ath driver. I still think the problem is a shared irq > interrupting after ath_stop puts the card to sleep. I did a little more debugging. Commenting out the ath_hal_setpower() call solves it (as you suggested). The interesting thing is that it doesn't hang right when that call is made (in ath_stop_locked()) or when the ATH_LOCK is dropped (in ath_stop()), but before the ath_suspend() function returns. That does seem to indicate that it is an interrupt occurring and not some other kernel subsystem accessing its config registers. I'll look at the irq handler next. Shouldn't a flag be set before returning from ath_stop() that says "ignore interrupts without touching hw"? Perhaps sc->sc_invalid? -- Nate