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