linux-kernel - Re: 2.6.20-rc6-mm3

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, 07 Feb 2007 15:53:50 +0100
From:	Thomas Gleixner <tglx@...utronix.de>
To:	dwalker@...sta.com
Cc:	Ingo Molnar <mingo@...e.hu>, Andrew Morton <akpm@...l.org>,
	linux-kernel@...r.kernel.org
Subject: Re: 2.6.20-rc6-mm3

On Tue, 2007-02-06 at 17:12 -0800, Daniel Walker wrote:
> On Wed, 2007-02-07 at 00:36 +0100, Thomas Gleixner wrote:
> 
> > There are no other clock event devices in a PC system at the moment
> > and /proc/interrupt does not care, whether the interrupt was setup for a
> > clock event device or something else. It displays the name which is
> > given in the irqaction struct and does not care what it means. I did not
> > change the name in the IRQ#0 setup, so it still displays "timer" (which
> > can either be PIT or HPET), but this is something the interrupt layer
> > does not know and does not care about.
> 
> So your saying the "timer" entry in /proc/interrupts can be either the
> HPET timer, the PIT timer? Mine says "IO-APIC-edge" which does that map
> to? It's going though the io-apic but it's still the pit ?

IO-APIC: Input/Output Advanced Programmable Interrupt Controller. This
device does not generate interrupts by itself. Devices, which generate
interrupts are connected to it.

23:         82          0   IO-APIC-fasteoi   ohci1394, HDA Intel

This is IRQ#23 coming in via IO-APIC (fasteoi type). The interrupt is
shared by two devices, which identified themself as "ohci1394" and "HDA
Intel" via request_irq(). The interrupt originates from one of those
devices. So it _IS_ going through the IO-APIC, but generated either by
the Firewire device or the Audio device.

  0:     186222          0   IO-APIC-edge      timer

This is IRQ#0 coming in via IO-APIC (edge type). The interrupt is not
shared. The device identified itself as "timer" via setup_irq(). The
interrupt originates from this device. The interrupt is either caused by
PIT or HPET via a hardware switch mechanism, which is activated when you
use HPET. There is no way to share IRQ#0 here. It's either or as defined
by hardware magic.

	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/