* Sat, 22 Sep 2007 00:32:05 +0200 (CEST)
[]
> Index: linux/Documentation/filesystems/proc.txt
>===================================================================
> --- linux.orig/Documentation/filesystems/proc.txt
> +++ linux/Documentation/filesystems/proc.txt
> @@ -347,7 +347,40 @@ connects the CPUs in a SMP system. This
> the IO-APIC automatically retry the transmission, so it should not be a big
> problem, but you should read the SMP-FAQ.
>
> -In this context it could be interesting to note the new irq directory in 2.4.
> +In 2.6.2* /proc/interrupts was expanded again. This time the goal was for
> +/proc/interrupts to display every IRQ vector in use by the system, not
> +just those considered 'most important'. The new vectors are:
> +
> + THR -- a threshold interrupt occurs when ECC memory correction is occuring
> + at too high a frequency. Threshold interrupt machinery is often put
> + into the ECC logic, as occasional ECC memory corrections are part of
> + normal operation (due to random alpha particles), but sequences of
> + ECC corrections or outright failures over some short interval usually
> + indicate a memory chip that is about to fail. Note that not every
> + platform has ECC threshold logic, and those that do generally require
> + it to be explicitly turned on.
+ THR -- a threshold interrupt happens, when frequency of ECC memory
+ corrections is too high. Threshold interrupt machinery is often put
+ into the ECC hardware, and must be explicitly enabled, if so. Occasional
+ ECC memory corrections are part of the normal operation (ionizing radiation
+ background). Sequences of ECC corrections or outright failures over some
+ short interval, usually indicate a memory chip, that is about to fail
+ completely.
(that "random alpha particles" bs, must be killed anyway)
> + TRM -- a thermal event interrupt occurs when a temperature threshold
> + has been exceeded for some CPU chip. This interrupt may also be generated
> + when the temperature drops back to normal.
> +
> + SPU -- a spurious interrupt is some interrupt that was raised then lowered
> + by some IO device before it could be fully processed by the APIC. Hence
> + the APIC sees the interrupt but does not know what device it came from.
> + For this case the APIC will generate the interrupt with a IRQ vector
> + of 0xff.
+ SPU -- a spurious interrupt. This is an interrupt, that was raised then
lowered
+ so quickly, that it was not fully processed by the APIC. Hence,
+ origin of it is unknown.
+ For this case, interrupt with a IRQ vector of 0xff will be generated.
> + RES, CAL, TLB -- rescheduling, call and tlb flush interrupts are
> + sent from one CPU to another per the needs of the OS. Typically,
> + their statistics are used by kernel developers and interested users to
> + determine the occurance of interrupt floods of the given type.
+ RES, CAL, TLB -- rescheduling, call and tlb flush interrupts,
+ produced by normal OS operation. Typically,
+ this information is used by kernel developers and interested users to
+ determine the occurance of interrupt floods of the given type.
> +The above IRQ vectors are displayed only when relevent. For example,
available?
> +the threshold vector does not exist on x86_64 platforms. Others are
> +suppressed when the system is a uniprocessor. As of this writing, only
> +i386 and x86_64 platforms support the new IRQ vector displays.
> +
> +Of some interest is the introduction of the /proc/irq directory to 2.4.
> It could be used to set IRQ to CPU affinity, this means that you can "hook"
> an
> IRQ to only one CPU, or to exclude a CPU of handling IRQs. The contents of
> the
> irq subdir is one subdir for each IRQ, and one file; prof_cpu_mask
_____
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
