Hi there,
My earlier question regarding the glibc "make check" nptl/tst-clock2.c
failure turns out to be due to my system clock running 3x normal speed.
Evidently, this is a known issue with 2.6.x kernels running on AMD 64
processors. The "noapic" boot option fixes the clock problem, but disrupts
other things... ethernet does work, etc. The solution seems to be using
"apci=noirq noapic" as boot options.
I am using the 2.6.14.2 kernel, and still need to use those boot parameters.
What is the current state of this bug?
-Janis
On Fri, 2005-11-18 at 20:01 -0500, [email protected] wrote:
> Hi there,
>
> My earlier question regarding the glibc "make check" nptl/tst-clock2.c
> failure turns out to be due to my system clock running 3x normal speed.
>
> Evidently, this is a known issue with 2.6.x kernels running on AMD 64
> processors. The "noapic" boot option fixes the clock problem, but disrupts
> other things... ethernet does work, etc. The solution seems to be using
> "apci=noirq noapic" as boot options.
>
> I am using the 2.6.14.2 kernel, and still need to use those boot parameters.
> What is the current state of this bug?
Interestingly, I found out last night that the 2.4.26 kernel can
recognize both processors in my X2. Unfortunately, it had the same time
synchronization issues as the newer 2.6.12+ kernels that I have been
running. It isn't solely related to the new kernel series.
--
Chris Largret <http://daga.dyndns.org>
On Sat, Nov 19, 2005 at 01:12:26PM -0800, Chris Largret wrote:
> On Fri, 2005-11-18 at 20:01 -0500, [email protected] wrote:
> > Hi there,
> >
> > My earlier question regarding the glibc "make check" nptl/tst-clock2.c
> > failure turns out to be due to my system clock running 3x normal speed.
> >
> > Evidently, this is a known issue with 2.6.x kernels running on AMD 64
> > processors. The "noapic" boot option fixes the clock problem, but disrupts
> > other things... ethernet does work, etc. The solution seems to be using
> > "apci=noirq noapic" as boot options.
> >
> > I am using the 2.6.14.2 kernel, and still need to use those boot parameters.
> > What is the current state of this bug?
>
> Interestingly, I found out last night that the 2.4.26 kernel can
> recognize both processors in my X2. Unfortunately, it had the same time
> synchronization issues as the newer 2.6.12+ kernels that I have been
> running. It isn't solely related to the new kernel series.
You could also be seeing the same problem outlined in.
http://marc.theaimsgroup.com/?t=113097284500003&r=2&w=2
Try booting with: acpi_skip_timer_override instead of the other command
line parameters.
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2006.linux.org.au/
Jan 23-28 2006 The Australian Linux Technical Conference!
On Sun, 20 Nov 2005 10:47:08 +1100
Tony Breeds <[email protected]> mentioned:
> On Sat, Nov 19, 2005 at 01:12:26PM -0800, Chris Largret wrote:
> > On Fri, 2005-11-18 at 20:01 -0500, [email protected] wrote:
> > > Hi there,
> > >
> > > My earlier question regarding the glibc "make check" nptl/tst-clock2.c
> > > failure turns out to be due to my system clock running 3x normal speed.
> > >
> > > Evidently, this is a known issue with 2.6.x kernels running on AMD 64
> > > processors. The "noapic" boot option fixes the clock problem, but disrupts
> > > other things... ethernet does work, etc. The solution seems to be using
> > > "apci=noirq noapic" as boot options.
> > >
> > > I am using the 2.6.14.2 kernel, and still need to use those boot parameters.
> > > What is the current state of this bug?
> >
> > Interestingly, I found out last night that the 2.4.26 kernel can
> > recognize both processors in my X2. Unfortunately, it had the same time
> > synchronization issues as the newer 2.6.12+ kernels that I have been
> > running. It isn't solely related to the new kernel series.
>
> You could also be seeing the same problem outlined in.
> http://marc.theaimsgroup.com/?t=113097284500003&r=2&w=2
>
> Try booting with: acpi_skip_timer_override instead of the other command
> line parameters.
My machine's clock runs about 2X from normal speed.
Could you try my patch which I just posted a hour ago?
http://marc.theaimsgroup.com/?l=linux-kernel&m=113249769027262&w=2
The patch will detect whether IO-APCI timer interupt is generated too fast
and try to use a legacy i8259A IRQ instead.
It might help. It also worked on 2.4.31 kernel for me.
>
> Yours Tony
>
> linux.conf.au http://linux.conf.au/ || http://lca2006.linux.org.au/
> Jan 23-28 2006 The Australian Linux Technical Conference!
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Akira Tsukamoto <[email protected], [email protected]>