# Disabling IRQ#9

## binary.root

Hi guys.

Help please deal with the following problem.

When run gentoo. Reports on Disabling IRQ # 9. At this stage stops downloading for 30-40 seconds. And after downloading is normal.

dmesg report

 *Quote:*   

> 
> 
> [drm] radeon: irq initialized.
> 
> [drm] GART: num cpu pages 131072, num gpu pages 131072
> ...

 

lspci 

 *Quote:*   

> 
> 
> 00:00.0 Host bridge: Advanced Micro Devices [AMD] RS780 Host Bridge
> 
> 00:01.0 PCI bridge: Toshiba America Info Systems Device 9602
> ...

 

Regards Nazar.

----------

## NeddySeagoon

binary.root,

Welcome to Gentoo,

What is your IRQ9 used for, whatever it is either won't work at all or won't work properly with the IRQ disabled.  They may be nothing there too.

Please post your /proc/interrupts

The 

```
nobody cared
```

means that an IRQ9 happened but ho interrupt handler could be found to service the request.

There are some kernel and sometimes some BIOS options to fix this but lets see if its a real interrupt first.

----------

## binary.root

Thanks for the welcome.

Here is my proc / interrupts

 *Quote:*   

> 
> 
>          CPU0       CPU1       
> 
>   0:         25          2   IO-APIC-edge      timer
> ...

 

Regards Nazar.

----------

## NeddySeagoon

binary.root

```
9: 100 99901 IO-APIC-fasteoi acpi 
```

Tats thermal monitoring, power control, fan speed and the like. Everythng else will work normally but your system may overheat.

Put  irqpoll on the kernel line in grub meanwhile.  This is a slowdown all round but it gets your acpi interrupts working again by polling, which is much slower and more CPU intensive.

Please put your kernel .config file onto a pastebin site.  It has some options for dealing with things like this.  There are also other kernel command line options you can try. 

Read  /usr/src/linux/Documentation/kernel-parameters.txt

The very last thing to do is to flash your BIOS with an update - but there is no way to tell if that will help or not.

----------

## binary.root

Sorry that instantly not answer.

So really my CPU operating temperature is +82-89 C.

A critical point is 105 C.

Try to revise irqpool. Also tried acpi = noirq, acpi = strict, pci = noacpi.

None of the above written not helped.

My configuration kernel.

http://pastebin.com/vDhhWAkw

Dmesg in full.

http://pastebin.com/tc4hrYpu

Regards Nazar.

----------

## NeddySeagoon

binary.root,

A few things.

Your dmesg is truncated because your kernel ring buffer is too small.  You set this in the kernel with the option

```
 (18) Kernel log buffer size (16 => 64KB, 17 => 128KB)
```

 Note that each increment doubles the buffer size so my 18 allocates 256k. 

There is nothing obvious in your kernel or dmesg related to your IRQ 9 issue.  However, you should fix

```
 r600_cp: Failed to load firmware "radeon/R600_rlc.bin"

[drm:r600_startup] *ERROR* Failed to load firmware!

radeon 0000:01:05.0: disabling GPU acceleration
```

as you are missing some of the functionality of your graphics card.

As you have set 

```
CONFIG_DRM_RADEON=y

CONFIG_DRM_RADEON_KMS=y
```

the firmware needs to be built into your kernel too.

We cannot tell your CPU operating temperatue - only that ACPI interrupts are not working so you have no control.  It may be the fan is switched hard on, as that would be safeand the ACPI control then turns it down. 

The kernel contains special sections for some laptops - what system do you have ?

----------

## binary.root

Good evening.

Thank you that showed me what was the problem. So really the problem was the fact that you have described above. This is all evidence of my inattention. Because in hanbook it indicates.

 *Quote:*   

> what system do you have?

 

my system is amd64.

model laptop toshiba satellite a300.

Regards Nazar.

----------

## NeddySeagoon

binary.root,

Try turning on

```
 Reroute for broken boot IRQs
```

in your kernel.

The help says 

```
This option enables a workaround that fixes a source of

spurious interrupts. This is recommended when threaded

interrupt handling is used on systems where the generation of

superfluous "boot interrupts" cannot be disabled.

Some chipsets generate a legacy INTx "boot IRQ" when the IRQ

entry in the chipset's IO-APIC is masked (as, e.g. the RT

kernel does during interrupt handling). On chipsets where this

boot IRQ generation cannot be disabled, this workaround keeps

the original IRQ line masked so that only the equivalent "boot

IRQ" is delivered to the CPUs. The workaround also tells the

kernel to set up the IRQ handler on the boot IRQ line. In this

way only one interrupt is delivered to the kernel. Otherwise

the spurious second interrupt may cause the kernel to bring

down (vital) interrupt lines.
```

----------

## binary.root

Good evening.

Well I did as you said. But this is not a positive outcome is not allowed. Temperatures further held within 80-90C.

Regards Nazar.

----------

## NeddySeagoon

binary.root,

Please check dmesg for the 'nobody cared' messge.

If that's gone, its a success at fixing the IRQ problem

----------

