* Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > Is this after resume ? If yes, then something (probably BIOS) is
> > fiddling with the TSC of one CPU when the resume happens.
>
> My P4 box has the same "problem", which is remedied by..
> - start = get_cycles_sync();
> + start =
* Mike Galbraith [EMAIL PROTECTED] wrote:
Is this after resume ? If yes, then something (probably BIOS) is
fiddling with the TSC of one CPU when the resume happens.
My P4 box has the same problem, which is remedied by..
- start = get_cycles_sync();
+ start = last_tsc =
(hm, google says i'm not the only one seeing this, so...)
On Sun, 2007-03-18 at 00:32 +0100, Thomas Gleixner wrote:
> Maxim,
>
> On Sun, 2007-03-18 at 01:00 +0200, Maxim wrote:
> > >Mar 14 00:22:23 MAIN kernel: [2.072931] checking TSC synchronization
> > >[CPU#0 -> CPU#1]:
> > >Mar 14
(hm, google says i'm not the only one seeing this, so...)
On Sun, 2007-03-18 at 00:32 +0100, Thomas Gleixner wrote:
Maxim,
On Sun, 2007-03-18 at 01:00 +0200, Maxim wrote:
Mar 14 00:22:23 MAIN kernel: [2.072931] checking TSC synchronization
[CPU#0 - CPU#1]:
Mar 14 00:22:23 MAIN
On Thu, 2007-03-22 at 08:28 -0700, Greg KH wrote:
> On Tue, Mar 20, 2007 at 11:54:03AM +, Pavel Machek wrote:
> > Hi!
> >
> > > [EMAIL PROTECTED]:/home/maxim# cat
> > > /sys/devices/system/clockevents/clockevents0/registered
> > > lapicF:0007 M:3(periodic) C: 1
> > > hpet
On Tue, Mar 20, 2007 at 11:54:03AM +, Pavel Machek wrote:
> Hi!
>
> > [EMAIL PROTECTED]:/home/maxim# cat
> > /sys/devices/system/clockevents/clockevents0/registered
> > lapicF:0007 M:3(periodic) C: 1
> > hpet F:0003 M:1(shutdown) C: 0
> > lapic
Hi!
> [EMAIL PROTECTED]:/home/maxim# cat
> /sys/devices/system/clockevents/clockevents0/registered
> lapicF:0007 M:3(periodic) C: 1
> hpet F:0003 M:1(shutdown) C: 0
> lapicF:0007 M:3(periodic) C: 0
> [EMAIL PROTECTED]:/home/maxim#
Now... this
Hi!
[EMAIL PROTECTED]:/home/maxim# cat
/sys/devices/system/clockevents/clockevents0/registered
lapicF:0007 M:3(periodic) C: 1
hpet F:0003 M:1(shutdown) C: 0
lapicF:0007 M:3(periodic) C: 0
[EMAIL PROTECTED]:/home/maxim#
Now... this file
On Tue, Mar 20, 2007 at 11:54:03AM +, Pavel Machek wrote:
Hi!
[EMAIL PROTECTED]:/home/maxim# cat
/sys/devices/system/clockevents/clockevents0/registered
lapicF:0007 M:3(periodic) C: 1
hpet F:0003 M:1(shutdown) C: 0
lapicF:0007
On Thu, 2007-03-22 at 08:28 -0700, Greg KH wrote:
On Tue, Mar 20, 2007 at 11:54:03AM +, Pavel Machek wrote:
Hi!
[EMAIL PROTECTED]:/home/maxim# cat
/sys/devices/system/clockevents/clockevents0/registered
lapicF:0007 M:3(periodic) C: 1
hpet
On Tue, 2007-20-03 at 10:15 +0100, Arjan van de Ven wrote:
> disabling that is a BAD idea. I'm no fan of SMM myself, but it's there,
> and we have to live with it. Disabling it without knowing what it does
> on your system is madness.
>
Like Lee said, for "debugging", mainly trying to resolve
Arjan van de Ven wrote:
On Tue, 2007-03-20 at 01:36 -0400, Eric St-Laurent wrote:
On Tue, 2007-20-03 at 01:04 -0400, Lee Revell wrote:
I think CONFIG_TRY_TO_DISABLE_SMI would be excellent for debugging,
not to mention people trying to spec out hardware for RT
applications...
There is a SMI
Am Dienstag, 20. März 2007 12:36 schrieb Andi Kleen:
> It's long after timer calibration, which is what it interfered with here.
>
> To handle that it would need to be moved to the x86 early quirks and
> use boot_ioremap etc. It would be probably somewhat messy, but doable.
USB is not specific
On Mon, Mar 19, 2007 at 09:27:34PM -0700, Greg KH wrote:
> On Sat, Mar 17, 2007 at 02:26:57PM +0100, Andi Kleen wrote:
> > Arjan van de Ven <[EMAIL PROTECTED]> writes:
> > >
> > > well we can do the handshake to take ownership like we do much later in
> > > boot, but that requires PCI to be there
On Tue, 2007-03-20 at 01:36 -0400, Eric St-Laurent wrote:
> On Tue, 2007-20-03 at 01:04 -0400, Lee Revell wrote:
>
> > I think CONFIG_TRY_TO_DISABLE_SMI would be excellent for debugging,
> > not to mention people trying to spec out hardware for RT
> > applications...
>
> There is a SMI disabling
On Mon, 2007-03-19 at 21:27 -0700, Greg KH wrote:
> On Sat, Mar 17, 2007 at 02:26:57PM +0100, Andi Kleen wrote:
> > Arjan van de Ven <[EMAIL PROTECTED]> writes:
> > >
> > > well we can do the handshake to take ownership like we do much later in
> > > boot, but that requires PCI to be there and
On Mon, 2007-03-19 at 21:27 -0700, Greg KH wrote:
On Sat, Mar 17, 2007 at 02:26:57PM +0100, Andi Kleen wrote:
Arjan van de Ven [EMAIL PROTECTED] writes:
well we can do the handshake to take ownership like we do much later in
boot, but that requires PCI to be there and fully
On Tue, 2007-03-20 at 01:36 -0400, Eric St-Laurent wrote:
On Tue, 2007-20-03 at 01:04 -0400, Lee Revell wrote:
I think CONFIG_TRY_TO_DISABLE_SMI would be excellent for debugging,
not to mention people trying to spec out hardware for RT
applications...
There is a SMI disabling module in
On Mon, Mar 19, 2007 at 09:27:34PM -0700, Greg KH wrote:
On Sat, Mar 17, 2007 at 02:26:57PM +0100, Andi Kleen wrote:
Arjan van de Ven [EMAIL PROTECTED] writes:
well we can do the handshake to take ownership like we do much later in
boot, but that requires PCI to be there and fully
Am Dienstag, 20. März 2007 12:36 schrieb Andi Kleen:
It's long after timer calibration, which is what it interfered with here.
To handle that it would need to be moved to the x86 early quirks and
use boot_ioremap etc. It would be probably somewhat messy, but doable.
USB is not specific to
Arjan van de Ven wrote:
On Tue, 2007-03-20 at 01:36 -0400, Eric St-Laurent wrote:
On Tue, 2007-20-03 at 01:04 -0400, Lee Revell wrote:
I think CONFIG_TRY_TO_DISABLE_SMI would be excellent for debugging,
not to mention people trying to spec out hardware for RT
applications...
There is a SMI
On Tue, 2007-20-03 at 10:15 +0100, Arjan van de Ven wrote:
disabling that is a BAD idea. I'm no fan of SMM myself, but it's there,
and we have to live with it. Disabling it without knowing what it does
on your system is madness.
Like Lee said, for debugging, mainly trying to resolve
On Mon, 2007-03-19 at 21:27 -0700, Greg KH wrote:
> On Sat, Mar 17, 2007 at 02:26:57PM +0100, Andi Kleen wrote:
> > Arjan van de Ven <[EMAIL PROTECTED]> writes:
> > >
> > > well we can do the handshake to take ownership like we do much later in
> > > boot, but that requires PCI to be there and
On Tue, 2007-20-03 at 01:04 -0400, Lee Revell wrote:
> I think CONFIG_TRY_TO_DISABLE_SMI would be excellent for debugging,
> not to mention people trying to spec out hardware for RT
> applications...
There is a SMI disabling module in RTAI, check the smi-module.c in this:
On 3/16/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
Yes, this is probably caused by SMM code trying to emulate a PS/2
keyboard from a (maybe connected or not) USB keyboard. Unfortunately we
have no way to disable this BIOS misfeature in the early boot process.
On Sat, Mar 17, 2007 at 02:26:57PM +0100, Andi Kleen wrote:
> Arjan van de Ven <[EMAIL PROTECTED]> writes:
> >
> > well we can do the handshake to take ownership like we do much later in
> > boot, but that requires PCI to be there and fully discovered, which we
> > don't have this early.
>
>
On Sat, Mar 17, 2007 at 02:26:57PM +0100, Andi Kleen wrote:
Arjan van de Ven [EMAIL PROTECTED] writes:
well we can do the handshake to take ownership like we do much later in
boot, but that requires PCI to be there and fully discovered, which we
don't have this early.
That's not true
On 3/16/07, Thomas Gleixner [EMAIL PROTECTED] wrote:
Yes, this is probably caused by SMM code trying to emulate a PS/2
keyboard from a (maybe connected or not) USB keyboard. Unfortunately we
have no way to disable this BIOS misfeature in the early boot process.
On Tue, 2007-20-03 at 01:04 -0400, Lee Revell wrote:
I think CONFIG_TRY_TO_DISABLE_SMI would be excellent for debugging,
not to mention people trying to spec out hardware for RT
applications...
There is a SMI disabling module in RTAI, check the smi-module.c in this:
On Mon, 2007-03-19 at 21:27 -0700, Greg KH wrote:
On Sat, Mar 17, 2007 at 02:26:57PM +0100, Andi Kleen wrote:
Arjan van de Ven [EMAIL PROTECTED] writes:
well we can do the handshake to take ownership like we do much later in
boot, but that requires PCI to be there and fully
Maxim,
On Sun, 2007-03-18 at 01:00 +0200, Maxim wrote:
> >Mar 14 00:22:23 MAIN kernel: [2.072931] checking TSC synchronization
> >[CPU#0 -> CPU#1]:
> >Mar 14 00:22:23 MAIN kernel: [2.092922] Measured 72051818872 cycles TSC
> >warp between CPUs, turning off
>
> ^ This one I don't think
On Saturday 17 March 2007 01:39:01 Thomas Gleixner wrote:
> On Fri, 2007-03-16 at 12:30 +0200, Maxim Levitsky wrote:
> > Mar 14 00:22:23 MAIN kernel: [2.072875] caller is
> > check_tsc_sync_source+0x1d/0x100
> > Mar 14 00:22:23 MAIN kernel: [2.072878] [show_trace_log_lvl+26/48]
> >
On Saturday 17 March 2007 01:19:44 Len Brown wrote:
> On Friday 16 March 2007 06:30, Maxim Levitsky wrote:
> >
> > Good day,
> >
> > I want to report regressions I have with 2.6.21-rc3 kernel.
> > I use CONFIG_NO_HZ.
>
> Do any of these issues go away with CONFIG_NO_HZ=n (or boot with nohz=n)
On Saturday 17 March 2007 03:32:53 Len Brown wrote:
> On Friday 16 March 2007 19:44, Thomas Gleixner wrote:
> > Maxim,
> >
> > On Fri, 2007-03-16 at 12:30 +0200, Maxim Levitsky wrote:
> > > 3) Sometimes I get this (once in three boots or so)
> > >
> > > [ 36.217405] ENABLING IO-APIC IRQs
> > >
On Sat, 2007-03-17 at 10:56 +0100, Thomas Gleixner wrote:
> > Maybe I could follow the new logic in apic.c if I saw the "apic=debug"
> > output for this box.
>
> calibrating APIC timer ...
> ... lapic delta = 2426884
> ... PM timer delta = 833908
> APIC calibration PIT not consistent with PM
Arjan van de Ven <[EMAIL PROTECTED]> writes:
>
> well we can do the handshake to take ownership like we do much later in
> boot, but that requires PCI to be there and fully discovered, which we
> don't have this early.
That's not true - we do early pci discovery. Doing USB handsoff
there would
On Sat, 2007-03-17 at 10:56 +0100, Thomas Gleixner wrote:
> calibrating APIC timer ...
> ... lapic delta = 2426884
> ... PM timer delta = 833908
> APIC calibration PIT not consistent with PM Timer: 232ms instead of 100ms
> APIC delta adjusted to PM-Timer: 1041737 (2426884)
> . delta 1041737
>
On Fri, 2007-03-16 at 21:32 -0400, Len Brown wrote:
> On Friday 16 March 2007 19:44, Thomas Gleixner wrote:
> > Maxim,
> >
> > On Fri, 2007-03-16 at 12:30 +0200, Maxim Levitsky wrote:
> > > 3) Sometimes I get this (once in three boots or so)
> > >
> > > [ 36.217405] ENABLING IO-APIC IRQs
> > >
Len,
On Fri, 2007-03-16 at 21:32 -0400, Len Brown wrote:
> > > [ 36.433917] APIC timer disabled due to verification failure.
> > >
> > > And NO_HZ is disabled due to that (I get 1000/s timer's interrupts)
> > > I haven't investigated that yet.
> > > It looks like another new test that my
Len,
On Fri, 2007-03-16 at 21:32 -0400, Len Brown wrote:
[ 36.433917] APIC timer disabled due to verification failure.
And NO_HZ is disabled due to that (I get 1000/s timer's interrupts)
I haven't investigated that yet.
It looks like another new test that my hardware fails to
On Fri, 2007-03-16 at 21:32 -0400, Len Brown wrote:
On Friday 16 March 2007 19:44, Thomas Gleixner wrote:
Maxim,
On Fri, 2007-03-16 at 12:30 +0200, Maxim Levitsky wrote:
3) Sometimes I get this (once in three boots or so)
[ 36.217405] ENABLING IO-APIC IRQs
[ 36.217587]
On Sat, 2007-03-17 at 10:56 +0100, Thomas Gleixner wrote:
calibrating APIC timer ...
... lapic delta = 2426884
... PM timer delta = 833908
APIC calibration PIT not consistent with PM Timer: 232ms instead of 100ms
APIC delta adjusted to PM-Timer: 1041737 (2426884)
. delta 1041737
.
Arjan van de Ven [EMAIL PROTECTED] writes:
well we can do the handshake to take ownership like we do much later in
boot, but that requires PCI to be there and fully discovered, which we
don't have this early.
That's not true - we do early pci discovery. Doing USB handsoff
there would be
On Sat, 2007-03-17 at 10:56 +0100, Thomas Gleixner wrote:
Maybe I could follow the new logic in apic.c if I saw the apic=debug
output for this box.
calibrating APIC timer ...
... lapic delta = 2426884
... PM timer delta = 833908
APIC calibration PIT not consistent with PM Timer: 232ms
On Saturday 17 March 2007 03:32:53 Len Brown wrote:
On Friday 16 March 2007 19:44, Thomas Gleixner wrote:
Maxim,
On Fri, 2007-03-16 at 12:30 +0200, Maxim Levitsky wrote:
3) Sometimes I get this (once in three boots or so)
[ 36.217405] ENABLING IO-APIC IRQs
[ 36.217587]
On Saturday 17 March 2007 01:19:44 Len Brown wrote:
On Friday 16 March 2007 06:30, Maxim Levitsky wrote:
Good day,
I want to report regressions I have with 2.6.21-rc3 kernel.
I use CONFIG_NO_HZ.
Do any of these issues go away with CONFIG_NO_HZ=n (or boot with nohz=n)
or are they
On Saturday 17 March 2007 01:39:01 Thomas Gleixner wrote:
On Fri, 2007-03-16 at 12:30 +0200, Maxim Levitsky wrote:
Mar 14 00:22:23 MAIN kernel: [2.072875] caller is
check_tsc_sync_source+0x1d/0x100
Mar 14 00:22:23 MAIN kernel: [2.072878] [show_trace_log_lvl+26/48]
Maxim,
On Sun, 2007-03-18 at 01:00 +0200, Maxim wrote:
Mar 14 00:22:23 MAIN kernel: [2.072931] checking TSC synchronization
[CPU#0 - CPU#1]:
Mar 14 00:22:23 MAIN kernel: [2.092922] Measured 72051818872 cycles TSC
warp between CPUs, turning off
^ This one I don't think is related
On Friday 16 March 2007 19:44, Thomas Gleixner wrote:
> Maxim,
>
> On Fri, 2007-03-16 at 12:30 +0200, Maxim Levitsky wrote:
> > 3) Sometimes I get this (once in three boots or so)
> >
> > [ 36.217405] ENABLING IO-APIC IRQs
> > [ 36.217587] ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
Maxim,
On Fri, 2007-03-16 at 12:30 +0200, Maxim Levitsky wrote:
> 3) Sometimes I get this (once in three boots or so)
>
> [ 36.217405] ENABLING IO-APIC IRQs
> [ 36.217587] ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
> [ 36.433917] APIC timer disabled due to verification failure.
>
On Fri, 2007-03-16 at 12:30 +0200, Maxim Levitsky wrote:
> Mar 14 00:22:23 MAIN kernel: [2.072875] caller is
> check_tsc_sync_source+0x1d/0x100
> Mar 14 00:22:23 MAIN kernel: [2.072878] [show_trace_log_lvl+26/48]
> show_trace_log_lvl+0x1a/0x30
> Mar 14 00:22:23 MAIN kernel: [
On Friday 16 March 2007 06:30, Maxim Levitsky wrote:
>
> Good day,
>
> I want to report regressions I have with 2.6.21-rc3 kernel.
> I use CONFIG_NO_HZ.
Do any of these issues go away with CONFIG_NO_HZ=n (or boot with nohz=n)
or are they all independent of it?
thanks,
-Len
> 1) Both suspend
On Friday 16 March 2007 06:30, Maxim Levitsky wrote:
Good day,
I want to report regressions I have with 2.6.21-rc3 kernel.
I use CONFIG_NO_HZ.
Do any of these issues go away with CONFIG_NO_HZ=n (or boot with nohz=n)
or are they all independent of it?
thanks,
-Len
1) Both suspend to
On Fri, 2007-03-16 at 12:30 +0200, Maxim Levitsky wrote:
Mar 14 00:22:23 MAIN kernel: [2.072875] caller is
check_tsc_sync_source+0x1d/0x100
Mar 14 00:22:23 MAIN kernel: [2.072878] [show_trace_log_lvl+26/48]
show_trace_log_lvl+0x1a/0x30
Mar 14 00:22:23 MAIN kernel: [2.072931]
Maxim,
On Fri, 2007-03-16 at 12:30 +0200, Maxim Levitsky wrote:
3) Sometimes I get this (once in three boots or so)
[ 36.217405] ENABLING IO-APIC IRQs
[ 36.217587] ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
[ 36.433917] APIC timer disabled due to verification failure.
And
On Friday 16 March 2007 19:44, Thomas Gleixner wrote:
Maxim,
On Fri, 2007-03-16 at 12:30 +0200, Maxim Levitsky wrote:
3) Sometimes I get this (once in three boots or so)
[ 36.217405] ENABLING IO-APIC IRQs
[ 36.217587] ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
[
56 matches
Mail list logo
