* [Xenomai-help] MSI Interrupt Crash
@ 2008-05-02 5:29 jeff koftinoff
2008-05-02 7:56 ` Philippe Gerum
0 siblings, 1 reply; 16+ messages in thread
From: jeff koftinoff @ 2008-05-02 5:29 UTC (permalink / raw)
To: xenomai
[-- Attachment #1: Type: text/html, Size: 5314 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Xenomai-help] MSI Interrupt Crash
2008-05-02 5:29 [Xenomai-help] MSI Interrupt Crash jeff koftinoff
@ 2008-05-02 7:56 ` Philippe Gerum
2008-05-02 8:50 ` Jan Kiszka
2008-05-02 14:17 ` Thomas Schaefer
0 siblings, 2 replies; 16+ messages in thread
From: Philippe Gerum @ 2008-05-02 7:56 UTC (permalink / raw)
To: jeff koftinoff; +Cc: xenomai
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; })
#define rthal_irq_chip_end(irq) ({ rthal_irq_descp(irq)->ipipe_end(irq, rthal_irq_descp(irq));
0; })
typedef irq_handler_t rthal_irq_host_handler_t;
--
Philippe.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [Xenomai-help] MSI Interrupt Crash
2008-05-02 7:56 ` Philippe Gerum
@ 2008-05-02 8:50 ` Jan Kiszka
2008-05-02 9:04 ` Philippe Gerum
2008-05-02 14:17 ` Thomas Schaefer
1 sibling, 1 reply; 16+ messages in thread
From: Jan Kiszka @ 2008-05-02 8:50 UTC (permalink / raw)
To: rpm; +Cc: xenomai
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. I'm still puzzled why the always-defined (in theory)
default handlers for enable/disable do not work.
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [Xenomai-help] MSI Interrupt Crash
2008-05-02 8:50 ` Jan Kiszka
@ 2008-05-02 9:04 ` Philippe Gerum
2008-05-02 9:07 ` Jan Kiszka
0 siblings, 1 reply; 16+ messages in thread
From: Philippe Gerum @ 2008-05-02 9:04 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai
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.
> Jan
>
--
Philippe.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [Xenomai-help] MSI Interrupt Crash
2008-05-02 9:04 ` Philippe Gerum
@ 2008-05-02 9:07 ` Jan Kiszka
2008-05-02 9:40 ` Philippe Gerum
2008-05-02 9:40 ` Philippe Gerum
0 siblings, 2 replies; 16+ messages in thread
From: Jan Kiszka @ 2008-05-02 9:07 UTC (permalink / raw)
To: rpm; +Cc: xenomai
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.
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [Xenomai-help] MSI Interrupt Crash
2008-05-02 9:07 ` Jan Kiszka
@ 2008-05-02 9:40 ` Philippe Gerum
2008-05-02 9:55 ` Jan Kiszka
2008-05-02 9:40 ` Philippe Gerum
1 sibling, 1 reply; 16+ messages in thread
From: Philippe Gerum @ 2008-05-02 9:40 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai
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 no 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.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [Xenomai-help] MSI Interrupt Crash
2008-05-02 9:40 ` Philippe Gerum
@ 2008-05-02 9:55 ` Jan Kiszka
2008-05-02 10:09 ` Philippe Gerum
0 siblings, 1 reply; 16+ messages in thread
From: Jan Kiszka @ 2008-05-02 9:55 UTC (permalink / raw)
To: rpm; +Cc: xenomai
Philippe Gerum wrote:
> 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.
Hmmmm... That makes me scratch my head. Could this change have some
impact on I-pipe as well? We are currently pulling hairs here as some
SCSI adapter is flooding us with spurious IRQs during init, but only if
I-pipe is enabled.
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Xenomai-help] MSI Interrupt Crash
2008-05-02 9:55 ` Jan Kiszka
@ 2008-05-02 10:09 ` Philippe Gerum
2008-05-02 10:42 ` Jan Kiszka
0 siblings, 1 reply; 16+ messages in thread
From: Philippe Gerum @ 2008-05-02 10:09 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai
Jan Kiszka wrote:
> Philippe Gerum wrote:
>> 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.
>
> Hmmmm... That makes me scratch my head. Could this change have some
> impact on I-pipe as well? We are currently pulling hairs here as some
> SCSI adapter is flooding us with spurious IRQs during init, but only if
> I-pipe is enabled.
>
__ipipe_enable_irq/__ipipe_disable_irq are not doing the right thing anymore,
but, AFAICT, this would only affect callers of ipipe_virtualize_irq and
ipipe_control_irq, using IPIPE_ENABLE_MASK.
Btw, are those APIC-based SMP spurious interrupts, or 8259-based ones?
--
Philippe.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Xenomai-help] MSI Interrupt Crash
2008-05-02 10:09 ` Philippe Gerum
@ 2008-05-02 10:42 ` Jan Kiszka
2008-05-02 10:53 ` Philippe Gerum
0 siblings, 1 reply; 16+ messages in thread
From: Jan Kiszka @ 2008-05-02 10:42 UTC (permalink / raw)
To: rpm; +Cc: xenomai
Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> 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.
>> Hmmmm... That makes me scratch my head. Could this change have some
>> impact on I-pipe as well? We are currently pulling hairs here as some
>> SCSI adapter is flooding us with spurious IRQs during init, but only if
>> I-pipe is enabled.
>>
>
> __ipipe_enable_irq/__ipipe_disable_irq are not doing the right thing anymore,
> but, AFAICT, this would only affect callers of ipipe_virtualize_irq and
> ipipe_control_irq, using IPIPE_ENABLE_MASK.
>
> Btw, are those APIC-based SMP spurious interrupts, or 8259-based ones?
x86-64, APIC, fasteoi. But it is no SMP artifact (maxcpus=1 makes no
difference). So far only one machine type is affected. And there is a
higher chance to get over the initialization with kernel 2.6.23 than
with .24. After that point, everything is fine.
Unfortunately, the box is highly contended (and also horribly slow at
boot), so testing and debugging is a lengthy process. Therefore, I'm
primarily collecting ideas about potential reasons.
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Xenomai-help] MSI Interrupt Crash
2008-05-02 10:42 ` Jan Kiszka
@ 2008-05-02 10:53 ` Philippe Gerum
2008-05-05 11:17 ` Jan Kiszka
0 siblings, 1 reply; 16+ messages in thread
From: Philippe Gerum @ 2008-05-02 10:53 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai
Jan Kiszka wrote:
> Philippe Gerum wrote:
>> Jan Kiszka wrote:
>>> Philippe Gerum wrote:
>>>> 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.
>>> Hmmmm... That makes me scratch my head. Could this change have some
>>> impact on I-pipe as well? We are currently pulling hairs here as some
>>> SCSI adapter is flooding us with spurious IRQs during init, but only if
>>> I-pipe is enabled.
>>>
>> __ipipe_enable_irq/__ipipe_disable_irq are not doing the right thing anymore,
>> but, AFAICT, this would only affect callers of ipipe_virtualize_irq and
>> ipipe_control_irq, using IPIPE_ENABLE_MASK.
>>
>> Btw, are those APIC-based SMP spurious interrupts, or 8259-based ones?
>
> x86-64, APIC, fasteoi. But it is no SMP artifact (maxcpus=1 makes no
> difference). So far only one machine type is affected. And there is a
> higher chance to get over the initialization with kernel 2.6.23 than
> with .24. After that point, everything is fine.
>
> Unfortunately, the box is highly contended (and also horribly slow at
> boot), so testing and debugging is a lengthy process. Therefore, I'm
> primarily collecting ideas about potential reasons.
>
Food for thought - no idea if that will make a difference for you, but I noticed
that doing it the other way was required for some boxes, so maybe yours is on
the other side of the fence...
diff --git a/arch/x86/kernel/io_apic_64.c b/arch/x86/kernel/io_apic_64.c
index bc82e4d..8d74218 100644
--- a/arch/x86/kernel/io_apic_64.c
+++ b/arch/x86/kernel/io_apic_64.c
@@ -1500,10 +1500,10 @@ static void ack_apic_level(unsigned int irq)
* from being delayed, waiting for a high priority interrupt
* handler running in a low priority domain to complete.
*/
+ __ack_APIC_irq();
spin_lock(&ioapic_lock);
__mask_IO_APIC_irq(irq);
spin_unlock(&ioapic_lock);
- __ack_APIC_irq();
#endif /* CONFIG_IPIPE */
}
--
Philippe.
^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [Xenomai-help] MSI Interrupt Crash
2008-05-02 10:53 ` Philippe Gerum
@ 2008-05-05 11:17 ` Jan Kiszka
0 siblings, 0 replies; 16+ messages in thread
From: Jan Kiszka @ 2008-05-05 11:17 UTC (permalink / raw)
To: rpm; +Cc: xenomai
Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> Jan Kiszka wrote:
>>>> Philippe Gerum wrote:
>>>>> 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.
>>>> Hmmmm... That makes me scratch my head. Could this change have some
>>>> impact on I-pipe as well? We are currently pulling hairs here as some
>>>> SCSI adapter is flooding us with spurious IRQs during init, but only if
>>>> I-pipe is enabled.
>>>>
>>> __ipipe_enable_irq/__ipipe_disable_irq are not doing the right thing anymore,
>>> but, AFAICT, this would only affect callers of ipipe_virtualize_irq and
>>> ipipe_control_irq, using IPIPE_ENABLE_MASK.
>>>
>>> Btw, are those APIC-based SMP spurious interrupts, or 8259-based ones?
>> x86-64, APIC, fasteoi. But it is no SMP artifact (maxcpus=1 makes no
>> difference). So far only one machine type is affected. And there is a
>> higher chance to get over the initialization with kernel 2.6.23 than
>> with .24. After that point, everything is fine.
>>
>> Unfortunately, the box is highly contended (and also horribly slow at
>> boot), so testing and debugging is a lengthy process. Therefore, I'm
>> primarily collecting ideas about potential reasons.
>>
>
> Food for thought - no idea if that will make a difference for you, but I noticed
> that doing it the other way was required for some boxes, so maybe yours is on
> the other side of the fence...
>
> diff --git a/arch/x86/kernel/io_apic_64.c b/arch/x86/kernel/io_apic_64.c
> index bc82e4d..8d74218 100644
> --- a/arch/x86/kernel/io_apic_64.c
> +++ b/arch/x86/kernel/io_apic_64.c
> @@ -1500,10 +1500,10 @@ static void ack_apic_level(unsigned int irq)
> * from being delayed, waiting for a high priority interrupt
> * handler running in a low priority domain to complete.
> */
> + __ack_APIC_irq();
> spin_lock(&ioapic_lock);
> __mask_IO_APIC_irq(irq);
> spin_unlock(&ioapic_lock);
> - __ack_APIC_irq();
> #endif /* CONFIG_IPIPE */
> }
Thanks, but makes no difference here. Will have to dig deeper - once
/this/ issue is on the top of my plist again... :-/
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Xenomai-help] MSI Interrupt Crash
2008-05-02 9:07 ` Jan Kiszka
2008-05-02 9:40 ` Philippe Gerum
@ 2008-05-02 9:40 ` Philippe Gerum
1 sibling, 0 replies; 16+ messages in thread
From: Philippe Gerum @ 2008-05-02 9:40 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Xenomai-help] MSI Interrupt Crash
2008-05-02 7:56 ` Philippe Gerum
2008-05-02 8:50 ` Jan Kiszka
@ 2008-05-02 14:17 ` Thomas Schaefer
2008-05-02 15:02 ` Philippe Gerum
1 sibling, 1 reply; 16+ messages in thread
From: Thomas Schaefer @ 2008-05-02 14:17 UTC (permalink / raw)
To: rpm, Jeff Koftinoff; +Cc: xenomai
>
> 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; })
> #define rthal_irq_chip_end(irq) ({ rthal_irq_descp(irq)-
> >ipipe_end(irq, rthal_irq_descp(irq));
> 0; })
>
> typedef irq_handler_t rthal_irq_host_handler_t;
We are using the current version from the SVN repository and those
changes are already in there.
Thomas
>
> --
> Philippe.
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
CONFIDENTIALITY NOTICE: This electronic mail message and any attachment hereto may contain confidential information of Meyer Sound Laboratories, Incorporated and is intended for the personal and confidential use of the designated recipient(s) only. If you are not the intended recipient (or responsible for delivering the message to the intended recipient), you have received this message in error and any review, distribution, or copying of this message or any attachment hereto is prohibited. If you have received this message in error, please promptly notify the sender and permanently delete it from your computer.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [Xenomai-help] MSI Interrupt Crash
2008-05-02 14:17 ` Thomas Schaefer
@ 2008-05-02 15:02 ` Philippe Gerum
0 siblings, 0 replies; 16+ messages in thread
From: Philippe Gerum @ 2008-05-02 15:02 UTC (permalink / raw)
To: Thomas Schaefer; +Cc: xenomai
Thomas Schaefer wrote:
>
>> 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; })
>> #define rthal_irq_chip_end(irq) ({ rthal_irq_descp(irq)-
>>> ipipe_end(irq, rthal_irq_descp(irq));
>> 0; })
>>
>> typedef irq_handler_t rthal_irq_host_handler_t;
>
> We are using the current version from the SVN repository and those
> changes are already in there.
>
Please send the output back:
--- ksrc/arch/x86/hal-common.c (revision 3734)
+++ ksrc/arch/x86/hal-common.c (working copy)
@@ -347,8 +347,20 @@
if (irq >= NR_IRQS)
return -EINVAL;
+ if (rthal_irq_descp(irq)->chip == NULL) {
+ printk(KERN_ERR "Xenomai: %s: no chip descriptor for irq %u\n", __FUNCTION__, irq);
+ return 0;
+ }
+
rthal_irq_desc_status(irq) &= ~IRQ_DISABLED;
+ if (rthal_irq_descp(irq)->chip->unmask == NULL) {
+ printk(KERN_ERR "Xenomai: NULL unmask handler for irq %u, chip %s (->enable=%p)\n",
+ irq, rthal_irq_descp(irq)->chip->name,
+ rthal_irq_descp(irq)->chip->enable);
+ return 0;
+ }
+
return rthal_irq_chip_enable(irq);
}
@@ -358,8 +370,20 @@
if (irq >= NR_IRQS)
return -EINVAL;
+ if (rthal_irq_descp(irq)->chip == NULL) {
+ printk(KERN_ERR "Xenomai: %s: no chip descriptor for irq %u\n", __FUNCTION__, irq);
+ return 0;
+ }
+
rthal_irq_desc_status(irq) |= IRQ_DISABLED;
+ if (rthal_irq_descp(irq)->chip->mask == NULL) {
+ printk(KERN_ERR "Xenomai: NULL mask handler for irq %u, chip %s (->disable=%p)\n",
+ irq, rthal_irq_descp(irq)->chip->name,
+ rthal_irq_descp(irq)->chip->disable);
+ return 0;
+ }
+
return rthal_irq_chip_disable(irq);
}
--
Philippe.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Xenomai-help] MSI Interrupt Crash
@ 2008-05-02 16:26 Thomas Schaefer
2008-05-04 8:46 ` Philippe Gerum
0 siblings, 1 reply; 16+ messages in thread
From: Thomas Schaefer @ 2008-05-02 16:26 UTC (permalink / raw)
To: rpm; +Cc: xenomai
[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]
> -----Original Message-----
> From: Philippe Gerum [mailto:philippe.gerum@domain.hid] On Behalf Of
> Philippe Gerum
> Sent: Friday, May 02, 2008 8:02 AM
> To: Thomas Schaefer
> Cc: Jeff Koftinoff; xenomai@xenomai.org
> Subject: Re: [Xenomai-help] MSI Interrupt Crash
>
> Thomas Schaefer wrote:
> >
> >> 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; })
> >> #define rthal_irq_chip_end(irq) ({ rthal_irq_descp(irq)-
> >>> ipipe_end(irq, rthal_irq_descp(irq));
> >> 0; })
> >>
> >> typedef irq_handler_t rthal_irq_host_handler_t;
> >
> > We are using the current version from the SVN repository and those
> > changes are already in there.
> >
>
> Please send the output back:
>
>
> --
> Philippe.
Here it is:
Xenomai: NULL unmask handler for irq 248, chip none (->enable=ffffffff8026f480)
Thomas
[-- Attachment #2: Type: text/html, Size: 7120 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [Xenomai-help] MSI Interrupt Crash
2008-05-02 16:26 Thomas Schaefer
@ 2008-05-04 8:46 ` Philippe Gerum
0 siblings, 0 replies; 16+ messages in thread
From: Philippe Gerum @ 2008-05-04 8:46 UTC (permalink / raw)
To: thomasschaefer; +Cc: xenomai
Thomas Schaefer wrote:
>> -----Original Message-----
>
>> From: Philippe Gerum [mailto:philippe.gerum@domain.hid] On Behalf Of
>
>> Philippe Gerum
>
>> Sent: Friday, May 02, 2008 8:02 AM
>
>> To: Thomas Schaefer
>
>> Cc: Jeff Koftinoff; xenomai@xenomai.org
>
>> Subject: Re: [Xenomai-help] MSI Interrupt Crash
>
>>
>
>> Thomas Schaefer wrote:
>
>> >
>
>> >> 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; })
>
>> >> #define rthal_irq_chip_end(irq) ({ rthal_irq_descp(irq)-
>
>> >>> ipipe_end(irq, rthal_irq_descp(irq));
>
>> >> 0; })
>
>> >>
>
>> >> typedef irq_handler_t rthal_irq_host_handler_t;
>
>> >
>
>> > We are using the current version from the SVN repository and those
>
>> > changes are already in there.
>
>> >
>
>>
>
>> Please send the output back:
>
>>
>
>>
>
>> --
>
>> Philippe.
>
>
>
> Here it is:
>
>
>
> Xenomai: NULL unmask handler for irq 248, chip none
You are trying to use an interrupt which has been allocated by the kernel, but
for which it has not defined any controller (i.e. set_irq_chip()); in that case,
mask/unmask are left to NULL pointers in the default invalid controller struct,
hence the crash. Xenomai can only use interrupts for which a valid controller
exists. You may want to check why interrupt #248 is not completely initialized.
--
Philippe.
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2008-05-05 11:17 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-05-02 5:29 [Xenomai-help] MSI Interrupt Crash jeff koftinoff
2008-05-02 7:56 ` Philippe Gerum
2008-05-02 8:50 ` Jan Kiszka
2008-05-02 9:04 ` Philippe Gerum
2008-05-02 9:07 ` Jan Kiszka
2008-05-02 9:40 ` Philippe Gerum
2008-05-02 9:55 ` Jan Kiszka
2008-05-02 10:09 ` Philippe Gerum
2008-05-02 10:42 ` Jan Kiszka
2008-05-02 10:53 ` Philippe Gerum
2008-05-05 11:17 ` Jan Kiszka
2008-05-02 9:40 ` Philippe Gerum
2008-05-02 14:17 ` Thomas Schaefer
2008-05-02 15:02 ` Philippe Gerum
-- strict thread matches above, loose matches on Subject: below --
2008-05-02 16:26 Thomas Schaefer
2008-05-04 8:46 ` Philippe Gerum
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.