* 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_ts
(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:
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
> > lapicF
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 fi
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 un
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 di
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
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 ful
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 ful
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:
https://www.rtai.org/RT
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.
https://mail.rtai.org/pipermail
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
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 i
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]
> > show_
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 Timer
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:
> 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 hardwa
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: [2.072931
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 t
Good day,
I want to report regressions I have with 2.6.21-rc3 kernel.
I use CONFIG_NO_HZ.
1) Both suspend to disk and suspend to RAM are completely broken:
On vanilla 2.6.20 suspend to disk works perfectly and suspend to ram works
_almost_ perfectly (I will tell about that later).
On 2.6.21-rc
29 matches
Mail list logo
