From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 5 05:45:33 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 A5AE316A420 for ; Wed, 5 Oct 2005 05:45:33 +0000 (GMT) (envelope-from kjelderg@gmail.com) Received: from qproxy.gmail.com (qproxy.gmail.com [72.14.204.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE60A43D53 for ; Wed, 5 Oct 2005 05:45:32 +0000 (GMT) (envelope-from kjelderg@gmail.com) Received: by qproxy.gmail.com with SMTP id o12so94190qba for ; Tue, 04 Oct 2005 22:45:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jq1nuP6thhV9ePEO9B2fhsEuOGPefJNp2NESRksWJKh7Kfz+dENg/KM16vbkXy5NL2SSNRHqoTQKMhxON5HjmRsNL1fcD7pyQcj4/U1h+tIv0npMJUWMY/C6PZfdNveom3YT1WfaMcmelZtfydHro0ujKXzZNgQ8MFSA2v2IlT8= Received: by 10.64.204.6 with SMTP id b6mr37837qbg; Tue, 04 Oct 2005 14:32:31 -0700 (PDT) Received: by 10.65.35.19 with HTTP; Tue, 4 Oct 2005 14:32:30 -0700 (PDT) Message-ID: Date: Wed, 5 Oct 2005 06:32:30 +0900 From: Eric Kjeldergaard To: Eric Anderson In-Reply-To: <4342A9E6.3020701@centtech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <434286E0.6020708@centtech.com> <20051004160118.3f2050d4@localhost> <43428C42.2020806@centtech.com> <4342A1FB.5020301@root.org> <4342A9E6.3020701@centtech.com> Cc: freebsd-acpi@freebsd.org Subject: Re: Sony VAIO - suspend/resume works, but SLOW X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eric Kjeldergaard List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2005 05:45:33 -0000 On 10/5/05, Eric Anderson wrote: > Nate Lawson wrote: > > Eric Anderson wrote: > > > >> Fabian Keil wrote: > >> > >>> > >>> If I didn't overlook it, your kernel lacks "device pmtimer". > >>> Without it, I get the symptoms you described. > >> > >> > >> > >> Right you are. I've just added it - rebuilding kernel now. > >> > >> How are others keeping their custom kernel config up-to-date? This > >> seems like a real issue to me, unless there's a tool to do this > >> already and I'm just not using it. I cp GENERIC, make my changes, and > >> move on. As my machine tracks -CURRENT, the GENERIC kernel changes, > >> but my custom config stays the same (I never 'merge' any changes in). > >> > >> Thanks Fabian for the hint.. > > > > > > My kernel config begins with: > > > > include GENERIC > > nodevice aac > > etc. > > > > Check out the PAE kernel config to see the syntax. > > > > Thanks - I'll give that a try, seems like an elegant solution. > > Back to the original subject - I've added the pmtimer to my kernel, and > now it does resume and act normal - yea! > > A couple things I noticed now: > - after resume, system won't reboot. It goes through the entire > process, but stops after the "Rebooting...". I have to manually power > off the machine, and power it back on. > > - when in X, and I do acpiconf -s3, it does indeed suspend. Resuming > appears to be coming back, but my xwindows is locked up (no mouse > movement, no screen updates, and a little screen distortion at the top - > so a video driver issue?). My caps lock and num lock keys seemed to > work, but I couldn't break from X. I think did the (not so smart) break > to debugger, which left me in a state I couldn't recover from. Reboot > ensued. I have a Radeon card in this laptop. > > So two questions: > When does one need the reset_video switch on/off? > > What's the next logical step in debugging this? One thing that I wonder immediately is if you have DRI being used in X. If so, it tends to lock on resume. Otherwise many people have success twiddling with the sysctl hw.syscons.sc_no_suspend_vtswitch and hw.acpi.reset_video . I'm not sure the actual rules for when these work although the reset_video one says: Call the VESA reset BIOS vector on the resume path . I guess I would assume this to be a quirk workaround. Best of luck, Eric -- If I write a signature, my emails will appear more personalised.