linux-kernel - Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325

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:	Fri, 20 Jun 2008 15:11:23 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	"Maciej W. Rozycki" <macro@...ux-mips.org>
cc:	Ingo Molnar <mingo@...e.hu>, "Rafael J. Wysocki" <rjw@...k.pl>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Len Brown <lenb@...nel.org>
Subject: Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325

On Thu, 19 Jun 2008, Maciej W. Rozycki wrote:
> On Thu, 19 Jun 2008, Ingo Molnar wrote:
> > * Maciej W. Rozycki <macro@...ux-mips.org> wrote:
> > does PIT programming matter? One detail which might matter and which 
> > touches IRQ0 generation is the clockevent driver on nohz/highres. See 
> > arch/x86/kernel/i8253.c:init_pit_timer():
> > 
> >         case CLOCK_EVT_MODE_SHUTDOWN:
> >         case CLOCK_EVT_MODE_UNUSED:
> >                 if (evt->mode == CLOCK_EVT_MODE_PERIODIC ||
> >                     evt->mode == CLOCK_EVT_MODE_ONESHOT) {
> >                         outb_pit(0x30, PIT_MODE);
> >                         outb_pit(0, PIT_CH0);
> >                         outb_pit(0, PIT_CH0);
> >                 }
> >                 pit_disable_clocksource();
> >                 break;
> > 
> >         case CLOCK_EVT_MODE_ONESHOT:
> >                 /* One shot setup */
> >                 pit_disable_clocksource();
> >                 outb_pit(0x38, PIT_MODE);
> >                 break;
> 
>  It does, though not necessarily in this case.  In principle all this
> 8254-through-APIC timer validation code assumes the source retriggers
> automatically and if an edge is lost because the APIC input targeted is
> masked or not configured yet, another one will follow shortly by itself.  
> It used to be the case when this code was implemented as we never used any
> of the single-shot modes of the 8254 back then.
> 
>  Is it now possible at the time check_timer() is called the 8254 has been
> put in one of the single-shot modes?  If so, then additional code has to
> be put in place either to switch the timer into the periodic mode for the
> duration of check_timer() or to rearm the timer if in a single-shot mode
> each time timer_irq_works() is called.

At this point the PIT is in periodic mode.

Let me explain how the timer startup works:

PIT is started in periodic mode
... basic CPU bring up
APIC timer initialization (switches PIT off)
...
Highres/Dyntick mode switches local apic timers to one shot mode

When the system has C2/C3 or C1E states, then we restart the PIT in
one shot mode and reprogram it every time when the system goes into
idle to replace the local apic timer, which stops in those states.

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