# Network causing IRQ storm



## bseiva (Mar 22, 2012)

Hi

I'm porting a Linux program to FreeBSD. This program consists of two threads: one that reads the status of some custom hardware and other that sends this information over the network.

The reader thread accesses the hardware via inb/outb calls, after I get permission with i386_set_ioperm.

The thread responsible for the network just opens a socket, waits for commands and sends the results to the client program. The client program is basically a while(1) loop that keeps sending "read command" to my threaded program (the server).

Whenever I execute my threaded program, after a (short) while I get

```
interrupt storm detected on "irq5:"; throttling interrupt source
```
several times. The keyboard goes unresponsive, so I'm not able to do anything.

To those wondering (I snipped off other irq's):
[CMD=]vmstat -i[/cmd]

```
interrupt             total     rate
irq5: ohci0 ehci0        57        1
```

Bear in mind that I issued this command immediately after boot, because my keyboard freezes when I execute the server. As far as I know, ohci0 and ehci0 are USB controllers, right? The only USB device in this system is the keyboard. So I'm kind of lost trying to figure out the real cause of the problem.

I've disabled the reader thread, letting only the 'networker' thread run, and the problem also surfaced.

I'm completely new to FreeBSD, but did my homework, and searched all the Internets and this and other forums, and did not find the solution. I already tried to raise (and I mean *really raise*, up high) hw.intr_storm_threshold, but to no avail. Recompiling the kernel is not an option.

Thanks in advance.


----------



## bseiva (Mar 22, 2012)

*Little Update*



			
				bseiva said:
			
		

> I've disabled the reader thread, letting only the 'networker' thread run, and the problem also surfaced.



I've forgotten that the 'networker' thread uses functions that access directly my custom hardware.

So it all boils down to this: if I access my custom hardware really fast, an unrelated interrupt will trigger, and will overwhelm the kernel. 

The range of ports accessed is from 0x300 to 0x333, in hexadecimal. The interrupt that gets triggered is always the one associated to USB drivers, no matter if I change the IRQ number.


----------

