Hi,

Sorry for the late reply.

Ettore Pedretti wrote:
> Hi,
> 
> You gave me two test modules. I sent you the trace of the second
> module plus the trace of the attach procedure.
> 
> I am now sending the trace of the very first module you sent:
> 
> insmod irqTest.ko
> 
> irq_test: before rtdm_irq_request
> irq_test: after rtdm_irq_request (err = 0)
> irq_test: before rtdm_irq_enable
> irq_test: after rtdm_irq_enable (err = 0)
> 
> Is this what you meant?
> 
Yes, thank you. The bug is definitely in the function ni_E_init(). 
Considering the number of cards supported by the ni_pcimio driver, the 
problem that you are facing is bound to occur in other configuration.

I will update the NI driver with configurable debug messages. I will 
come back as soon as possible. Sorry for the lack of reactivity, my free 
time is quite reduced during this pre-Christmas period.

> Please note that all the previous xenomai and kernel patches are in place.
> Cheers
> Ettore
> 
> 
> 2009/12/15 Alexis Berlemont <berlemont.h...@free.fr>:
>> Ettore Pedretti wrote:
>>> Hi,
>>>
>>> I have added routeirq to the kernel parameters:
>>>
>>> kernel          /boot/vmlinuz-2.6.31.1 root=LABEL=ROOTFS_TEST ro noht
>>> mem=2048M memmap=1024M pci=routeirq
>>>
>>> When I insert your test module:
>>>
>>> fangorn:~/control/CHAMP/irqTest# insmod test_module.ko
>>>
>>> The trace is:
>>>
>>> rq_test: before request_irq
>>> irq_test: after request_irq (err = 0)
>> Great ! and did the "rtdm test module" behave well ?
>>
>> Could you also send the kernel traces (with the debug messages we added).
>>
>>> When I try the attach procedure:
>>>
>>> analogy_config analogy0 analogy_ni_pcimio
>>> Message from sysl...@fangorn at Dec 15 07:39:25 ...
>>>  kernel:Oops: 0000 [#1] PREEMPT SMP
>>>
>>> Message from sysl...@fangorn at Dec 15 07:39:25 ...
>>>  kernel:last sysfs file: /sys/class/net/lo/operstate
>>>
>>> Message from sysl...@fangorn at Dec 15 07:39:25 ...
>>>  kernel:Process analogy_config (pid: 3556, ti=f6c48000 task=f790c730
>>> task.ti=f6c48000)
>>>
>>> Message from sysl...@fangorn at Dec 15 07:39:25 ...
>>>  kernel:I-pipe domain Linux
>>>
>>> Message from sysl...@fangorn at Dec 15 07:39:25 ...
>>>  kernel:Stack:
>>>
>>> Message from sysl...@fangorn at Dec 15 07:39:25 ...
>>>  kernel:Call Trace:
>>>
>>> Message from sysl...@fangorn at Dec 15 07:39:25 ...
>>>  kernel:Code: 8b 45 9c e8 f2 f1 fa ff 89 c2 83 f8 01 0f 85 d4 fe ff ff
>>> 8b 55 9c 8b 82 74 01 00 00 8b 00 f6 40 3c 06 0f 84 22 01 00 00 8b 42
>>> 18 <8b> 40 04 89 45 b0 8b 40 14 8b 40 04 85 c0 0f 84 0b 01 00 00 31
>>>
>>> Message from sysl...@fangorn at Dec 15 07:39:25 ...
>>>  kernel:EIP: [<f8c7f029>] ni_E_init+0x267/0xff1 [analogy_ni_mio]
>>> SS:ESP 0068:f6c49dc8
>>>
>>> Message from sysl...@fangorn at Dec 15 07:39:25 ...
>>>  kernel:CR2: 0000000000000004
>>>
>>> And the trace:
>>>
>>> a4l: analogy_ni_pcimio: pcimio_attach: found pci-6711 board
>>> mite 0000:04:01.0: PCI->APIC IRQ transform: INT A -> IRQ 48
>>> mite 0000:04:01.0: setting latency timer to 64
>>> a4l: MITE: 0xd0801000 mapped to f8e32000
>>> a4l: DAQ: 0xd0800000 mapped to f8e36000
>>> a4l: MITE: version = 1, type = 1, mite mode = 1, interface mode = 3
>>> a4l: MITE: num channels = 3, write post fifo depth = 1, wins = 0, iowins =
>>> 2
>>> a4l: analogy_ni_pcimio: pcimio_attach: found irq 48
>>> BUG: unable to handle kernel NULL pointer dereference at 00000004
>>> IP: [<f8c7f029>] ni_E_init+0x267/0xff1 [analogy_ni_mio]
>>> *pde = 00000000
>>> Oops: 0000 [#1] PREEMPT SMP
>>> last sysfs file: /sys/class/net/lo/operstate
>>> Modules linked in: test_module xeno_native analogy_ni_pcimio
>>> analogy_ni_mio analogy_ni_tio analogy_8255 analogy_ni_mite
>>> xeno_analogy xeno_rtdm astropci ext3 jbd mbcache ide_pci_generic
>>> ide_core ata_piix e1000 sata_mv libata unix [last unloaded:
>>> scsi_wait_scan]
>>>
>>> Pid: 3556, comm: analogy_config Not tainted (2.6.31.1 #1) X6DA8
>>> EIP: 0060:[<f8c7f029>] EFLAGS: 00010202 CPU: 1
>>> EIP is at ni_E_init+0x267/0xff1 [analogy_ni_mio]
>>> EAX: 00000000 EBX: f8a24280 ECX: f8c33e6c EDX: f8c33e60
>>> ESI: 00000000 EDI: f8c33e60 EBP: f6c49e38 ESP: f6c49dc8
>>>  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
>>> Process analogy_config (pid: 3556, ti=f6c48000 task=f790c730
>>> task.ti=f6c48000)
>>> I-pipe domain Linux
>>> Stack:
>>>  f6c49dd0 c10143ee f6c49dd8 f8c33e60 f6c49de0 c105ad27 f6c49dfc f8a10a5d
>>> <0> f8c2de00 00000000 00000001 f8c33e94 fffffff0 f6c49e14 f8c2e118
>>> 00000001
>>> <0> f8c30d0d f8c33e88 f8c33e60 f6c49e38 f8c2eccf 00000001 f8c33e60
>>> 00000030
>>> Call Trace:
>>>  [<c10143ee>] ? unmask_IO_APIC_irq+0xd/0xf
>>>  [<c105ad27>] ? xnintr_enable+0xb/0xd
>>>  [<f8a10a5d>] ? rtdm_irq_request+0x48/0x5e [xeno_rtdm]
>>>  [<f8c2de00>] ? a4l_handle_irq+0x0/0x1a [xeno_analogy]
>>>  [<f8c2e118>] ? __a4l_request_irq+0x33/0x39 [xeno_analogy]
>>>  [<f8c2eccf>] ? a4l_request_irq+0x98/0xaf [xeno_analogy]
>>>  [<f8c8dd8a>] ? pcimio_attach+0x54d/0x664 [analogy_ni_pcimio]
>>>  [<f8c2cfef>] ? a4l_assign_driver+0x61/0x134 [xeno_analogy]
>>>  [<f8c2d2ba>] ? a4l_device_attach+0x54/0x6d [xeno_analogy]
>>>  [<c106641a>] ? xnshadow_ppd_get+0x4f/0x58
>>>  [<f8c2d54f>] ? a4l_ioctl_devcfg+0x57/0x104 [xeno_analogy]
>>>  [<f8c2f36f>] ? a4l_rt_ioctl+0x33/0x3a [xeno_analogy]
>>>  [<f8a0f3e6>] ? __rt_dev_ioctl+0xd1/0xd8 [xeno_rtdm]
>>>  [<f8a11e77>] ? sys_rtdm_open+0x5c/0x64 [xeno_rtdm]
>>>  [<f8a11dde>] ? sys_rtdm_ioctl+0x29/0x2b [xeno_rtdm]
>>>  [<c1069ade>] ? losyscall_event+0xa9/0x190
>>>  [<c10567fe>] ? __ipipe_dispatch_event+0xdf/0x201
>>>  [<c1069a35>] ? losyscall_event+0x0/0x190
>>>  [<c10167d1>] ? __ipipe_syscall_root+0x3b/0xc4
>>>  [<c1002cfd>] ? system_call+0x2d/0x4f
>>> Code: 8b 45 9c e8 f2 f1 fa ff 89 c2 83 f8 01 0f 85 d4 fe ff ff 8b 55
>>> 9c 8b 82 74 01 00 00 8b 00 f6 40 3c 06 0f 84 22 01 00 00 8b 42 18 <8b>
>>> 40 04 89 45 b0 8b 40 14 8b 40 04 85 c0 0f 84 0b 01 00 00 31
>>> EIP: [<f8c7f029>] ni_E_init+0x267/0xff1 [analogy_ni_mio] SS:ESP
>>> 0068:f6c49dc8
>>> CR2: 0000000000000004
>>> ---[ end trace bcff6beb2ba30576 ]---
>>>
>>> Ettore
>>>
>>>
>>> 2009/12/2 Alexis Berlemont <berlemont.h...@free.fr>:
>>>> Hi,
>>>>
>>>> Ettore Pedretti wrote:
>>>>> Hi,
>>>> Sorry for the late reply.
>>>>
>>>>> I applied your kernel patch before applying the xenomai patch. When I
>>>>> insert the kernel patch I obtain:
>>>>>
>>>>> insmod: error inserting 'test_module.ko': -1 Function not implemented
>>>> Yes. request_irq returns an error because the io_apic did not register
>>>> the interrupt.
>>>>
>>>>> Attached is the content of dmesg from boot to module insertion.
>>>> Thanks to your traces and a look at the x86-specific pci code in the
>>>> kernel (arch/x86/pci), I think I understand the way it works.
>>>>
>>>> The fact that request_irq return -ENOSYS is normal: the irq is not
>>>> "enabled". In order to enable the pci card's irq, we have to enable the
>>>> pci device (thanks to a call to pci_enable()). This operation will route
>>>> the PCI interrupt line to an io_apic irq; after that, the io_apic will
>>>> register the irq. Once this procedure is complete, the irq is made
>>>> available for Linux.
>>>>
>>>> That is the reason why, our little Linux test module failed and our
>>>> little RTDM test module crashed.
>>>>
>>>> If you had the kernel boot argument "pci=routeirq", both test modules
>>>> should insmod fine because all pci interrupt are "enabled" during the
>>>> PCI discovery.
>>>>
>>>> Concerning the analogy driver, that does not explain the problem because
>>>> the pci board enabling is _supposed_ to be ok. Could you also test the
>>>> attach procedure with kernel boot argument specified above ?
>>>>
>>>>> Cheers
>>>>> -ep
>>>>>
>>>>> ps. I am leaving the mountain tomorrow and will be travelling until
>>>>> Friday. I hope I will be able to test the machine at distance without
>>>>> crashing it for good.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2009/11/29 Alexis Berlemont <berlemont.h...@free.fr>:
>>>>>> Hi,
>>>>>>
>>>>>> Ettore Pedretti wrote:
>>>>>>> 2009/11/26 Alexis Berlemont <berlemont.h...@free.fr>:
>>>>>>>> On Thu, Nov 26, 2009 at 9:22 AM, Ettore Pedretti <epedr...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>> Hi Alexis,
>>>>>>>>>
>>>>>>>>> I applied the patch to my local git repository:
>>>>>>>>>
>>>>>>>>> fangorn:/usr/src#
>>>>>>>>> cd xenomai-head/
>>>>>>>>> fangorn:/usr/src/xenomai-head# git apply ../patch_debug_1.diff
>>>>>>>>> patch_debug_1.diff
>>>>>>>>> fangorn:/usr/src/xenomai-head# git apply ../patch_debug_1.diff
>>>>>>>>> ../patch_debug_1.diff:14: trailing whitespace.
>>>>>>>>>    rtdm_printk("\t handler=%p, irq=%d, cookie=%p\n",
>>>>>>>>> warning: 1 line adds whitespace errors.
>>>>>>>>>
>>>>>>>>> Then created a debian package:
>>>>>>>>>
>>>>>>>>> git-buildpackage -us -uc -rfakeroot --git-debian-branch=master
>>>>>>>>> --git-upstream-branch=origin/master --git-ignore-new
>>>>>>>>>
>>>>>>>>> built a new kernel package:
>>>>>>>>>
>>>>>>>>> fakeroot make-kpkg --initrd --added-patches xenomai
>>>>>>>>> --revision=ipipeComedi.2.4.06 --config menuconfig binary-arch
>>>>>>>>>
>>>>>>>>> and installed the Debian package with dpkg -i
>>>>>>>>>
>>>>>>>>> This is what happens when i insert the module into the kernel:
>>>>>>>>>
>>>>>>>>> fangorn:~/control/CHAMP/irqTest# insmod irqTest.ko
>>>>>>>>> Killed
>>>>>>>>>
>>>>>>>>> Message from sysl...@fangorn at Nov 26 00:09:52 ...
>>>>>>>>>  kernel:Oops: 0000 [#1] PREEMPT SMP
>>>>>>>>> fangorn:~/control/CHAMP/irqTest#
>>>>>>>>> Message from sysl...@fangorn at Nov 26 00:09:52 ...
>>>>>>>>>  kernel:last sysfs file: /sys/class/net/lo/operstate
>>>>>>>>>
>>>>>>>>> Message from sysl...@fangorn at Nov 26 00:09:52 ...
>>>>>>>>>  kernel:Process insmod (pid: 3566, ti=f6c02000 task=f78634b0
>>>>>>>>> task.ti=f6c02000)
>>>>>>>>>
>>>>>>>>> Message from sysl...@fangorn at Nov 26 00:09:52 ...
>>>>>>>>>  kernel:I-pipe domain Linux
>>>>>>>>>
>>>>>>>>> Message from sysl...@fangorn at Nov 26 00:09:52 ...
>>>>>>>>>  kernel:Stack:
>>>>>>>>>
>>>>>>>>> Message from sysl...@fangorn at Nov 26 00:09:52 ...
>>>>>>>>>  kernel:Call Trace:
>>>>>>>>>
>>>>>>>>> Message from sysl...@fangorn at Nov 26 00:09:52 ...
>>>>>>>>>  kernel:Code:  Bad EIP value.
>>>>>>>>>
>>>>>>>>> Message from sysl...@fangorn at Nov 26 00:09:52 ...
>>>>>>>>>  kernel:EIP: [<00000000>] 0x0 SS:ESP 0068:f6c03f18
>>>>>>>>>
>>>>>>>>> Message from sysl...@fangorn at Nov 26 00:09:52 ...
>>>>>>>>>  kernel:CR2: 0000000000000000
>>>>>>>>>
>>>>>>>>> dmesg after insmod:
>>>>>>>>>
>>>>>>>>> irq_test: before rtdm_irq_request
>>>>>>>>> BUG: unable to handle kernel NULL pointer dereference at (null)
>>>>>>>>> IP: [<(null)>] (null)
>>>>>>>>> *pde = 00000000
>>>>>>>>> Oops: 0000 [#1] PREEMPT SMP
>>>>>>>>> last sysfs file: /sys/class/net/lo/operstate
>>>>>>>>> Modules linked in: irqTest(+) xeno_native analogy_ni_pcimio
>>>>>>>>> analogy_ni_mio analogy_ni_tio analogy_8255 analogy_ni_mite
>>>>>>>>> xeno_analogy xeno_rtdm astropci ext3 jbd mbcache ide_pci_generic
>>>>>>>>> ide_core ata_piix sata_mv e1000 libata unix [last unloaded:
>>>>>>>>> scsi_wait_scan]
>>>>>>>>>
>>>>>>>>> Pid: 3566, comm: insmod Not tainted (2.6.31.1 #1) X6DA8
>>>>>>>>> EIP: 0060:[<00000000>] EFLAGS: 00010246 CPU: 1
>>>>>>>>> EIP is at 0x0
>>>>>>>>> EAX: 00000030 EBX: 00000000 ECX: 00000030 EDX: c1250b80
>>>>>>>>> ESI: f8e24500 EDI: 00000000 EBP: f6c03f1c ESP: f6c03f18
>>>>>>>>>  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
>>>>>>>>> Process insmod (pid: 3566, ti=f6c02000 task=f78634b0
>>>>>>>>> task.ti=f6c02000)
>>>>>>>>> I-pipe domain Linux
>>>>>>>>> Stack:
>>>>>>>>>  c1154166 f6c03f24 c105abf7 f6c03f40 f8a0ea5d f8e24000 00000000
>>>>>>>>> 00000000
>>>>>>>>> <0> f8e27000 00000000 f6c03f58 f8e2703e 00000000 f8e24066 00000000
>>>>>>>>> f8e27000
>>>>>>>>> <0> f6c03f84 c1001028 f8e243c0 00000001 fffffffc f8e243c0 00000000
>>>>>>>>> f6c03f84
>>>>>>>>> Call Trace:
>>>>>>>>>  [<c1154166>] ? rthal_irq_enable+0x2d/0x31
>>>>>>>>>  [<c105abf7>] ? xnintr_enable+0xb/0xd
>>>>>>>>>  [<f8a0ea5d>] ? rtdm_irq_request+0x48/0x5e [xeno_rtdm]
>>>>>>>>>  [<f8e24000>] ? test_handler+0x0/0x1c [irqTest]
>>>>>>>>>  [<f8e27000>] ? __test_init+0x0/0x7e [irqTest]
>>>>>>>>>  [<f8e2703e>] ? __test_init+0x3e/0x7e [irqTest]
>>>>>>>>>  [<f8e27000>] ? __test_init+0x0/0x7e [irqTest]
>>>>>>>>>  [<c1001028>] ? do_one_initcall+0x23/0x183
>>>>>>>>>  [<c103a825>] ? blocking_notifier_call_chain+0x1a/0x1c
>>>>>>>>>  [<c10481e9>] ? sys_init_module+0xad/0x1ec
>>>>>>>>>  [<c1092cc5>] ? sys_close+0x71/0xb5
>>>>>>>>>  [<c1002c25>] ? sysenter_do_call+0x12/0x16
>>>>>>>>> Code:  Bad EIP value.
>>>>>>>>> EIP: [<00000000>] 0x0 SS:ESP 0068:f6c03f18
>>>>>>>>> CR2: 0000000000000000
>>>>>>>>> ---[ end trace ac2616367ecf94b2 ]---
>>>>>>>>>
>>>>>>>>> I hope this is what you wanted me to try. Please let me know.
>>>>>>>> So if I understand well, you "insmoded" the little test module which
>>>>>>>> does nothing but calling rtdm_irq_request() and the NULL pointer bug
>>>>>>>> occured.
>>>>>>> Correct
>>>>>>>
>>>>>>>> This bug occurred before calling analogy_config, you did not tried to
>>>>>>>> attach the ni_pcimio driver, right ?
>>>>>>> I insmod-ed the test module that gave that error dump. I later tried
>>>>>>> to attach the driver which causes the usual error. The stack-dumps I
>>>>>>> sent are solely related to insmod of test program.
>>>>>>>
>>>>>>>> If I am right, it seems like the bug is not located in analogy but
>>>>>>>> between Xenomai's nucleus and Ipipe, which is ... weird.
>>>>>>>>
>>>>>>>> What is your kernel configuration ? no IO_APIC ?
>>>>>>> I put back my config to IO_APIC. Should I disable that again?
>>>>>>> attached is my kernel configuration (configAnalogy)
>>>>>>>
>>>>>>>
>>>>>>>> Which irq did you try to request ? 48 or 5 ?
>>>>>>> I do not know. do I have to pass parameters to insmod?
>>>>>>>
>>>>>>> This is my /proc/interrupts if that is helpful
>>>>>>>         CPU0       CPU1
>>>>>>>  0:        222          0   IO-APIC-edge      timer
>>>>>>>  1:          0          9   IO-APIC-edge      i8042
>>>>>>>  2:          0          0    XT-PIC-XT        cascade
>>>>>>>  12:          0        132   IO-APIC-edge      i8042
>>>>>>>  14:          0          8   IO-APIC-edge      ata_piix
>>>>>>>  15:          0      12358   IO-APIC-edge      ata_piix
>>>>>>>  20:          0          0   IO-APIC-fasteoi   astropci0
>>>>>>>  28:          0        235   IO-APIC-fasteoi   sata_mv
>>>>>>>  54:          0      77950   IO-APIC-fasteoi   eth0
>>>>>>> NMI:          0          0   Non-maskable interrupts
>>>>>>> LOC:   45365307   45365133   Local timer interrupts
>>>>>>> SPU:          0          0   Spurious interrupts
>>>>>>> CNT:          0          0   Performance counter interrupts
>>>>>>> PND:          0          0   Performance pending work
>>>>>>> RES:       2555       2212   Rescheduling interrupts
>>>>>>> CAL:         60         58   Function call interrupts
>>>>>>> TLB:        419        200   TLB shootdowns
>>>>>>> TRM:          0          0   Thermal event interrupts
>>>>>>> THR:          0          0   Threshold APIC interrupts
>>>>>>> MCE:          0          0   Machine check exceptions
>>>>>>> MCP:        152        152   Machine check polls
>>>>>>> ERR:          0
>>>>>>> MIS:          0
>>>>>>>
>>>>>>> and my /proc/xenomai/irq
>>>>>>>
>>>>>>> IRQ         CPU0        CPU1
>>>>>>> 516:           0           0         [IPI]
>>>>>>> 519:    46161773    46161772         [timer]
>>>>>>> 520:           0           0         [critical sync]
>>>>>>> 546:           0           0         [virtual]
>>>>>>>
>>>>>>>
>>>>>>>> Which CPU are you using ?
>>>>>>> CPU0: Intel(R) Xeon(TM) CPU 3.00GHz stepping 03
>>>>>>> CPU1: Intel(R) Xeon(TM) CPU 3.00GHz stepping 03
>>>>>>>
>>>>>>> As Philippe rightly pointed out this is a 32-bit install although the
>>>>>>> CPUs are 64 bit
>>>>>> Following Philippe's advice, I attached a little patch for your kernel
>>>>>> sources. Could you apply it and send the kernel log messages ?
>>>>>>
>>>>>> You will also find attached the sources of a little module which calls
>>>>>> Linux' request_irq(48). Could you insmod the module and send a dump of
>>>>>> /proc/interrupts ?
>>>>>>
>>>>>>>> Thank you for your time.
>>>>>>>>
>>>>>>>>> Cheers
>>>>>>>>> Ettore
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2009/11/24 Alexis Berlemont <berlemont.h...@free.fr>:
>>>>>>>>>> On Tuesday 24 November 2009 22:34:33 Ettore Pedretti wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Would it help at this stage if I re-enable IO APIC, run your
>>>>>>>>>>> program
>>>>>>>>>>> and send you the call-stack dump? I am willing to test your patch
>>>>>>>>>>> on
>>>>>>>>>>> our hardware as soon as you got one ready, if that can be of help.
>>>>>>>>>> Sorry, I did not answer your question. The bug occurs in both
>>>>>>>>>> configurations;
>>>>>>>>>> so, do not bother changing your configuration for the moment.
>>>>>>>>>>
>>>>>>>>>>> Cheers
>>>>>>>>>>> Ettore
>>>>>>>>>>>
>>>>>>>>>>> 2009/11/23 Alexis Berlemont <berlemont.h...@free.fr>:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> On Monday 23 November 2009 18:26:15 Ettore Pedretti wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is finally working. here is the dmesg after I insert a
>>>>>>>>>>>>> module:
>>>>>>>>>>>>>
>>>>>>>>>>>>> irq_test: before rtdm_irq_request
>>>>>>>>>>>>> irq_test: after rtdm_irq_request (err = -22)
>>>>>>>>>>>>> irq_test: before rtdm_irq_enable
>>>>>>>>>>>>> irq_test: after rtdm_irq_enable (err = -22)
>>>>>>>>>>>> rtdm_irq_request() returns -EINVAL because the IO APIC is
>>>>>>>>>>>> disabled.
>>>>>>>>>>>> So,
>>>>>>>>>>>> the irq 48 turns into the irq 5;
>>>>>>>>>>>>
>>>>>>>>>>>>> Attached are a complete call-stack dump and my present kernel
>>>>>>>>>>>>>  configuration.
>>>>>>>>>>>> With the fact that there is still a NULL pointer bug without IO
>>>>>>>>>>>> APIC,
>>>>>>>>>>>> the
>>>>>>>>>>>> bug is bound to be located in analogy. There may be some wrong
>>>>>>>>>>>> write
>>>>>>>>>>>> access on the interrupt structure.
>>>>>>>>>>>>
>>>>>>>>>>>> I will come back with a patch which dumps the structure's content
>>>>>>>>>>>> at
>>>>>>>>>>>> various locations in the attach code.
>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers
>>>>>>>>>>>>> Ettore
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2009/11/23 Alexis Berlemont <berlemont.h...@free.fr>:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Nov 23, 2009 at 9:28 AM, Ettore Pedretti
>>>>>>>>>>>>>> <e...@st-and.ac.uk>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have compiled the module using this makefile:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> prefix := $(shell /usr/bin/xeno-config --prefix)
>>>>>>>>>>>>>>> obj-m   := irqTest.o
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ifeq ($(prefix),)
>>>>>>>>>>>>>>> $(error Please add <xeno-install>/bin to your PATH variable)
>>>>>>>>>>>>>>> endif
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> KDIR    := /lib/modules/$(shell uname -r)/build
>>>>>>>>>>>>>>> PWD     := $(shell pwd)
>>>>>>>>>>>>>>> EXTRA_CFLAGS := -I/usr/include/xenomai -I/usr/include/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> all: default
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> default:
>>>>>>>>>>>>>>>     $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> install:
>>>>>>>>>>>>>>>     $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules_install
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> clean:
>>>>>>>>>>>>>>>     rm -fr *.mod.c *.o *.ko irqTest *~ .irqTest* .tmp_versions
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The module seems to compiles fine:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> make -C /lib/modules/2.6.31.1/build
>>>>>>>>>>>>>>> SUBDIRS=/home/ep41/control/CHAMP/irqTest modules
>>>>>>>>>>>>>>> make[1]: Entering directory `/usr/src/linux-2.6.31.1'
>>>>>>>>>>>>>>>  CC [M]  /home/ep41/control/CHAMP/irqTest/irqTest.o
>>>>>>>>>>>>>>>  Building modules, stage 2.
>>>>>>>>>>>>>>>  MODPOST 1 modules
>>>>>>>>>>>>>>>  CC      /home/ep41/control/CHAMP/irqTest/irqTest.mod.o
>>>>>>>>>>>>>>>  LD [M]  /home/ep41/control/CHAMP/irqTest/irqTest.ko
>>>>>>>>>>>>>>> make[1]: Leaving directory `/usr/src/linux-2.6.31.1'
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> To make sure module dependencies are in place I modprobe
>>>>>>>>>>>>>>> irqbench
>>>>>>>>>>>>>>> (probably not necessary).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> modprobe xeno_irqbench
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> All the loaded modules:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> fangorn:~# lsmod
>>>>>>>>>>>>>>> Module                  Size  Used by
>>>>>>>>>>>>>>> xeno_irqbench           5152  0
>>>>>>>>>>>>>>> xeno_native            83296  0
>>>>>>>>>>>>>>> analogy_ni_pcimio      15676  0
>>>>>>>>>>>>>>> analogy_ni_mio         41596  1 analogy_ni_pcimio
>>>>>>>>>>>>>>> analogy_ni_tio         21724  1 analogy_ni_mio
>>>>>>>>>>>>>>> analogy_8255            4060  1 analogy_ni_mio
>>>>>>>>>>>>>>> analogy_ni_mite         9980  3
>>>>>>>>>>>>>>> analogy_ni_pcimio,analogy_ni_mio,analogy_ni_tio xeno_analogy
>>>>>>>>>>>>>>> 38876  5
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> analogy_ni_pcimio,analogy_ni_mio,analogy_ni_tio,analogy_8255,analogy_
>>>>>>>>>>>>>>> ni_ mite xeno_rtdm              24244  3
>>>>>>>>>>>>>>> xeno_irqbench,analogy_ni_mio,xeno_analogy astropci
>>>>>>>>>>>>>>> 10968 0
>>>>>>>>>>>>>>> ext3                  112900  1
>>>>>>>>>>>>>>> jbd                    44016  1 ext3
>>>>>>>>>>>>>>> mbcache                 6652  1 ext3
>>>>>>>>>>>>>>> ide_pci_generic         3712  0
>>>>>>>>>>>>>>> ide_core               79388  1 ide_pci_generic
>>>>>>>>>>>>>>> e1000                 118204  0
>>>>>>>>>>>>>>> ata_piix               15968  2
>>>>>>>>>>>>>>> sata_mv                27632  0
>>>>>>>>>>>>>>> libata                151468  2 ata_piix,sata_mv
>>>>>>>>>>>>>>> unix                   24460  10
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When I insert the module it complains about missing symbols:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> insmod irqTest.ko
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> insmod: error inserting 'irqTest.ko': -1 Unknown symbol in
>>>>>>>>>>>>>>> module
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> dmesg:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> irqTest: module license 'unspecified' taints kernel.
>>>>>>>>>>>>>>> Disabling lock debugging due to kernel taint
>>>>>>>>>>>>>>> irqTest: Unknown symbol xnintr_enable
>>>>>>>>>>>>>>> irqTest: Unknown symbol xnintr_detach
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What am I doing wrong?
>>>>>>>>>>>>>> It's me who did wrong. I just tested the compilation inside the
>>>>>>>>>>>>>> kernel.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> xnintr_* symbols are only exported for GPL compliant modules.
>>>>>>>>>>>>>> So,
>>>>>>>>>>>>>> could you add the following line in the test module:
>>>>>>>>>>>>>> MODULE_LICENSE("GPL");
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> With that, the insmod operation should work.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> BTW, I disabled  CONFIG_X86_IO_APIC and  the SMP option: same
>>>>>>>>>>>>>>> problem.
>>>>>>>>>>>>>> Could you send the call-stack dump ? Maybe, that will unveil a
>>>>>>>>>>>>>> clue.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Cheers
>>>>>>>>>>>>>>> Ettore
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2009/11/22 Alexis Berlemont <alexis.berlem...@gmail.com>:
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Sunday 22 November 2009 20:35:51 Ettore Pedretti wrote:
>>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I downloaded Xenomai 2.5-rc4 from the xenomai-head.git. I
>>>>>>>>>>>>>>>>> need
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> use the comedi drivers for Xenomai for a NI PCI-6711
>>>>>>>>>>>>>>>>> function
>>>>>>>>>>>>>>>>> generator board.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> When I try to use the test program cmd_write (or cmd-read) I
>>>>>>>>>>>>>>>>> obtain
>>>>>>>>>>>>>>>>> the following:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> fangorn:~# cmd_write -vcmd_write: device analogy0 opened
>>>>>>>>>>>>>>>>> (fd=0)
>>>>>>>>>>>>>>>>> cmd_write: basic descriptor retrieved
>>>>>>>>>>>>>>>>>     subdevices count = 0
>>>>>>>>>>>>>>>>>     read subdevice index = 0
>>>>>>>>>>>>>>>>>     write subdevice index = 0
>>>>>>>>>>>>>>>>> cmd_write: a4l_get_desc failed (ret=-22)
>>>>>>>>>>>>>>>>> *** glibc detected *** cmd_write: free(): invalid next size
>>>>>>>>>>>>>>>>> (fast):
>>>>>>>>>>>>>>>>> 0x0804d008 ***
>>>>>>>>>>>>>>>>> ======= Backtrace: =========
>>>>>>>>>>>>>>>>> /lib/i686/cmov/libc.so.6[0xb7e52624]
>>>>>>>>>>>>>>>>> /lib/i686/cmov/libc.so.6(cfree+0x96)[0xb7e54826]
>>>>>>>>>>>>>>>>> cmd_write[0x804927c]
>>>>>>>>>>>>>>>>> /lib/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7dfa455]
>>>>>>>>>>>>>>>>> cmd_write[0x8048b01]
>>>>>>>>>>>>>>>>> ======= Memory map: ========
>>>>>>>>>>>>>>>>> 08048000-0804a000 r-xp 00000000 08:01 10855303
>>>>>>>>>>>>>>>>> /usr/bin/cmd_write
>>>>>>>>>>>>>>>>> 0804a000-0804b000 rw-p 00002000 08:01 10855303
>>>>>>>>>>>>>>>>> /usr/bin/cmd_write
>>>>>>>>>>>>>>>>> 0804b000-0806e000 rw-p 00000000 00:00 0          [heap]
>>>>>>>>>>>>>>>>> b7c00000-b7c21000 rw-p 00000000 00:00 0
>>>>>>>>>>>>>>>>> b7c21000-b7d00000 ---p 00000000 00:00 0
>>>>>>>>>>>>>>>>> b7dce000-b7dda000 r-xp 00000000 08:01 6127619
>>>>>>>>>>>>>>>>>  /lib/libgcc_s.so.1
>>>>>>>>>>>>>>>>> b7dda000-b7ddb000 rw-p 0000b000 08:01 6127619
>>>>>>>>>>>>>>>>>  /lib/libgcc_s.so.1
>>>>>>>>>>>>>>>>> b7de0000-b7de3000 rw-s 00000000 00:0b 426        /dev/rtheap
>>>>>>>>>>>>>>>>> b7de3000-b7de4000 rw-p 00000000 00:00 0
>>>>>>>>>>>>>>>>> b7de4000-b7f39000 r-xp 00000000 08:01 6144250
>>>>>>>>>>>>>>>>>  /lib/i686/cmov/libc-2.7.so b7f39000-b7f3a000 r--p 00155000
>>>>>>>>>>>>>>>>> 08:01
>>>>>>>>>>>>>>>>> 6144250    /lib/i686/cmov/libc-2.7.so b7f3a000-b7f3c000 rw-p
>>>>>>>>>>>>>>>>> 00156000 08:01 6144250    /lib/i686/cmov/libc-2.7.so
>>>>>>>>>>>>>>>>> b7f3c000-b7f3f000 rw-p 00000000 00:00 0
>>>>>>>>>>>>>>>>> b7f3f000-b7f54000 r-xp 00000000 08:01 6144264
>>>>>>>>>>>>>>>>> /lib/i686/cmov/libpthread-2.7.so
>>>>>>>>>>>>>>>>> b7f54000-b7f56000 rw-p 00014000 08:01 6144264
>>>>>>>>>>>>>>>>> /lib/i686/cmov/libpthread-2.7.so
>>>>>>>>>>>>>>>>> b7f56000-b7f58000 rw-p 00000000 00:00 0
>>>>>>>>>>>>>>>>> b7f58000-b7f5a000 r-xp 00000000 08:01 10808118
>>>>>>>>>>>>>>>>> /usr/lib/librtdm.so.1.0.0 b7f5a000-b7f5b000 rw-p 00001000
>>>>>>>>>>>>>>>>> 08:01
>>>>>>>>>>>>>>>>> 10808118   /usr/lib/librtdm.so.1.0.0 b7f5b000-b7f5c000 rw-p
>>>>>>>>>>>>>>>>> 00000000 00:00 0
>>>>>>>>>>>>>>>>> b7f5c000-b7f63000 r-xp 00000000 08:01 10808119
>>>>>>>>>>>>>>>>>  /usr/lib/libnative.so.3.0.0 b7f63000-b7f64000 rw-p 00006000
>>>>>>>>>>>>>>>>> 08:01
>>>>>>>>>>>>>>>>> 10808119 /usr/lib/libnative.so.3.0.0 b7f64000-b7f67000 r-xp
>>>>>>>>>>>>>>>>> 00000000 08:01 10808112   /usr/lib/libanalogy.so.1.0.0
>>>>>>>>>>>>>>>>> b7f67000-b7f68000 rw-p 00002000 08:01 10808112
>>>>>>>>>>>>>>>>> /usr/lib/libanalogy.so.1.0.0
>>>>>>>>>>>>>>>>> b7f69000-b7f6a000 rw-p 00000000 00:00 0
>>>>>>>>>>>>>>>>> b7f6a000-b7f6d000 rw-s 00000000 00:0b 426        /dev/rtheap
>>>>>>>>>>>>>>>>> b7f6d000-b7f6f000 rw-p 00000000 00:00 0
>>>>>>>>>>>>>>>>> b7f6f000-b7f89000 r-xp 00000000 08:01 6127618
>>>>>>>>>>>>>>>>>  /lib/ld-2.7.so
>>>>>>>>>>>>>>>>> b7f89000-b7f8b000 rw-p 0001a000 08:01 6127618
>>>>>>>>>>>>>>>>>  /lib/ld-2.7.so
>>>>>>>>>>>>>>>>> bfab1000-bfac6000 rw-p 00000000 00:00 0          [stack]
>>>>>>>>>>>>>>>>> ffffe000-fffff000 r-xp 00000000 00:00 0          [vdso]
>>>>>>>>>>>>>>>>> Aborted
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This is probably because the device /dev/analogy0 does not
>>>>>>>>>>>>>>>>> exist.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This is the output of uname -a
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Linux fangorn 2.6.31.1 #1 SMP PREEMPT Fri Nov 20 20:42:26
>>>>>>>>>>>>>>>>> PST
>>>>>>>>>>>>>>>>> 2009
>>>>>>>>>>>>>>>>> i686 GNU/Linux
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> And these are the relevant entries in dmesg
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> dmesg:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I-pipe 2.4-06: pipeline enabled.
>>>>>>>>>>>>>>>>> I-pipe: Domain Xenomai registered.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Xenomai: hal/i386 started.
>>>>>>>>>>>>>>>>> Xenomai: scheduling class idle registered.
>>>>>>>>>>>>>>>>> Xenomai: scheduling class rt registered.
>>>>>>>>>>>>>>>>> Xenomai: real-time nucleus v2.5-rc4 (Flying In A Blue Dream)
>>>>>>>>>>>>>>>>> loaded. Xenomai: SMI-enabled chipset found
>>>>>>>>>>>>>>>>> Xenomai: SMI workaround enabled
>>>>>>>>>>>>>>>>> Xenomai: starting RTDM services.
>>>>>>>>>>>>>>>>> Xenomai: starting native API services.
>>>>>>>>>>>>>>>>> Analogy: MITE: Available NI device IDs: 0x1880
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> result of lspci for the relevant board:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 04:01.0 Class ff00: National Instruments PCI-6711
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> And lsmod:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Module                  Size  Used by
>>>>>>>>>>>>>>>>> xeno_native           105088  0
>>>>>>>>>>>>>>>>> analogy_ni_pcimio      15644  0
>>>>>>>>>>>>>>>>> analogy_ni_mio         44860  1 analogy_ni_pcimio
>>>>>>>>>>>>>>>>> analogy_ni_tio         24956  1 analogy_ni_mio
>>>>>>>>>>>>>>>>> analogy_8255            3900  1 analogy_ni_mio
>>>>>>>>>>>>>>>>> analogy_ni_mite        10140  3
>>>>>>>>>>>>>>>>>  analogy_ni_pcimio,analogy_ni_mio,analogy_ni_tio
>>>>>>>>>>>>>>>>> xeno_analogy
>>>>>>>>>>>>>>>>>  40220  5
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> analogy_ni_pcimio,analogy_ni_mio,analogy_ni_tio,analogy_8255,analog
>>>>>>>>>>>>>>>>> y_n i_mit e xeno_rtdm              28436  2
>>>>>>>>>>>>>>>>> analogy_ni_mio,xeno_analogy astropci               10944  0
>>>>>>>>>>>>>>>>> ext3                  109636  1
>>>>>>>>>>>>>>>>> jbd                    43920  1 ext3
>>>>>>>>>>>>>>>>> mbcache                 6272  1 ext3
>>>>>>>>>>>>>>>>> ide_pci_generic         3712  0
>>>>>>>>>>>>>>>>> ide_core               74204  1 ide_pci_generic
>>>>>>>>>>>>>>>>> ata_piix               15748  2
>>>>>>>>>>>>>>>>> sata_mv                26448  0
>>>>>>>>>>>>>>>>> e1000                 114208  0
>>>>>>>>>>>>>>>>> libata                142156  2 ata_piix,sata_mv
>>>>>>>>>>>>>>>>> unix                   22992  10
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> According to this post:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://www.mail-archive.com/xenomai-help@gna.org/msg09595.html
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The analogy driver "a4l_pcimio" will be registered with
>>>>>>>>>>>>>>>>>> your
>>>>>>>>>>>>>>>>>> last
>>>>>>>>>>>>>>>>>> insmod (analogy_ni_pcimio). You can check that by typing
>>>>>>>>>>>>>>>>>> "cat
>>>>>>>>>>>>>>>>>> /proc/analogy/drivers", you will see only one entry:
>>>>>>>>>>>>>>>>>> a4l_pcimio.
>>>>>>>>>>>>>>>>> fangorn:~# cat /proc/analogy/drivers
>>>>>>>>>>>>>>>>> --  Analogy drivers --
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> | idx | driver name
>>>>>>>>>>>>>>>>> |  00 | analogy_ni_pcimio
>>>>>>>>>>>>>>>>> |  01 | analogy_8255
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> There are two entries and the drivers are not attached:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> fangorn:~# cat /proc/analogy/devices
>>>>>>>>>>>>>>>>> --  Analogy devices --
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> | idx | status | driver
>>>>>>>>>>>>>>>>> |  00 | Unused | No driver
>>>>>>>>>>>>>>>>> |  01 | Unused | No driver
>>>>>>>>>>>>>>>>> |  02 | Unused | No driver
>>>>>>>>>>>>>>>>> |  03 | Unused | No driver
>>>>>>>>>>>>>>>>> |  04 | Unused | No driver
>>>>>>>>>>>>>>>>> |  05 | Unused | No driver
>>>>>>>>>>>>>>>>> |  06 | Unused | No driver
>>>>>>>>>>>>>>>>> |  07 | Unused | No driver
>>>>>>>>>>>>>>>>> |  08 | Unused | No driver
>>>>>>>>>>>>>>>>> |  09 | Unused | No driver
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I'm aware of the name change of the drivers:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://www.mail-archive.com/xenomai-...@gna.org/msg00741.html
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> - a4l_pcimio becomes analogy_ni_pcimio
>>>>>>>>>>>>>>>>>> - 8255 becomes analogy_8255.
>>>>>>>>>>>>>>>>>> Consequently, the command line to attach these drivers has
>>>>>>>>>>>>>>>>>> changed. Starting from now, we have to type:
>>>>>>>>>>>>>>>>>> - analogy_config analogyX analogy_ni_pcimio (instead of
>>>>>>>>>>>>>>>>>> a4l_pcimio)
>>>>>>>>>>>>>>>>> This is what happens when I try to attach the driver to de
>>>>>>>>>>>>>>>>> device:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> fangorn:~# analogy_config analogy0 analogy_ni_pcimio
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Message from sysl...@fangorn at Nov 21 23:22:37 ...
>>>>>>>>>>>>>>>>>  kernel:Oops: 0000 [#1] PREEMPT SMP
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Message from sysl...@fangorn at Nov 21 23:22:37 ...
>>>>>>>>>>>>>>>>>  kernel:last sysfs file:
>>>>>>>>>>>>>>>>>  /sys/devices/pci0000:00/0000:00:1e.0/0000:06:02.0/class
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Message from sysl...@fangorn at Nov 21 23:22:37 ...
>>>>>>>>>>>>>>>>>  kernel:Process analogy_config (pid: 3409, ti=f64cc000
>>>>>>>>>>>>>>>>> task=f79013b0 task.ti=f64cc000)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Message from sysl...@fangorn at Nov 21 23:22:37 ...
>>>>>>>>>>>>>>>>>  kernel:I-pipe domain Linux
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Message from sysl...@fangorn at Nov 21 23:22:37 ...
>>>>>>>>>>>>>>>>>  kernel:Stack:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Message from sysl...@fangorn at Nov 21 23:22:37 ...
>>>>>>>>>>>>>>>>>  kernel:Call Trace:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Message from sysl...@fangorn at Nov 21 23:22:37 ...
>>>>>>>>>>>>>>>>>  kernel:Code: 8b 45 9c e8 f2 f1 fa ff 89 c2 83 f8 01 0f 85
>>>>>>>>>>>>>>>>> d4
>>>>>>>>>>>>>>>>> fe
>>>>>>>>>>>>>>>>> ff
>>>>>>>>>>>>>>>>> ff 8b 55 9c 8b 82 74 01 00 00 8b 00 f6 40 3c 06 0f 84 22 01
>>>>>>>>>>>>>>>>> 00
>>>>>>>>>>>>>>>>> 00
>>>>>>>>>>>>>>>>> 8b 42 18 <8b> 40 04 89 45 b0 8b 40 14 8b 40 04 85 c0 0f 84
>>>>>>>>>>>>>>>>> 0b
>>>>>>>>>>>>>>>>> 01
>>>>>>>>>>>>>>>>> 00
>>>>>>>>>>>>>>>>> 00 31
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Message from sysl...@fangorn at Nov 21 23:22:37 ...
>>>>>>>>>>>>>>>>>  kernel:EIP: [<f8c7d029>] ni_E_init+0x267/0xff1
>>>>>>>>>>>>>>>>> [analogy_ni_mio]
>>>>>>>>>>>>>>>>> SS:ESP 0068:f64cddc8
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Message from sysl...@fangorn at Nov 21 23:22:37 ...
>>>>>>>>>>>>>>>>>  kernel:CR2: 0000000000000004
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> relevant dmeg:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> a4l: analogy_ni_pcimio: pcimio_attach: found pci-6711 board
>>>>>>>>>>>>>>>>> mite 0000:04:01.0: PCI->APIC IRQ transform: INT A -> IRQ 48
>>>>>>>>>>>>>>>>> mite 0000:04:01.0: setting latency timer to 64
>>>>>>>>>>>>>>>>> a4l: MITE: 0xd0801000 mapped to f8e26000
>>>>>>>>>>>>>>>>> a4l: DAQ: 0xd0800000 mapped to f8e2a000
>>>>>>>>>>>>>>>>> a4l: MITE: version = 1, type = 1, mite mode = 1, interface
>>>>>>>>>>>>>>>>> mode
>>>>>>>>>>>>>>>>> = 3
>>>>>>>>>>>>>>>>> a4l: MITE: num channels = 3, write post fifo depth = 1, wins
>>>>>>>>>>>>>>>>> =
>>>>>>>>>>>>>>>>> 0,
>>>>>>>>>>>>>>>>> iowins = 2 a4l: analogy_ni_pcimio: pcimio_attach: found irq
>>>>>>>>>>>>>>>>> 48
>>>>>>>>>>>>>>>>> BUG: unable to handle kernel NULL pointer dereference at
>>>>>>>>>>>>>>>>> 00000004
>>>>>>>>>>>>>>>>> IP: [<f8c7d029>] ni_E_init+0x267/0xff1 [analogy_ni_mio]
>>>>>>>>>>>>>>>>> *pde = 00000000
>>>>>>>>>>>>>>>>> Oops: 0000 [#1] PREEMPT SMP
>>>>>>>>>>>>>>>>> last sysfs file:
>>>>>>>>>>>>>>>>> /sys/devices/pci0000:00/0000:00:1e.0/0000:06:02.0/class
>>>>>>>>>>>>>>>>> Modules
>>>>>>>>>>>>>>>>> linked in: xeno_native analogy_ni_pcimio analogy_ni_mio
>>>>>>>>>>>>>>>>> analogy_ni_tio analogy_8255 analogy_ni_mite xeno_analogy
>>>>>>>>>>>>>>>>> xeno_rtdm
>>>>>>>>>>>>>>>>> astropci ext3 jbd mbcache ide_pci_generic ide_core ata_piix
>>>>>>>>>>>>>>>>> sata_mv
>>>>>>>>>>>>>>>>> e1000 libata unix [last unloaded: scsi_wait_scan]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Pid: 3409, comm: analogy_config Not tainted (2.6.31.1 #1)
>>>>>>>>>>>>>>>>> X6DA8
>>>>>>>>>>>>>>>>> EIP: 0060:[<f8c7d029>] EFLAGS: 00010202 CPU: 1
>>>>>>>>>>>>>>>>> EIP is at ni_E_init+0x267/0xff1 [analogy_ni_mio]
>>>>>>>>>>>>>>>>> EAX: 00000000 EBX: f8a22280 ECX: f8c31e6c EDX: f8c31e60
>>>>>>>>>>>>>>>>> ESI: 00000000 EDI: f8c31e60 EBP: f64cde38 ESP: f64cddc8
>>>>>>>>>>>>>>>>>  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
>>>>>>>>>>>>>>>>> Process analogy_config (pid: 3409, ti=f64cc000 task=f79013b0
>>>>>>>>>>>>>>>>>  task.ti=f64cc000) I-pipe domain Linux
>>>>>>>>>>>>>>>>> Stack:
>>>>>>>>>>>>>>>>>  f64cddd0 c10142b6 f64cddd8 f8c31e60 f64cdde0 c105abf7
>>>>>>>>>>>>>>>>> f64cddfc
>>>>>>>>>>>>>>>>> f8a0ea5d <0> f8c2be00 00000000 00000001 f8c31e94 fffffff0
>>>>>>>>>>>>>>>>> f64cde14
>>>>>>>>>>>>>>>>> f8c2c118 00000001 <0> f8c2ed0d f8c31e88 f8c31e60 f64cde38
>>>>>>>>>>>>>>>>> f8c2cccf
>>>>>>>>>>>>>>>>> 00000001 f8c31e60 00000030 Call Trace:
>>>>>>>>>>>>>>>>>  [<c10142b6>] ? unmask_IO_APIC_irq+0xd/0xf
>>>>>>>>>>>>>>>>>  [<c105abf7>] ? xnintr_enable+0xb/0xd
>>>>>>>>>>>>>>>>>  [<f8a0ea5d>] ? rtdm_irq_request+0x48/0x5e [xeno_rtdm]
>>>>>>>>>>>>>>>>>  [<f8c2be00>] ? a4l_handle_irq+0x0/0x1a [xeno_analogy]
>>>>>>>>>>>>>>>>>  [<f8c2c118>] ? __a4l_request_irq+0x33/0x39 [xeno_analogy]
>>>>>>>>>>>>>>>>>  [<f8c2cccf>] ? a4l_request_irq+0x98/0xaf [xeno_analogy]
>>>>>>>>>>>>>>>>>  [<f8c8bd8a>] ? pcimio_attach+0x54d/0x664
>>>>>>>>>>>>>>>>> [analogy_ni_pcimio]
>>>>>>>>>>>>>>>>>  [<f8c2afef>] ? a4l_assign_driver+0x61/0x134 [xeno_analogy]
>>>>>>>>>>>>>>>>>  [<f8c2b2ba>] ? a4l_device_attach+0x54/0x6d [xeno_analogy]
>>>>>>>>>>>>>>>>>  [<c10662ea>] ? xnshadow_ppd_get+0x4f/0x58
>>>>>>>>>>>>>>>>>  [<f8c2b54f>] ? a4l_ioctl_devcfg+0x57/0x104 [xeno_analogy]
>>>>>>>>>>>>>>>>>  [<f8c2d36f>] ? a4l_rt_ioctl+0x33/0x3a [xeno_analogy]
>>>>>>>>>>>>>>>>>  [<f8a0d3e6>] ? __rt_dev_ioctl+0xd1/0xd8 [xeno_rtdm]
>>>>>>>>>>>>>>>>>  [<f8a0fe77>] ? sys_rtdm_open+0x5c/0x64 [xeno_rtdm]
>>>>>>>>>>>>>>>>>  [<f8a0fdde>] ? sys_rtdm_ioctl+0x29/0x2b [xeno_rtdm]
>>>>>>>>>>>>>>>>>  [<c10699ae>] ? losyscall_event+0xa9/0x190
>>>>>>>>>>>>>>>>>  [<c10566ce>] ? __ipipe_dispatch_event+0xdf/0x201
>>>>>>>>>>>>>>>>>  [<c1069905>] ? losyscall_event+0x0/0x190
>>>>>>>>>>>>>>>>>  [<c10166a1>] ? __ipipe_syscall_root+0x3b/0xc4
>>>>>>>>>>>>>>>>>  [<c1002cfd>] ? system_call+0x2d/0x4f
>>>>>>>>>>>>>>>>> Code: 8b 45 9c e8 f2 f1 fa ff 89 c2 83 f8 01 0f 85 d4 fe ff
>>>>>>>>>>>>>>>>> ff
>>>>>>>>>>>>>>>>> 8b
>>>>>>>>>>>>>>>>> 55 9c 8b 82 74 01 00 00 8b 00 f6 40 3c 06 0f 84 22 01 00 00
>>>>>>>>>>>>>>>>> 8b
>>>>>>>>>>>>>>>>> 42
>>>>>>>>>>>>>>>>> 18 <8b> 40 04 89 45 b0 8b 40 14 8b 40 04 85 c0 0f 84 0b 01
>>>>>>>>>>>>>>>>> 00
>>>>>>>>>>>>>>>>> 00
>>>>>>>>>>>>>>>>> 31
>>>>>>>>>>>>>>>>> EIP: [<f8c7d029>] ni_E_init+0x267/0xff1 [analogy_ni_mio]
>>>>>>>>>>>>>>>>> SS:ESP
>>>>>>>>>>>>>>>>> 0068:f64cddc8 CR2: 0000000000000004
>>>>>>>>>>>>>>>>> ---[ end trace c887d49bb5e86cf4 ]---
>>>>>>>>>>>>>>>> Thanks for such a great report.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I keep two things in mind:
>>>>>>>>>>>>>>>> - cmd_write's error handling path is not buggy (that was
>>>>>>>>>>>>>>>> already
>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>> my todo list). I will fix that as soon as possible.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - according to the call-stack dump you made, the irq handler
>>>>>>>>>>>>>>>> registering seems to be the source of the trouble. What
>>>>>>>>>>>>>>>> strikes
>>>>>>>>>>>>>>>> me
>>>>>>>>>>>>>>>> is that the oops occurred very low (unmask_IO_APIC_irq: we
>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>> no
>>>>>>>>>>>>>>>> more in the analogy layer).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In order to be sure that the problem is located in analogy,
>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>> be great to test that calling rtdm_request_irq(... , 48, ...)
>>>>>>>>>>>>>>>> does
>>>>>>>>>>>>>>>> not trigger the bug.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Here is a little test module you could try to insmod. If you
>>>>>>>>>>>>>>>> do
>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>> want to bother finding out how to compile it, you can replace
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> code of an existing rtdm driver (for example:
>>>>>>>>>>>>>>>> xenomai/ksrc/drivers/testing/irqbench.c) with the source
>>>>>>>>>>>>>>>> below.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Another interesting test would be to disable
>>>>>>>>>>>>>>>> CONFIG_X86_IO_APIC
>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>> your kernel configuration (in "Processor type and features",
>>>>>>>>>>>>>>>> disable
>>>>>>>>>>>>>>>> the SMP option and disable "IO APIC" under "Local APIC").
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> #include <linux/version.h>
>>>>>>>>>>>>>>>> #include <linux/module.h>
>>>>>>>>>>>>>>>> #include <linux/ioport.h>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> #include <rtdm/rtdm_driver.h>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> int test_handler(rtdm_irq_t *irq_handle)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>     rtdm_printk("irq_test: INTERRUPT!\n");
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>     return RTDM_IRQ_HANDLED;
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> static rtdm_irq_t handle;
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> static int __init __test_init(void)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>     int err;
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>     rtdm_printk("irq_test: before rtdm_irq_request\n");
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>     err = rtdm_irq_request(&handle, 48, test_handler, 0,
>>>>>>>>>>>>>>>> "test_irq", NULL);
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>     rtdm_printk("irq_test: after rtdm_irq_request (err =
>>>>>>>>>>>>>>>> %d)\n",
>>>>>>>>>>>>>>>> err);
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>     rtdm_printk("irq_test: before rtdm_irq_enable\n");
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>     err = rtdm_irq_enable(&handle);
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>     rtdm_printk("irq_test: after rtdm_irq_enable (err =
>>>>>>>>>>>>>>>> %d)\n",
>>>>>>>>>>>>>>>> err);
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>     return err;
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> static void __exit __test_exit(void)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>     rtdm_irq_free(&handle);
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> module_init(__test_init);
>>>>>>>>>>>>>>>> module_exit(__test_exit);
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Can anyone help?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Best regards
>>>>>>>>>>>>>>>>> Ettore Pedretti
>>>>>>>>>>>>>> Alexis.
>>>>>>>>>>>> Alexis.
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Xenomai-help mailing list
>>>>>>>>>> Xenomai-help@gna.org
>>>>>>>>>> https://mail.gna.org/listinfo/xenomai-help
>>>>>>>>>>
>>>>>> Alexis.
>>>>>>
>>>>>
>>>> Alexis.
>>>>
>>>
>>>
>> Alexis.
>>
> 
> 
> 

Alexis.

_______________________________________________
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help

Reply via email to