Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261275AbVALS43 (ORCPT ); Wed, 12 Jan 2005 13:56:29 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261249AbVALSyx (ORCPT ); Wed, 12 Jan 2005 13:54:53 -0500 Received: from grendel.digitalservice.pl ([217.67.200.140]:27096 "HELO mail.digitalservice.pl") by vger.kernel.org with SMTP id S261280AbVALSvs (ORCPT ); Wed, 12 Jan 2005 13:51:48 -0500 From: "Rafael J. Wysocki" To: Pavel Machek Subject: Re: 2.6.10-mm2: swsusp regression [update] Date: Wed, 12 Jan 2005 19:51:47 +0100 User-Agent: KMail/1.7.1 Cc: Andi Kleen , Linux Kernel Mailing List , ncunningham@linuxmail.org References: <20050106002240.00ac4611.akpm@osdl.org> <200501081610.57625.rjw@sisk.pl> <20050108154439.GA24771@elf.ucw.cz> In-Reply-To: <20050108154439.GA24771@elf.ucw.cz> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Message-Id: <200501121951.48102.rjw@sisk.pl> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1619 Lines: 54 H, On Saturday, 8 of January 2005 16:44, Pavel Machek wrote: [-- snip --] > > > > The regression is caused by the timer driver. Obviously, turning > > > > timer_resume() in arch/x86_64/kernel/time.c into a NOOP makes it go > > > > away. [-- snip --] > > > > > > ..you might want to look at i386 time code, they have common > > > ancestor, and i386 one seems to work. Well, I've changed timer_resume() in arch/x86_64/kernel/time.c into the following function: static int timer_resume(struct sys_device *dev) { unsigned long flags; unsigned long sec; unsigned long ctime = get_cmos_time(); long sleep_length = (ctime - sleep_start) * HZ; if (vxtime.hpet_address) hpet_reenable(); sec = ctime + clock_cmos_diff; write_seqlock_irqsave(&xtime_lock,flags); xtime.tv_sec = sec; xtime.tv_nsec = 0; write_sequnlock_irqrestore(&xtime_lock,flags); printk ("jiffies = %lu, sleep_length = %ld\n", jiffies, sleep_length); return 0; } and that's what I get from the log: Jan 12 19:43:42 albercik kernel: jiffies = 4294847120, sleep_length = -3189288131000 (for example - the second number is always negative and huge). Would it mean that get_cmos_time() needs fixing? Greets, RJW -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/