From owner-freebsd-amd64@FreeBSD.ORG Tue Dec 2 17:43:30 2008 Return-Path: Delivered-To: freebsd-amd64@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id B022A1065676; Tue, 2 Dec 2008 17:43:29 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Alexander Motin Date: Tue, 2 Dec 2008 12:43:03 -0500 User-Agent: KMail/1.6.2 References: <1224616985.00027652.1224606603@10.7.7.3> <1224728582.00028075.1224715806@10.7.7.3> <4932F34C.1040804@FreeBSD.org> In-Reply-To: <4932F34C.1040804@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200812021243.08513.jkim@FreeBSD.org> Cc: freebsd-acpi@FreeBSD.org, freebsd-amd64@FreeBSD.org, peter@FreeBSD.org Subject: Re: Semi-working patch for amd64 suspend/resume X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2008 17:43:30 -0000 On Sunday 30 November 2008 03:10 pm, Alexander Motin wrote: > Hi. > > Alexander Motin wrote: > > Jung-uk Kim wrote: > >> I was working on suspend/resume support for amd64 and this is > >> the result. It works with a modified QEMU (QEMU does not > >> support S3) but real boxes that I have don't seem to like it > >> (e.g., broken BIOSes). If there is someone interested in > >> finishing it off or giving it a try, the patch is here: > >> > >> http://people.freebsd.org/~jkim/amd64_suspend.diff > > > > I have tried it on my Acer TM6292. S1/S2 are unsupported. On S3 > > system successfully got down, but on wakeup button, two seconds > > after power up, even without video initialization, it shut down, > > reset and then started usual boot. I have tried both original and > > updated BIOS, without any difference. > > > > Can I give you any other help? > > I have spent a day investigating the problem. I was inserting empty > infinite loop into the different points of wakeup process trying to > find the place where system reboots. I just haven't found any other > feedback channel as video is not initialized and beeper is not > working for some reason. > > As result, I have found, that if I am inserting: > qqq: > > jmp qqq > lines before line 98 of acpi_switch.S: > movl $MSR_MTRRdefType, %ecx > > movl WAKEUP_CTX(mtrr), %eax > > wrmsr > system hangs, but if I insert it just after them - system reboots. > > With just commenting this three lines I was able to get successful > suspend/resume with UP amd64 kernel!!! Good catch! I can confirm this is a correct bandaid. We cannot restore this MSR without restoring entire MTRR map. Actually, I should have written separate functions to save/restore all global MSRs. Only per-CPU MSRs should be embedded like that. > Here is problems I still have now: > - SMP kernel resume is not working, system reboots while doing > acpi_wakeup_cpus(); My dual-core CPU seems to resume okay but quite unstable. Can you try something like the following in amd64/mp_machdep.c and tell me if it helps? ------------ @@ -57,6 +57,7 @@ #include #include +#include #include #include #include @@ -1121,6 +1121,8 @@ int cpumask = PCPU_GET(cpumask); if (savectx2(&stopxpcbs[cpu])) { + /* Flush CPU cache. */ + wbinvd(); /* Indicate that we are suspended. */ atomic_set_int(&stopped_cpus, cpumask); } else { ------------ > - text mode video does not restores on resume, while Xorg graphic > one does. hw.acpi.reset_video=1 does not help, it just hanging > resume process. It is very common problem for modern video cards. We cannot do much here without help of GPU-specific routines (e.g., ATI ATOM BIOS parser for RadeonHD) or in-kernel realmode emulation[1] (e.g., NetBSD). Thanks for the feedback! Jung-uk Kim [1] http://cvsweb.netbsd.org/bsdweb.cgi/src/common/lib/libx86emu/ http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/x86/x86/vga_post.c