* Re: Testing IRDA device driver
From: Amit Virdi @ 2011-04-19 10:14 UTC (permalink / raw)
To: samuel, davem, eric.dumazet; +Cc: Amit Virdi, netdev
In-Reply-To: <4DA830EF.701@st.com>
Hey,
I have been trying to transfer a file from one system to another using
IrCOMM layer on IrDA. We have a DICE's Fast IrDA Controller on our board
and I've written driver for the same. I need your help in
finding/resolving the problem, please.
In my setup, I'm using two identical boards having the IrDA IP logic.
Once the board is up, I'm executing two commands:
1. ifconfig irda0 up
2. echo 1 > /proc/sys/net/irda/discovery
Both the IrDA devices discover each other successfully. If I run
irattach, I can see SNRM command being sent and its response being
received on one board. Then some more messages are exchanged- i:cmd,
i:rsp, rr:cmd etc. I could see QOS parameters being exchanged. However,
after this rr:cmd and rr:rsp messages are exchanged for sometime and
then I get "IrLAP, no activity on link!" messages. No more messages are
exchanged thereafter.I took the irdadump logs for both the transmitter
and receiver. All the messages sent by the transmitter are received
successfully.
Meanwhile, when the rr:cmd rr:rsp messages are being exchanged, I tried
using ircp to transfer/receive file, but received an error message
"Connecting...failed". Could you please help me? I'm really bogged down
by this problem. I've been trying hard for the past couple of weeks. I
shall be very much thankful to you.
Best Regards
Amit Virdi
On 4/15/2011 5:20 PM, Amit Virdi wrote:
> Hi All/Samuel,
>
> I need your help in transferring file through IrCOMM layer.
>
> I'm facing a strange problem. I'm using same kernel image on two
> similar boards. When I run irattach /dev/ircomm0 on one board, the
> DISCOVERY protocol is initiated and the IrDA devices on both the
> boards detect each other. When irattach is run on board 2 also, SNRM
> command is sent by board 2 and UA response is received by it. After
> few more commands, "sirdev_receive too early" message is displayed
> multiple times and then "IrLAP, no activity on the link" message is
> received. The subsequent DISCOVERY REQUEST/RESPONSE does not have the
> hint field as c404 but 4400. If I run ircp -r on one board or ircp
> <filename>, I get "Connecting... failed" message.
>
> Is anyone having a clue what might be the problem?Here's the detailed
> description of the scenario:
> 1. When the boards are booted up, I run ifconfig irda0 up on both the
> boards. The port is up, no IrDA message is exchanged.
> 2. I run "irattach /dev/ircomm0 -s" on board 1. IrDA discovery
> protocol is initiated, XID command is sent and XID response is
> received. irdadump utility shows the messages exchanged.
> =============
> root@driver_s320:~# irattach /dev/ircomm0 -s &
> [2] 1456
> root@driver_s320:~# 00:02:08.167760 (37538.46 ms) xid:cmd f41be1cd >
> ffffffff S=6 s=0 (14)
> ff 3f 01 cd e1 1b f4 ff ff ff ff 01 00 00
> 00:02:08.261248 (0093.49 ms) xid:cmd f41be1cd > ffffffff S=6 s=1 (14)
> ff 3f 01 cd e1 1b f4 ff ff ff ff 01 01 00
> 00:02:08.361205 (0099.96 ms) xid:cmd f41be1cd > ffffffff S=6 s=2 (14)
> ff 3f 01 cd e1 1b f4 ff ff ff ff 01 02 00
> 00:02:08.362522 (0001.32 ms) xid:rsp f41be1cd < 0c4619da S=6 s=2 Linux
> hint=4400 [ Computer LAN Access ] (21)
> fe bf 01 da 19 46 0c cd e1 1b f4 01 02 00 44 00
> 4c 69 6e 75 78
> 00:02:08.461210 (0098.69 ms) xid:cmd f41be1cd > ffffffff S=6 s=3 (14)
> ff 3f 01 cd e1 1b f4 ff ff ff ff 01 03 00
> 00:02:08.561216 (0100.01 ms) xid:cmd f41be1cd > ffffffff S=6 s=4 (14)
> ff 3f 01 cd e1 1b f4 ff ff ff ff 01 04 00
> 00:02:08.661216 (0100.00 ms) xid:cmd f41be1cd > ffffffff S=6 s=5 (14)
> ff 3f 01 cd e1 1b f4 ff ff ff ff 01 05 00
> 00:02:08.761269 (0100.05 ms) xid:cmd f41be1cd > ffffffff S=6 s=* Linux
> hint=c404 [ Computer LAN Access IrCOMM ] (22)
> ff 3f 01 cd e1 1b f4 ff ff ff ff 01 ff 00 c4 04
> 00 4c 69 6e 75 78
> 00:02:12.351472 (3590.20 ms) xid:cmd f168e953 > ffffffff S=6 s=0 (14)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 00 00
> 00:02:12.351818 (0000.35 ms) xid:cmd f41be1cd > ffffffff S=6 s=0 (14)
> ff 3f 01 cd e1 1b f4 ff ff ff ff 01 00 00
> 00:02:12.451344 (0099.53 ms) xid:cmd f41be1cd > ffffffff S=6 s=1 (14)
> ff 3f 01 cd e1 1b f4 ff ff ff ff 01 01 00
> 00:02:12.551376 (0100.03 ms) xid:cmd f41be1cd > ffffffff S=6 s=2 (14)
> ff 3f 01 cd e1 1b f4 ff ff ff ff 01 02 00
> 00:02:12.651354 (0099.98 ms) xid:cmd f41be1cd > ffffffff S=6 s=3 (14)
> ff 3f 01 cd e1 1b f4 ff ff ff ff 01 03 00
> 00:02:12.751354 (0100.00 ms) xid:cmd f41be1cd > ffffffff S=6 s=4 (14)
> ff 3f 01 cd e1 1b f4 ff ff ff ff 01 04 00
> 00:02:12.752730 (0001.38 ms) xid:rsp f41be1cd < 0c4619da S=6 s=4 Linux
> hint=4400 [ Computer LAN Access ] (21)
> fe bf 01 da 19 46 0c cd e1 1b f4 01 04 00 44 00
> 4c 69 6e 75 78
> =============
> 3. cat /proc/net/irda/discovery shows the output
> root@driver_s320:~# cat /proc/net/irda/discovery
> IrLMP: Discovery log:
>
> nickname: Linux, hint: 0x4400, saddr: 0xf41be1cd, daddr: 0x0c4619da
>
> 4. I run irattach /dev/ircomm0 -s on board 2 also
> 5. As a result, board 1 receives SNRM command. It sends the UA
> response. However, it receives "sirdev_write_complete - schedule speed
> change failed: -11" error multiple times.
> =======================
> 00:04:27.510549 (2114.77 ms) snrm:cmd ca=fe pf=1 f41be1cd < 0c4619da
> new-ca=f4
> LAP QoS: Baud Rate=9600bps Max Turn Time=500ms Data Size=2048B
> Window Size=7 Add BOFS=0 Min Turn Time=10000us Link Disc=12s (32)
> ff 93 da 19 46 0c cd e1 1b f4 f4 01 01 02 82 01
> 01 83 01 3f 84 01 7f 85 01 ff 86 01 01 08 01 07
> 00:04:27.512138 (0001.59 ms) ua:rsp ca=f4 pf=1 f41be1cd > 0c4619da
> LAP QoS: Baud Rate=9600bps Max Turn Time=500ms Data Size=2048B
> Window Size=7 Add BOFS=0 Min Turn Time=10000us Link Disc=12s (31)
> f4 73 cd e1 1b f4 da 19 46 0c 01 01 02 82 01 01
> 83 01 3f 84 01 7f 85 01 ff 86 01 01 08 01 07
> 00:04:27.613760 (0101.62 ms) rr:cmd < ca=f4 pf=1 nr=0 (2)
> f5 11
> 00:04:27.613952 (0000.19 ms) rr:rsp > ca=f4 pf=1
> nrsirdev_write_complete - schedule speed change failed: -11
> =0 (2)
> f4 11 sirdev_write_complete - schedule speed change failed: -11
>
> 00:04:27.61460sirdev_write_complete - schedule speed change failed: -11
> 2 (0000.65 ms) isirdev_write_complete - schedule speed change failed: -11
> :cmd < ca=f4 pfsirdev_write_complete - schedule speed change failed: -11
> =1 nr=0 ns=0 LM sirdev_write_complete - schedule speed change failed: -11
> slsap=12 dlsap=0sirdev_write_complete - schedule speed change failed: -11
> sirdev_write_complete - schedule speed change failed: -11
>
> f5 10 80 12 01sirdev_write_complete - schedule speed change
> failed: -11
> 00
> 00:04:27.615866 (0001.26 ms) i:rsp > ca=f4 pf=1 nr=1 ns=0 LM slsap=00
> dlsap=12 CONN_RSP (6)
> f4 30 92 00 81 00
> =======================
> 6. Board 2 receives following error messages.
> sirdev_receive - too early: c79e5026 / 30!
>
> 7. Few more messages are exchanged
> =======================
> 00:04:27.615866 (0001.26 ms) i:rsp > ca=f4 pf=1 nr=1 ns=0 LM slsap=00
> dlsap=12 CONN_RSP (6)
> f4 30 92 00 81 00
> 00:04:27.617376 (0001.51 ms) i:cmd < ca=f4 pf=1 nr=1 ns=1 LM slsap=12
> dlsap=00 GET_VALUE_BY_CLASS: "IrDA:IrCOMM" "Parameters" (28)
> f5 32 00 12 84 0b 49 72 44 41 3a 49 72 43 4f 4d
> 4d 0a 50 61 72 61 6d 65 74 65 72 73
> 00:04:27.617978 (0000.60 ms) i:rsp > ca=f4 pf=1 nr=2 ns=1 LM slsap=00
> dlsap=12 GET_VALUE_BY_CLASS: Success
> IrCOMM Parameters Service Type=NINE_WIRE THREE_WIRE Port Type=N/A
> (19)
> f4 52 12 00 84 00 00 01 23 43 02 00 06 00 01 06
> 01 01 00
> 00:04:27.620832 (0002.85 ms) i:cmd < ca=f4 pf=0 nr=2 ns=2 LM slsap=12
> dlsap=00 DISC (6)
> f5 44 80 12 02 01
> 00:04:27.621237 (0000.41 ms) i:cmd < ca=f4 pf=1 nr=2 ns=3 LM slsap=13
> dlsap=00 CONN_CMD (6)
> f5 56 80 13 01 00
> 00:04:27.622725 (0001.49 ms) i:rsp > ca=f4 pf=1 nr=4 ns=2 LM slsap=00
> dlsap=13 CONN_RSP (6)
> f4 94 93 00 81 00
> 00:04:27.624464 (0001.74 ms) i:cmd < ca=f4 pf=1 nr=3 ns=4 LM slsap=13
> dlsap=00 GET_VALUE_BY_CLASS: "IrDA:IrCOMM" "IrDA:TinyTP:LsapSel" (37)
> f5 78 00 13 84 0b 49 72 44 41 3a 49 72 43 4f 4d
> 4d 13 49 72 44 41 3a 54 69 6e 79 54 50 3a 4c 73
> 00:04:27.625088 (0000.62 ms) i:rsp > ca=f4 pf=1 nr=5 ns=3 LM slsap=00
> dlsap=13 GET_VALUE_BY_CLASS: Success Integer: 11 (15)
> f4 b6 13 00 84 00 00 01 23 43 01 00 00 00 11
> 00:04:27.627525 (0002.44 ms) i:cmd < ca=f4 pf=0 nr=4 ns=5 LM slsap=13
> dlsap=00 DISC (6)
> f5 8a 80 13 02 01
> 00:04:27.628016 (0000.49 ms) i:cmd < ca=f4 pf=1 nr=4 ns=6 LM slsap=11
> dlsap=11 CONN_CMD TTP credits=16 (7)
> f5 9c 91 11 01 00 10
> 00:04:27.629957 (0001.94 ms) i:rsp > ca=f4 pf=1 nr=7 ns=4 LM slsap=11
> dlsap=11 CONN_RSP TTP credits=16 (7)
> f4 f8 91 11 81 00 10
> 00:04:27.633168 (0003.21 ms) i:cmd < ca=f4 pf=1 nr=5 ns=7 LM slsap=11
> dlsap=11 TTP credits=0
> IrCOMM Service Type=NINE_WIRE Data Rate=9600 Data Format=13 Flow
> Control=00 DTEline State=0c (24)
> f5 be 11 11 00 12 00 01 04 10 04 00 00 25 80 11
> 01 13 12 01 00 20 01 0c
> 00:04:27.634586 (0001.42 ms) rr:rsp > ca=f4 pf=1 nr=0 (2)
> f4 11
> 00:04:27.642005 (0007.42 ms) xid:cmd f168e953 > ffffffff S=6 s=1 (14)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 01 00
> 00:04:27.648576 (0006.57 ms) xid:cmd f168e953 > ffffffff S=6 s=2 (14)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 02 00
> 00:04:27.655098 (0006.52 ms) xid:cmd f168e953 > ffffffff S=6 s=3 (14)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 03 00
> 00:04:27.661669 (0006.57 ms) xid:cmd f168e953 > ffffffff S=6 s=4 (14)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 04 00
> 00:04:27.668240 (0006.57 ms) xid:cmd f168e953 > ffffffff S=6 s=5 (14)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 05 00
> 00:04:27.674762 (0006.52 ms) xid:cmd f168e953 > ffffffff S=6 s=*
> driver_s320 hint=c404 [ Computer LAN Access IrCOMM ] (28)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 ff 00 c4 04
> 00 64 72 69 76 65 72 5f 73 33 32 30
> 00:04:27.681333 (0006.57 ms) xid:cmd f168e953 > ffffffff S=6 s=0 (14)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 00 00
> 00:04:27.687904 (0006.57 ms) xid:cmd f168e953 > ffffffff S=6 s=1 (14)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 01 00
> 00:04:27.806010 (0118.11 ms) xid:cmd f168e953 > ffffffff S=6 s=0 (14)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 00 00
> 00:04:28.133157 (0327.15 ms) rr:cmd < ca=f4 pf=1 nr=5 (2)
> f5 b1
> 00:04:28.133402 (0000.25 ms) i:rsp > ca=f4 pf=0 nr=0 ns=5 LM slsap=11
> dlsap=11 TTP credits=1
> IrCOMM Data Rate=9600 Data Format=13 Flow Control=00 DTEline
> State=0c (21)
> f4 0a 11 11 01 0f 10 04 00 00 25 80 11 01 13 12
> 01 00 20 01 0c
> 00:04:28.134314 (0000.91 ms) i:rsp > ca=f4 pf=0 nr=0 ns=6 LM slsap=11
> dlsap=11 TTP credits=0 IrCOMM (36)
> f4 0c 11 11 00 00 ff ff ff ff ff ff ff ff ff ff
> ff ff c0 ff 3f 01 53 e9 68 f1 ff ff ff ff 01 00
> 00:04:28.135557 (0001.24 ms) i:rsp > ca=f4 pf=0 nr=0 ns=7 LM slsap=11
> dlsap=11 TTP credits=0 IrCOMM (36)
> f4 0e 11 11 00 00 ff ff ff ff ff ff ff ff ff ff
> ff ff c0 ff 3f 01 53 e9 68 f1 ff ff ff ff 01 01
> 00:04:28.136298 (0000.74 ms) xid:cmd f168e953 > ffffffff S=6 s=1 (14)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 01 00
> 00:04:28.136645 (0000.35 ms) i:rsp > ca=f4 pf=0 nr=0 ns=0 LM slsap=11
> dlsap=11 TTP credits=0 IrCOMM (36)
> f4 00 11 11 00 00 ff ff ff ff ff ff ff ff ff ff
> ff ff c0 ff 3f 01 53 e9 68 f1 ff ff ff ff 01 02
> 00:04:28.136912 (0000.27 ms) xid:cmd f168e953 > ffffffff S=6 s=2 (14)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 02 00
> 00:04:28.137413 (0000.50 ms) xid:cmd f168e953 > ffffffff S=6 s=3 (14)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 03 00
> 00:04:28.137738 (0000.32 ms) i:rsp > ca=f4 pf=0 nr=0 ns=1 LM slsap=11
> dlsap=11 TTP credits=0 IrCOMM (36)
> f4 02 11 11 00 00 ff ff ff ff ff ff ff ff ff ff
> ff ff c0 ff 3f 01 53 e9 68 f1 ff ff ff ff 01 03
> 00:04:28.138832 (0001.09 ms) i:rsp > ca=f4 pf=0 nr=0 ns=2 LM slsap=11
> dlsap=11 TTP credits=0 IrCOMM (36)
> f4 04 11 11 00 00 ff ff ff ff ff ff ff ff ff ff
> ff ff c0 ff 3f 01 53 e9 68 f1 ff ff ff ff 01 04
> 00:04:28.139898 (0001.07 ms) i:rsp > ca=f4 pf=1 nr=0 ns=3 LM slsap=11
> dlsap=11 TTP credits=0 IrCOMM (36)
> f4 16 11 11 00 00 ff ff ff ff ff ff ff ff ff ff
> ff ff c0 ff 3f 01 53 e9 68 f1 ff ff ff ff 01 05
> 00:04:28.141216 (0001.32 ms) rr:cmd < ca=f4 pf=1 nr=7 (2)
> f5 f1
> 00:04:28.141370 (0000.15 ms) i:rsp > ca=f4 pf=0 nr=0 ns=7 LM slsap=11
> dlsap=11 TTP credits=0 IrCOMM (36)
> f4 0e 11 11 00 00 ff ff ff ff ff ff ff ff ff ff
> ff ff c0 ff 3f 01 53 e9 68 f1 ff ff ff ff 01 01
> 00:04:28.142453 (0001.08 ms) i:rsp > ca=f4 pf=0 nr=0 ns=0 LM slsap=11
> dlsap=11 TTP credits=0 IrCOMM (36)
> f4 00 11 11 00 00 ff ff ff ff ff ff ff ff ff ff
> ff ff c0 ff 3f 01 53 e9 68 f1 ff ff ff ff 01 02
> 00:04:28.143541 (0001.09 ms) i:rsp > ca=f4 pf=0 nr=0 ns=1 LM slsap=11
> dlsap=11 TTP credits=0 IrCOMM (36)
> f4 02 11 11 00 00 ff ff ff ff ff ff ff ff ff ff
> ff ff c0 ff 3f 01 53 e9 68 f1 ff ff ff ff 01 03
> 00:04:28.144629 (0001.09 ms) i:rsp > ca=f4 pf=0 nr=0 ns=2 LM slsap=11
> dlsap=11 TTP credits=0 IrCOMM (36)
> f4 04 11 11 00 00 ff ff ff ff ff ff ff ff ff ff
> ff ff c0 ff 3f 01 53 e9 68 f1 ff ff ff ff 01 04
> 00:04:28.145765 (0001.14 ms) i:rsp > ca=f4 pf=1 nr=0 ns=3 LM slsap=11
> dlsap=11 TTP credits=0 IrCOMM (36)
> f4 16 11 11 00 00 ff ff ff ff ff ff ff ff ff ff
> ff ff c0 ff 3f 01 53 e9 68 f1 ff ff ff ff 01 05
> 00:04:28.147157 (0001.39 ms) rr:cmd < ca=f4 pf=1 nr=0 (2)
> f5 11
> 00:04:28.147322 (0000.17 ms) i:rsp > ca=f4 pf=0 nr=0 ns=0 LM slsap=11
> dlsap=11 TTP credits=0 IrCOMM (36)
> f4 00 11 11 00 00 ff ff ff ff ff ff ff ff ff ff
> ff ff c0 ff 3f 01 53 e9 68 f1 ff ff ff ff 01 02
> 00:04:28.148405 (0001.08 ms) i:rsp > ca=f4 pf=0 nr=0 ns=1 LM slsap=11
> dlsap=11 TTP credits=0 IrCOMM (36)
> f4 02 11 11 00 00 ff ff ff ff ff ff ff ff ff ff
> ff ff c0 ff 3f 01 53 e9 68 f1 ff ff ff ff 01 03
> 00:04:28.149498 (0001.09 ms) i:rsp > ca=f4 pf=0 nr=0 ns=2 LM slsap=11
> dlsap=11 TTP credits=0 IrCOMM (36)
> f4 04 11 11 00 00 ff ff ff ff ff ff ff ff ff ff
> ff ff c0 ff 3f 01 53 e9 68 f1 ff ff ff ff 01 04
> 00:04:28.150581 (0001.08 ms) i:rsp > ca=f4 pf=1 nr=0 ns=3 LM slsap=11
> dlsap=11 TTP credits=0 IrCOMM (36)
> f4 16 11 11 00 00 ff ff ff ff ff ff ff ff ff ff
> ff ff c0 ff 3f 01 53 e9 68 f1 ff ff ff ff 01 05
>
> 8. In between the board 1 sends few XID commands with changed HW address.
> 00:04:28.165952 (0015.37 ms) xid:cmd f168e953 > ffffffff S=6 s=4 (14)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 04 00
> 00:04:28.255925 (0089.97 ms) xid:cmd f168e953 > ffffffff S=6 s=5 (14)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 05 00
> 00:04:28.345898 (0089.97 ms) xid:cmd f168e953 > ffffffff S=6 s=*
> driver_s320 hint=c404 [ Computer LAN Access IrCOMM ] (28)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 ff 00 c4 04
> 00 64 72 69 76 65 72 5f 73 33 32 30
> 00:04:30.816069 (2470.17 ms) xid:cmd f168e953 > ffffffff S=6 s=0 (14)
> ff 3f 01 53 e9 68 f1 ff ff ff ff 01 00 00
>
> 9. Then few logs of no activity on the link are received:
> IrLAP, no activity on link!
> IrLAP, no activity on link!
> IrLAP, no activity on link!
> IrLAP, no activity on link!
>
> 10. The board 1 again sends XID commands with *original* HW address.
> Board 2 also sends the XID commands
> 11. XID response is sent by both the boards to each other. Now, the
> hint field is not c404 but 4400. hint becomes c404 when we run
> irattach /dev/ircomm0. Before that it is 4400 (by default)
> ==================
> 00:04:58.208341 (0001.47 ms) xid:rsp f41be1cd < 0c4619da S=6 s=3
> driver_s310 hint=4400 [ Computer LAN Access ] (27)
> fe bf 01 da 19 46 0c cd e1 1b f4 01 03 00 44 00
> 64 72 69 76 65 72 5f 73 33 31 30
> 00:04:58.306869 (0098.53 ms) xid:cmd f41be1cd > ffffffff S=6 s=4 (14)
> ff 3f 01 cd e1 1b f4 ff ff ff ff 01 04 00
> 00:04:58.406874 (0100.00 ms) xid:cmd f41be1cd > ffffffff S=6 s=5 (14)
> ff 3f 01 cd e1 1b f4 ff ff ff ff 01 05 00
> 00:04:58.506880 (0100.01 ms) xid:cmd f41be1cd > ffffffff S=6 s=*
> driver_s320 hint=4400 [ Computer LAN Access ] (27)
> ff 3f 01 cd e1 1b f4 ff ff ff ff 01 ff 00 44 00
> 64 72 69 76 65 72 5f 73 33 32 30
> 00:04:58.744384 (0237.50 ms) xid:cmd ffffffff < 0c4619da S=6 s=0 (14)
> ff 3f 01 da 19 46 0c ff ff ff ff 01 00 00
> 00:04:58.844277 (0099.89 ms) xid:cmd ffffffff < 0c4619da S=6 s=1 (14)
> ff 3f 01 da 19 46 0c ff ff ff ff 01 01 00
> 00:04:58.944277 (0100.00 ms) xid:cmd ffffffff < 0c4619da S=6 s=2 (14)
> ff 3f 01 da 19 46 0c ff ff ff ff 01 02 00
> 00:04:58.944485 (0000.21 ms) xid:rsp f41be1cd > 0c4619da S=6 s=2
> driver_s320 hint=4400 [ Computer LAN Access ] (27)
> fe bf 01 cd e1 1b f4 da 19 46 0c 01 02 00 44 00
> 64 72 69 76 65 72 5f 73 33 32 30
> ==================
> 12. cat /proc/net/irda/discovery shows the following output.
> ==================
> root@driver_s320:~# cat /proc/net/irda/discovery
> IrLMP: Discovery log:
>
> nickname: driver_s310, hint: 0x4400, saddr: 0xf41be1cd, daddr: 0x0c4619da
> ==================
> 13. The above XID CMD/RSP sequence goes on and on.
>
> I shall be very much thankful for any support
>
> ~Amit Virdi
>
> On 4/13/2011 12:10 PM, Amit Virdi wrote:
>> Hi All,
>>
>> For the past few days I've been trying to test a driver that I've
>> written for DICE Fast IrDA controller. As per my requirements, I need
>> to use IrCOMM as the upper layer.
>>
>> I'm using the same kernel image on the both the boards. When I run
>> irattach on either of the boards I can see discovery protocol being
>> initiated and completing successfully (cat /proc/net/irda/discovery
>> giving output with other ends's device's MAC address as the daddr)
>> but I'm struggling to test the driver further.
>>
>> I've observed that the discovery request/response sequence goes on
>> for 5 minutes. After this, the discovery process stops. On the master
>> side, I could see no IrLAP frame being sent/received and also the
>> output of cat /proc/net/irda/discovery is NULL. However, on the slave
>> side, the cat /proc/net/irda/discovery output shows the master side!!
>>
>> If I run irattach on the slave side also, no DISCOVERY message is
>> exchanged and then, the output of slave side also doesn't show anything.
>>
>> Sometimes, I start getting log "IrLAP, no activity on link!" and then
>> ircomm_close() API is called from within the stack.
>>
>> If, I try to run getty on /dev/ircomm0, it does not work!
>>
>> If I try to transfer data using
>> echo "1234567890" > /dev/ircomm0
>> on the master side, and
>> cat /dev/ircomm0
>> on the slave side, I can see SNRM command, UA response, RR command,
>> IrLMP connect/disconnect etc. However, the data transfer actually
>> didn't happen. I cannot see the string "1234567890" on the slave side.
>>
>> Please suggest what I'm missing/doing wrong. I need to transfer data
>> from one device to another to complete the testing. I shall be very
>> much thankful for suggestions/advice.
>>
>> Thanks n Regards
>> Amit Virdi
^ permalink raw reply
* Hight speed data sending from custom IP out of kernel
From: Michal Simek @ 2011-04-19 9:49 UTC (permalink / raw)
To: netdev
Hi,
I would like to create demo for high speed data sending from custom IP through
the ethernet. I think the best description is that there are dmaable memory
mapped registers or just memory which store data I want to send (for example 200MB).
Linux should handle all communication between target(probably server) and host
(client) but data in the packets should go from that custom IP and can't go
through the kernel because of performance issue.
Ethernet core have own DMA which I could use but the question is if there is any
option how to convince the kernel that data will go directly from memory mapped
registers and the kernel/driver/... just setup dma BD for headers and second for
data.
Do you have any experience with any solution with passing data completely out of
kernel?
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
^ permalink raw reply
* Add NAPI support to ll_temac driver
From: Michal Simek @ 2011-04-19 9:35 UTC (permalink / raw)
To: netdev
Hi,
I would like to try to add NAPI support for ll_temac and look if help us to
improve performance on Microblaze system. I would expect that bandwidth should
be increased.
We have the second non mainline driver which use tasklets and it provides better
performance than mainline driver but not so big that's why I think that NAPI
can increase performance.
Can you please point me to any driver which I could use as a template?
Or any developer guide to do so.
Do you know any other option how to improve driver performance on low speed cpu?
I have found that driver spends a lot of time on skb allocation and preallocated
SKBs help a little bit. I have done a test where I increased number of
preallocated BDs(SKBs) for rx to 35000 and disable new BD(SKB) allocation in
rx_irq. 35000 BDs is setup because I need them to successfully finish netperf
test. I have got 25% bandwidth increasing.
It will be also nice to be able to allocate several BDs(SKBs) which could be
faster than allocate them in sequence.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
^ permalink raw reply
* Re: [PATCH net-next-2.6 0/8] sctp: some cleanup and tiny fix for add/del ip
From: Wei Yongjun @ 2011-04-19 8:18 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: David Miller, netdev@vger.kernel.org, lksctp
In-Reply-To: <4DAD438D.8040506@6wind.com>
> Hi Wei Yongjun,
>
> do you plan to send other patches, like "sctp: make sctp over IPv6 work with IPsec.", too?
Yes, I am doing this work now. And will commit those patch after backport
to net-next-2.6 tree and testing.
>
>
> Regards,
> Nicolas
>
> Le 19/04/2011 07:07, Wei Yongjun a écrit :
>> Series of 8 patches against net-next-2.6, include some cleanup
>> and tiny fix for add/del ip, which have been waiting on vlad's
>> lksctp-dev tree for long times.
>>
>> Shan Wei (5):
>> sctp: delete unused macro definition of sctp_chunk_is_control
>> sctp: fix the comment of sctp_sf_violation_paramlen()
>> sctp: use common head of addr parameter to access member in addr-unrelated code
>> sctp: kill abandoned SCTP_CMD_TRANSMIT command
>> sctp: use memdup_user to copy data from userspace
>>
>> Vlad Yasevich (3):
>> sctp: teach CACC algorithm about removed transports
>> sctp: Allow bindx_del to accept 0 port.
>> sctp: Release all routes when processing acks ADD_IP or DEL_IP
>>
>> include/net/sctp/command.h | 1 -
>> include/net/sctp/constants.h | 1 -
>> net/sctp/input.c | 2 +-
>> net/sctp/outqueue.c | 11 ++++++++---
>> net/sctp/sm_make_chunk.c | 18 +++++++-----------
>> net/sctp/sm_sideeffect.c | 6 ------
>> net/sctp/sm_statefuns.c | 5 +++--
>> net/sctp/socket.c | 28 +++++++++++-----------------
>> 8 files changed, 30 insertions(+), 42 deletions(-)
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH net-next-2.6 0/8] sctp: some cleanup and tiny fix for add/del ip
From: Nicolas Dichtel @ 2011-04-19 8:10 UTC (permalink / raw)
To: Wei Yongjun; +Cc: David Miller, netdev@vger.kernel.org, lksctp
In-Reply-To: <4DAD18AB.3040401@cn.fujitsu.com>
Hi Wei Yongjun,
do you plan to send other patches, like "sctp: make sctp over IPv6 work with
IPsec.", too?
Regards,
Nicolas
Le 19/04/2011 07:07, Wei Yongjun a écrit :
> Series of 8 patches against net-next-2.6, include some cleanup
> and tiny fix for add/del ip, which have been waiting on vlad's
> lksctp-dev tree for long times.
>
> Shan Wei (5):
> sctp: delete unused macro definition of sctp_chunk_is_control
> sctp: fix the comment of sctp_sf_violation_paramlen()
> sctp: use common head of addr parameter to access member in addr-unrelated code
> sctp: kill abandoned SCTP_CMD_TRANSMIT command
> sctp: use memdup_user to copy data from userspace
>
> Vlad Yasevich (3):
> sctp: teach CACC algorithm about removed transports
> sctp: Allow bindx_del to accept 0 port.
> sctp: Release all routes when processing acks ADD_IP or DEL_IP
>
> include/net/sctp/command.h | 1 -
> include/net/sctp/constants.h | 1 -
> net/sctp/input.c | 2 +-
> net/sctp/outqueue.c | 11 ++++++++---
> net/sctp/sm_make_chunk.c | 18 +++++++-----------
> net/sctp/sm_sideeffect.c | 6 ------
> net/sctp/sm_statefuns.c | 5 +++--
> net/sctp/socket.c | 28 +++++++++++-----------------
> 8 files changed, 30 insertions(+), 42 deletions(-)
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: linux-next: manual merge of the net tree with the net-current tree
From: David Miller @ 2011-04-19 7:41 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, yanivr, shemminger
In-Reply-To: <20110419131618.a474326a.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 19 Apr 2011 13:16:18 +1000
> Today's linux-next merge of the net tree got a conflict in
> drivers/net/bnx2x/bnx2x_ethtool.c between commit 70dda99c41fc ("bnx2x:
> Fix port identification problem") from the net-current tree and commit
> 32d3613475d8 ("bnx2x: convert to set_phys_id") from the net tree.
>
> I fixed it up (maybe - see below) and can carry the fix as necessary.
Your conflict resolution was pretty much perfect :-)
I've merged net-2.6 into net-next-2.6 to fix this up.
Thanks!
^ permalink raw reply
* Re: [PATCH] net: vxge: convert to hw_features
From: David Miller @ 2011-04-19 6:05 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, jdmason
In-Reply-To: <20110418233121.5D8BB13A66@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Tue, 19 Apr 2011 01:31:21 +0200 (CEST)
> Side effect: ->gro_enable is removed as napi_gro_receive() does the
> fallback itself.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Applied.
^ permalink raw reply
* Re: [PATCH] net: vmxnet3: convert to hw_features
From: David Miller @ 2011-04-19 6:04 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, sbhatewara, pv-drivers
In-Reply-To: <20110418233121.AEC4913A68@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Tue, 19 Apr 2011 01:31:21 +0200 (CEST)
> This also removes private feature flags that were always set to true.
>
> You may want to move vmxnet3_set_features() to vmxnet3_drv.c as a following
> cleanup.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Applied.
^ permalink raw reply
* Re: [PATCH] net: s2io: convert to hw_features
From: David Miller @ 2011-04-19 6:04 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, jdmason
In-Reply-To: <20110418233121.1726C13A64@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Tue, 19 Apr 2011 01:31:20 +0200 (CEST)
> This removes advertising HW_CSUM as driver does not support it.
>
> Note: driver advertises TSO6 but not IPV6_CSUM - bug maybe?
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Yes it's probably a bug. Since, as I understand it, this driver is
in pretty deep maintainence mode the best thing to do is probably
to remove the TSO6 flag.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: qlge: convert to hw_features
From: David Miller @ 2011-04-19 6:04 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, ron.mercer, linux-driver
In-Reply-To: <20110418233121.2FF0113A65@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Tue, 19 Apr 2011 01:31:21 +0200 (CEST)
> Another simple conversion.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Applied.
^ permalink raw reply
* Re: [PATCH v2] net: chelsio: convert to hw_features
From: David Miller @ 2011-04-19 6:04 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev
In-Reply-To: <20110418233120.CCB2313909@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Tue, 19 Apr 2011 01:31:20 +0200 (CEST)
> Also remove flags that were not used or are now redundant to hw_features bits.
> No device had UDP_CSUM_CAPABLE set.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> ---
> v2: fix usage of uninitialized variable in sge_rx()
Applied.
^ permalink raw reply
* Re: [PATCH] net: fix section mismatches
From: David Miller @ 2011-04-19 5:59 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, klassert, perex, samuel, grundler
In-Reply-To: <20110418233120.E4B1F138DD@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Tue, 19 Apr 2011 01:31:20 +0200 (CEST)
> Fix build warnings like the following:
>
> WARNING: drivers/net/built-in.o(.data+0x12434): Section mismatch in reference from the variable madgemc_driver to the variable .init.data:madgemc_adapter_ids
>
> And add some consts to EISA device ID tables along the way.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
I've applied this, thanks!
^ permalink raw reply
* Re: [PATCH net-next 4/5] be2net: pass domain id to be_cmd_link_status_query
From: David Miller @ 2011-04-19 5:56 UTC (permalink / raw)
To: ajit.khaparde; +Cc: netdev
In-Reply-To: <20110418223033.GA9515@akhaparde-VBox>
From: Ajit Khaparde <ajit.khaparde@emulex.com>
Date: Mon, 18 Apr 2011 17:30:33 -0500
>
> Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
That's not all this patch does:
> @@ -293,7 +293,6 @@ struct be_adapter {
> u8 eq_next_idx;
> struct be_drv_stats drv_stats;
>
> - struct vlan_group *vlan_grp;
> u16 vlans_added;
> u16 max_vlans; /* Number of vlans supported */
> u8 vlan_tag[VLAN_N_VID];
...
> @@ -1012,15 +1004,10 @@ static void be_rx_compl_process(struct be_adapter *adapter,
> skb->rxhash = rxcp->rss_hash;
>
>
> - if (unlikely(rxcp->vlanf)) {
> - if (!adapter->vlan_grp || adapter->vlans_added == 0) {
> - kfree_skb(skb);
> - return;
> - }
> - vlan_hwaccel_receive_skb(skb, adapter->vlan_grp, rxcp->vid);
> - } else {
> - netif_receive_skb(skb);
> - }
> + if (unlikely(rxcp->vlanf))
> + __vlan_hwaccel_put_tag(skb, rxcp->vid);
> +
> + netif_receive_skb(skb);
> }
>
> /* Process the RX completion indicated by rxcp when GRO is enabled */
It seems to be also converting the driver over to the new VLAN
interfaces.
Please seperate this part into a seperate patch and resubmit your
patch series.
Thanks.
^ permalink raw reply
* Re: [PATCH v2] net: r8169: convert to hw_features
From: David Miller @ 2011-04-19 5:54 UTC (permalink / raw)
To: romieu; +Cc: dave, netdev, nic_swsd
In-Reply-To: <20110418180857.GB18469@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Mon, 18 Apr 2011 20:08:57 +0200
> [...]
>> I've attached my ancient patch, if it helps.
>
> Thanks, it works way better now (see below). It is ok for me to use
> you s-o-b on it ?
>
> I have given it a try on 8169, 8168b, 8168d, 8102e and the load can
> dramatically fall (more at 1000 Mbps than at 100 Mbps).
>
> David (M.), should it go through net-next or be made ready for net-2.6 ?
>
> Subject: [PATCH] r8169: TSO fixes.
Francois, since TSO is disabled by default I'm applying this to
net-next-2.6, thanks!
Maybe we can progressively start to try and turn these things on
by default now that we know more about the TX descriptor layout
differences.
^ permalink raw reply
* Re: [PATCH] net: myri10ge: convert to hw_features
From: David Miller @ 2011-04-19 5:49 UTC (permalink / raw)
To: mirq-linux; +Cc: jon.mason, netdev, gallatin, brice
In-Reply-To: <20110418110347.GA18324@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Mon, 18 Apr 2011 13:03:47 +0200
> On Sun, Apr 17, 2011 at 11:30:53PM -0700, David Miller wrote:
>> From: Jon Mason <jon.mason@myri.com>
>> Date: Fri, 15 Apr 2011 13:29:22 -0500
>>
>> > On Fri, Apr 15, 2011 at 04:50:50PM +0200, Michał Mirosław wrote:
>> >> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
>> >> ---
>> >> drivers/net/myri10ge/myri10ge.c | 66 +++++++-------------------------------
>> >> 1 files changed, 12 insertions(+), 54 deletions(-)
>> >>
>> >> diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
>> >> index 1446de5..a48eb92 100644
>> >> --- a/drivers/net/myri10ge/myri10ge.c
>> >> +++ b/drivers/net/myri10ge/myri10ge.c
>> >> @@ -205,7 +205,6 @@ struct myri10ge_priv {
>> >> int tx_boundary; /* boundary transmits cannot cross */
>> >> int num_slices;
>> >> int running; /* running? */
>> >> - int csum_flag; /* rx_csums? */
>> > Get rid of MXGEFW_FLAGS_CKSUM in drivers/net/myri10ge/myri10ge_mcp.h,
>> > as this was the only thing using it.
>> ...
>> > ethtool_op_set_tso does not support TSO6. This would remove the
>> > enable/disable of that feature.
>> Michał please fix these issues and resubmit this patch, thanks!
>
> There are no issues. MXGEFW_FLAGS_CKSUM is used elsewhere in the driver
> and TSO6 is handled by masking netdev->hw_features at devinit time.
>
> BTW, ethtool_op_set_tso() is not used at all in new offload changing scheme.
Ok, applied, thanks!
^ permalink raw reply
* Re: [PATCH] acenic: Fix using the specified speed when configuring NIC
From: David Miller @ 2011-04-19 5:46 UTC (permalink / raw)
To: decot; +Cc: jes, linux-acenic, netdev, linux-kernel
In-Reply-To: <1303001827-4283-1-git-send-email-decot@google.com>
From: David Decotigny <decot@google.com>
Date: Sat, 16 Apr 2011 17:57:07 -0700
> This patch needs review, as I did not test it: I only think something
> is weird by looking at the code, but experts must confirm.
>
> This tells the NIC to take the speed specified by ethtool into account
> when configuring the NIC, instead of keeping the previous speed.
>
> Signed-off-by: David Decotigny <decot@google.com>
Looks correct, but seems to be dependent upon some other patches which
have feedback pending which you need to address.
Please resubmit that when the other series ends up being applied after
you've fixed it up.
^ permalink raw reply
* Re: [PATCH net-next-2.6 0/8] sctp: some cleanup and tiny fix for add/del ip
From: Shan Wei @ 2011-04-19 5:31 UTC (permalink / raw)
To: Wei Yongjun; +Cc: David Miller, netdev@vger.kernel.org, lksctp
In-Reply-To: <4DAD18AB.3040401@cn.fujitsu.com>
Wei Yongjun wrote, at 04/19/2011 01:07 PM:
> Series of 8 patches against net-next-2.6, include some cleanup
> and tiny fix for add/del ip, which have been waiting on vlad's
> lksctp-dev tree for long times.
Thanks for your job, and expect others.
>
> Shan Wei (5):
> sctp: delete unused macro definition of sctp_chunk_is_control
> sctp: fix the comment of sctp_sf_violation_paramlen()
> sctp: use common head of addr parameter to access member in addr-unrelated code
> sctp: kill abandoned SCTP_CMD_TRANSMIT command
> sctp: use memdup_user to copy data from userspace
>
> Vlad Yasevich (3):
> sctp: teach CACC algorithm about removed transports
> sctp: Allow bindx_del to accept 0 port.
> sctp: Release all routes when processing acks ADD_IP or DEL_IP
>
> include/net/sctp/command.h | 1 -
> include/net/sctp/constants.h | 1 -
> net/sctp/input.c | 2 +-
> net/sctp/outqueue.c | 11 ++++++++---
> net/sctp/sm_make_chunk.c | 18 +++++++-----------
> net/sctp/sm_sideeffect.c | 6 ------
> net/sctp/sm_statefuns.c | 5 +++--
> net/sctp/socket.c | 28 +++++++++++-----------------
> 8 files changed, 30 insertions(+), 42 deletions(-)
>
--
Best Regards
-----
Shan Wei
^ permalink raw reply
* [PATCH net-next-2.6 1/8 v2] sctp: delete unused macro definition of sctp_chunk_is_control
From: Wei Yongjun @ 2011-04-19 5:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, lksctp
In-Reply-To: <4DAD1915.70503@cn.fujitsu.com>
From: Shan Wei <shanwei@cn.fujitsu.com>
The macro never be used.
And if needed, can use !sctp_chunk_is_data instead of.
Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
---
Sorry for missing 'From ...' in the first version
---
include/net/sctp/constants.h | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/include/net/sctp/constants.h b/include/net/sctp/constants.h
index c70d8cc..deac13d 100644
--- a/include/net/sctp/constants.h
+++ b/include/net/sctp/constants.h
@@ -150,7 +150,6 @@ SCTP_SUBTYPE_CONSTRUCTOR(OTHER, sctp_event_other_t, other)
SCTP_SUBTYPE_CONSTRUCTOR(PRIMITIVE, sctp_event_primitive_t, primitive)
-#define sctp_chunk_is_control(a) (a->chunk_hdr->type != SCTP_CID_DATA)
#define sctp_chunk_is_data(a) (a->chunk_hdr->type == SCTP_CID_DATA)
/* Calculate the actual data size in a data chunk */
--
1.6.5.2
^ permalink raw reply related
* [PATCH net-next-2.6 8/8] sctp: Release all routes when processing acks ADD_IP or DEL_IP
From: Wei Yongjun @ 2011-04-19 5:15 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, lksctp
In-Reply-To: <4DAD18AB.3040401@cn.fujitsu.com>
From: Vlad Yasevich <vladislav.yasevich@hp.com>
When processing an ACK for ADD_IP parameter, we only release
the routes on non-active transports. This can cause a wrong
source address to be used. We can release the routes and
cause new route lookups and source address selection so that
new addresses can be used as source. Additionally, we don't need
to lookup routes for all transports at the same time. We can let
the transmit code path update the cached route when the transport
actually sends something.
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
---
net/sctp/sm_make_chunk.c | 8 ++------
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index 844adfd..f87ccb1 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -3193,11 +3193,8 @@ static void sctp_asconf_param_success(struct sctp_association *asoc,
local_bh_enable();
list_for_each_entry(transport, &asoc->peer.transport_addr_list,
transports) {
- if (transport->state == SCTP_ACTIVE)
- continue;
dst_release(transport->dst);
- sctp_transport_route(transport, NULL,
- sctp_sk(asoc->base.sk));
+ transport->dst = NULL;
}
break;
case SCTP_PARAM_DEL_IP:
@@ -3207,8 +3204,7 @@ static void sctp_asconf_param_success(struct sctp_association *asoc,
list_for_each_entry(transport, &asoc->peer.transport_addr_list,
transports) {
dst_release(transport->dst);
- sctp_transport_route(transport, NULL,
- sctp_sk(asoc->base.sk));
+ transport->dst = NULL;
}
break;
default:
--
1.6.5.2
^ permalink raw reply related
* [PATCH net-next-2.6 7/8] sctp: Allow bindx_del to accept 0 port
From: Wei Yongjun @ 2011-04-19 5:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, lksctp
In-Reply-To: <4DAD18AB.3040401@cn.fujitsu.com>
From: Vlad Yasevich <vladislav.yasevich@hp.com>
We allow 0 port when adding new addresses. It only
makes sence to allow 0 port when removing addresses.
When removing the currently bound port will be used
when the port in the address is set to 0.
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
---
net/sctp/socket.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 5c9980a..431b890 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -658,11 +658,15 @@ static int sctp_bindx_rem(struct sock *sk, struct sockaddr *addrs, int addrcnt)
goto err_bindx_rem;
}
- if (sa_addr->v4.sin_port != htons(bp->port)) {
+ if (sa_addr->v4.sin_port &&
+ sa_addr->v4.sin_port != htons(bp->port)) {
retval = -EINVAL;
goto err_bindx_rem;
}
+ if (!sa_addr->v4.sin_port)
+ sa_addr->v4.sin_port = htons(bp->port);
+
/* FIXME - There is probably a need to check if sk->sk_saddr and
* sk->sk_rcv_addr are currently set to one of the addresses to
* be removed. This is something which needs to be looked into
--
1.6.5.2
^ permalink raw reply related
* [PATCH net-next-2.6 6/8] sctp: teach CACC algorithm about removed transports
From: Wei Yongjun @ 2011-04-19 5:13 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, lksctp
In-Reply-To: <4DAD18AB.3040401@cn.fujitsu.com>
From: Vlad Yasevich <vladislav.yasevich@hp.com>
When we have have to remove a transport due to ASCONF, we move
the data to a new active path. This can trigger CACC algorithm
to not mark that data as missing when SACKs arrive. This is
because the transport passed to the CACC algorithm is the one
this data is sitting on, not the one it was sent on (that one
may be gone). So, by sending the original transport (even if
it's NULL), we may start marking data as missing.
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
---
net/sctp/outqueue.c | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
index bf92a5b..7812772 100644
--- a/net/sctp/outqueue.c
+++ b/net/sctp/outqueue.c
@@ -131,7 +131,8 @@ static inline int sctp_cacc_skip_3_1_d(struct sctp_transport *primary,
static inline int sctp_cacc_skip_3_1_f(struct sctp_transport *transport,
int count_of_newacks)
{
- if (count_of_newacks < 2 && !transport->cacc.cacc_saw_newack)
+ if (count_of_newacks < 2 &&
+ (transport && !transport->cacc.cacc_saw_newack))
return 1;
return 0;
}
@@ -618,9 +619,12 @@ redo:
/* If we are retransmitting, we should only
* send a single packet.
+ * Otherwise, try appending this chunk again.
*/
if (rtx_timeout || fast_rtx)
done = 1;
+ else
+ goto redo;
/* Bundle next chunk in the next round. */
break;
@@ -1683,8 +1687,9 @@ static void sctp_mark_missing(struct sctp_outq *q,
/* SFR-CACC may require us to skip marking
* this chunk as missing.
*/
- if (!transport || !sctp_cacc_skip(primary, transport,
- count_of_newacks, tsn)) {
+ if (!transport || !sctp_cacc_skip(primary,
+ chunk->transport,
+ count_of_newacks, tsn)) {
chunk->tsn_missing_report++;
SCTP_DEBUG_PRINTK(
--
1.6.5.2
^ permalink raw reply related
* [PATCH net-next-2.6 5/8] sctp: use memdup_user to copy data from userspace
From: Wei Yongjun @ 2011-04-19 5:13 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, lksctp
In-Reply-To: <4DAD18AB.3040401@cn.fujitsu.com>
From: Shan Wei <shanwei@cn.fujitsu.com>
Use common function to simply code.
Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
---
net/sctp/socket.c | 22 ++++++----------------
1 files changed, 6 insertions(+), 16 deletions(-)
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index deb82e3..5c9980a 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -3215,14 +3215,9 @@ static int sctp_setsockopt_hmac_ident(struct sock *sk,
if (optlen < sizeof(struct sctp_hmacalgo))
return -EINVAL;
- hmacs = kmalloc(optlen, GFP_KERNEL);
- if (!hmacs)
- return -ENOMEM;
-
- if (copy_from_user(hmacs, optval, optlen)) {
- err = -EFAULT;
- goto out;
- }
+ hmacs= memdup_user(optval, optlen);
+ if (IS_ERR(hmacs))
+ return PTR_ERR(hmacs);
idents = hmacs->shmac_num_idents;
if (idents == 0 || idents > SCTP_AUTH_NUM_HMACS ||
@@ -3257,14 +3252,9 @@ static int sctp_setsockopt_auth_key(struct sock *sk,
if (optlen <= sizeof(struct sctp_authkey))
return -EINVAL;
- authkey = kmalloc(optlen, GFP_KERNEL);
- if (!authkey)
- return -ENOMEM;
-
- if (copy_from_user(authkey, optval, optlen)) {
- ret = -EFAULT;
- goto out;
- }
+ authkey= memdup_user(optval, optlen);
+ if (IS_ERR(authkey))
+ return PTR_ERR(authkey);
if (authkey->sca_keylength > optlen - sizeof(struct sctp_authkey)) {
ret = -EINVAL;
--
1.6.5.2
^ permalink raw reply related
* [PATCH net-next-2.6 4/8] sctp: kill abandoned SCTP_CMD_TRANSMIT command
From: Wei Yongjun @ 2011-04-19 5:12 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, lksctp
In-Reply-To: <4DAD18AB.3040401@cn.fujitsu.com>
From: Shan Wei <shanwei@cn.fujitsu.com>
Remove SCTP_CMD_TRANSMIT command as it never be used.
Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
---
include/net/sctp/command.h | 1 -
net/sctp/sm_sideeffect.c | 6 ------
2 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/include/net/sctp/command.h b/include/net/sctp/command.h
index c01dc99..2b44764 100644
--- a/include/net/sctp/command.h
+++ b/include/net/sctp/command.h
@@ -73,7 +73,6 @@ typedef enum {
SCTP_CMD_INIT_FAILED, /* High level, do init failure work. */
SCTP_CMD_REPORT_DUP, /* Report a duplicate TSN. */
SCTP_CMD_STRIKE, /* Mark a strike against a transport. */
- SCTP_CMD_TRANSMIT, /* Transmit the outqueue. */
SCTP_CMD_HB_TIMERS_START, /* Start the heartbeat timers. */
SCTP_CMD_HB_TIMER_UPDATE, /* Update a heartbeat timers. */
SCTP_CMD_HB_TIMERS_STOP, /* Stop the heartbeat timers. */
diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
index 5f86ee4..3b80fe2 100644
--- a/net/sctp/sm_sideeffect.c
+++ b/net/sctp/sm_sideeffect.c
@@ -1415,12 +1415,6 @@ static int sctp_cmd_interpreter(sctp_event_t event_type,
SCTP_RTXR_T3_RTX);
break;
- case SCTP_CMD_TRANSMIT:
- /* Kick start transmission. */
- error = sctp_outq_uncork(&asoc->outqueue);
- local_cork = 0;
- break;
-
case SCTP_CMD_ECN_CE:
/* Do delayed CE processing. */
sctp_do_ecn_ce_work(asoc, cmd->obj.u32);
--
1.6.5.2
^ permalink raw reply related
* [PATCH net-next-2.6 2/8] sctp: fix the comment of sctp_sf_violation_paramlen()
From: Wei Yongjun @ 2011-04-19 5:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, lksctp
In-Reply-To: <4DAD18AB.3040401@cn.fujitsu.com>
From: Shan Wei <shanwei@cn.fujitsu.com>
Update the comment about sctp_sf_violation_paramlen() to be
more precise.
Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
---
net/sctp/sm_statefuns.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
index 7679208..c085472 100644
--- a/net/sctp/sm_statefuns.c
+++ b/net/sctp/sm_statefuns.c
@@ -4343,8 +4343,9 @@ static sctp_disposition_t sctp_sf_violation_chunklen(
/*
* Handle a protocol violation when the parameter length is invalid.
- * "Invalid" length is identified as smaller than the minimal length a
- * given parameter can be.
+ * If the length is smaller than the minimum length of a given parameter,
+ * or accumulated length in multi parameters exceeds the end of the chunk,
+ * the length is considered as invalid.
*/
static sctp_disposition_t sctp_sf_violation_paramlen(
const struct sctp_endpoint *ep,
--
1.6.5.2
^ permalink raw reply related
* [PATCH net-next-2.6 3/8] sctp: use common head of addr parameter to access member in addr-unrelated code
From: Wei Yongjun @ 2011-04-19 5:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, lksctp
In-Reply-To: <4DAD18AB.3040401@cn.fujitsu.com>
From: Shan Wei <shanwei@cn.fujitsu.com>
The 'p' member of struct sctp_paramhdr is common part for
IPv4 addr parameter and IPv6 addr parameter in union sctp_addr_param.
For addr-related code, use specified addr parameter.
Otherwise, use common header to access type/length member.
Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
---
net/sctp/input.c | 2 +-
net/sctp/sm_make_chunk.c | 10 +++++-----
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/sctp/input.c b/net/sctp/input.c
index 5436c69..30cec77 100644
--- a/net/sctp/input.c
+++ b/net/sctp/input.c
@@ -1017,7 +1017,7 @@ static struct sctp_association *__sctp_rcv_asconf_lookup(
/* Skip over the ADDIP header and find the Address parameter */
param = (union sctp_addr_param *)(asconf + 1);
- af = sctp_get_af_specific(param_type2af(param->v4.param_hdr.type));
+ af = sctp_get_af_specific(param_type2af(param->p.type));
if (unlikely(!af))
return NULL;
diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index b3434cc..844adfd 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -2923,7 +2923,7 @@ static __be16 sctp_process_asconf_param(struct sctp_association *asoc,
asconf_param->param_hdr.type != SCTP_PARAM_SET_PRIMARY)
return SCTP_ERROR_UNKNOWN_PARAM;
- switch (addr_param->v4.param_hdr.type) {
+ switch (addr_param->p.type) {
case SCTP_PARAM_IPV6_ADDRESS:
if (!asoc->peer.ipv6_address)
return SCTP_ERROR_DNS_FAILED;
@@ -2936,7 +2936,7 @@ static __be16 sctp_process_asconf_param(struct sctp_association *asoc,
return SCTP_ERROR_DNS_FAILED;
}
- af = sctp_get_af_specific(param_type2af(addr_param->v4.param_hdr.type));
+ af = sctp_get_af_specific(param_type2af(addr_param->p.type));
if (unlikely(!af))
return SCTP_ERROR_DNS_FAILED;
@@ -3100,7 +3100,7 @@ struct sctp_chunk *sctp_process_asconf(struct sctp_association *asoc,
/* Skip the address parameter and store a pointer to the first
* asconf parameter.
*/
- length = ntohs(addr_param->v4.param_hdr.length);
+ length = ntohs(addr_param->p.length);
asconf_param = (sctp_addip_param_t *)((void *)addr_param + length);
chunk_len -= length;
@@ -3177,7 +3177,7 @@ static void sctp_asconf_param_success(struct sctp_association *asoc,
((void *)asconf_param + sizeof(sctp_addip_param_t));
/* We have checked the packet before, so we do not check again. */
- af = sctp_get_af_specific(param_type2af(addr_param->v4.param_hdr.type));
+ af = sctp_get_af_specific(param_type2af(addr_param->p.type));
af->from_addr_param(&addr, addr_param, htons(bp->port), 0);
switch (asconf_param->param_hdr.type) {
@@ -3304,7 +3304,7 @@ int sctp_process_asconf_ack(struct sctp_association *asoc,
/* Skip the address parameter in the last asconf sent and store a
* pointer to the first asconf parameter.
*/
- length = ntohs(addr_param->v4.param_hdr.length);
+ length = ntohs(addr_param->p.length);
asconf_param = (sctp_addip_param_t *)((void *)addr_param + length);
asconf_len -= length;
--
1.6.5.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox