linux-kernel - Re: [patch] clockevents: drivers for i386, fix #2

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:	Wed, 4 Oct 2006 09:02:05 -0700
From:	Andrew Morton <akpm@...l.org>
To:	tglx@...utronix.de
Cc:	Ingo Molnar <mingo@...e.hu>, LKML <linux-kernel@...r.kernel.org>,
	Jim Gettys <jg@...top.org>, John Stultz <johnstul@...ibm.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Dave Jones <davej@...hat.com>
Subject: Re: [patch] clockevents: drivers for i386, fix #2

On Wed, 04 Oct 2006 13:19:35 +0200
Thomas Gleixner <tglx@...utronix.de> wrote:

> On Wed, 2006-10-04 at 12:53 +0200, Ingo Molnar wrote:
> > there's one material difference we just found: in the !hres case we'll 
> > do the timer IRQ handling mostly from the lapic vector - while in 
> > mainline we do it from the irq0 vector. So, how does your 
> > /proc/interrupts look like? How frequently does LOC increase, and how 
> > frequently does IRQ 0 increase?

sony:/home/akpm> cat /proc/interrupts ; sleep 1 ; cat /proc/interrupts
           CPU0       
  0:      39256   IO-APIC-edge      timer
  1:          8   IO-APIC-edge      i8042
  8:          1   IO-APIC-edge      rtc
  9:        160   IO-APIC-fasteoi   acpi
 11:          3   IO-APIC-edge      sonypi
 12:        107   IO-APIC-edge      i8042
 14:          5   IO-APIC-edge      libata
 15:          0   IO-APIC-edge      libata
 16:          1   IO-APIC-fasteoi   yenta, uhci_hcd:usb4
 17:        246   IO-APIC-fasteoi   ohci1394, eth0
 18:       5759   IO-APIC-fasteoi   libata
 19:          3   IO-APIC-fasteoi   ipw2200
 20:        710   IO-APIC-fasteoi   HDA Intel, uhci_hcd:usb3
 21:          2   IO-APIC-fasteoi   ehci_hcd:usb1
 22:          0   IO-APIC-fasteoi   uhci_hcd:usb2, uhci_hcd:usb5
NMI:          0 
LOC:       3131 
ERR:          0
MIS:          0
           CPU0       
  0:      39519   IO-APIC-edge      timer
  1:          8   IO-APIC-edge      i8042
  8:          1   IO-APIC-edge      rtc
  9:        160   IO-APIC-fasteoi   acpi
 11:          3   IO-APIC-edge      sonypi
 12:        107   IO-APIC-edge      i8042
 14:          5   IO-APIC-edge      libata
 15:          0   IO-APIC-edge      libata
 16:          1   IO-APIC-fasteoi   yenta, uhci_hcd:usb4
 17:        248   IO-APIC-fasteoi   ohci1394, eth0
 18:       5759   IO-APIC-fasteoi   libata
 19:          3   IO-APIC-fasteoi   ipw2200
 20:        715   IO-APIC-fasteoi   HDA Intel, uhci_hcd:usb3
 21:          2   IO-APIC-fasteoi   ehci_hcd:usb1
 22:          0   IO-APIC-fasteoi   uhci_hcd:usb2, uhci_hcd:usb5
NMI:          0 
LOC:       3134 
ERR:          0
MIS:          0

> > (meanwhile we'll fix and restore things so that it matches mainline 
> > behavior.)
> 
> Andrew, does the patch below fix your problem ?
> 
> You should see the same weird behaviour when you run a plain -mm3 with
> CONFIG_SMP=y on that box. This moves update_process_times() to the lapic
> too.
> 	tglx
> 
> 
> Index: linux-2.6.18-mm3/arch/i386/kernel/apic.c
> ===================================================================
> --- linux-2.6.18-mm3.orig/arch/i386/kernel/apic.c	2006-10-04 13:02:35.000000000 +0200
> +++ linux-2.6.18-mm3/arch/i386/kernel/apic.c	2006-10-04 12:59:06.000000000 +0200
> @@ -84,7 +84,9 @@ static void lapic_timer_setup(enum clock
>  static struct clock_event_device lapic_clockevent = {
>  	.name = "lapic",
>  	.capabilities = CLOCK_CAP_NEXTEVT | CLOCK_CAP_PROFILE
> +#ifdef CONFIG_SMP
>  			| CLOCK_CAP_UPDATE,
> +#endif
>  	.shift = 32,
>  	.set_mode = lapic_timer_setup,
>  	.set_next_event = lapic_next_event,

that (after a tweak to make it compile) fixes it.   What's it do?

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