Jan Kiszka wrote:
> Philippe Gerum wrote:
>> Jan Kiszka wrote:
>>> Philippe Gerum wrote:
>>>> jeff koftinoff wrote:
>>>>> Hi all,
>>>>>
>>>>> I am currently writing an rtdm driver for an fpga card.
>>>>> I am using the latest Xenomai version from the svn repository and kernel
>>>>> version 2.6.24.5.
>>>>> This runs on a Core2Duo with a debian 64 bit version.
>>>>> The driver seems to work fine as long as I use legacy interrupts and not
>>>>> MSI's.
>>>>>
>>>>>
>>>>> As soon as I use pci_enable_msi before rtdm_irq_request I get:
>>>>>
>>>>> [ 4260.359093] fpga_driver :MSI Enabled
>>>>> [ 4260.359095] fpga_driver :IORESOURCE_IRQ IRQ: 248
>>>>> [ 4260.359109] Unable to handle kernel NULL pointer dereference at
>>>>> 0000000000000000 RIP:
>>>>> [ 4260.359113] [<0000000000000000>]
>>>>> [ 4260.359117] PGD 3b1f7067 PUD 3b1f6067 PMD 0
>>>>> [ 4260.359121] Oops: 0010 [1] SMP
>>>>> [ 4260.359125] CPU 1
>>>>> [ 4260.359127] Modules linked in: fpga_module(P) af_packet binfmt_misc
>>>>> rfcomm l2cap bluetooth ppdev ipv6 sbs container dock video output sbshc
>>>>> battery iptable_filter ip_tables x_tables ac coretemp max6650 sbp2
>>>>> parport_pc lp parport atl1 mii i2c_core psmouse serio_raw button shpchp
>>>>> iTCO_wdt iTCO_vendor_support intel_agp pci_hotplug evdev pcspkr ext3 jbd
>>>>> mbcache sg sr_mod cdrom ata_generic sd_mod pata_acpi usbhid hid ohci1394
>>>>> ieee1394 ahci pata_jmicron libata scsi_mod ehci_hcd uhci_hcd usbcore
>>>>> dm_mirror dm_snapshot dm_mod fan fuse
>>>>> [ 4260.359179] Pid: 7016, comm: insmod Tainted: P 2.6.24.5 #1
>>>>> [ 4260.359181] RIP: 0010:[<0000000000000000>] [<0000000000000000>]
>>>>> [ 4260.359185] RSP: 0000:ffff81003b23dc80 EFLAGS: 00010246
>>>>> [ 4260.359187] RAX: ffffffff805dc2c0 RBX: 0000000000000000 RCX:
>>>>> ffff810001018780
>>>>> [ 4260.359189] RDX: ffff81008099a000 RSI: 0000000000000000 RDI:
>>>>> 00000000000000f8
>>>>> [ 4260.359192] RBP: ffffffff882cc688 R08: 0000000000000000 R09:
>>>>> 00000000000000c1
>>>>> [ 4260.359194] R10: 0000000000000000 R11: 0000000000000000 R12:
>>>>> ffff81003ee87800
>>>>> [ 4260.359196] R13: ffffffff882cbee0 R14: 0000000000000000 R15:
>>>>> 000000000000000f
>>>>> [ 4260.359198] FS: 00002b43257436e0(0000) GS:ffff81003ec01700(0000)
>>>>> knlGS:0000000000000000
>>>>> [ 4260.359200] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>>>>> [ 4260.359202] CR2: 0000000000000000 CR3: 0000000032168000 CR4:
>>>>> 00000000000006e0
>>>>> [ 4260.359204] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
>>>>> 0000000000000000
>>>>> [ 4260.359206] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
>>>>> 0000000000000400
>>>>> [ 4260.359209] Process insmod (pid: 7016, threadinfo ffff81003b23c000,
>>>>> task ffff810032166fc0)
>>>>> [ 4260.359210] Stack: ffffffff8041e0ff ffff81003ee87800
>>>>> ffffffff802c8a58 ffff81003ee87800
>>>>> [ 4260.359216] ffff81003ee87800 ffff81003ee87800 ffffffff882ca374
>>>>> 0000000000000000
>>>>> [ 4260.359221] ffffffff882ca521 0000000000000001 ffff81003ee87870
>>>>> ffffffff882cc1a0
>>>>> [ 4260.359225] Call Trace:
>>>>> [ 4260.359231] [<ffffffff8041e0ff>] rthal_irq_enable+0x2f/0x40
>>>>> [ 4260.359236] [<ffffffff802c8a58>] rtdm_irq_request+0x48/0x60
>>>>> [ 4260.359242] [<ffffffff882ca374>]
>>>>> :fpga_module:pci_request_resources+0x104/0x1d0
>>>>> [ 4260.359246] [<ffffffff882ca521>] :fpga_module:pci_probe+0xe1/0x180
>>>>> [ 4260.359250] [<ffffffff8039ec88>] pci_device_probe+0xf8/0x170
>>>>> [ 4260.359256] [<ffffffff8040069c>] driver_probe_device+0x9c/0x1b0
>>>>> [ 4260.359259] [<ffffffff80400969>] __driver_attach+0xc9/0xd0
>>>>> [ 4260.359262] [<ffffffff804008a0>] __driver_attach+0x0/0xd0
>>>>> [ 4260.359265] [<ffffffff803ff8dd>] bus_for_each_dev+0x4d/0x80
>>>>> [ 4260.359270] [<ffffffff803ffcec>] bus_add_driver+0xac/0x220
>>>>> [ 4260.359274] [<ffffffff8039ef09>] __pci_register_driver+0x69/0xb0
>>>>> [ 4260.359280] [<ffffffff88069037>] :fpga_module:card_init+0x37/0x64
>>>>> [ 4260.359284] [<ffffffff802657be>] sys_init_module+0x18e/0x1a90
>>>>> [ 4260.359293] [<ffffffff80389b28>] _atomic_dec_and_lock+0x48/0x70
>>>>> [ 4260.359298] [<ffffffff80253330>] param_get_int+0x0/0x20
>>>>> [ 4260.359304] [<ffffffff8020c3f2>] system_call+0x92/0x97
>>>>> [ 4260.359308]
>>>>> [ 4260.359310]
>>>>> [ 4260.359310] Code: Bad RIP value.
>>>>> [ 4260.359313] RIP [<0000000000000000>]
>>>>> [ 4260.359315] RSP <ffff81003b23dc80>
>>>>> [ 4260.359316] CR2: 0000000000000000
>>>>> [ 4260.359325] ---[ end trace 502b14894d3ed93b ]---
>>>>>
>>>>> Any advice?
>>>>>
>>>> Does this help?
>>>>
>>>> --- include/asm-x86/wrappers_64.h (revision 3719)
>>>> +++ include/asm-x86/wrappers_64.h (revision 3720)
>>>> @@ -31,8 +31,8 @@
>>>> #define rthal_irq_descp(irq) (irq_desc + irq)
>>>> #define rthal_irq_desc_status(irq) (rthal_irq_descp(irq)->status)
>>>>
>>>> -#define rthal_irq_chip_enable(irq) ({
>>>> rthal_irq_descp(irq)->chip->enable(irq); 0; })
>>>> -#define rthal_irq_chip_disable(irq) ({
>>>> rthal_irq_descp(irq)->chip->disable(irq); 0; })
>>>> +#define rthal_irq_chip_enable(irq) ({
>>>> rthal_irq_descp(irq)->chip->unmask(irq); 0; })
>>>> +#define rthal_irq_chip_disable(irq) ({
>>>> rthal_irq_descp(irq)->chip->mask(irq); 0; })
>>> Will probably create a BUG on disable, as not all irq_chips define
>>> unmask IIRC.
>> The "rule" has evolved from defining enable/disable to always defining
>> mask/unmask
>> since 2.6.19 it seems. This is a per-arch issue anyway, and as far as x86_64
>> is concerned,
>> 2.6.24 chip descriptors all define mask/unmask.
>>
>> Still, the ipipe has to be fixed to, since __ipipe_enable/disable_irq still
>> call ->enable(), ->disable().
>>
>> I'm still puzzled why the always-defined (in theory)
>>> default handlers for enable/disable do not work.
>>>
>> The only explanation would be that set_irq_chip() is not called for
>> that interrupt; in which case, we would be fixing a real problem but still
>> different from the initial issue.
>
> That's my point: Let's check first if set_irq_chip() was called for this
> line (adding some printk instrumentation should suffice) and why we
> still find 'enable' as NULL.
>
What bothers me even more regarding that issue, is that _all_ interrupts
managed by that chip should have caused the default handlers to be installed
for the descriptor, so this even means that not a single interrupt was
registered
to be managed by that descriptor. Weird.
PS: We really do want to call mask/unmask instead of disable/enable in any
case, because ->disable()
became a nop in 2.6.21, so we just can't rely on its default action anyway.
This is a separate
issue, that caused rthal_irq_disable() not to actually mask the interrupt when
the I/O APIC is enabled.
> Jan
>
--
Philippe.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
