Stuck in Interrupt handler before driver has registered irq? How can that be?

AustinMarton · 11-11-2009, 03:06 PM

Hi everyone,

We are developing for uClinux on the softcore nios2 processor on a Cyclone2 FPGA. Sometimes a bug in our VHDL code is making one of the interrupt lines stay active at startup. When this happen the system shows "Uncompressing Linux... Ok, booting the kernel." and then freezes there. I have used a kernel debugger and can see that it is stuck in a loop in the interrupt handler of the driver I have written, the irqhandler just keeps executing because the interrupt line is high. What I want to know is, how come the driver is handling interrupts BEFORE the driver has been initialised and registered that irq line?

On a normal boot it would show my printk's when the driver init is run and when the "request_irq" function is successful. But in this case no printks are displayed? Is the driver actually being loaded but the boot info is not printed because the interrupt takes priority?

Thanks,
Austin.

Anisha Kaul · 11-12-2009, 01:48 AM

Kindly post some code for us to see !!

AustinMarton · 11-15-2009, 04:10 PM

We are able to fix the problem with our hardware interrupt line, but I would like to understand how it is possible for the interrupt handler to be being called before the IRQ is registered???

If I boot with the interrupt line active and debug the kernel I can see it is stuck in my interrupt handler:
InterruptOccurs.jpg

Whereas on a normal boot the output would be:

Code:

[NiosII EDS]$ nios2-terminal
nios2-terminal: connected to hardware target using JTAG UART on cable
nios2-terminal: "USB-Blaster [USB 7-1.2]", device 1, instance 0
nios2-terminal: (Use the IDE stop button or Ctrl-C to terminate)

Linux version 2.6.27 (xxxxx@localhost.localdomain) (gcc version 3.4.6) #1700 PREEMPT Mon Nov 16 09:15:31 NZDT 2009


uClinux/Nios II
Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 2032
Kernel command line: 
PID hash table entries: 32 (order: 5, 128 bytes)
Dentry cache hash table entries: 1024 (order: 0, 4096 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Memory available: 4928k/2980k RAM, 0k/0k ROM (1578k kernel code, 1402k data)
Calibrating delay loop... 45.67 BogoMIPS (lpj=228352)
Mount-cache hash table entries: 512
net_namespace: 256 bytes
NET: Registered protocol family 16
Test are we here? static int __init c1588stats_device_init(void) 
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 512 (order: 0, 4096 bytes)
TCP bind hash table entries: 512 (order: -1, 2048 bytes)
TCP: Hash tables configured (established 512 bind 512)
TCP reno registered
NET: Registered protocol family 1
io scheduler noop registered
io scheduler deadline registered (default)
c1588stats_probe: c1588stats
c1588stats: IRQ request successful
c1588stats at 00000010,81820000 IRQ 6

It is not until that last line that the interrupt line is registered!

How can this be?