Hi Chris,

Chris Verges wrote:
> Hi Wolfgang,
> 
> I've upgraded to v2.6.32 and am building the entire SocketCAN subsystem
> into the kernel (monolithic).  Our electrical engineer has confirmed
> that this is the proper initialization command for the can0 interface:
> 
>       ip link set can0 \
>               type can \
>                       tq 90 \
>                       prop-seg 1 \
>                       phase-seg1 5 \
>                       phase-seg2 4 \
>                       sjw 2
> 
> This results in the following:
> 
> # ip link set can0 type can tq 90 prop-seg 1 phase-seg1 5 phase-seg2 4
> sjw 2
> at91_can at91_can: writing AT91_BR: 0x00081043
> 
> # ip -d -s link show can0
> 2: can0: <NOARP,ECHO> mtu 16 qdisc pfifo_fast state DOWN qlen 1000
>     link/can
>     can state STOPPED restart-ms 0
>     bitrate 1003313 sample-point 0.636
>     tq 90 prop-seg 1 phase-seg1 5 phase-seg2 4 sjw 2
>     : tseg1 4..16 tseg2 2..8 sjw 1..4 brp 2..128 brp-inc 1
>     clock 99328000
>     re-started bus-errors arbit-lost error-warn error-pass bus-off
>     0          0          0          0          0          0
>     RX: bytes  packets  errors  dropped overrun mcast
>     0          0        0       0       0       0
>     TX: bytes  packets  errors  dropped carrier collsns
>     0          0        0       0       0       0
> 
> Unfortunately, we still see cansend hang:
> 
> # cansend can0 123#
> BUG: soft lockup - CPU#0 stuck for 61s! [cansend:1424]
> Modules linked in:
> 
> Pid: 1424, comm:              cansend
> CPU: 0    Not tainted  (2.6.32 #1)
> PC is at at91_poll+0x294/0x4d8
> LR is at net_rx_action+0xa0/0x218
> pc : [<c0199440>]    lr : [<c0218ba8>]    psr: 00000013
> sp : c3979d98  ip : c3979dd8  fp : 4026e000
> r10: 0000000c  r9 : c03ae1f0  r8 : 00000000
> r7 : 4426e000  r6 : c39be2c0  r5 : 0000000c  r4 : c39be000
> r3 : 04000000  r2 : c3978000  r1 : 0000000c  r0 : 00000000
> Flags: nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
> Control: 0005317f  Table: 23b4c000  DAC: 00000015
> 
> There definitely seems to be interaction with the at91_poll() function
> in this "hang" time.  I'm wondering why the driver isn't failing
> gracefully.  I'll start diving into the code, but hopefully someone else
> with more experience on the at91_can driver will have a quicker insight.

Hm, the hang is not OK, of course, and might be due to a software issue.
Nevertheless, to you see any message going out to the wire?

Wolfgang.

> Thanks,
> Chris
> _______________________________________________
> Socketcan-users mailing list
> [email protected]
> https://lists.berlios.de/mailman/listinfo/socketcan-users
> 
> 

_______________________________________________
Socketcan-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-users

Reply via email to