Problem with MPC8536 and external IRQs when using a loadable kernel module

Mark Pearson Mark.Pearson at bladenetwork.net
Fri Dec 10 07:45:15 EST 2010


I have a curious problem. This is on a MPC8636 based platform with
36-bit address space (that may or may not be important).

 

I have a very simple driver that registers for one of the external IRQs
with a trivial interrupt handler. It works great when built in as part
of the kernel.

 

However, if I make it a loadable module I get the crash shown below
(blade_irq is my IRQ handler).

 

-----Console capture ----------------------------------------

Unable to handle kernel paging request for instruction fetch

Faulting instruction address: 0xf31200f8

Oops: Kernel access of bad area, sig: 11 [#1]

COMPASS

Modules linked in: blade_pnic blade_irq_drv blade_cpld_mmap_drv

NIP: f31200f8 LR: c006a26c CTR: f31200f8

REGS: c057bdd0 TRAP: 0400   Not tainted  (2.6.32.12-131)

MSR: 00029000 <EE,ME,CE>  CR: 24024048  XER: 00000000

TASK = c0544318[0] 'swapper' THREAD: c057a000

GPR00: 00000000 c057be80 c0544318 00000012 00000000 08f9cac0 c058177c
ef820000 

GPR08: 00000200 c04a0000 f31200f8 c058a368 2dc6c000 1012b250 3ffbd200
00000000 

GPR16: 3ff91140 3ffb22f8 00000000 00000000 00000000 00000000 00000000
00000000 

GPR24: 00000000 00000000 00001600 c049fe4c 00000000 00000000 00000012
ea7975c0 

NIP [f31200f8] blade_irq+0x0/0x110 [blade_irq_drv]

LR [c006a26c] handle_IRQ_event+0x64/0x13c

Call Trace:

[c057be80] [c0547b80] 0xc0547b80 (unreliable)

[c057bea0] [c006c41c] handle_fasteoi_irq+0x68/0xf4

[c057beb0] [c0004da0] do_IRQ+0x98/0xb4

[c057bed0] [c000fe0c] ret_from_except+0x0/0x18

[c057bf90] [c0008168] cpu_idle+0x50/0xd8

[c057bfb0] [c000237c] rest_init+0x5c/0x70

[c057bfc0] [c0516850] start_kernel+0x238/0x2c4

[c057bff0] [c000039c] skpinv+0x2b4/0x2f0

Instruction dump:

7d6903a6 4e800420 3d60c007 396bb59c 7d6903a6 4e800420 38000000 38600000 

90040068 4e800020 38600000 4e800020 <9421fff0> 7c0802a6 3d20f312
bfc10008 

Kernel panic - not syncing: Fatal exception in interrupt

Rebooting in 180 seconds..

----- End of Console capture --------------------------------

 

I've done a few things

 

-          Verified the symbol address and the NIP match. They seem
correct

-          Removed all code from the IRQ handler and just return
IRQ_HANDLED. Still crashes

-          Put an infinite loop at the start of the IRQ handler - loop
isn't hit and still crashes so I assume the handler itself is never run.

-          I'm able to call my IRQ handler from the module init code and
it runs successfully. The problem is only when running in an interrupt
context.

-          I also as a somewhat stupid test passed the physical address
rather than the virtual address when registering the handler. Still
crashes (not sure if that's a valid thing to do to be honest, but I
figured it might be a virtual memory paging issue...grasping at
straws.....).

 

I do have a ticket in with Freescale support but they suggested I post
here for quicker and wider responses and if there are any ideas out
there I'd really appreciate them. Any chance anyone else has hit this
and knows a workaround or solution? Are there any examples of working
driver modules that use interrupts on the 8536 out there in case I've
done something really goofy in my code? Any suggestions of things to
try?

 

Thanks in advance 

 

Mark

 

 

 



Confidentiality Notice: This message and any attachments may contain  privileged and confidential information. If you have reason to believe that you are not the intended recipient or a person responsible for delivering this information to an intended recipient, you are hereby notified that any review, dissemination, distribution, or copying of this message is strictly prohibited. Please contact the sender immediately by reply mail and destroy all copies of the original message.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20101209/bb104bb9/attachment-0001.html>


More information about the Linuxppc-dev mailing list