From owner-freebsd-acpi@FreeBSD.ORG Wed Jun 15 21:44:12 2005 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 434A816A41C for ; Wed, 15 Jun 2005 21:44:12 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0D4043D49 for ; Wed, 15 Jun 2005 21:44:11 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.231] (Not Verified[216.133.140.1]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Wed, 15 Jun 2005 17:57:35 -0400 From: John Baldwin To: freebsd-acpi@freebsd.org Date: Wed, 15 Jun 2005 16:38:14 -0400 User-Agent: KMail/1.8 References: <200506032012.j53KCC5k077879@repoman.freebsd.org> <42B06B2D.4010600@centtech.com> <42B08B57.6010203@root.org> In-Reply-To: <42B08B57.6010203@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506151638.15687.jhb@FreeBSD.org> Cc: Subject: Re: cvs commit: src/sys/dev/acpica acpi.c X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2005 21:44:12 -0000 On Wednesday 15 June 2005 04:11 pm, Nate Lawson wrote: > Eric Anderson wrote: > >>>> Ok - I've narrowed it down. A GENERIC kernel will go into S3 just > >>>> fine on this laptop. Removing apic from the kernel will break that. > > It is interesting that the suspend path without the apic support causes > a hang for you. This should be investigated. Does it work if you have > apic compiled in but boot with hint.apic.0.disabled="1" ? Any ideas > where to look John? Not for the !APIC case, no. It would probably be good to get that working first before trying to work on the APIC case. Perhaps the ioapic resume code is using locks when it shouldn't though. Is it not safe to grab a spin lock when intr_resume() is called? > >>> ioapic_suspend: not implemented! > >>> ioapic_suspend: not implemented! > > I still think this needs to be implemented although it's not likely to > be your problem. Actually, we already reprogram all the APIC intpins on resume in ioapic_resume() from saved state. There's actually not anything for ioapic_suspend() to do, so I've mostly left this as a marker until the current resume code is tested. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org