Hi Tim,
Responses inline.
Regards,
Greg
On 4 November 2014 09:40, Tim Sander <t...@krieglstein.org> wrote:
> Hi Greg
> > Ah... Yes, using A9 (GICv1) which means you don't have grouping without
> the
> > security extensions.
> Ok switching the GIC to version 2 works seems to work. In a way that Linux
> still
> boots up and i get a FIQ.
>
> I have some problems still:
> It seems as if the exeption of the bugsplat below
> is called from handle_fasteoi_irq (or is it just interrupted?). Which
> would mean
> that the cpu is not jumping to the FIQ handler but the normal irq handler.
> This
> might point to a problem in the qemu FIQ code. But i am not sure, so the
> error
> might also be in the linux user mode.
>
> I have loaded a firmware my driver module with "set_fiq_handler" but the
> area
> where the fiq has landed (0xfff1240) is filled completly with zeros?
>
> Best regards
> Tim
>
> Bad mode in data abort handler detected
> Internal error: Oops - bad mode: 0 [#1] PREEMPT SMP ARM
> Modules linked in: firq(O) ipv6
> CPU: 0 PID: 103 Comm: systemd-udevd Tainted: G O 3.14.0 #1
> task: bf2b9300 ti: bf362000 task.ti: bf362000
> PC is at 0xffff1240
> LR is at handle_fasteoi_irq+0x9c/0x13c
> pc : [<ffff1240>] lr : [<8005cda0>] psr: 600f01d1
> sp : bf363e70 ip : 07a7e79d fp : 00000000
> r10: 76f92008 r9 : 80590080 r8 : 76e8e4d0
> r7 : f8200100 r6 : bf363fb0 r5 : bf008414 r4 : bf0083c0
> r3 : 80230d04 r2 : 0000002f r1 : 00000000 r0 : bf0083c0
> Flags: nZCv IRQs off FIQs off Mode FIQ_32 ISA ARM Segment user
>
It looks like we are in FIQ mode and interrupts have been masked.
> Control: 10c53c7d Table: 60004059 DAC: 00000015
> Process systemd-udevd (pid: 103, stack limit = 0xbf362240)
> Stack: (0xbf363e70 to 0xbf364000)
> 3e60: bf0083c0 00000000 0000002f
> 80230d04
> 3e80: bf0083c0 bf008414 bf363fb0 f8200100 76e8e4d0 80590080 76f92008
> 00000000
> 3ea0: 07a7e79d bf363e70 8005cda0 ffff1240 600f01d1 ffffffff 8005cd04
> 0000002f
> 3ec0: 0000002f 800598bc 8058cc70 8000ed00 f820010c 8059684c bf363ef8
> 80008528
> 3ee0: 80023730 80023744 200f0113 ffffffff bf363f2c 80012180 00000000
> 805baa00
> 3f00: 00000000 00000100 00000002 00000022 00000000 bf362000 76e8e4d0
> 80590080
> 3f20: 76f92008 00000000 0000000a bf363f40 80023730 80023744 200f0113
> ffffffff
> 3f40: bf007a14 8059ac00 00000000 0000000a ffff8dd7 00400140 bf0079c0
> 8058cc70
> 3f60: 00000022 00000000 f8200100 76e8e4d0 76f9201c 76f92008 00000000
> 80023af0
> 3f80: 8058cc70 8000ed04 f820010c 8059684c bf363fb0 80008528 00000000
> 76dd3b44
> 3fa0: 600f0010 ffffffff 0000000c 8001233c 00000000 00000000 76f93428
> 76f93428
> 3fc0: 76f93438 00000000 76f93448 0000000c 76e8e4d0 76f9201c 76f92008
> 00000000
> 3fe0: 00000000 7ec115c0 76f60914 76dd3b44 600f0010 ffffffff 9fffd821
> 9fffdc21
> [<8005cda0>] (handle_fasteoi_irq) from [<80230d04>] (gic_eoi_irq+0x0/0x4c)
>
It certainly looks like we are going down the standard IRQ patch as you
suggested. I'm not a Linux driver guy, but do you see any kind of activity
(break points, printfs, ...) through your FIQ handler?
> [<80230d04>] (gic_eoi_irq) from [<f8200100>] (0xf8200100)
> Code: ee02af10 f57ff06f e59d8000 e59d9004 (e599b00c)
> ---[ end trace 3dc3571209a017e1 ]---
> Kernel panic - not syncing: Fatal exception in interrupt
>
>
It is hard to determine entirely what is happening here based on this
info. I do have code of my own that routes KGDB interrupts as FIQs and
with the workaround I see the FIQs handled as expected. Some things we can
try to get more info in hopes of pinpointing where to look:
1. At the top of hw/intc/arm_gic.c there is the following commented out
line:
//#define DEBUG_GIC
Uncomment the line, rebuild and rerun. This will give us some trace on
what is going through the GIC code.
2. Run qemu with the "-d int" option which will print a message on each
interrupt. We should see an FIQ at some point if they are occurring. The
only issue is that there will be numerous IRQs, so you'll have to parse
through them to find an "exception 6 [FIQ].
3. If you set a breakpoint in your driver, is it possible to see that
FIQs are on from the kernel debugger. Clearly you have to try this from a
path where interrupts are masked. I see the following on my system
mentioned above:
...
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
...
