On Thu, 8 Jul 1999, Jos van de Ven wrote:
>
> > In this case, /proc/interrupts does not see any interrupts being generated
> > by the Cyclom-Y card, even though the IRQ is registered by the driver
> > (i.e., it's listed in /proc/interrupts, yet with '0' interrrupts
> > generated).
> I like to see that /proc/interrupts still, if possible.
Ok, here it is:
CPU0 CPU1
0: 28041 27516 IO-APIC-edge timer
1: 0 2 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
8: 1 1 IO-APIC-edge rtc
9: 0 0 IO-APIC-edge Cyclom-Y
12: 0 0 IO-APIC-edge PS/2 Mouse
13: 1 0 XT-PIC fpu
16: 28556 28630 IO-APIC-level aic7xxx, aic7xxx
20: 1279 1339 IO-APIC-level SMC EPIC/100
21: 1357 1442 IO-APIC-level SMC EPIC/100
NMI: 0
ERR: 0
The Cyclom-Y allocated the IRQ as IO-APIC-edge (that's what you probably
wanted to know, isn't it?!).
> > If kernel is compiled as UP, the Cyclom-Y works fine, using the _same_ IRQ
> > that it tried to use on the SMP kernel.
> Hmm. We can do that another way. I sent you a patch, with which you can enable
> the use of IO-APIC-Level ipv Edge or XT-PIC per interrupt. It's a simple patch,
> but it has already prover to be useful.
Tried the patch on the client's system. The results are as follows:
- 'ioapic_level=9' : makes no difference (i.e., problem is still the same)
- 'xtpci=9' : problem is solved (i.e., interrupts are seen by the system)
I'm thinking about notifying Dell about this, but I'd like to hear from
the Linux SMP / APIC people first. Could anyone explain with "slightly"
more details what's going on here?? Is there a way to fix this in
software? Is it useful to contact Dell about this ??
TIA and Regards,
Ivan Passos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/