Hey Wolfgang,
I made some great progress in the last few hours. I figured that the PEAK
PCI can bus card had IRQ 11 according to "lspci" and after the kernel
modules are loaded it switched to IRQ 16 which caused all the trouble since
the USB and the SCSI controller have the same IRQ.
Now, I just went ahead and hard coded
/usr/src/xenomai/ksrc/drivers/can/sja1000/rtcan_sja1000.c
FUNCTION rtcan_sja1000_register...
#############
chip->bus_err_on = 1;
printk("PETER chip->irq_num = %i\n", chip->irq_num);
chip->irq_num = 11;
printk("PETER chip->irq_num = %i\n", chip->irq_num);
ret = rtdm_irq_request(&dev->irq_handle,
chip->irq_num, rtcan_sja_interrupt,
chip->irq_flags, sja_ctrl_name, dev);
#############
After compiling, I was able to load all three modules and
Name___________ _Baudrate State___ TX_Counter RX_Counter ____Errors
rtcan0 1000000 active 1 0 0
rtcan1 undefined stopped 0 0 0
r...@mandy:/usr/src/xenomai/ksrc/drivers/can/sja1000# cat /proc/xenomai/irq
IRQ CPU0 CPU1 CPU2 CPU3 CPU4
CPU5 CPU6 CPU7
11: 0 0 0 0 0
0 0 0 SJA1000 SJA1000
521: 5 1 0 0 3
2 1 1 [IPI]
524: 267014 183344 104046 50083 487162
389563 399807 299675 [timer]
525: 0 0 0 0 0
0 0 0 [critical sync]
578: 38 0 0 0 4
0 0 1 [virtual]
r...@mandy:/usr/src/xenomai/ksrc/drivers/can/sja1000# cat
/proc/rtcan/rtcan0/info
Device rtcan0
Controller SJA1000
Board PEAK-PCI
Clock-Hz 8000000
Baudrate 1000000
Bit-time brp=1 prop_seg=0 phase_seg1=5 phase_seg2=2 sjw=1 sam=0
Ctrl-Mode
State active
TX-Counter 1
RX-Counter 0
Errors 0
Refcount 0
However, I was not able to start my program that communicates on the can
bus. Instead, dmesg shows
[ 2162.848141] PETER chip->irq_num = 16 PETER chip->irq_num = 11rtcan:
registered rtcan0
[ 2162.848157] PETER rtcan_peak_pci_add_chan
drivers/xenomai/can/sja1000/rtcan_peak_pci.c 164 :
[ 2162.848164] PEAK-PCI-CAN: base_addr=ffffc90007fb8400
conf_addr=ffffc90007f3c000 irq=16
[ 2162.848168] PETER chip->irq_num = 16 PETER chip->irq_num = 11rtcan:
registered rtcan1
[ 5252.947307] irq 16: nobody cared (try booting with the "irqpoll" option)
[ 5252.947313] Pid: 0, comm: swapper Tainted: P
2.6.34.5-ipipe-2.5.5.1-test_02 #10
[ 5252.947316] Call Trace:
[ 5252.947319] <IRQ> [<ffffffff810a2736>] __report_bad_irq+0x26/0xa0
[ 5252.947331] [<ffffffff810a293c>] note_interrupt+0x18c/0x1d0
[ 5252.947333] [<ffffffff810a3335>] handle_fasteoi_irq+0xb5/0xe0
[ 5252.947336] [<ffffffff81005e6d>] handle_irq+0x1d/0x30
[ 5252.947338] [<ffffffff81005340>] do_IRQ+0x70/0x100
[ 5252.947340] [<ffffffff810a8d57>] __ipipe_sync_stage+0x207/0x20d
[ 5252.947342] [<ffffffff810052d0>] ? do_IRQ+0x0/0x100
[ 5252.947344] [<ffffffff810a8d5d>] ? __xirq_end+0x0/0x9c
[ 5252.947345] [<ffffffff810052d0>] ? do_IRQ+0x0/0x100
[ 5252.947347] [<ffffffff810a9213>] __ipipe_walk_pipeline+0x113/0x120
[ 5252.947350] [<ffffffff81023084>] __ipipe_handle_irq+0x124/0x310
[ 5252.947352] [<ffffffff810a2af0>] ? __ipipe_ack_fasteoi_irq+0x0/0x10
[ 5252.947356] [<ffffffff81552193>] common_interrupt+0x13/0x2c
[ 5252.947357] <EOI> [<ffffffff81023416>] ? __ipipe_halt_root+0x26/0x40
[ 5252.947362] [<ffffffff8100ba06>] default_idle+0x36/0x90
[ 5252.947365] [<ffffffff81001d84>] cpu_idle+0x74/0xd0
[ 5252.947368] [<ffffffff8154c1af>] start_secondary+0x1b2/0x1b6
[ 5252.947370] handlers:
[ 5252.947370] [<ffffffff813cd590>] (usb_hcd_irq+0x0/0xb0)
[ 5252.947374] [<ffffffffa0066c30>] (mpt_interrupt+0x0/0xa00 [mptbase])
[ 5252.947382] Disabling IRQ #16
Which I guess tells me that I have to hard code the irq number somewhere
else as well. I hope we narrowed down the problem and I really hope that
there is a way to resolve this IRQ conflict
THANKS so much,
peter
On Mon, Oct 11, 2010 at 5:09 PM, Peter Pastor <[email protected]>wrote:
> Hey Wolfgang,
>
> I am compiling the rtcan code as modules. Also, for debugging purposes, I
> moved the xeno_can.ko and friends out of the /lib/modules directory and
> successfully booted into xenomai. Once xenomai booted up correctly, I insmod
> the modules by hand, first xeno_can.ko, then xeno_can_sja1000.ko and then
> the xeno_can_peak_pci.ko. The first two modules do not cause any trouble.
> However, the last one causes the system to freeze (after a short delay).
>
> The ERROR message is
> ERROR -16: IRQ is busy, check shared interrupt support !
> ERROR -16 while trying to register SJA1000 device.
>
> It turns out that I haven't had the shared interrupt support turned on !!
>
> However, after enabling shared inturrupts (in the real-time subsystem
> category) and recompiling and rebooting... the error message disappears but
> the system still freezes after a certain while. I cannot really grep what
> comes out of the dmesg and also, it seems that each time I load this final
> kernel module it spits out slightly different things.
>
> Initially it seems that everything is fine. It registers rtcan0 and rtcan1
> on IRQ 16
>
> I do not quit understand why it is assigned to 16 though and not 11.
>
> Well, I assume that the system freeze because of the interrupt assignment.
> Is there a way to load the kernel module with the desired IRQ as parameter ?
>
> I attached 2 more pictures: 1) right after loading the xeno_can_peak_pci.ko
> and 2) after the system "woke" up again as "zombie".
>
> Sorry for not posting the content of the images. I was not able to pipe it
> into a file (file system got re-mounted as read-only). Hope that is ok.
>
> BTW: the MP-BIOS bug: 8254 timer not connected to IO-APIC and the address
> space collision: host bridge window [ ... ] conflicts with PCI Bus 0000:00 [
> ... ] pci no compatible bridge window for [ ... ] still exist (see attached
> image >> error.jpg)
>
> THANKS so much,
> peter
>
>
>
>
>
>
> On Mon, Oct 11, 2010 at 2:23 PM, Peter Pastor <[email protected]>wrote:
>
>> Hey Wolfgang,
>>
>> we are using this card
>>
>> http://www.gridconnect.com/pcicanin2ch.html
>>
>> 07:04.0 Network controller [0280]: PEAK-System Technik GmbH PCAN-PCI
>> CAN-Bus controller [001c:0001] (rev 02)
>> Subsystem: PEAK-System Technik GmbH Device [001c:0005]
>> Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
>> Stepping- SERR- FastB2B- DisINTx-
>> Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>> Interrupt: pin A routed to IRQ 11
>> Region 0: Memory at f3ae0000 (32-bit, non-prefetchable) [size=64K]
>> Region 1: Memory at f3af0000 (32-bit, non-prefetchable) [size=64K]
>>
>> I will let you know how it goes with the printks.
>>
>> THANKS a lot,
>> peter
>>
>> On Mon, Oct 11, 2010 at 12:38 PM, Wolfgang Grandegger
>> <[email protected]>wrote:
>>
>>> On 10/11/2010 09:10 PM, Gilles Chanteperdrix wrote:
>>> > Peter Pastor wrote:
>>> >> Hey Gilles,
>>> >>
>>> >> Thanks for the hint. I "fixed" this problem by loading the nvidia
>>> driver
>>> >> (instead of nv) as default. Now the graphic cards uses IRQ 24 which
>>> does not
>>> >> collide with IRQ 11 of the CAN bus card (see attached lspci.txt).
>>> >>
>>> >> The only other device that uses IRQ 11 is
>>> >> # 00:00.0 Host bridge [0600]: Intel Corporation 5520 I/O Hub to ESI
>>> Port
>>> >> [8086:3406] (rev 13)
>>> >>
>>> >> But I guess that is ok, is it ? I checked the FAQs and went through
>>> the list
>>> >> but I feel I can't do much. I will try a few things and disable
>>> everything
>>> >> that is unneeded. The FAQ list also suggests to enable CONFIG_PCI_MSI
>>> which
>>> >> is disabled right now. What would now be a reasonable thing to do ?
>>> >
>>> > Keep PCI_MSI disabled. The FAQ is wrong and should be fixed.
>>> >
>>> >>
>>> >> How can I find out and about which device is causing the address space
>>> >> collision ?
>>> >>
>>> >> # address space collision: host bridge window [mem
>>> 0xd7f00000-0xe0000000]
>>> >> conflicts with PCI Bus 0000:00 [mem 0xe0000000-0xf7ffffff]
>>> >>
>>> >> I attached the syslog of the latest boot. I enabled some debugging
>>> infos
>>> >> which hopefully allow to trace down the problem. Interestingly, this
>>> time,
>>> >> the kernel spit out
>>> >>
>>> >> # RT-Socket-CAN 0.90.2 - (C) 2006 RT-Socket-CAN Development Team
>>> >>
>>> >> right before it froze.
>>> >
>>> > You should try and put some printks in RTCan code to see how far it
>>> > goes. But I guess Wolfgang may be of more help.
>>>
>>> Well, normally messages like:
>>>
>>> RTCAN SJA1000 driver initialized
>>> PEAK-PCI-CAN: initializing device 001c:0001
>>> PEAK-PCI-CAN: base_addr=c907c000 conf_addr=c907a000 irq=16
>>> rtcan: registered rtcan0
>>> PEAK-PCI-CAN: base_addr=c907e400 conf_addr=c907a000 irq=16
>>> rtcan: registered rtcan1
>>>
>>> should follow. I would add printk's into peak_pci_init_one() and
>>> rtcan_peak_pci_add_chan() in ksrc/drivers/can/sja1000/rtcan_peak_pci.c.
>>> Did you compile the SJA1000 driver's into the kernel? Try building
>>> modules, which you then can load manually.
>>>
>>> BTW: what PEAK PCI card are you using?
>>>
>>> Wolfgang.
>>>
>>
>>
>
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
