Fwd: Problem with so Loved interrupts

Fwd: Problem with so Loved interrupts

[Willy Lambert]

---------- Forwarded message ----------
From: Willy Lambert <lambert.willy@gmail.com>
Date: 2011/11/9
Subject: Problem with so Loved interrupts
To: linux-can <linux-can@vger.kernel.org>


Hi all,
I am having interruption problems again.
The symptom is a /proc/interrupt or /proc/xenomia/irq not rising.
I am sure of my Hardware because I used an archive of a working linux
system and it works. So the wired are Ok, device is responding, BIOS
is well configured.
I check this : http://comments.gmane.org/gmane.network.socketcan.user/813,
and I am sure it is not the case since it worked with the old system
and it has been electrically protected.
I also recheck this
http://old.nabble.com/Re%3A-Trying-to-use-socketCan-on-an-Ixxat-PC-I-04-104-p30752686.html
but once again, everything is ok with old software.
So what did I changed ? I was updating many of my dependencies on my
target and even tried 64b, so the road have been very long. What I
accuse much is my new kernel. Before it was a 2.6.35.7, now it is a
2.6.38.8 with xenomai patches. I may have forgot to select a kernel
option for interrupts...

For completeness :
my boot up script :
#choose driver under xenomai or gnulinux
BAUDRATE=1000000
#notice that we can only set one IRQ for both can, this is an hardware
limitation
CAN_OPTS="irq=10,10 mem=0xD0000,0xD0200 ocr=0x5e,0x5e cdr=0,0"
if [ $OROCOS_TARGET == "xenomai" ]
then
modprobe xeno_can_mem $CAN_OPTS
rtcanconfig rtcan0 -b $BAUDRATE -v start
rtcanconfig rtcan1 -b $BAUDRATE -v start
else
modprobe sja1000_isa $CAN_OPTS
#chargement de l'interface dans ifconfig
ip link set can0 type can bitrate $BAUDRATE restart-ms 1000
ip link set can1 type can bitrate $BAUDRATE restart-ms 1000
#demarrage de l'interface
ifconfig can0 up
ifconfig can1 up
fi
The load seems to be OK there is no error.

/proc/xenomai/interrupt :
IRQ         CPU0
  0:       88694         [timer]
 10:           0         SJA1000 SJA1000
 34:           0         [virtual]

/proc/iomem :
root@beta(8.2):~# cat /proc/iomem
00000000-0000ffff : reserved
00010000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : PCI Bus 0000:00
  000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000d0000-000dffff : PCI Bus 0000:00
  000d0000-000d007f : sja1000-mem
  000d0200-000d027f : sja1000-mem
000e0000-000fffff : reserved
  000f0000-000fffff : System ROM
00100000-7f69ffff : System RAM
  01000000-01282733 : Kernel code
  01282734-013f163f : Kernel data
....

I am sorry I don't have the dmesg yet, I'll provide it as soon as possible

Re: Problem with so Loved interrupts

[Willy Lambert]

2011/11/9 Willy Lambert <lambert.willy@gmail.com>:
> ---------- Forwarded message ----------
> From: Willy Lambert <lambert.willy@gmail.com>
> Date: 2011/11/9
> Subject: Problem with so Loved interrupts
> To: linux-can <linux-can@vger.kernel.org>
>
>
> Hi all,
> I am having interruption problems again.
> The symptom is a /proc/interrupt or /proc/xenomia/irq not rising.
> I am sure of my Hardware because I used an archive of a working linux
> system and it works. So the wired are Ok, device is responding, BIOS
> is well configured.
> I check this : http://comments.gmane.org/gmane.network.socketcan.user/813,
> and I am sure it is not the case since it worked with the old system
> and it has been electrically protected.
> I also recheck this
> http://old.nabble.com/Re%3A-Trying-to-use-socketCan-on-an-Ixxat-PC-I-04-104-p30752686.html
> but once again, everything is ok with old software.
> So what did I changed ? I was updating many of my dependencies on my
> target and even tried 64b, so the road have been very long. What I
> accuse much is my new kernel. Before it was a 2.6.35.7, now it is a
> 2.6.38.8 with xenomai patches. I may have forgot to select a kernel
> option for interrupts...
>
> For completeness :
> my boot up script :
> #choose driver under xenomai or gnulinux
> BAUDRATE=1000000
> #notice that we can only set one IRQ for both can, this is an hardware
> limitation
> CAN_OPTS="irq=10,10 mem=0xD0000,0xD0200 ocr=0x5e,0x5e cdr=0,0"
> if [ $OROCOS_TARGET == "xenomai" ]
> then
> modprobe xeno_can_mem $CAN_OPTS
> rtcanconfig rtcan0 -b $BAUDRATE -v start
> rtcanconfig rtcan1 -b $BAUDRATE -v start
> else
> modprobe sja1000_isa $CAN_OPTS
> #chargement de l'interface dans ifconfig
> ip link set can0 type can bitrate $BAUDRATE restart-ms 1000
> ip link set can1 type can bitrate $BAUDRATE restart-ms 1000
> #demarrage de l'interface
> ifconfig can0 up
> ifconfig can1 up
> fi
> The load seems to be OK there is no error.
>

RTCAN DRIVER :
********************

> /proc/xenomai/interrupt :
> IRQ         CPU0
>   0:       88694         [timer]
>  10:           0         SJA1000 SJA1000
>  34:           0         [virtual]
>
> /proc/iomem :
> root@beta(8.2):~# cat /proc/iomem
> 00000000-0000ffff : reserved
> 00010000-0009fbff : System RAM
> 0009fc00-0009ffff : reserved
> 000a0000-000bffff : PCI Bus 0000:00
>   000a0000-000bffff : Video RAM area
> 000c0000-000c7fff : Video ROM
> 000d0000-000dffff : PCI Bus 0000:00
>   000d0000-000d007f : sja1000-mem
>   000d0200-000d027f : sja1000-mem
> 000e0000-000fffff : reserved
>   000f0000-000fffff : System ROM
> 00100000-7f69ffff : System RAM
>   01000000-01282733 : Kernel code
>   01282734-013f163f : Kernel data
> ....
>
> I am sorry I don't have the dmesg yet, I'll provide it as soon as possible
>

[ 3037.567570] RT-Socket-CAN 0.90.2 - (C) 2006 RT-Socket-CAN Development Team
[ 3037.571859] RTCAN SJA1000 driver initialized
[ 3037.574343] rtcan: registered rtcan0
[ 3037.574365] rtcan: registered rtcan1



SJA1000 DRIVER :
************************

Here is the dmesg when loading the sja1000_isa driver :
[ 1966.225513] CAN device driver interface
[ 1966.231935] sja1000 CAN netdevice driver
[ 1966.237265] sja1000_isa sja1000_isa.0: sja1000_isa device
registered (reg_base=0xc00d0000, irq=10)
[ 1966.239329] sja1000_isa sja1000_isa.1: sja1000_isa device
registered (reg_base=0xc00d0200, irq=10)
[ 1966.242129] Legacy sja1000_isa driver for max. 8 devices registered
[ 1966.258488] sja1000_isa sja1000_isa.0: setting BTR0=0x00 BTR1=0x14
[ 1966.265427] sja1000_isa sja1000_isa.1: setting BTR0=0x00 BTR1=0x14
(so everything seems ok)

Here is the /proc/interrupts
root@beta(8.2):/opt/ard/arp_hml/script/linux# cat /proc/interrupts
           CPU0
  0:     192360    XT-PIC-XT-PIC    timer
  1:          2    XT-PIC-XT-PIC    i8042
  2:          0    XT-PIC-XT-PIC    cascade
  5:        101    XT-PIC-XT-PIC    uhci_hcd:usb3
  6:       2526    XT-PIC-XT-PIC    ehci_hcd:usb1, uhci_hcd:usb2, eth0
  8:          0    XT-PIC-XT-PIC    rtc0
  9:          0    XT-PIC-XT-PIC    acpi
 10:          0    XT-PIC-XT-PIC    can0, can1
 12:          4    XT-PIC-XT-PIC    i8042
 14:          0    XT-PIC-XT-PIC    ata_piix
 15:       4081    XT-PIC-XT-PIC    ata_piix
NMI:          0   Non-maskable interrupts
MCE:          0   Machine check exceptions
MCP:          8   Machine check polls
ERR:          0

/proc/iomem :
000d0000-000dffff : PCI Bus 0000:00
  000d0000-000d007f : sja1000-mem
  000d0200-000d027f : sja1000-mem

Re: Problem with so Loved interrupts

[Wolfgang Grandegger]

On 11/10/2011 09:56 AM, Willy Lambert wrote:
> 2011/11/9 Willy Lambert <lambert.willy@gmail.com>:
>> ---------- Forwarded message ----------
>> From: Willy Lambert <lambert.willy@gmail.com>
>> Date: 2011/11/9
>> Subject: Problem with so Loved interrupts
>> To: linux-can <linux-can@vger.kernel.org>
>>
>>
>> Hi all,
>> I am having interruption problems again.
>> The symptom is a /proc/interrupt or /proc/xenomia/irq not rising.
>> I am sure of my Hardware because I used an archive of a working linux
>> system and it works. So the wired are Ok, device is responding, BIOS
>> is well configured.
>> I check this : http://comments.gmane.org/gmane.network.socketcan.user/813,
>> and I am sure it is not the case since it worked with the old system
>> and it has been electrically protected.
>> I also recheck this
>> http://old.nabble.com/Re%3A-Trying-to-use-socketCan-on-an-Ixxat-PC-I-04-104-p30752686.html
>> but once again, everything is ok with old software.

Please describe "old system" and "old software".

>> So what did I changed ? I was updating many of my dependencies on my
>> target and even tried 64b, so the road have been very long. What I
>> accuse much is my new kernel. Before it was a 2.6.35.7, now it is a
>> 2.6.38.8 with xenomai patches. I may have forgot to select a kernel
>> option for interrupts...

Well, you get other interrupts and therefore it seem to be specific to
the CAN hardware and the bus/slot it is connected to. You say that it
works with your 2.6.35.7 kernel but does not with 2.6.38.8 on the
*identical* hardware, right? Then I would check the kernel configs for
PNP related differences.

Wolfgang.

Re: Problem with so Loved interrupts

[Willy Lambert]

2011/11/10 Wolfgang Grandegger <wg@grandegger.com>:
> On 11/10/2011 09:56 AM, Willy Lambert wrote:
>> 2011/11/9 Willy Lambert <lambert.willy@gmail.com>:
>>> ---------- Forwarded message ----------
>>> From: Willy Lambert <lambert.willy@gmail.com>
>>> Date: 2011/11/9
>>> Subject: Problem with so Loved interrupts
>>> To: linux-can <linux-can@vger.kernel.org>
>>>
>>>
>>> Hi all,
>>> I am having interruption problems again.
>>> The symptom is a /proc/interrupt or /proc/xenomia/irq not rising.
>>> I am sure of my Hardware because I used an archive of a working linux
>>> system and it works. So the wired are Ok, device is responding, BIOS
>>> is well configured.
>>> I check this : http://comments.gmane.org/gmane.network.socketcan.user/813,
>>> and I am sure it is not the case since it worked with the old system
>>> and it has been electrically protected.
>>> I also recheck this
>>> http://old.nabble.com/Re%3A-Trying-to-use-socketCan-on-an-Ixxat-PC-I-04-104-p30752686.html
>>> but once again, everything is ok with old software.
>
> Please describe "old system" and "old software".

The system is a PC104 board with an Atom processor, on top of wich a
CAN PC104 board is connected via the ISA bus. The sja1000 are acessed
by iomem. With your help we did some Bios magics and some tunings to
make it running. I currently have a fully working CAN bus with one
device (and resistors...) that is configured at the rigth baudrate.
This device has a led that change color with CAN NMT states, so I can
easily see if a CAN message is going on the bus (with a 000#01.00 NMT
request for instance).

The old system is a Debian 6.0.1 distibution with a custom 2.6.35.7
built kernel with all that was required to make it working.
The new one is the same debian with a custom 2.6.38.8 kernel with
xenomai 2.6.0 patches.

>
>>> So what did I changed ? I was updating many of my dependencies on my
>>> target and even tried 64b, so the road have been very long. What I
>>> accuse much is my new kernel. Before it was a 2.6.35.7, now it is a
>>> 2.6.38.8 with xenomai patches. I may have forgot to select a kernel
>>> option for interrupts...
>
> Well, you get other interrupts and therefore it seem to be specific to
> the CAN hardware and the bus/slot it is connected to. You say that it
> works with your 2.6.35.7 kernel but does not with 2.6.38.8 on the
> *identical* hardware, right? Then I would check the kernel configs for
> PNP related differences.
>

The hardware and Bios are identical with last . I use clonezilla
(http://clonezilla.org/clonezilla-live.php) to switch between the old
archived filesystem and the new one.

I also seen something interesting on the new kernel system. I don't
have interrupts but the first message goes on the bus ! Because the
led of my device turn into the operationnal state afet a 000#01.00
request (tested with xenomai driver). So the message goes, but the
"ack" if any is not going back to the driver.

There is on difference on the interrupts type. Here is the old system
2.6.35.7 /proc/interrupts. Note that the type is IO-APIC
root@beta:~# cat /proc/interrupts
           CPU0
  0:    5288851   IO-APIC-edge      timer
  1:          4   IO-APIC-edge      i8042
  8:          1   IO-APIC-edge      rtc0
  9:          0   IO-APIC-fasteoi   acpi
 10:          6   IO-APIC-edge      can0, can1
 12:          7   IO-APIC-edge      i8042
 14:          0   IO-APIC-edge      ata_piix
 15:       3755   IO-APIC-edge      ata_piix
 19:        232   IO-APIC-fasteoi   uhci_hcd:usb3
 23:          2   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb2
 40:       4563   PCI-MSI-edge      eth0
NMI:          0   Non-maskable interrupts
LOC:       5406   Local timer interrupts
SPU:          0   Spurious interrupts
PMI:          0   Performance monitoring interrupts
PND:          0   Performance pending work
TRM:          0   Thermal event interrupts
THR:          0   Threshold APIC interrupts
MCE:          0   Machine check exceptions
MCP:         18   Machine check polls
ERR:          0
MIS:          0





> Wolfgang.
>
>

Re: Problem with so Loved interrupts

[Wolfgang Grandegger]

On 11/10/2011 11:56 AM, Willy Lambert wrote:
> 2011/11/10 Wolfgang Grandegger <wg@grandegger.com>:
>> On 11/10/2011 09:56 AM, Willy Lambert wrote:
>>> 2011/11/9 Willy Lambert <lambert.willy@gmail.com>:
>>>> ---------- Forwarded message ----------
>>>> From: Willy Lambert <lambert.willy@gmail.com>
>>>> Date: 2011/11/9
>>>> Subject: Problem with so Loved interrupts
>>>> To: linux-can <linux-can@vger.kernel.org>
>>>>
>>>>
>>>> Hi all,
>>>> I am having interruption problems again.
>>>> The symptom is a /proc/interrupt or /proc/xenomia/irq not rising.
>>>> I am sure of my Hardware because I used an archive of a working linux
>>>> system and it works. So the wired are Ok, device is responding, BIOS
>>>> is well configured.
>>>> I check this : http://comments.gmane.org/gmane.network.socketcan.user/813,
>>>> and I am sure it is not the case since it worked with the old system
>>>> and it has been electrically protected.
>>>> I also recheck this
>>>> http://old.nabble.com/Re%3A-Trying-to-use-socketCan-on-an-Ixxat-PC-I-04-104-p30752686.html
>>>> but once again, everything is ok with old software.
>>
>> Please describe "old system" and "old software".
> 
> The system is a PC104 board with an Atom processor, on top of wich a
> CAN PC104 board is connected via the ISA bus. The sja1000 are acessed
> by iomem. With your help we did some Bios magics and some tunings to
> make it running. I currently have a fully working CAN bus with one
> device (and resistors...) that is configured at the rigth baudrate.
> This device has a led that change color with CAN NMT states, so I can
> easily see if a CAN message is going on the bus (with a 000#01.00 NMT
> request for instance).
> 
> The old system is a Debian 6.0.1 distibution with a custom 2.6.35.7
> built kernel with all that was required to make it working.
> The new one is the same debian with a custom 2.6.38.8 kernel with
> xenomai 2.6.0 patches.
> 
>>
>>>> So what did I changed ? I was updating many of my dependencies on my
>>>> target and even tried 64b, so the road have been very long. What I
>>>> accuse much is my new kernel. Before it was a 2.6.35.7, now it is a
>>>> 2.6.38.8 with xenomai patches. I may have forgot to select a kernel
>>>> option for interrupts...
>>
>> Well, you get other interrupts and therefore it seem to be specific to
>> the CAN hardware and the bus/slot it is connected to. You say that it
>> works with your 2.6.35.7 kernel but does not with 2.6.38.8 on the
>> *identical* hardware, right? Then I would check the kernel configs for
>> PNP related differences.
>>
> 
> The hardware and Bios are identical with last . I use clonezilla
> (http://clonezilla.org/clonezilla-live.php) to switch between the old
> archived filesystem and the new one.
> 
> I also seen something interesting on the new kernel system. I don't
> have interrupts but the first message goes on the bus ! Because the
> led of my device turn into the operationnal state afet a 000#01.00
> request (tested with xenomai driver). So the message goes, but the
> "ack" if any is not going back to the driver.
> 
> There is on difference on the interrupts type. Here is the old system
> 2.6.35.7 /proc/interrupts. Note that the type is IO-APIC
> root@beta:~# cat /proc/interrupts
>            CPU0
>   0:    5288851   IO-APIC-edge      timer
>   1:          4   IO-APIC-edge      i8042
>   8:          1   IO-APIC-edge      rtc0
>   9:          0   IO-APIC-fasteoi   acpi
>  10:          6   IO-APIC-edge      can0, can1
>  12:          7   IO-APIC-edge      i8042
>  14:          0   IO-APIC-edge      ata_piix
>  15:       3755   IO-APIC-edge      ata_piix
>  19:        232   IO-APIC-fasteoi   uhci_hcd:usb3
>  23:          2   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb2
>  40:       4563   PCI-MSI-edge      eth0
> NMI:          0   Non-maskable interrupts
> LOC:       5406   Local timer interrupts
> SPU:          0   Spurious interrupts
> PMI:          0   Performance monitoring interrupts
> PND:          0   Performance pending work
> TRM:          0   Thermal event interrupts
> THR:          0   Threshold APIC interrupts
> MCE:          0   Machine check exceptions
> MCP:         18   Machine check polls
> ERR:          0
> MIS:          0

Can't tell where the difference comes from, sorry. You should first try
*without* Xenomai (and Xenomai patches) just to be sure that it's not
related to Xenomai. If if still doesn't work, please show use the
.config and /proc/modules of both setups (2.6.35 and 2.6.38).

Wolfgang.

Re: Problem with so Loved interrupts

[Willy Lambert]

2011/11/10 Wolfgang Grandegger <wg@grandegger.com>:
> On 11/10/2011 11:56 AM, Willy Lambert wrote:
>> 2011/11/10 Wolfgang Grandegger <wg@grandegger.com>:
>>> On 11/10/2011 09:56 AM, Willy Lambert wrote:
>>>> 2011/11/9 Willy Lambert <lambert.willy@gmail.com>:
>>>>> ---------- Forwarded message ----------
>>>>> From: Willy Lambert <lambert.willy@gmail.com>
>>>>> Date: 2011/11/9
>>>>> Subject: Problem with so Loved interrupts
>>>>> To: linux-can <linux-can@vger.kernel.org>
>>>>>
>>>>>
>>>>> Hi all,
>>>>> I am having interruption problems again.
>>>>> The symptom is a /proc/interrupt or /proc/xenomia/irq not rising.
>>>>> I am sure of my Hardware because I used an archive of a working linux
>>>>> system and it works. So the wired are Ok, device is responding, BIOS
>>>>> is well configured.
>>>>> I check this : http://comments.gmane.org/gmane.network.socketcan.user/813,
>>>>> and I am sure it is not the case since it worked with the old system
>>>>> and it has been electrically protected.
>>>>> I also recheck this
>>>>> http://old.nabble.com/Re%3A-Trying-to-use-socketCan-on-an-Ixxat-PC-I-04-104-p30752686.html
>>>>> but once again, everything is ok with old software.
>>>
>>> Please describe "old system" and "old software".
>>
>> The system is a PC104 board with an Atom processor, on top of wich a
>> CAN PC104 board is connected via the ISA bus. The sja1000 are acessed
>> by iomem. With your help we did some Bios magics and some tunings to
>> make it running. I currently have a fully working CAN bus with one
>> device (and resistors...) that is configured at the rigth baudrate.
>> This device has a led that change color with CAN NMT states, so I can
>> easily see if a CAN message is going on the bus (with a 000#01.00 NMT
>> request for instance).
>>
>> The old system is a Debian 6.0.1 distibution with a custom 2.6.35.7
>> built kernel with all that was required to make it working.
>> The new one is the same debian with a custom 2.6.38.8 kernel with
>> xenomai 2.6.0 patches.
>>
>>>
>>>>> So what did I changed ? I was updating many of my dependencies on my
>>>>> target and even tried 64b, so the road have been very long. What I
>>>>> accuse much is my new kernel. Before it was a 2.6.35.7, now it is a
>>>>> 2.6.38.8 with xenomai patches. I may have forgot to select a kernel
>>>>> option for interrupts...
>>>
>>> Well, you get other interrupts and therefore it seem to be specific to
>>> the CAN hardware and the bus/slot it is connected to. You say that it
>>> works with your 2.6.35.7 kernel but does not with 2.6.38.8 on the
>>> *identical* hardware, right? Then I would check the kernel configs for
>>> PNP related differences.
>>>
>>
>> The hardware and Bios are identical with last . I use clonezilla
>> (http://clonezilla.org/clonezilla-live.php) to switch between the old
>> archived filesystem and the new one.
>>
>> I also seen something interesting on the new kernel system. I don't
>> have interrupts but the first message goes on the bus ! Because the
>> led of my device turn into the operationnal state afet a 000#01.00
>> request (tested with xenomai driver). So the message goes, but the
>> "ack" if any is not going back to the driver.
>>
>> There is on difference on the interrupts type. Here is the old system
>> 2.6.35.7 /proc/interrupts. Note that the type is IO-APIC
>> root@beta:~# cat /proc/interrupts
>>            CPU0
>>   0:    5288851   IO-APIC-edge      timer
>>   1:          4   IO-APIC-edge      i8042
>>   8:          1   IO-APIC-edge      rtc0
>>   9:          0   IO-APIC-fasteoi   acpi
>>  10:          6   IO-APIC-edge      can0, can1
>>  12:          7   IO-APIC-edge      i8042
>>  14:          0   IO-APIC-edge      ata_piix
>>  15:       3755   IO-APIC-edge      ata_piix
>>  19:        232   IO-APIC-fasteoi   uhci_hcd:usb3
>>  23:          2   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb2
>>  40:       4563   PCI-MSI-edge      eth0
>> NMI:          0   Non-maskable interrupts
>> LOC:       5406   Local timer interrupts
>> SPU:          0   Spurious interrupts
>> PMI:          0   Performance monitoring interrupts
>> PND:          0   Performance pending work
>> TRM:          0   Thermal event interrupts
>> THR:          0   Threshold APIC interrupts
>> MCE:          0   Machine check exceptions
>> MCP:         18   Machine check polls
>> ERR:          0
>> MIS:          0
>
> Can't tell where the difference comes from, sorry. You should first try
> *without* Xenomai (and Xenomai patches) just to be sure that it's not
> related to Xenomai. If if still doesn't work, please show use the
> .config and /proc/modules of both setups (2.6.35 and 2.6.38).
>

My non working 2.6.38.8 was built from the default Debian .config file
with many options included and an initrd. I didn't came from 2.5.37.5
because for some reason I had a kernel boot panic because of
filesystem/disk driver modules. But I managed to find the right optio
today.

With a fresh 2.6.38.8 made from the 2.6.35.7 .config file with make
oldconfig, installed on the old system  it works ! And I still have
IO-APIC-edge interrupts.  I also made a try adding xenomai with
success. For completeness I tested this ligth 2.6.38.8 kernel on the
"new" filesystem in place of the faulty 2.6.38.8 kernel and everything
seems OK.

The IRQ type differences must be due to kernel configurations (my
faulty big 2.6.38.8 one and my working-now ligth 2.6.38.8 from
2.5.35.7).
I prefere using the light kernel version that's now working so I don't
mind giving up with debugging this problem. If you are interested in
finding what's happening let me know.



I'll do my personnal functionnal tests and I'll try the platform
driver. Thanks for help.

> Wolfgang.
>

Re: Problem with so Loved interrupts

[Willy Lambert]

2011/11/10 Willy Lambert <lambert.willy@gmail.com>:
> 2011/11/10 Wolfgang Grandegger <wg@grandegger.com>:
>> On 11/10/2011 11:56 AM, Willy Lambert wrote:
>>> 2011/11/10 Wolfgang Grandegger <wg@grandegger.com>:
>>>> On 11/10/2011 09:56 AM, Willy Lambert wrote:
>>>>> 2011/11/9 Willy Lambert <lambert.willy@gmail.com>:
>>>>>> ---------- Forwarded message ----------
>>>>>> From: Willy Lambert <lambert.willy@gmail.com>
>>>>>> Date: 2011/11/9
>>>>>> Subject: Problem with so Loved interrupts
>>>>>> To: linux-can <linux-can@vger.kernel.org>
>>>>>>
>>>>>>
>>>>>> Hi all,
>>>>>> I am having interruption problems again.
>>>>>> The symptom is a /proc/interrupt or /proc/xenomia/irq not rising.
>>>>>> I am sure of my Hardware because I used an archive of a working linux
>>>>>> system and it works. So the wired are Ok, device is responding, BIOS
>>>>>> is well configured.
>>>>>> I check this : http://comments.gmane.org/gmane.network.socketcan.user/813,
>>>>>> and I am sure it is not the case since it worked with the old system
>>>>>> and it has been electrically protected.
>>>>>> I also recheck this
>>>>>> http://old.nabble.com/Re%3A-Trying-to-use-socketCan-on-an-Ixxat-PC-I-04-104-p30752686.html
>>>>>> but once again, everything is ok with old software.
>>>>
>>>> Please describe "old system" and "old software".
>>>
>>> The system is a PC104 board with an Atom processor, on top of wich a
>>> CAN PC104 board is connected via the ISA bus. The sja1000 are acessed
>>> by iomem. With your help we did some Bios magics and some tunings to
>>> make it running. I currently have a fully working CAN bus with one
>>> device (and resistors...) that is configured at the rigth baudrate.
>>> This device has a led that change color with CAN NMT states, so I can
>>> easily see if a CAN message is going on the bus (with a 000#01.00 NMT
>>> request for instance).
>>>
>>> The old system is a Debian 6.0.1 distibution with a custom 2.6.35.7
>>> built kernel with all that was required to make it working.
>>> The new one is the same debian with a custom 2.6.38.8 kernel with
>>> xenomai 2.6.0 patches.
>>>
>>>>
>>>>>> So what did I changed ? I was updating many of my dependencies on my
>>>>>> target and even tried 64b, so the road have been very long. What I
>>>>>> accuse much is my new kernel. Before it was a 2.6.35.7, now it is a
>>>>>> 2.6.38.8 with xenomai patches. I may have forgot to select a kernel
>>>>>> option for interrupts...
>>>>
>>>> Well, you get other interrupts and therefore it seem to be specific to
>>>> the CAN hardware and the bus/slot it is connected to. You say that it
>>>> works with your 2.6.35.7 kernel but does not with 2.6.38.8 on the
>>>> *identical* hardware, right? Then I would check the kernel configs for
>>>> PNP related differences.
>>>>
>>>
>>> The hardware and Bios are identical with last . I use clonezilla
>>> (http://clonezilla.org/clonezilla-live.php) to switch between the old
>>> archived filesystem and the new one.
>>>
>>> I also seen something interesting on the new kernel system. I don't
>>> have interrupts but the first message goes on the bus ! Because the
>>> led of my device turn into the operationnal state afet a 000#01.00
>>> request (tested with xenomai driver). So the message goes, but the
>>> "ack" if any is not going back to the driver.
>>>
>>> There is on difference on the interrupts type. Here is the old system
>>> 2.6.35.7 /proc/interrupts. Note that the type is IO-APIC
>>> root@beta:~# cat /proc/interrupts
>>>            CPU0
>>>   0:    5288851   IO-APIC-edge      timer
>>>   1:          4   IO-APIC-edge      i8042
>>>   8:          1   IO-APIC-edge      rtc0
>>>   9:          0   IO-APIC-fasteoi   acpi
>>>  10:          6   IO-APIC-edge      can0, can1
>>>  12:          7   IO-APIC-edge      i8042
>>>  14:          0   IO-APIC-edge      ata_piix
>>>  15:       3755   IO-APIC-edge      ata_piix
>>>  19:        232   IO-APIC-fasteoi   uhci_hcd:usb3
>>>  23:          2   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb2
>>>  40:       4563   PCI-MSI-edge      eth0
>>> NMI:          0   Non-maskable interrupts
>>> LOC:       5406   Local timer interrupts
>>> SPU:          0   Spurious interrupts
>>> PMI:          0   Performance monitoring interrupts
>>> PND:          0   Performance pending work
>>> TRM:          0   Thermal event interrupts
>>> THR:          0   Threshold APIC interrupts
>>> MCE:          0   Machine check exceptions
>>> MCP:         18   Machine check polls
>>> ERR:          0
>>> MIS:          0
>>
>> Can't tell where the difference comes from, sorry. You should first try
>> *without* Xenomai (and Xenomai patches) just to be sure that it's not
>> related to Xenomai. If if still doesn't work, please show use the
>> .config and /proc/modules of both setups (2.6.35 and 2.6.38).
>>
>
> My non working 2.6.38.8 was built from the default Debian .config file
> with many options included and an initrd. I didn't came from 2.5.37.5
> because for some reason I had a kernel boot panic because of
> filesystem/disk driver modules. But I managed to find the right optio
> today.
>
> With a fresh 2.6.38.8 made from the 2.6.35.7 .config file with make
> oldconfig, installed on the old system  it works ! And I still have
> IO-APIC-edge interrupts.  I also made a try adding xenomai with
> success. For completeness I tested this ligth 2.6.38.8 kernel on the
> "new" filesystem in place of the faulty 2.6.38.8 kernel and everything
> seems OK.
>
> The IRQ type differences must be due to kernel configurations (my
> faulty big 2.6.38.8 one and my working-now ligth 2.6.38.8 from
> 2.5.35.7).
> I prefere using the light kernel version that's now working so I don't
> mind giving up with debugging this problem. If you are interested in
> finding what's happening let me know.
>
>
>
> I'll do my personnal functionnal tests and I'll try the platform
> driver. Thanks for help.
>

FYI some kernel configs that may be linked to the problem are :

•	Bus options (PCI etc.) ->Interrupts on hypertransports devices
•	Processor type and features ->Local APIC support on uniprocessors
•	Processor type and features ->IO-APIC support on uniprocessors
•	Bus options (PCI etc.) ->PCI IOV Support

I can't spend more time now on it to really find the one that is
responsible of this IRQ type change



>> Wolfgang.
>>
>