2.6.18-rc5-mm1: strange /proc/interrupts contents on HPC nx6325

2.6.18-rc5-mm1: strange /proc/interrupts contents on HPC nx6325

[Rafael J. Wysocki]

Hi,

[I'm not quite sure who should be on the Cc list.]

The contents of /proc/interrupts look strange on the HPC nx6325 I'm currently using
(2.6.18-rc5-mm1, 64-bit kernel):

           CPU0       CPU1       
  0:      18073          0    <NULL>-edge     timer
  1:        163          0   IO-APIC-edge     i8042
  8:          0          0   IO-APIC-edge     rtc
  9:        120          0   IO-APIC-fasteoi  acpi
 12:        149          0   IO-APIC-edge     i8042
 14:         24          0   IO-APIC-edge     ide0
 16:       4796          0   IO-APIC-fasteoi  libata
 19:         75          0   IO-APIC-fasteoi  ehci_hcd:usb1, ohci_hcd:usb2, ohci_hcd:usb3
 20:          7          0   IO-APIC-fasteoi  yenta, ohci1394, sdhci:slot0
 23:        672          0   IO-APIC-fasteoi  eth0
4348:        188          0   PCI-MSI-<NULL>  HDA Intel
NMI:         89         59 
LOC:      18036      18171 
ERR:          0

Still, the timer and the sound card seem to work in spite of the NULLs.

On 2.6.18-rc6 /proc/interrupts looks saner to me:

           CPU0       CPU1       
  0:     489283          0  local-APIC-edge  timer
  1:       2596          0    IO-APIC-edge  i8042
  8:          0          0    IO-APIC-edge  rtc
 12:        148          0    IO-APIC-edge  i8042
 14:      17261          0    IO-APIC-edge  ide0
169:       5147          0   IO-APIC-level  acpi
177:          4          0   IO-APIC-level  sdhci:slot0, yenta, ohci1394
217:      82575          0   IO-APIC-level  libata, HDA Intel
225:      29230          0   IO-APIC-level  ehci_hcd:usb1, ohci_hcd:usb2, ohci_hcd:usb3
233:      37655          0   IO-APIC-level  eth0
NMI:        674       1052 
LOC:     489293     489595 
ERR:          1
MIS:          0

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

Re: 2.6.18-rc5-mm1: strange /proc/interrupts contents on HPC nx6325

[Andrew Morton]

On Wed, 6 Sep 2006 21:17:30 +0200
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> Hi,
> 
> [I'm not quite sure who should be on the Cc list.]

I know ;)

> The contents of /proc/interrupts look strange on the HPC nx6325 I'm currently using
> (2.6.18-rc5-mm1, 64-bit kernel):
> 
>            CPU0       CPU1       
>   0:      18073          0    <NULL>-edge     timer
>   1:        163          0   IO-APIC-edge     i8042
>   8:          0          0   IO-APIC-edge     rtc
>   9:        120          0   IO-APIC-fasteoi  acpi
>  12:        149          0   IO-APIC-edge     i8042
>  14:         24          0   IO-APIC-edge     ide0
>  16:       4796          0   IO-APIC-fasteoi  libata
>  19:         75          0   IO-APIC-fasteoi  ehci_hcd:usb1, ohci_hcd:usb2, ohci_hcd:usb3
>  20:          7          0   IO-APIC-fasteoi  yenta, ohci1394, sdhci:slot0
>  23:        672          0   IO-APIC-fasteoi  eth0
> 4348:        188          0   PCI-MSI-<NULL>  HDA Intel
> NMI:         89         59 
> LOC:      18036      18171 
> ERR:          0

This is due to a gruesome hack (IMO) in the genirq code (handle_irq_name())
which magically "knows" about the various types of IRQ handler, but doesn't
know about the MSI ones.  It should be converted to a field in irq_desc, or
a callback or something.  

I already had a whine about this then forgot about it, but it seems that
code can't be changed by whining at it ;)

Re: 2.6.18-rc5-mm1: strange /proc/interrupts contents on HPC nx6325

[Ingo Molnar]

* Andrew Morton <akpm@osdl.org> wrote:

> This is due to a gruesome hack (IMO) in the genirq code 
> (handle_irq_name()) which magically "knows" about the various types of 
> IRQ handler, but doesn't know about the MSI ones.  It should be 
> converted to a field in irq_desc, or a callback or something.

a field in irq_desc[] was frowned upon during initial genirq review, due 
to size reasons, so i removed it and replaced it with the hack.

> I already had a whine about this then forgot about it, but it seems that
> code can't be changed by whining at it ;)

;)

i think we could add a 'register handler name' API (or extend 
set_irq_handler() API), to pass in the name of handlers, and store it in 
a small array (instead of embedding it in irq_desc)? handle_irq_name() 
is not performance-critical.

	Ingo

Re: 2.6.18-rc5-mm1: strange /proc/interrupts contents on HPC nx6325

[Andrew Morton]

On Thu, 7 Sep 2006 15:51:05 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Andrew Morton <akpm@osdl.org> wrote:
> 
> > This is due to a gruesome hack (IMO) in the genirq code 
> > (handle_irq_name()) which magically "knows" about the various types of 
> > IRQ handler, but doesn't know about the MSI ones.  It should be 
> > converted to a field in irq_desc, or a callback or something.
> 
> a field in irq_desc[] was frowned upon during initial genirq review, due 
> to size reasons, so i removed it and replaced it with the hack.

irq_desc[] is already in the hundred-byte range.  I'm a bit surprised that
another char* is worth sweating over.

What's in irq_chip.name, btw?  "name for /proc/interrupts".  hmm.

> > I already had a whine about this then forgot about it, but it seems that
> > code can't be changed by whining at it ;)
> 
> ;)
> 
> i think we could add a 'register handler name' API (or extend 
> set_irq_handler() API), to pass in the name of handlers, and store it in 
> a small array (instead of embedding it in irq_desc)? handle_irq_name() 
> is not performance-critical.

spose so.