Messages in this thread Patch in this message | | | Date | Fri, 24 Aug 2007 20:30:00 -0700 | From | Andrew Morton <> | Subject | Re: 2.6.23-rc3-mm1 |
| |
On Sat, 25 Aug 2007 02:47:59 +0200 Tilman Schmidt <tilman@imap.cc> wrote:
> Am 25.08.2007 02:07 schrieb Andrew Morton: > > On Sat, 25 Aug 2007 01:27:25 +0200 > > Tilman Schmidt <tilman@imap.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? > > The one allowing drivers/scsi/advansys.c to compile with CONFIG_ISA=n: > > Date: Wed, 22 Aug 2007 10:28:02 -0600 > From: Matthew Wilcox <matthew@wil.cx> > Subject: Re: drivers/scsi/advansys.c - ld error ( Re: 2.6.23-rc3-mm1 ) > Message-ID: <20070822162802.GJ9163@parisc-linux.org> > > When CONFIG_ISA is disabled, the isa_driver support will not be compiled > in. Define stubs so that we don't get link-time errors.
oh, OK, I have 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 > > > > What architecture? > > i386. The machine is a Pentium D 940 which would be x86_64 capable, > but I'm still running 32 bit kernels on it.
OK.
> > 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. > > Will do that anyway.
It looks like you'll need to :(
> > Perhaps it would be helpful if you could do a > > > > diff -u dmesg-2.6.23-rc3 dmesg-2.6.26-rc3-mm1 > > I hope the attached helps. I created it by taking /var/log/boot.msg > of the two systems, removing everything after "Kernel logging stopped", > editing out the printk timestamps and then running diff -u on them, > so it should be more or less the dmesg diff. I did not edit out any > of the differences because I'm lazy. (And also because I wasn't so sure > what would or wouldn't be interesting for you.) >
--- /tmp/bootmsg-2.6.23-rc3 2007-08-25 02:25:54.000000000 +0200 > +++ /tmp/bootmsg-2.6.23-rc3-mm1 2007-08-25 02:26:08.000000000 +0200 > @@ -1,10 +1,10 @@ > > ... > > <6>..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 > -<6>checking TSC synchronization [CPU#0 -> CPU#1]: passed. > +<6>checking TSC synchronization [CPU#0 -> CPU#1]: > +<4>Measured 32 cycles TSC warp between CPUs, turning off TSC clock. > +<4>Marking TSC unstable due to: check_tsc_sync_source failed.
looky here.
> <6>Brought up 2 CPUs > <6>Booting paravirtualized kernel on bare hardware > <6>NET: Registered protocol family 16 > <6>ACPI: bus type pci registered > -<3>PCI: BIOS Bug: MCFG area at f0000000 is not E820-reserved > -<3>PCI: Not using MMCONFIG.
hm, I wonder if that's related.
> <6>PCI: Using configuration type 1 > <4>Setting up standard PCI resources > <7>ACPI: EC: Look up EC in DSDT > <6>ACPI: Interpreter enabled > <6>ACPI: (supports S0 S3) > <6>ACPI: Using IOAPIC for interrupt routing > +<5>PCI: MCFG configuration 0: base 4026531840 segment 0 buses 0 - 127 > +<5>PCI: MCFG area at f0000000 reserved in ACPI motherboard resources > +<6>PCI: Using MMCONFIG
we're using mmconfig
> <6>ACPI: PCI Root Bridge [PCI0] (0000:00) > +<7>PCI: Probing PCI hardware (bus 00) > <4>PCI quirk: region 0400-047f claimed by ICH6 ACPI/GPIO/TCO > <4>PCI quirk: region 0500-053f claimed by ICH6 GPIO > <6>PCI: Transparent bridge - 0000:00:1e.0 > @@ -285,7 +291,9 @@ > <6>NetLabel: protocols = UNLABELED CIPSOv4 > <6>NetLabel: unlabeled traffic allowed by default > <4>ACPI: RTC can wake from S4 > -<6>Time: tsc clocksource has been installed. > +<6>Time: hpet clocksource has been installed. > +<6>Switched to high resolution mode on CPU 0 > +<6>Switched to high resolution mode on CPU 1
No longer using tsc, using hpet instead. Slower.
> -<7>hpet_resources: 0xfed00000 is busy > +<4>hpet_acpi_add: no address or irqs in _CRS
oh boy
> +<4>thermal: Unknown symbol acpi_processor_set_thermal_limit
I think there are acpi fixes in Len's latest tree which will fix this.
> <6>Linux agpgart interface v0.102 > +<6>rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0 > +<4>rtc_cmos: probe of 00:03 failed with error -16 > +<6>agpgart: suspend/resume problematic: resume with 3D/DRI active may lockup X.Org > +<4>on some chipset/BIOS combos (see DEBUG_AGP_PM in intel-agp.c) > <6>agpgart: Detected an Intel 965Q Chipset. > <6>agpgart: Unknown page table size, assuming 512KB > <6>agpgart: Detected 7676K stolen memory. > <6>agpgart: AGP aperture is 256M @ 0x40000000 > -<6>rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0 > -<4>rtc_cmos: probe of 00:03 failed with error -16
I wonder if that was supposed to happen. It's also happening in 2.6.23-rc3 base.
I don't see anything there which would cause you to lose the clock setting, but there are obviously a few things going wrong in the time-management area here. Please explicity retest this stuff as the code evolves and kepp us informed of the problems.
Thanks. - 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/
| |