# Kernel Panic - not syncing: Fatal error in interrupt

## iarwain

I get a "Kernel Panic - not syncing: Fatal error in interrupt". It happens in X and in terminal (with X closed). I don't know what can it be, but as it says about interrupts, here's my /proc/interrupts:

```
           CPU0       

  0:     865326          XT-PIC  timer

  1:       2453          XT-PIC  i8042

  2:          0          XT-PIC  cascade

  5:          0          XT-PIC  Ensoniq AudioPCI

  8:          2          XT-PIC  rtc

  9:       3193          XT-PIC  uhci_hcd, uhci_hcd, eth0

 10:       5387          XT-PIC  ide2

 11:      50365          XT-PIC  nvidia

 12:      45375          XT-PIC  i8042

 14:         50          XT-PIC  ide0

 15:         39          XT-PIC  ide1

NMI:          0 

ERR:          0

```

The kernel panic output displays a lot of things about ipv4. In all the crashes I was downloading comething from the net. I've recently switched from 2.4 to 2.6. In my opinion that "XT-PIC" is a bit suspicious. Any ideas?

Help me please.

----------

## GungHo

Hi,

looks similar on my box:

```
          CPU0       

  0:     512389          XT-PIC  timer

  1:       1112          XT-PIC  i8042

  2:          0          XT-PIC  cascade

  9:          0          XT-PIC  acpi

 10:        229          XT-PIC  bttv0, uhci_hcd, uhci_hcd, uhci_hcd

 11:        572          XT-PIC  sym53c8xx, EMU10K1, DE434/5 (0000:00:0a.0)

 12:       7215          XT-PIC  i8042

 14:       4400          XT-PIC  ide0

 15:        236          XT-PIC  ide1

NMI:          0 

LOC:     512241 

ERR:       2602

MIS:          0
```

Your NIC seems to share it's Interrupt with USB controllers. And you say, that the problem happened when y d'loaded anything. Have you tried to plug your NIC into another slot ?

Any other messages, when it happened, in /(var/log/messages for instance ?

----------

## iarwain

Hi. Thanks for your answer.

I've tried changing the NIC to another pci slot, but it always shares an interrupt with another device. So I've disabled USB support in the kernel, so that now my /proc/interrupts looks like this:

```
           CPU0       

  0:     422565          XT-PIC  timer

  1:       1127          XT-PIC  i8042

  2:          0          XT-PIC  cascade

  5:          0          XT-PIC  Ensoniq AudioPCI

  8:          2          XT-PIC  rtc

  9:       1350          XT-PIC  eth0

 10:       4036          XT-PIC  ide2

 11:      22802          XT-PIC  nvidia

 12:      12810          XT-PIC  i8042

 14:         43          XT-PIC  ide0

 15:         39          XT-PIC  ide1

NMI:          0 

ERR:          0

```

But I continue having the Kernel Panic. This is really weird. I never had this problem with 2.4 series for years.

And there's nothing realted in /var/log/messages.

Thanks.

----------

## wizatdiz

Just out of interest, what kernel are you running?

I have been having a problem with 2.6.11-rc4-mm1.  When I do a reboot from GDM, I get "Kernel panic - not syncing: Aiee, killing interrupt handler" with no additional information.

----------

## Gentree

Ahh this explains a lot.

One of my most reliable kernels : 2.6.9-nitro1 , started doing this all the time recently. It cost me one of my partitions.

Internestingly 2.6.10-nitro4 seems pretty immune on the same setup although I do occationally get a warning.

A fresh Win2k install has been crashing all morning , this may also explain that.

So too much IRQ sharing going on.

Is there no better way to orgainse this than just swapping things arround and hoping. Hardly a scientific approach.

I can reserve IRQs from the BIOS to enable manual config.

It seems I may be best to reserve an IRQ for the NIC but how?

There is kernel option to let Linux use or over-ride the BIOS irq settings . 

Can anyone give specifics here?

THX  :Cool: 

PS I have now disabled the onboard usb.serial and printer ports to free up some interrupts.

The additional uhci and ehci is from a PCI usb2 card.

This seems to have worked and 2k is stabel as well. It now looks like this:

```
           CPU0       

  0:    9465591          XT-PIC  timer

  1:        682          XT-PIC  i8042

  2:          0          XT-PIC  cascade

  3:          0          XT-PIC  Ensoniq AudioPCI

  7:      19865          XT-PIC  uhci_hcd

  8:          2          XT-PIC  rtc

  9:          0          XT-PIC  acpi

 10:          0          XT-PIC  uhci_hcd, eth1

 11:     327531          XT-PIC  aic7xxx, ehci_hcd, eth0

 12:     146534          XT-PIC  i8042

 14:         22          XT-PIC  ide0

 15:      13561          XT-PIC  ide1

NMI:          0 

LOC:    9465891 

ERR:        228
```

This looks so similar I guess you have similar mobos. (ABIT kx7-333)

----------

## iarwain

 *wizatdiz wrote:*   

> Just out of interest, what kernel are you running?
> 
> I have been having a problem with 2.6.11-rc4-mm1.  When I do a reboot from GDM, I get "Kernel panic - not syncing: Aiee, killing interrupt handler" with no additional information.

 

Mine is 2.6.10-gentoo-r6.

----------

## Gentree

I dont think this is actually a specific kernel version causing pbs. It is a kernel / irq issue.

My two main kernels are in my sig. 2.6.9-nitro1 has been rock solid for 9 mths until I put the new PCI USB card in . This seems to going a bit too far with the IRQ sharing and things get unstable . These errors are specifally caused by interrupts getting messed up it seems . 

I cured my problem by disableing as much as I could in BIOS. More of a work around but at least I am running now.

HTH  :Cool: 

----------

## transienteagle

Peeps,

This link might help

http://www.scyld.com/pci_irq.html

regards

TE

----------

## iarwain

I've been googling about this and it seems I'm not the only one with exactly the same problem:

http://www.linuxquestions.org/questions/showthread.php?s=&threadid=212359&perpage=15&pagenumber=1

Maybe I'll go back to 2.4.

Help!

----------

## iarwain

Good news, I've found a solution: disabling "CFQ I/O Scheduler" in the kernel. I've taken this solution fro another kernel-panic thread in this forum(I can't find the link).

Now I know how to solve it, but not why.

----------

