[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1188001291.6163.36.camel@localhost.localdomain>
Date: Fri, 24 Aug 2007 17:21:31 -0700
From: john stultz <johnstul@...ibm.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Tilman Schmidt <tilman@...p.cc>, linux-kernel@...r.kernel.org,
Thomas Gleixner <tglx@...utronix.de>, Andi Kleen <ak@...e.de>,
Len Brown <lenb@...nel.org>, linux-acpi@...r.kernel.org,
Dave Jones <davej@...emonkey.org.uk>,
Thomas Renninger <trenn@...e.de>,
Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>
Subject: Re: 2.6.23-rc3-mm1
On Fri, 2007-08-24 at 17:07 -0700, Andrew Morton wrote:
> On Sat, 25 Aug 2007 01:27:25 +0200
> Tilman Schmidt <tilman@...p.cc> wrote:
>
> > Am 22.08.2007 11:06 schrieb Andrew Morton:
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/
> >
> > After applying Matthew Wilcox' patch to include/linux/isa.h
>
> which patch is that?
>
> > this compiles
> > and boots on my Intel/openSUSE 10.2 test machine but throws out the
> > following messages I don't remember ever seeing with other kernels:
> >
> > - on console early during boot, also in SuSE's /var/log/boot.msg:
> >
> > your system time is not correct:
> > Wed Jul 13 13:15:31 UTC 1910
> > setting system time to:
> > Tue Jul 24 00:00:00 UTC 2007
Hrmm. I'm not super familiar w/ SuSE's init scripts, but I'm guessing
that's the ntpdate call. And "Tuesday Jul 24th"? Sounds about a month
off, is this just stale info?
> What architecture?
>
> if x86_64 then perhaps something went wrong with the old x86_64 dynticks
> leftovers which were in rc3-mm1. I've just merged a shiny fresh new series
> so perhaps things there got fixed. Please retest next -mm.
>
[snip]
> > - from fsck during boot:
> >
> > /dev/system/root: Superblock last mount time is in the future. FIXED.
> > /dev/system/root: Superblock last write time is in the future. FIXED.
>
> Presumably related to the time problem.
Does this show up before or after the above date stuff?
Does the issue go away using an older kernel (I want to eliminate easy
stuff like CMOS batteries giving up)?
Also you're not using Linus' CMOS corrupting suspend/resume debugging
trick, right (I'm forgetting the CONFIG name).
thanks
-john
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists