Re: IO-APIC on nforce2

Re: IO-APIC on nforce2

[Christian Kroener]

thanks very much for the replies... Ross, I will test your patch as soon 
as I get home.
Some more infos: my machine worked pretty well and stable even with the 
irq0 as XT-PIC. Though I worried about the constant hi-load I got.
At the moment, using 2.6.4-ck2 patched only with the io_apic.c-diff from 
Ross I get this output on system-log:

ENABLING IO-APIC IRQs
IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 
not connected.
A..TIMER: vector=0x31 pin1=2 pin2=-1
..MP-BIOS bug: 8254 timer not connected to IO-APIC INTIN2
..TIMER: Is timer irq0 connected to IO-APIC INTIN0?...
IOAPIC[0]: Set PCI routing entry (2-0 -> 0x31 -> IRQ 0 Mode:0 Active:0)
..TIMER: works OK on IO-APIC INTIN0 irq0
Using local APIC timer interrupts.
calibrating APIC timer ...

cat /proc/interrupts gives me:

           CPU0      
  0:   13681442    IO-APIC-edge  timer
  1:         35    IO-APIC-edge  i8042
  2:          0          XT-PIC  cascade
  8:          4    IO-APIC-edge  rtc
  9:          0   IO-APIC-level  acpi
 12:       2054    IO-APIC-edge  i8042
 14:      81623    IO-APIC-edge  ide0
 15:         87    IO-APIC-edge  ide1
 16:       2397   IO-APIC-level  ide2, saa7134[0]
 17:        156   IO-APIC-level  CMI8738
 19:    1161008   IO-APIC-level  nvidia
 20:    3050303   IO-APIC-level  ohci_hcd, eth0
 21: 2316037857   IO-APIC-level  ehci_hcd
 22:         76   IO-APIC-level  ohci_hcd
NMI:          0
LOC:   13633382
ERR:          0
MIS:          0

irq-routing:

IO APIC #2......
.... register #00: 02000000
.......    : physical APIC id: 02
.......    : Delivery Type: 0
.......    : LTS          : 0
.... register #01: 00170011
.......     : max redirection entries: 0017
.......     : PRQ implemented: 0
.......     : IO APIC version: 0011
.... register #02: 00000000
.......     : arbitration: 00
.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 001 01  0    0    0   0   0    1    1    31
01 001 01  0    0    0   0   0    1    1    39
02 000 00  0    0    0   0   0    0    0    00
03 001 01  0    0    0   0   0    1    1    41
04 001 01  0    0    0   0   0    1    1    49
05 001 01  0    0    0   0   0    1    1    51
06 001 01  0    0    0   0   0    1    1    59
07 001 01  0    0    0   0   0    1    1    61
08 001 01  0    0    0   0   0    1    1    69
09 001 01  0    1    0   0   0    1    1    71
0a 001 01  0    0    0   0   0    1    1    79
0b 001 01  0    0    0   0   0    1    1    81
0c 001 01  0    0    0   0   0    1    1    89
0d 001 01  0    0    0   0   0    1    1    91
0e 001 01  0    0    0   0   0    1    1    99
0f 001 01  0    0    0   0   0    1    1    A1
10 001 01  1    1    0   0   0    1    1    D1
11 001 01  1    1    0   0   0    1    1    D9
12 001 01  1    1    0   0   0    1    1    E1
13 001 01  1    1    0   0   0    1    1    C9
14 001 01  1    1    0   0   0    1    1    B1
15 001 01  1    1    0   0   0    1    1    C1
16 001 01  1    1    0   0   0    1    1    B9
17 001 01  1    1    0   0   0    1    1    A9
IRQ to pin mappings:
IRQ0 -> 0:2-> 0:0
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ5 -> 0:5
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9-> 0:9
IRQ10 -> 0:10
IRQ11 -> 0:11
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
IRQ16 -> 0:16
IRQ17 -> 0:17
IRQ18 -> 0:18
IRQ19 -> 0:19
IRQ20 -> 0:20
IRQ21 -> 0:21
IRQ22 -> 0:22
IRQ23 -> 0:23

Maybe some of the copy+paste wrent wrong (sucky Mozilla mail here).

Earlier versions of -mm reported setting irq0 as virtual wire irq worked 
and I didnt experience any uncommon hi-load with them. -mm latest sets 
the timer irq as ExtINT, resulting in these strange constant hi-loads.

I will report results of testing your patch later, Ross.
thanks, christian.

Re: IO-APIC on nforce2

[really bensoo_at_soo_dot_com]

i must add that i've been using your patches for
the nForce chipset since they first appeared on
this mailing list, and while they've all helped
this box to last a bit longer between lockups
none of them cured it.  Once the IO-APIC code was
compiled in and the Athlon idle powersaving
turned on it would inevitabley lock up in a day
or two.

This incorrect result from the mismatch between
your 2.6.3 patches and the current IO-APIC
code is the first time this box seems to be
free from lockup.

b

On Tue, Apr 13, 2004 at 05:18:24PM -0400, really bensoo_at_soo_dot_com wrote:
> My irq0 says XT-PIC.  i'm not complaining, box's still
> very stable and since the last post i've burned a few
> DVDs on it while running the file share client and
> playing music.
> 
> cat /proc/interrupts
> 
>            CPU0       
>   0:  759809583          XT-PIC  timer
>   1:     382279    IO-APIC-edge  i8042
>   2:          0          XT-PIC  cascade
>   8:          1    IO-APIC-edge  rtc
>   9:          0   IO-APIC-level  acpi
>  12:    6386931    IO-APIC-edge  i8042
>  14:    2117474    IO-APIC-edge  ide0
>  15:    5575006    IO-APIC-edge  ide1
> 201:    6425958   IO-APIC-level  EMU10K1
> 209:  167929203   IO-APIC-level  eth0
> NMI:          0 
> LOC:  759718637 
> ERR:          0
> MIS:          0

Re: IO-APIC on nforce2

[really bensoo_at_soo_dot_com]

On Tue, Apr 13, 2004 at 02:55:52PM +1000, Ross Dickson wrote:
> Are you using my io-apic patch with the apic ack delay or with the
> C1idle version?
> i.e. patched io_apic.c and apic.c and using kernel arg "apic_tack="
> or patched io_apic.c and process.c and using kernel arg "idle=C1halt"?

i'm using your C1idle patches:

nforce2-idleC1halt-rd-2.6.3.patch
nforce2-ioapic-rd-2.6.3.patch

cat /proc/cmdline
BOOT_IMAGE=linux-test ro root=305 idebus=33 acpi=on idle=C1halt

> Could you please cat /proc/interrupts.
> I would like to see how irq0 is routed.

My irq0 says XT-PIC.  i'm not complaining, box's still
very stable and since the last post i've burned a few
DVDs on it while running the file share client and
playing music.

cat /proc/interrupts

           CPU0       
  0:  759809583          XT-PIC  timer
  1:     382279    IO-APIC-edge  i8042
  2:          0          XT-PIC  cascade
  8:          1    IO-APIC-edge  rtc
  9:          0   IO-APIC-level  acpi
 12:    6386931    IO-APIC-edge  i8042
 14:    2117474    IO-APIC-edge  ide0
 15:    5575006    IO-APIC-edge  ide1
201:    6425958   IO-APIC-level  EMU10K1
209:  167929203   IO-APIC-level  eth0
NMI:          0 
LOC:  759718637 
ERR:          0
MIS:          0


> 
> And from boot log
> with my new timer setup

my boot dmesg timer setup:

ENABLING IO-APIC IRQs
init IO_APIC IRQs
 IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected.
..TIMER: vector=0x31 pin1=2 pin2=-1
..MP-BIOS bug: 8254 timer not connected to IO-APIC INTIN2
..TIMER: Is timer irq0 connected to IO-APIC INTIN0? ...
IOAPIC[0]: Set PCI routing entry (2-0 -> 0x31 -> IRQ 0 Mode:0 Active:0)
IOAPIC[0]: Set PCI routing entry (2-2 -> 0x31 -> IRQ 0 Mode:0 Active:0)
..MP-BIOS: 8254 timer not connected to IO-APIC INTIN0
...trying to set up timer (IRQ0) through the 8259A ...  failed.
...trying to set up timer as Virtual Wire IRQ... failed.
...trying to set up timer as ExtINT IRQ... works.
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 2135.0772 MHz.
..... host bus clock speed is 388.0322 MHz.

-------------------------------------------------------------
ioapic routing:

number of MP IRQ sources: 15.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................

IO APIC #2......
.... register #00: 02000000
.......    : physical APIC id: 02
.......    : Delivery Type: 0
.......    : LTS          : 0
.... register #01: 00170011
.......     : max redirection entries: 0017
.......     : PRQ implemented: 0
.......     : IO APIC version: 0011
.... register #02: 00000000
.......     : arbitration: 00
.... IRQ redirection table:
 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:   
 00 000 00  1    0    0   0   0    0    0    00
 01 001 01  0    0    0   0   0    1    1    39
 02 001 01  1    0    0   0   0    1    1    31
 03 001 01  0    0    0   0   0    1    1    41
 04 001 01  0    0    0   0   0    1    1    49
 05 001 01  0    0    0   0   0    1    1    51
 06 001 01  0    0    0   0   0    1    1    59
 07 001 01  1    0    0   0   0    1    1    61
 08 001 01  0    0    0   0   0    1    1    69
 09 001 01  0    1    0   0   0    1    1    71
 0a 001 01  0    0    0   0   0    1    1    79
 0b 001 01  0    0    0   0   0    1    1    81
 0c 001 01  0    0    0   0   0    1    1    89
 0d 001 01  0    0    0   0   0    1    1    91
 0e 001 01  0    0    0   0   0    1    1    99
 0f 001 01  0    0    0   0   0    1    1    A1
 10 001 01  1    1    0   0   0    1    1    D1
 11 001 01  1    1    0   0   0    1    1    D9
 12 001 01  1    1    0   0   0    1    1    E1
 13 001 01  1    1    0   0   0    1    1    C9
 14 001 01  1    1    0   0   0    1    1    B1
 15 001 01  1    1    0   0   0    1    1    C1
 16 001 01  1    1    0   0   0    1    1    B9
 17 001 01  1    1    0   0   0    1    1    A9
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ5 -> 0:5
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ10 -> 0:10
IRQ11 -> 0:11
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
IRQ16 -> 0:16
IRQ17 -> 0:17
IRQ18 -> 0:18
IRQ19 -> 0:19
IRQ20 -> 0:20
IRQ21 -> 0:21
IRQ22 -> 0:22
IRQ23 -> 0:23
.................................... done.
PCI: Using ACPI for IRQ routing

> I am now using forcedeth for onboard ether. It works well and is
> convenient when rebuilding and testing kernels and modules.

i would too but am still on a coax network here...
What?  Upgrade?  What?

b

Re: IO-APIC on nforce2

[Christian Kröner]

Here is some other (maybe useful) info I can give:

This is part of my system log from kernel 2.6.5-mm4 (no other patches than -mm).
The irq0 gets set to XT-PIC with this kernel version...

timer setup:

ENABLING IO-APIC IRQs
init IO_APIC IRQs
IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected.
 ..TIMER: vector=0x31 pin1=2 pin2=-1
..MP-BIOS bug: 8254 timer not connected to IO-APIC
...trying to set up timer (IRQ0) through the 8259A ...  failed.
...trying to set up timer as Virtual Wire IRQ... failed.
...trying to set up timer as ExtINT IRQ... works.
Using local APIC timer interrupts.

interrupt routing:

number of MP IRQ sources: 15.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................
  IO APIC #2......
  .... register #00: 02000000
  .......    : physical APIC id: 02
  .......    : Delivery Type: 0
  .......    : LTS          : 0
  .... register #01: 00170011
  .......     : max redirection entries: 0017
  .......     : PRQ implemented: 0
  .......     : IO APIC version: 0011
  .... register #02: 00000000
  .......     : arbitration: 00
  .... IRQ redirection table:
   NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
   00 000 00  1    0    0   0   0    0    0    00
   01 001 01  0    0    0   0   0    1    1    39
   02 000 00  1    0    0   0   0    0    0    00
   03 001 01  0    0    0   0   0    1    1    41
   04 001 01  0    0    0   0   0    1    1    49
   05 001 01  0    0    0   0   0    1    1    51
   06 001 01  0    0    0   0   0    1    1    59
   07 001 01  1    0    0   0   0    1    1    61
   08 001 01  0    0    0   0   0    1    1    69
   09 001 01  0    1    0   0   0    1    1    71
   0a 001 01  0    0    0   0   0    1    1    79
   0b 001 01  0    0    0   0   0    1    1    81
   0c 001 01  0    0    0   0   0    1    1    89
   0d 001 01  0    0    0   0   0    1    1    91
   0e 001 01  0    0    0   0   0    1    1    99
   0f 001 01  0    0    0   0   0    1    1    A1
   10 001 01  1    1    0   0   0    1    1    D1
   11 001 01  1    1    0   0   0    1    1    D9
   12 001 01  1    1    0   0   0    1    1    E1
   13 001 01  1    1    0   0   0    1    1    C9
   14 001 01  1    1    0   0   0    1    1    B1
   15 001 01  1    1    0   0   0    1    1    C1
   16 001 01  1    1    0   0   0    1    1    B9
   17 001 01  1    1    0   0   0    1    1    A9


Now, with 2.6.5-mm5-1, patched by hand with the io_apic.c-patch I got from Ross
(removing the declaration of extern int timer_ack in check_timer(), changing nothing else),
I get the following:

timer setup:

ENABLING IO-APIC IRQs
init IO_APIC IRQs
 IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected.
..TIMER: vector=0x31 pin1=2 pin2=-1
..MP-BIOS bug: 8254 timer not connected to IO-APIC INTIN2
..TIMER: Check if 8254 timer connected to IO-APIC INTIN0? ...
..TIMER: works OK on IO-APIC irq0
Using local APIC timer interrupts.

irq routing:

number of MP IRQ sources: 15.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................
IO APIC #2......
.... register #00: 02000000
.......    : physical APIC id: 02
.......    : Delivery Type: 0
.......    : LTS          : 0
.... register #01: 00170011
.......     : max redirection entries: 0017
.......     : PRQ implemented: 0
.......     : IO APIC version: 0011
.... register #02: 00000000
.......     : arbitration: 00
.... IRQ redirection table:
 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
 00 001 01  0    0    0   0   0    1    1    31
 01 001 01  0    0    0   0   0    1    1    39
 02 000 00  1    0    0   0   0    0    0    00
 03 001 01  0    0    0   0   0    1    1    41
 04 001 01  0    0    0   0   0    1    1    49
 05 001 01  0    0    0   0   0    1    1    51
 06 001 01  0    0    0   0   0    1    1    59
 07 001 01  0    0    0   0   0    1    1    61
 08 001 01  0    0    0   0   0    1    1    69
 09 001 01  0    1    0   0   0    1    1    71
 0a 001 01  0    0    0   0   0    1    1    79
 0b 001 01  0    0    0   0   0    1    1    81
 0c 001 01  0    0    0   0   0    1    1    89
 0d 001 01  0    0    0   0   0    1    1    91
 0e 001 01  0    0    0   0   0    1    1    99
 0f 001 01  0    0    0   0   0    1    1    A1
 10 001 01  1    1    0   0   0    1    1    D1
 11 001 01  1    1    0   0   0    1    1    D9
 12 001 01  1    1    0   0   0    1    1    E1
 13 001 01  1    1    0   0   0    1    1    C9
 14 001 01  1    1    0   0   0    1    1    B1
 15 001 01  1    1    0   0   0    1    1    C1
 16 001 01  1    1    0   0   0    1    1    B9
 17 001 01  1    1    0   0   0    1    1    A9
IRQ to pin mappings:
IRQ0 -> 0:0
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ5 -> 0:5
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ10 -> 0:10
IRQ11 -> 0:11
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
IRQ16 -> 0:16
IRQ17 -> 0:17
IRQ18 -> 0:18
IRQ19 -> 0:19
IRQ20 -> 0:20
IRQ21 -> 0:21
IRQ22 -> 0:22
IRQ23 -> 0:23
.................................... done.

cat /proc/interrupts gets me:

          CPU0
  0:     568313    IO-APIC-edge  timer
  1:       1359    IO-APIC-edge  i8042
  2:          0          XT-PIC  cascade
  7:          0    IO-APIC-edge  parport0
  8:          4    IO-APIC-edge  rtc
  9:          0   IO-APIC-level  acpi
 12:      14859    IO-APIC-edge  i8042
 14:      17983    IO-APIC-edge  ide0
 15:         92    IO-APIC-edge  ide1
 16:       2335   IO-APIC-level  ide2, saa7134[0]
 17:        142   IO-APIC-level  CMI8738
 19:      31779   IO-APIC-level  nvidia
 20:      72619   IO-APIC-level  ohci_hcd, eth0
 21:   86626041   IO-APIC-level  ehci_hcd
 22:         78   IO-APIC-level  ohci_hcd
NMI:          0
LOC:     566374
ERR:          0
MIS:          0

There is NO constant hi-load anymore, cool!

thanks, christian.

P.S: Ross, could you send a patch that could be applied using the patch-utility?

Re: IO-APIC on nforce2

[Maciej W. Rozycki]

On Tue, 13 Apr 2004, Ross Dickson wrote:

> Maciej forwarded me some an override patch he developed for another
> architecture where one could spec MP info as kernel args and that worked but
> we still had no nmi_debug=1 with the timer_ack=1 situation, which he then
> fixed in 2.6.3-mm3 but it got pulled for 2.6.4
> 
> Maciej, is that override code good to go on latest kernels? I am a novice to 
> acpi parsing etc.

 I suppose it should be fine.

> Unfortunately spurious interrupts contribute to disconnect rate - and there
> are lots of those in XT-PIC mode. I hacked the proc/interrupts code to view
> them on irq7 and it was really bad if I used local apic without io-apic.

 Spurious interrupts are normally recorded in the "ERR" entry in
/proc/interrupts, so you shouldn't have to record them separately.  And
there should be none counted, except perhaps a few arriving upon 
initialization of the local APIC.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: IO-APIC on nforce2

[Ross Dickson]

On Tuesday 13 April 2004 15:08, Len Brown wrote:
> On Mon, 2004-04-12 at 21:17, Ross Dickson wrote:
> 
> > I am working with 2.4.26-rc2 and have noticed a change with the the recent acpi?
> > update. The recent fix to stop unnecessary ioapic irq routing entries puts the 
> > following if statement into io_apic.c, io_apic_set_pci_routing()
> > 
> > 	/*
> > 	 * IRQs < 16 are already in the irq_2_pin[] map
> > 	 */
> > 	if (irq >= 16)
> > 		add_pin_to_irq(irq, ioapic, pin);
> > 
> > which prevents my io-apic patch from using that function to reprogram the
> > io-apic pin on irq0 from pin2 to pin0. 
> > 
> > As a quick fix you could drop the "if (irq >= 16)".
> > I don't know what harm if any that would do other than create unwanted
> > irq mapping entries as in the past.
> 
> I made that change -- sorry I broke your patch.
> No, I doubt it would matter if you hacked out "if (irq >=16)"
> for the time being.

Thanks Len, my patch was a bit of a quick hack anyway.

> 
> I haven't been following this thread closely, but
> http://bugme.osdl.org/show_bug.cgi?id=1203 says I should;-)
> 
> I understand that these boards have the timer attached to pin0
> in APIC mode, but that the BIOS says it is connected to pin2:
> 
> ACPI: INT_SRC_OVR (bus[0] irq[0x0] global_irq[0x2] polarity[0x0]
> trigger[0x0])
> 
> Wouldn't it be a simpler patch to recognize this board and simply
> disable this bogus BIOS INT_SRC_OVR?

I will go with you on this one as I have read the intel spec docs 
but have not yet learnt the acpi code base. 

Maciej forwarded me some an override patch he developed for another
architecture where one could spec MP info as kernel args and that worked but
we still had no nmi_debug=1 with the timer_ack=1 situation, which he then
fixed in 2.6.3-mm3 but it got pulled for 2.6.4

Maciej, is that override code good to go on latest kernels? I am a novice to 
acpi parsing etc.

Also some users reported clock skew with timer routed via io-apic pin0.
We never got to the bottom of that so I don't know if doing a pci quirk
on nforce2 would satisfy all for widespread use.

> 
> Also, what is the symptom of the XT-PIC timer?  Is it the source
> of the nForce2 hangs, or something else?  The latest message
> suggested that it caused a backround load on the system, but
> I don't recall hearing that one on this thread before.

Christian could we have more detail on "hi-load" XTPIC please?

Source of nforce2 hang is officially not commented on by Nvidia or 
AMD. 

>From what I know it appears now to be an Athlon to chipset problem as it has
also occured on an SIS-740 board. It seems to have less to do with the 
interrupt routing and everything to do with the timing of back to back C1 
disconnect cycles when those cycles are occuring at a high rate.

Unfortunately spurious interrupts contribute to disconnect rate - and there
are lots of those in XT-PIC mode. I hacked the proc/interrupts code to view
them on irq7 and it was really bad if I used local apic without io-apic.

What I think the mechanism is...
After C1 cycle has occured, if the HLT instruction (to disconnect again) is
executed sooner than about 1us after the interrupt that pulled cpu out
of the C1 cycle occured then likely -we die. The probability of this happening
greatly increases with the rate of C1 cycles. Evident by 1000Hz timer ticks
of 2.6 showing problem up more than 100Hz 2.4. 

Also acpi support for nforce2 in apic with io-apic mode is not widespread 
amongst major 2.4 distros to my knowledge - they stick with
XTPIC on install. Also in XTPIC mode the southbridge accesses provide
the delay time needed for stability in most cases but of course NVIDIA to my
knowledge have not published PCI irq routing registers to be able to manually 
route irqs so devices get stuck unnecessarily sharing a single irq in XTPIC 
mode. I tried a kernel hacked with the AMD 76x registers but they were 
obviously different. 

I think this is going to be a major headache when 2.6 is the main stream distro
as there is a lot of cheap nforce2 out there.
Judging from the silence from AMD hardware vendors- they seem prepared to
wait it out - maybe hoping everyone will go 64bit before it hits the fan?

-Ross.

> 
> thanks,
> -Len
> 
> 
> 
> 
> 

Re: IO-APIC on nforce2

[Len Brown]

On Mon, 2004-04-12 at 21:17, Ross Dickson wrote:

> I am working with 2.4.26-rc2 and have noticed a change with the the recent acpi?
> update. The recent fix to stop unnecessary ioapic irq routing entries puts the 
> following if statement into io_apic.c, io_apic_set_pci_routing()
> 
> 	/*
> 	 * IRQs < 16 are already in the irq_2_pin[] map
> 	 */
> 	if (irq >= 16)
> 		add_pin_to_irq(irq, ioapic, pin);
> 
> which prevents my io-apic patch from using that function to reprogram the
> io-apic pin on irq0 from pin2 to pin0. 
> 
> As a quick fix you could drop the "if (irq >= 16)".
> I don't know what harm if any that would do other than create unwanted
> irq mapping entries as in the past.

I made that change -- sorry I broke your patch.
No, I doubt it would matter if you hacked out "if (irq >=16)"
for the time being.

I haven't been following this thread closely, but
http://bugme.osdl.org/show_bug.cgi?id=1203 says I should;-)

I understand that these boards have the timer attached to pin0
in APIC mode, but that the BIOS says it is connected to pin2:

ACPI: INT_SRC_OVR (bus[0] irq[0x0] global_irq[0x2] polarity[0x0]
trigger[0x0])

Wouldn't it be a simpler patch to recognize this board and simply
disable this bogus BIOS INT_SRC_OVR?

Also, what is the symptom of the XT-PIC timer?  Is it the source
of the nForce2 hangs, or something else?  The latest message
suggested that it caused a backround load on the system, but
I don't recall hearing that one on this thread before.

thanks,
-Len

Re: IO-APIC on nforce2

[Ross Dickson]

On Tuesday 13 April 2004 14:01, really bensoo_at_soo_dot_com wrote:
> Very odd.  i'm using plain 2.6.5 with your 2.6.3

Yes odd, it's the first report of a "hi-load" XT-PIC issue I know of.

> APIC patches, and left all this io_apic_set_pci_routing()
> stuff in.  And, for this first time in who knows
> how long i seem to have a stable computer.  Actually
> been up more than eight days.

Sounds Very Good.

Are you using my io-apic patch with the apic ack delay or with the
C1idle version?
i.e. patched io_apic.c and apic.c and using kernel arg "apic_tack="
or patched io_apic.c and process.c and using kernel arg "idle=C1halt"?

My cat proc/cmdline
root=/dev/hdb2 idle=C1halt nmi_watchdog=1

Could you please cat /proc/interrupts.
I would like to see how irq0 is routed.
Mine looks like.

           CPU0
  0:     229404    IO-APIC-edge  timer
  1:        376    IO-APIC-edge  keyboard
  2:          0          XT-PIC  cascade
  9:          0   IO-APIC-level  acpi
 12:      13499    IO-APIC-edge  PS/2 Mouse
 14:      10482    IO-APIC-edge  ide0
 15:         73    IO-APIC-edge  ide1
 16:      27055   IO-APIC-level  nvidia
 20:      46913   IO-APIC-level  eth0, usb-ohci
 21:       3660   IO-APIC-level  ehci_hcd, NVIDIA nForce Audio
 22:          0   IO-APIC-level  usb-ohci
NMI:     229547
LOC:     229340
ERR:          0
MIS:          0

And from boot log
with my new timer setup

ENABLING IO-APIC IRQs
init IO_APIC IRQs
 IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected.
..TIMER: vector=0x31 pin1=2 pin2=-1
..MP-BIOS bug: 8254 timer not connected to IO-APIC INTIN2
..TIMER: Check if 8254 timer connected to IO-APIC INTIN0? ...
activating NMI Watchdog ... done.
testing NMI watchdog ... OK.
..TIMER: works OK on IO-APIC irq0
Using local APIC timer interrupts.
calibrating APIC timer ...

and my ioapic routing

number of MP IRQ sources: 15.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................

IO APIC #2......
.... register #00: 02000000
.......    : physical APIC id: 02
.......    : Delivery Type: 0
.......    : LTS          : 0
.... register #01: 00170011
.......     : max redirection entries: 0017
.......     : PRQ implemented: 0
.......     : IO APIC version: 0011
.... register #02: 00000000
.......     : arbitration: 00
.... IRQ redirection table:
 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
 00 001 01  0    0    0   0   0    1    1    31
 01 001 01  0    0    0   0   0    1    1    39
 02 000 00  1    0    0   0   0    0    0    00
 03 001 01  0    0    0   0   0    1    1    41
 04 001 01  0    0    0   0   0    1    1    49
 05 001 01  0    0    0   0   0    1    1    51
 06 001 01  0    0    0   0   0    1    1    59
 07 001 01  0    0    0   0   0    1    1    61
 08 001 01  0    0    0   0   0    1    1    69
 09 001 01  0    1    0   0   0    1    1    71
 0a 001 01  0    0    0   0   0    1    1    79
 0b 001 01  0    0    0   0   0    1    1    81
 0c 001 01  0    0    0   0   0    1    1    89
 0d 001 01  0    0    0   0   0    1    1    91
 0e 001 01  0    0    0   0   0    1    1    99
 0f 001 01  0    0    0   0   0    1    1    A1
 10 001 01  1    1    0   0   0    1    1    D9
 11 001 01  1    1    0   0   0    1    1    E1
 12 001 01  1    1    0   0   0    1    1    C9
 13 001 01  1    1    0   0   0    1    1    D1
 14 001 01  1    1    0   0   0    1    1    B1
 15 001 01  1    1    0   0   0    1    1    C1
 16 001 01  1    1    0   0   0    1    1    B9
 17 001 01  1    1    0   0   0    1    1    A9
IRQ to pin mappings:
IRQ0 -> 0:0
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ5 -> 0:5
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ10 -> 0:10
IRQ11 -> 0:11
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
IRQ16 -> 0:16
IRQ17 -> 0:17
IRQ18 -> 0:18
IRQ19 -> 0:19
IRQ20 -> 0:20
IRQ21 -> 0:21
IRQ22 -> 0:22
IRQ23 -> 0:23
.................................... done.
PCI: Using ACPI for IRQ routing


> 
> This is an old overclocked MSI K7N2 with the first
> revision of the nForce2 chipset, the one that's only
> supposed to have UDMA100 (dunno if that's the chipset
> or the MSI mboard: the 2.6.X kernels have always said
> during bootup that it's running UDMA133).  i use an
> old Tulip ethercard instead of the onboard LAN.
>
 
I am now using forcedeth for onboard ether. It works well and is
convenient when rebuilding and testing kernels and modules.

> This machine is the beater box: an HTPC and a 24/7
> file share client, compile and test stuff, play music
> thru an Audigy sound card, burn DVD's, play video
> files, many of these things at the same time.
> 
> Before this kernel i was lucky to have uptimes over
> two days.

Yes I remember how frustrating it felt to have linux regularly die and 
even fail to boot properly.

> 
> b
> 
> On Tue, Apr 13, 2004 at 11:17:31AM +1000, Ross Dickson wrote:
> > I am working with 2.4.26-rc2 and have noticed a change with the the recent acpi?
> > update. The recent fix to stop unnecessary ioapic irq routing entries puts the 
> > following if statement into io_apic.c, io_apic_set_pci_routing()
> > 
> > 	/*
> > 	 * IRQs < 16 are already in the irq_2_pin[] map
> > 	 */
> > 	if (irq >= 16)
> > 		add_pin_to_irq(irq, ioapic, pin);
> > 
> > which prevents my io-apic patch from using that function to reprogram the
> > io-apic pin on irq0 from pin2 to pin0. 
> 
> 
> 
> 

I did some more reading on kernel version re Maciej's 8259 ack patch
Ignore my comments in previous posting as patch was fully pulled from all
kernels at end of 2.6.3 ie. never appeared in 2.6.4 or later

>>I have not as yet downloaded 2.6.5xxx
>>From memory this 2.4.26-rc2 code should be very similar to the (2.6.5-linus)
>>but a bit different to the -mm series. For the -mm series I think you can drop
>>the "timer_ack=" lines from my changes as it still has Maciej Rozycki's 8259 
>>ack patch? The timer ack should already have been correctly set to off by it's
>>checking if the apic is an integrated one.

Shame as it seemed theoretically correct to me to not ack.
http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-04/2143.html

Regards
Ross.

Re: IO-APIC on nforce2

[really bensoo_at_soo_dot_com]

Very odd.  i'm using plain 2.6.5 with your 2.6.3
APIC patches, and left all this io_apic_set_pci_routing()
stuff in.  And, for this first time in who knows
how long i seem to have a stable computer.  Actually
been up more than eight days.

This is an old overclocked MSI K7N2 with the first
revision of the nForce2 chipset, the one that's only
supposed to have UDMA100 (dunno if that's the chipset
or the MSI mboard: the 2.6.X kernels have always said
during bootup that it's running UDMA133).  i use an
old Tulip ethercard instead of the onboard LAN.

This machine is the beater box: an HTPC and a 24/7
file share client, compile and test stuff, play music
thru an Audigy sound card, burn DVD's, play video
files, many of these things at the same time.

Before this kernel i was lucky to have uptimes over
two days.

b

On Tue, Apr 13, 2004 at 11:17:31AM +1000, Ross Dickson wrote:
> I am working with 2.4.26-rc2 and have noticed a change with the the recent acpi?
> update. The recent fix to stop unnecessary ioapic irq routing entries puts the 
> following if statement into io_apic.c, io_apic_set_pci_routing()
> 
> 	/*
> 	 * IRQs < 16 are already in the irq_2_pin[] map
> 	 */
> 	if (irq >= 16)
> 		add_pin_to_irq(irq, ioapic, pin);
> 
> which prevents my io-apic patch from using that function to reprogram the
> io-apic pin on irq0 from pin2 to pin0. 

Re: IO-APIC on nforce2

[Ross Dickson]

[-- Attachment #1: Type: text/plain, Size: 11113 bytes --]

Christian Kröner wrote

> I got a problem using LOCAL APIC and IO-APIC on my uniprocessor nforce2 board. 
> With recent kernels (latest -mm and 2.6.5-linus) the timer irq gets set to 
> XT-PIC, which results in having a constant hi-load of 15% (after booting) to 
> about 25% (after having the system run about 12 h). Earlier versions of -mm 
> set the timer-irq to IO-APIC-level (or edge, i dont remember it well) and i 
> never had any constant hi-load with these versions. Since mainline kernel 
> versions never ever set the timer irq to IO-APIC-{level,edge} i used to patch 
> them with the ross' nforce-patches, so that the timer-irq gets to be 
> IO-APCI-edge, which worked even though the patch applied with offset. Anyways 
> with the latest mm-kernels these patches dont work anymore. I could apply 
> them with offset but it seems the code isn't used or something else is wrong 
> since the timer-irq stays XT-PIC, which results in the problems above. Could 
> anyone point out, how to resolve this problem or tell me what I could do, to 
> get my timer-irq right? I'm sure willing to test patches... 
> Thanks in advance, christian. 
> - 


Hi Christian

I don't know why the high load on xtpic except maybe heaps of spurious irq's 
under the hood.

I am working with 2.4.26-rc2 and have noticed a change with the the recent acpi?
update. The recent fix to stop unnecessary ioapic irq routing entries puts the 
following if statement into io_apic.c, io_apic_set_pci_routing()

	/*
	 * IRQs < 16 are already in the irq_2_pin[] map
	 */
	if (irq >= 16)
		add_pin_to_irq(irq, ioapic, pin);

which prevents my io-apic patch from using that function to reprogram the
io-apic pin on irq0 from pin2 to pin0. 

As a quick fix you could drop the "if (irq >= 16)".
I don't know what harm if any that would do other than create unwanted
irq mapping entries as in the past.

As a better solution to work with the new code I have created a function to
change the pin an irq comes into the io-apic on and also re-initialise the 
io-apic to deal with the change. 

Here is the function for 2.4.26-rc2.

/*
 * reroute irq to different pin clearing old and enabling new
 */
static void __init replace_IO_APIC_pin_at_irq(unsigned int irq,
						int oldapic, int oldpin,
						int newapic, int newpin)
{
	struct IO_APIC_route_entry entry;
	unsigned long flags;
	/*
	 * read oldapic entry
	 */
	spin_lock_irqsave(&ioapic_lock, flags);
	*(((int*)&entry) + 0) = io_apic_read(oldapic, 0x10 + 2 * oldpin);
	*(((int*)&entry) + 1) = io_apic_read(oldapic, 0x11 + 2 * oldpin);
	spin_unlock_irqrestore(&ioapic_lock, flags);
	/*
	 * Check delivery_mode to be sure we're not clearing an SMI pin
	 */
	if (entry.delivery_mode == dest_SMI)
		return;
	/*
	 * clear oldpin on oldapic
	 */
	clear_IO_APIC_pin(oldapic, oldpin);
	/*
	 * reroute irq to newpin on newapic
	 */
	replace_pin_at_irq(irq, oldapic, oldpin, newapic, newpin);
	/*
	 * Enable newpin on newapic
	*/
	spin_lock_irqsave(&ioapic_lock, flags);
	io_apic_write(newapic, 0x10 + 2*newpin, *(((int *)&entry) + 0));
	io_apic_write(newapic, 0x11 + 2*newpin, *(((int *)&entry) + 1));
	spin_unlock_irqrestore(&ioapic_lock, flags);
}

I am now using this instead of the io_apic_set_pci_routing().
My modified check_timer() to work with it is as follows.

/*
 * This code may look a bit paranoid, but it's supposed to cooperate with
 * a wide range of boards and BIOS bugs.  Fortunately only the timer IRQ
 * is so screwy.  Thanks to Brian Perkins for testing/hacking this beast
 * fanatically on his truly buggy board.
 */
static inline void check_timer(void)
{
	extern int timer_ack;
	int pin1, pin2;
	int vector, i;

	/*
	 * get/set the timer IRQ vector:
	 */
	disable_8259A_irq(0);
	vector = assign_irq_vector(0);
	set_intr_gate(vector, interrupt[0]);

	/*
	 * Subtle, code in do_timer_interrupt() expects an AEOI
	 * mode for the 8259A whenever interrupts are routed
	 * through I/O APICs.  Also IRQ0 has to be enabled in
	 * the 8259A which implies the virtual wire has to be
	 * disabled in the local APIC.
	 */
	apic_write_around(APIC_LVT0, APIC_LVT_MASKED | APIC_DM_EXTINT);
	init_8259A(1);
	timer_ack = 1;
	enable_8259A_irq(0);

	pin1 = find_isa_irq_pin(0, mp_INT);
	pin2 = find_isa_irq_pin(0, mp_ExtINT);

	printk(KERN_INFO "..TIMER: vector=0x%02X pin1=%d pin2=%d\n", vector, pin1, pin2);

	if (pin1 != -1) {
		for(i=0;i<2;i++) {
			/*
			 * Ok, does IRQ0 through the IOAPIC work?
			 */
			unmask_IO_APIC_irq(0);
			if (timer_irq_works()) {
				if (nmi_watchdog == NMI_IO_APIC) {
					disable_8259A_irq(0);
					setup_nmi();
					enable_8259A_irq(0);
					check_nmi_watchdog();
				}
				printk(KERN_INFO "..TIMER: works OK on IO-APIC irq0\n" );
				return;
			}
			mask_IO_APIC_irq(0);
			if(!i) { /* try INTIN0 if INTIN2 failed */
				printk(KERN_ERR "..MP-BIOS bug: 8254 timer not connected to IO-APIC INTIN%d\n",pin1);
				printk(KERN_INFO "..TIMER: Check if 8254 timer connected to IO-APIC INTIN0? ...\n");
				replace_IO_APIC_pin_at_irq(0, 0, pin1, 0, 0);
				timer_ack=0;
				disable_8259A_irq(0);
			} else { /* restore settings */
				clear_IO_APIC_pin(0, 0);
				printk(KERN_ERR "..TIMER: 8254 timer not connected to IO-APIC INTIN0\n");
				timer_ack=1;
				enable_8259A_irq(0);
			}
		}
	}

	printk(KERN_INFO "...trying to set up timer (IRQ0) through the 8259A ... ");
	if (pin2 != -1) {
		printk("\n..... (found pin %d) ...", pin2);
		/*
		 * legacy devices should be connected to IO APIC #0
		 */
		setup_ExtINT_IRQ0_pin(pin2, vector);
		if (timer_irq_works()) {
			printk("works.\n");
			if (pin1 != -1)
				replace_pin_at_irq(0, 0, pin1, 0, pin2);
			else
				add_pin_to_irq(0, 0, pin2);
			if (nmi_watchdog == NMI_IO_APIC) {
				setup_nmi();
				check_nmi_watchdog();
			}
			return;
		}
		/*
		 * Cleanup, just in case ...
		 */
		clear_IO_APIC_pin(0, pin2);
	}
	printk(" failed.\n");

	if (nmi_watchdog) {
		printk(KERN_WARNING "timer doesn't work through the IO-APIC - disabling NMI Watchdog!\n");
		nmi_watchdog = 0;
	}

	printk(KERN_INFO "...trying to set up timer as Virtual Wire IRQ...");

	disable_8259A_irq(0);
	irq_desc[0].handler = &lapic_irq_type;
	apic_write_around(APIC_LVT0, APIC_DM_FIXED | vector);	/* Fixed mode */
	enable_8259A_irq(0);

	if (timer_irq_works()) {
		printk(" works.\n");
		return;
	}
	apic_write_around(APIC_LVT0, APIC_LVT_MASKED | APIC_DM_FIXED | vector);
	printk(" failed.\n");

	printk(KERN_INFO "...trying to set up timer as ExtINT IRQ...");

	init_8259A(0);
	make_8259A_irq(0);
	apic_write_around(APIC_LVT0, APIC_DM_EXTINT);

	unlock_ExtINT_logic();

	if (timer_irq_works()) {
		printk(" works.\n");
		return;
	}
	printk(" failed :(.\n");
	panic("IO-APIC + timer doesn't work! pester mingo@redhat.com");
}

This version loops twice on the "pin1" attempt, firstly trying the bios assigned
pin, then trying pin0 with no timer acks and the 8259 xtpic disabled.

I have not as yet downloaded 2.6.5xxx
From memory this 2.4.26-rc2 code should be very similar to the (2.6.5-linus)
but a bit different to the -mm series. For the -mm series I think you can drop
the "timer_ack=" lines from my changes as it still has Maciej Rozycki's 8259 
ack patch? The timer ack should already have been correctly set to off by it's
checking if the apic is an integrated one.

Here are the changes as a diff on the io_apic.c in 2.4.26-rc2

--- io_apic.c.orig	2004-04-08 15:56:53.000000000 +1000
+++ io_apic.c	2004-04-10 02:33:02.000000000 +1000
@@ -197,10 +197,48 @@ static void clear_IO_APIC (void)
 		for (pin = 0; pin < nr_ioapic_registers[apic]; pin++)
 			clear_IO_APIC_pin(apic, pin);
 }

 /*
+ * reroute irq to different pin clearing old and enabling new
+ */
+static void __init replace_IO_APIC_pin_at_irq(unsigned int irq,
+						int oldapic, int oldpin,
+						int newapic, int newpin)
+{
+	struct IO_APIC_route_entry entry;
+	unsigned long flags;
+	/*
+	 * read oldapic entry
+	 */
+	spin_lock_irqsave(&ioapic_lock, flags);
+	*(((int*)&entry) + 0) = io_apic_read(oldapic, 0x10 + 2 * oldpin);
+	*(((int*)&entry) + 1) = io_apic_read(oldapic, 0x11 + 2 * oldpin);
+	spin_unlock_irqrestore(&ioapic_lock, flags);
+	/*
+	 * Check delivery_mode to be sure we're not clearing an SMI pin
+	 */
+	if (entry.delivery_mode == dest_SMI)
+		return;
+	/*
+	 * clear oldpin on oldapic
+	 */
+	clear_IO_APIC_pin(oldapic, oldpin);
+	/*
+	 * reroute irq to newpin on newapic
+	 */
+	replace_pin_at_irq(irq, oldapic, oldpin, newapic, newpin);
+	/*
+	 * Enable newpin on newapic
+	*/
+	spin_lock_irqsave(&ioapic_lock, flags);
+	io_apic_write(newapic, 0x10 + 2*newpin, *(((int *)&entry) + 0));
+	io_apic_write(newapic, 0x11 + 2*newpin, *(((int *)&entry) + 1));
+	spin_unlock_irqrestore(&ioapic_lock, flags);
+}
+
+/*
  * support for broken MP BIOSs, enables hand-redirection of PIRQ0-7 to
  * specific CPU-side IRQs.
  */

 #define MAX_PIRQS 8
@@ -1582,11 +1620,11 @@ static inline void unlock_ExtINT_logic(v
  */
 static inline void check_timer(void)
 {
 	extern int timer_ack;
 	int pin1, pin2;
-	int vector;
+	int vector, i;

 	/*
 	 * get/set the timer IRQ vector:
 	 */
 	disable_8259A_irq(0);
@@ -1609,25 +1647,39 @@ static inline void check_timer(void)
 	pin2 = find_isa_irq_pin(0, mp_ExtINT);

 	printk(KERN_INFO "..TIMER: vector=0x%02X pin1=%d pin2=%d\n", vector, pin1, pin2);

 	if (pin1 != -1) {
-		/*
-		 * Ok, does IRQ0 through the IOAPIC work?
-		 */
-		unmask_IO_APIC_irq(0);
-		if (timer_irq_works()) {
-			if (nmi_watchdog == NMI_IO_APIC) {
+		for(i=0;i<2;i++) {
+			/*
+			 * Ok, does IRQ0 through the IOAPIC work?
+			 */
+			unmask_IO_APIC_irq(0);
+			if (timer_irq_works()) {
+				if (nmi_watchdog == NMI_IO_APIC) {
+					disable_8259A_irq(0);
+					setup_nmi();
+					enable_8259A_irq(0);
+					check_nmi_watchdog();
+				}
+				printk(KERN_INFO "..TIMER: works OK on IO-APIC irq0\n" );
+				return;
+			}
+			mask_IO_APIC_irq(0);
+			if(!i) { /* try INTIN0 if INTIN2 failed */
+				printk(KERN_ERR "..MP-BIOS bug: 8254 timer not connected to IO-APIC INTIN%d\n",pin1);
+				printk(KERN_INFO "..TIMER: Check if 8254 timer connected to IO-APIC INTIN0? ...\n");
+				replace_IO_APIC_pin_at_irq(0, 0, pin1, 0, 0);
+				timer_ack=0;
 				disable_8259A_irq(0);
-				setup_nmi();
+			} else { /* restore settings */
+				clear_IO_APIC_pin(0, 0);
+				printk(KERN_ERR "..TIMER: 8254 timer not connected to IO-APIC INTIN0\n");
+				timer_ack=1;
 				enable_8259A_irq(0);
-				check_nmi_watchdog();
 			}
-			return;
 		}
-		clear_IO_APIC_pin(0, pin1);
-		printk(KERN_ERR "..MP-BIOS bug: 8254 timer not connected to IO-APIC\n");
 	}

 	printk(KERN_INFO "...trying to set up timer (IRQ0) through the 8259A ... ");
 	if (pin2 != -1) {
 		printk("\n..... (found pin %d) ...", pin2);

Also attached as tarball if whitespace problems,
Hope this helps, Please cc me on responses,
Ross Dickson


[-- Attachment #2: nforce2-ioapic-rd-2.4.26-rc2.patch.tgz --]
[-- Type: application/x-tgz, Size: 1420 bytes --]

IO-APIC on nforce2

[Christian Kröner]

I got a problem using LOCAL APIC and IO-APIC on my uniprocessor nforce2 board. 
With recent kernels (latest -mm and 2.6.5-linus) the timer irq gets set to 
XT-PIC, which results in having a constant hi-load of 15% (after booting) to 
about 25% (after having the system run about 12 h). Earlier versions of -mm 
set the timer-irq to IO-APIC-level (or edge, i dont remember it well) and i 
never had any constant hi-load with these versions. Since mainline kernel 
versions never ever set the timer irq to IO-APIC-{level,edge} i used to patch 
them with the ross' nforce-patches, so that the timer-irq gets to be 
IO-APCI-edge, which worked even though the patch applied with offset. Anyways 
with the latest mm-kernels these patches dont work anymore. I could apply 
them with offset but it seems the code isn't used or something else is wrong 
since the timer-irq stays XT-PIC, which results in the problems above. Could 
anyone point out, how to resolve this problem or tell me what I could do, to 
get my timer-irq right? I'm sure willing to test patches...
Thanks in advance, christian.