linux-kernel - Re: [BUG] 2.6.21-rc1,2,3 regressions on my system that I found so far

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 18 Mar 2007 00:32:54 +0100
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Maxim <maximlevitsky@...il.com>
Cc:	Len Brown <lenb@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [BUG] 2.6.21-rc1,2,3 regressions on my system that I found so
	far

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 to NO_HZ, maybe it is hardware
> problem, but it exist without NO_HZ

The TSC is checked for synchronization between the CPUs. It's nothing to
worry about. We switch off the TSC and use a different clocksource.

Is this after resume ? If yes, then something (probably BIOS) is
fiddling with the TSC of one CPU when the resume happens.

> >[   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.
> 
> This one is now discussed, I will look at it and it is not related to NO_HZ

I sent a patch for this yesterday:

http://marc.info/?l=linux-kernel&m=117408952322631&w=2

> And I forgot to tell about another problem with (now I know ,hi-resolution timers)
> That before suspend to ram APIC timer is used and HPET is not used :
> 
> root@...N:/home/maxim# cat /sys/devices/system/clockevents/clockevents0/registered
> lapic                F:0007 M:3(periodic) C: 1
> hpet                 F:0003 M:1(shutdown) C: 0
> lapic                F:0007 M:3(periodic) C: 0
> root@...N:/home/maxim#   
> 
> But after suspend to ram HPET is 'woken'
> 
> root@...N:/home/maxim# cat /sys/devices/system/clockevents/clockevents0/registered
> lapic                F:0007 M:3(one shoot) C: 1
> hpet                 F:0003 M:3(one shoot) C: 0
> lapic                F:0007 M:3(one shoot) C: 0

This is unrelated to suspend / resume. The local apic timers stop
(hardware madness), when the CPU enters C3 power state. In this case we
switch to HPET (or PIT when HPET is not available) and broadcast the
events via Inter Processor Interrupts. This is nothing to worry about. 

I'm a bit surprised though, that your system was in periodic mode before
suspend and switched to one shot mode on resume.

Is this reproducible ? If yes, can you please provide the dmesg output
from boot to resume ?

> Note that I added those (one shoot), (periodic) descriptions, would be
> nice to have them in kernel, can I send a patch ?  ;-)

Sure, just s/shoot/shot/ :)

> and I see average of 18 IRQs/sec on IRQ 0

So dynticks are working as expected.

	tglx


-
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/