* Re: [PATCH net-next 0/7] qlcnic: Refactoring and enhancements for all adapters.
From: Zoltan Kiss @ 2014-01-27 22:04 UTC (permalink / raw)
To: David Miller, himanshu.madhani; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <20140123.161437.1632835743136251770.davem@davemloft.net>
On 24/01/14 00:14, David Miller wrote:
> From: Himanshu Madhani <himanshu.madhani@qlogic.com>
> Date: Thu, 23 Jan 2014 17:18:27 -0500
>
>> This patch series contains following patches.
>>
>> o Enhanced debug data collection when we are in Tx-timeout situation.
>> o Enhanced MSI-x vector calculation for defualt load path as well
>> as for TSS/RSS ring change path.
>> o Refactored interrupt coalescing code for all adapters.
>> o Refactored interrupt handling as well as cleanup of poll controller
>> code patch for all adapters.
>> o changed rx_mac_learn type to boolean.
>>
>> Please apply to net-next.
>
> Series applied, thanks.
Not that I reject fame, but the commit message contains my name as
sign-off, while I've never seen a bit of that code :)
Zoli
^ permalink raw reply
* Re: [BUG] null pointer dereference in tcp_gso_segment()
From: Arnaud Ebalard @ 2014-01-27 22:14 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Eric Dumazet, Daniel Borkmann, Herbert Xu,
Willy Tarreau, netdev
In-Reply-To: <1390699105.27806.63.camel@edumazet-glaptop2.roam.corp.google.com>
Hi Eric,
Eric Dumazet <eric.dumazet@gmail.com> writes:
> On Sun, 2014-01-26 at 00:54 +0100, Arnaud Ebalard wrote:
>
>> Thanks for the explanation and sorry for the delay, I only just found
>> the time to take a look at the code. For the discussion, a simplified
>> version of tcp_gso_segment() is:
>>
>>
>> th = tcp_hdr(skb);
>> thlen = th->doff * 4;
>>
>> ...
>>
>> __skb_pull(skb, thlen);
>>
>> ...
>>
>> mss = tcp_skb_mss(skb);
>> if (unlikely(skb->len <= mss))
>> goto out;
>>
>> ...
>>
>> segs = skb_segment(skb, features);
>> skb = segs;
>>
>> ...
>>
>> skb = skb->next;
>> th = tcp_hdr(skb); <- bug occurs here
>>
>>
>> So the logic seems to be that if we pass the mss test (i.e. skb->len >
>> mss), then skb_segment() *should* indeed create at least two segments
>> from the skb. I took a look at skb_segment() but the code is !trivial,
>> i.e. it is not obvious that there is no way for the function to deliver
>> a sk_buff skb w/ a NULL skb->next. Eric, I guess you or Herbert are
>> familiar enough w/ the code to tell. But before checking that, your lead
>> below is interesting ...
>>
>> > Since TCP stack seemed to be the provider of the packet in your stack
>> > trace, check tcp_set_skb_tso_segs()
>>
>> It is indeed called in tcp_write_xmit() which appears in the
>> backtrace. That function you point has an interesting property:
>>
>> static void tcp_set_skb_tso_segs(const struct sock *sk, struct sk_buff *skb,
>> unsigned int mss_now)
>> {
>> /* Make sure we own this skb before messing gso_size/gso_segs */
>> WARN_ON_ONCE(skb_cloned(skb));
>>
>> if (skb->len <= mss_now || skb->ip_summed == CHECKSUM_NONE) {
>> /* Avoid the costly divide in the normal
>> * non-TSO case.
>> */
>> skb_shinfo(skb)->gso_segs = 1;
>> skb_shinfo(skb)->gso_size = 0;
>> skb_shinfo(skb)->gso_type = 0;
>> } else {
>> skb_shinfo(skb)->gso_segs = DIV_ROUND_UP(skb->len, mss_now);
>> skb_shinfo(skb)->gso_size = mss_now;
>> skb_shinfo(skb)->gso_type = sk->sk_gso_type;
>> }
>> }
>>
>> If it is called with skb->len <= mss, the resulting skb will be modified
>> so that you will then have skb_shinfo(skb)->gso_size set to 0,
>> i.e. skb->len > skb_shinfo(skb)->gso_size.
>>
>
> The key part is that gso_size is set to 0.
>
> Meaning its not a gso packet :
>
> static inline bool skb_is_gso(const struct sk_buff *skb)
> {
> return skb_shinfo(skb)->gso_size;
> }
>
> So the packet cannot possibly go up to tcp_gso_segment() because
> we fail the first test in :
>
> static inline bool netif_needs_gso(struct sk_buff *skb,
> netdev_features_t features)
> {
> return skb_is_gso(skb) && (!skb_gso_ok(skb, features) ||
> unlikely((skb->ip_summed != CHECKSUM_PARTIAL) &&
> (skb->ip_summed != CHECKSUM_UNNECESSARY)));
> }
Considering that, I decided to spend some time tonight on the other
possibility i.e. something happening in skb_segment() resulting in
skb->next being NULL. I monitored how the skb look like before entering
skb_segment(), how it looks after the end of the loop and also how many
round of the loop below do happen:
segs = skb_segment(skb, features);
if (IS_ERR(segs))
goto out;
/* Only first segment might have ooo_okay set */
segs->ooo_okay = ooo_okay;
delta = htonl(oldlen + (thlen + mss));
skb = segs;
th = tcp_hdr(skb);
seq = ntohl(th->seq);
newcheck = ~csum_fold((__force __wsum)((__force u32)th->check +
(__force u32)delta));
do {
th->fin = th->psh = 0;
th->check = newcheck;
if (skb->ip_summed != CHECKSUM_PARTIAL)
th->check =
csum_fold(csum_partial(skb_transport_header(skb),
thlen, skb->csum));
seq += mss;
if (copy_destructor) {
skb->destructor = gso_skb->destructor;
skb->sk = gso_skb->sk;
sum_truesize += skb->truesize;
}
skb = skb->next;
th = tcp_hdr(skb);
th->seq = htonl(seq);
th->cwr = 0;
} while (skb->next);
Usually, if we initially have tcp_skb_pcount(skb) == X, then we end up
doing X-1 rounds in the loop (i.e. skb is a list of X chained
sk_buff). But I managed to reproduce the two following situations in a
row in a same download session just before a crash):
before skb_segment(), tcp_skb_pcount(skb) is 17 but we only do 7 rounds
in the loop, i.e. the result is a list of 8 sk_buff.
before skb_segment(), tcp_skb_pcount(skb) is 14 but we only do 1 round
in the loop, i.e. the result is a list of 2 sk_buff.
Eric, if you still accept two potentially stupid questions:
- is skb_segment() behavior expected (e.g. frag or frag_list related)?
- if the above can happen, what prevents having skb_segment() deliver a
sk_buff w/ skb->next set to NULL?
The full trace of the crash is provided below. Note that the function
dev_queue_xmit_nit() in the trace is the first one called in
dev_hard_start_xmit() after the call to tcp_gso_segment(), i.e. it is
provided with the packet just processed by skb_segment().
[ 144.482460] tcp_skb_pcount 17, rounds 7, mss 1448, pre_len 24648 post_len 24616
[ 144.491462] tcp_skb_pcount 14, rounds 1, mss 1448, pre_len 20304 post_len 20272
[ 144.501836] Unable to handle kernel paging request at virtual address efe8f259
[ 144.509079] pgd = def84000
[ 144.511790] [efe8f259] *pgd=00000000
[ 144.515384] Internal error: Oops: 15 [#1] ARM
[ 144.519747] Modules linked in:
[ 144.522819] CPU: 0 PID: 3521 Comm: nginx Not tainted 3.13.0.rn102-00594-ga0fa1dd3cdbc-dirty #73
[ 144.531531] task: dd436700 ti: dfa5a000 task.ti: dfa5a000
[ 144.536947] PC is at kmem_cache_alloc+0x3c/0xe8
[ 144.541487] LR is at skb_clone+0x58/0xcc
[ 144.545417] pc : [<c0087ed8>] lr : [<c044829c>] psr: a00f0113
[ 144.545417] sp : dfa5ba40 ip : 0b50a8c0 fp : c05a2474
[ 144.556913] r10: dfa84540 r9 : 00000004 r8 : 00e2879e
[ 144.562146] r7 : c044829c r6 : 00000020 r5 : efe8f259 r4 : df801e00
[ 144.568683] r3 : 00000000 r2 : 00000000 r1 : 00000020 r0 : df801e00
[ 144.575221] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 144.582368] Control: 10c5387d Table: 1ef84019 DAC: 00000015
[ 144.588122] Process nginx (pid: 3521, stack limit = 0xdfa5a238)
[ 144.594051] Stack: (0xdfa5ba40 to 0xdfa5c000)
[ 144.598419] ba40: dfa84540 00000020 c0774620 df1ff800 00000000 c044829c ded01c00 ded01f0c
[ 144.606612] ba60: 00000000 c0451c94 df38a074 df1ff800 c05a2474 c0454ff0 00000004 ded01f20
[ 144.614806] ba80: c0774618 c0774620 dfa84540 c077c368 dfb7e530 df38a074 df1ff800 c0455364
[ 144.622999] baa0: 00000001 c0471e64 c0494634 df1ff800 00000000 00000000 00000000 ded57700
[ 144.631193] bac0: df1ff800 dfb7e530 df1ff800 df38a074 00000010 c046bd18 ded57700 00000000
[ 144.639386] bae0: 00000042 00000000 df38a074 df1ff800 dfb7e530 c04557dc ded57760 0002018a
[ 144.647579] bb00: 00000000 dd44cb40 dd44cbbc 0000000e 00000000 dfb7e530 df1ff800 df0a6e00
[ 144.655773] bb20: 00000010 c0494828 80000000 0b50a8c0 00000000 dfb7e530 cf781400 00000000
[ 144.663966] bb40: cf781604 df0a6e00 00000000 009c0000 00000000 c0494c50 dfb7e530 c0494d80
[ 144.672160] bb60: dfb7e480 cf781400 dfb7e480 00000020 00000000 ffffc33b 00000020 cf781400
[ 144.680353] bb80: dfb7e530 c077c368 00000000 df0a6e00 00000000 c04a990c efe8f259 134d4ee2
[ 144.688546] bba0: df801780 00000000 00000002 00000000 00000000 ffffc33b 001995f3 00000000
[ 144.696740] bbc0: cf781400 cf781400 dfb7e480 000005a8 df1bc480 00004988 00000000 2c79279e
[ 144.704933] bbe0: 00000000 c04a9f8c 00000000 00000000 0000000d 0000000c 0000000c 00000018
[ 144.713127] bc00: cf781400 cf7814bc 00000002 d08210e4 d08210d0 c04a3f20 dfa84540 cf781400
[ 144.721320] bc20: d08210e4 dfa84540 cf781400 d08210d0 dfa84540 000033b8 c0774618 c04aa8fc
[ 144.729514] bc40: 00000020 cf781400 cf781400 c04a6988 00000000 00000014 00000001 00000002
[ 144.737707] bc60: dfa84540 cf781400 df0a6480 cf781400 d08210d0 dfa84540 000033b8 c04ae840
[ 144.745901] bc80: c048fc40 c0471e64 c048fc40 c0471e64 dec1b300 c0774b64 dfa84540 dfa84540
[ 144.754095] bca0: c07a7e70 00000000 cf781400 c04b1004 df1ff800 c0471ee4 00000000 dfa5bcd4
[ 144.762288] bcc0: c048fc40 80000000 c048f958 c0774b64 00000010 c0774b64 3050a8c0 c05accb4
[ 144.770482] bce0: c0777470 00000000 c07a7e70 dfa84540 dfa84540 00000000 c0774618 c048fcd4
[ 144.778675] bd00: d08210d0 c07779e8 c0774628 df1ff800 dfa84540 c048fa80 ded01c00 c0774614
[ 144.786869] bd20: c0774614 c07779e8 c0774628 df1ff800 00000008 c045123c 00000003 00000000
[ 144.795062] bd40: e1448080 42000000 df1ff800 dfa84540 00000001 c0774628 00000000 dfa84540
[ 144.803256] bd60: 00000003 df3bd400 e1448080 42000000 df1ff800 dfa84540 00000001 c0453760
[ 144.811449] bd80: 00000004 c00194b0 e1448000 c03841c0 df5aca80 00020040 dedfa248 dee89c00
[ 144.819642] bda0: 00000001 df1ffbe0 00000001 0000004e 00000000 00000000 00001000 00000040
[ 144.827836] bdc0: df1ffbe0 00000100 00000000 00000100 df3bd400 c079f71c 00000000 c03842dc
[ 144.836029] bde0: c0dbe240 c00ad218 00020040 df1ff800 00000100 df1ffbfc 000038d0 00000000
[ 144.844223] be00: dfa5be48 c00ad2b8 00000000 dfa5be48 dfb4c600 c0384238 df1ffbfc 00000040
[ 144.852416] be20: 0000012c c07afbc0 c07afbc8 c077c368 c07afbc0 c04534ac 00000000 ffffc33d
[ 144.860610] be40: dfb4c600 00000001 0000000c c07b0950 c07b0940 dfa5a000 00000003 00000100
[ 144.868803] be60: 0000000c c001ec54 52e6c1c4 1ee3afbb de8a4760 0000000a ffffc33c 00404140
[ 144.876997] be80: 000003ff c078ef20 00000018 00000000 000003ff c07fb040 c0774048 0000ffff
[ 144.885190] bea0: 00000000 c001ef98 c078ef20 c000eac4 c008bf04 c07fb040 dfa5bee8 c00084dc
[ 144.893384] bec0: c008bee8 c008bf04 400f0013 ffffffff dfa5bf1c 00000000 dd423780 dfa5bf88
[ 144.901577] bee0: 00000000 c0011140 df5acaa0 00000002 dd423788 00000000 df5acaa0 00000002
[ 144.909771] bf00: dd423000 00032e80 00000000 dd423780 dfa5bf88 00000000 dd423788 dfa5bf30
[ 144.917965] bf20: c008bee8 c008bf04 400f0013 ffffffff 00000000 00000000 df5acaa0 de8a4760
[ 144.926158] bf40: dd423788 00000000 0066d8d0 00000000 00000000 00000000 00000000 00000000
[ 144.934351] bf60: 00000000 bed61258 dfa5a000 0000000a dfa5a000 00000000 00000000 c008cca8
[ 144.942545] bf80: ffffffff 000007ff 0063aa50 00000000 bed61258 00000000 00a29cf0 000000ef
[ 144.950738] bfa0: c000e384 c000e200 bed61258 00000000 00000008 0000000a bed61258 3f9c55b0
[ 144.958932] bfc0: bed61258 00000000 00a29cf0 000000ef 7fffefff 00000000 3f9c55b0 00000000
[ 144.967125] bfe0: 0008b3b0 bed611cc 000251a3 b6b5298c 000f0010 00000008 00000000 00000000
[ 144.975325] [<c0087ed8>] (kmem_cache_alloc+0x3c/0xe8) from [<c044829c>] (skb_clone+0x58/0xcc)
[ 144.983875] [<c044829c>] (skb_clone+0x58/0xcc) from [<c0451c94>] (dev_queue_xmit_nit+0x114/0x214)
[ 144.992768] [<c0451c94>] (dev_queue_xmit_nit+0x114/0x214) from [<c0455364>] (dev_hard_start_xmit+0x1c8/0x484)
[ 145.002711] [<c0455364>] (dev_hard_start_xmit+0x1c8/0x484) from [<c046bd18>] (sch_direct_xmit+0xa4/0x19c)
[ 145.012298] [<c046bd18>] (sch_direct_xmit+0xa4/0x19c) from [<c04557dc>] (__dev_queue_xmit+0x1bc/0x3dc)
[ 145.021629] [<c04557dc>] (__dev_queue_xmit+0x1bc/0x3dc) from [<c0494828>] (ip_finish_output+0x1f4/0x440)
[ 145.031129] [<c0494828>] (ip_finish_output+0x1f4/0x440) from [<c0494c50>] (ip_local_out+0x28/0x2c)
[ 145.040107] [<c0494c50>] (ip_local_out+0x28/0x2c) from [<c0494d80>] (ip_queue_xmit+0x12c/0x384)
[ 145.048828] [<c0494d80>] (ip_queue_xmit+0x12c/0x384) from [<c04a990c>] (tcp_transmit_skb+0x42c/0x86c)
[ 145.058067] [<c04a990c>] (tcp_transmit_skb+0x42c/0x86c) from [<c04a9f8c>] (tcp_write_xmit+0x174/0xa74)
[ 145.067393] [<c04a9f8c>] (tcp_write_xmit+0x174/0xa74) from [<c04aa8fc>] (__tcp_push_pending_frames+0x30/0x98)
[ 145.077328] [<c04aa8fc>] (__tcp_push_pending_frames+0x30/0x98) from [<c04a6988>] (tcp_rcv_established+0x144/0x5a0)
[ 145.087699] [<c04a6988>] (tcp_rcv_established+0x144/0x5a0) from [<c04ae840>] (tcp_v4_do_rcv+0x104/0x240)
[ 145.097200] [<c04ae840>] (tcp_v4_do_rcv+0x104/0x240) from [<c04b1004>] (tcp_v4_rcv+0x6ec/0x728)
[ 145.105918] [<c04b1004>] (tcp_v4_rcv+0x6ec/0x728) from [<c048fcd4>] (ip_local_deliver_finish+0x94/0x21c)
[ 145.115417] [<c048fcd4>] (ip_local_deliver_finish+0x94/0x21c) from [<c048fa80>] (ip_rcv_finish+0x128/0x2e8)
[ 145.125178] [<c048fa80>] (ip_rcv_finish+0x128/0x2e8) from [<c045123c>] (__netif_receive_skb_core+0x4c4/0x5d0)
[ 145.135115] [<c045123c>] (__netif_receive_skb_core+0x4c4/0x5d0) from [<c0453760>] (napi_gro_receive+0x74/0xa0)
[ 145.145139] [<c0453760>] (napi_gro_receive+0x74/0xa0) from [<c03841c0>] (mvneta_rx+0x420/0x498)
[ 145.153856] [<c03841c0>] (mvneta_rx+0x420/0x498) from [<c03842dc>] (mvneta_poll+0xa4/0x3b8)
[ 145.162225] [<c03842dc>] (mvneta_poll+0xa4/0x3b8) from [<c04534ac>] (net_rx_action+0x98/0x180)
[ 145.170858] [<c04534ac>] (net_rx_action+0x98/0x180) from [<c001ec54>] (__do_softirq+0xc8/0x1f4)
[ 145.179575] [<c001ec54>] (__do_softirq+0xc8/0x1f4) from [<c001ef98>] (irq_exit+0x6c/0xa8)
[ 145.187774] [<c001ef98>] (irq_exit+0x6c/0xa8) from [<c000eac4>] (handle_IRQ+0x34/0x84)
[ 145.195709] [<c000eac4>] (handle_IRQ+0x34/0x84) from [<c00084dc>] (armada_370_xp_handle_irq+0x4c/0xbc)
[ 145.205038] [<c00084dc>] (armada_370_xp_handle_irq+0x4c/0xbc) from [<c0011140>] (__irq_svc+0x40/0x50)
[ 145.214271] Exception stack(0xdfa5bee8 to 0xdfa5bf30)
[ 145.219333] bee0: df5acaa0 00000002 dd423788 00000000 df5acaa0 00000002
[ 145.227526] bf00: dd423000 00032e80 00000000 dd423780 dfa5bf88 00000000 dd423788 dfa5bf30
[ 145.235717] bf20: c008bee8 c008bf04 400f0013 ffffffff
[ 145.240786] [<c0011140>] (__irq_svc+0x40/0x50) from [<c008bf04>] (do_sendfile+0x270/0x314)
[ 145.249070] [<c008bf04>] (do_sendfile+0x270/0x314) from [<c008cca8>] (SyS_sendfile64+0x94/0xd0)
[ 145.257787] [<c008cca8>] (SyS_sendfile64+0x94/0xd0) from [<c000e200>] (ret_fast_syscall+0x0/0x30)
[ 145.266677] Code: e5935000 e3550000 0a00001b e5943014 (e7950003)
[ 145.272781] ---[ end trace 26c398308530643d ]---
[ 145.277405] Kernel panic - not syncing: Fatal exception in interrupt
[ 145.283818] Unable to handle kernel paging request at virtual address 2c78f4b6
[ 145.291050] pgd = def84000
[ 145.293761] [2c78f4b6] *pgd=00000000
[ 145.297351] Internal error: Oops: 15 [#2] ARM
[ 145.301713] Modules linked in:
[ 145.304784] CPU: 0 PID: 3521 Comm: nginx Tainted: G D 3.13.0.rn102-00594-ga0fa1dd3cdbc-dirty #73
[ 145.314452] task: dd436700 ti: dfa5a000 task.ti: dfa5a000
[ 145.319868] PC is at ata_scsi_qc_complete+0x24/0x360
[ 145.324842] LR is at __ata_qc_complete+0x94/0x13c
[ 145.329554] pc : [<c0345c9c>] lr : [<c033fc78>] psr: 400f0193
[ 145.329554] sp : dfa5b6d0 ip : 00000001 fp : 00000001
[ 145.341049] r10: df347910 r9 : 00000001 r8 : 00000001
[ 145.346281] r7 : df390000 r6 : dfa84900 r5 : 00000000 r4 : df3900d0
[ 145.352819] r3 : c0345c78 r2 : 2c78f4b6 r1 : 00000003 r0 : df3900d0
[ 145.359357] Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
[ 145.366590] Control: 10c5387d Table: 1ef84019 DAC: 00000015
[ 145.372344] Process nginx (pid: 3521, stack limit = 0xdfa5a238)
[ 145.378272] Stack: (0xdfa5b6d0 to 0xdfa5c000)
[ 145.382637] b6c0: df347910 c033f9d8 00000000 c066840b
[ 145.390831] b6e0: c066840b df3900d0 df390000 df391440 00000000 00000001 df347910 c033fc78
[ 145.399024] b700: 00000000 00000001 df390000 c033ffd0 00000000 c0349f8c df390000 00000008
[ 145.407217] b720: e08d4100 00000001 df315410 c0352808 c030f660 c07fcd0c 0000000a c03094a8
[ 145.415410] b740: c07b2ef4 c07b2eac 00000048 00000000 df347a90 00000001 df347a90 e08d4000
[ 145.423603] b760: 00000001 00000001 00000001 c0353988 df36fa80 00000069 00000000 00000000
[ 145.431797] b780: 00000069 c07afc83 df347a00 c0042480 c07b29d8 c003f8e8 00000001 df347a00
[ 145.439990] b7a0: 00000069 dfa5bee8 000003ff c07fb040 c0774048 0000ffff 00010000 c004260c
[ 145.448183] b7c0: 00000069 c00443f8 00000069 dfa5bee8 00000069 c0041df8 c078ef20 c000eac0
[ 145.456377] b7e0: 00000010 c07fb040 dfa5b818 c0008540 c0040394 c0558b98 600f0113 ffffffff
[ 145.464570] b800: dfa5b84c 00000000 dfa5a000 c07b04a8 c07b0304 c0011140 0000019b 00000000
[ 145.472763] b820: c07b32cc 00000000 c07b04a8 c07b04a8 dfa5a000 00000000 00000000 dfa5a000
[ 145.480957] b840: c07b04a8 c07b0304 600f0193 dfa5b860 c0040394 c0558b98 600f0113 ffffffff
[ 145.489150] b860: c07b0304 dfa5b88c 0000000b dfa5b8e6 dfa5a000 c077400c c077a5e8 dfa5a000
[ 145.497343] b880: 00000001 c00108b8 c0664a04 00000000 00000500 00000500 dfa5a238 0000000b
[ 145.505537] b8a0: 600f0193 00000000 00000008 bf000000 00000000 65000000 35333935 20303030
[ 145.513730] b8c0: 35353365 30303030 30613020 31303030 35652062 30333439 28203431 35393765
[ 145.521923] b8e0: 33303030 df002029 c05a2474 c2648667 c06b1808 efe8f259 dee99180 00000015
[ 145.530117] b900: dfa5b9f8 dfa5b9f8 00000004 dfa84540 c05a2474 c0558a20 dee99180 c0014518
[ 145.538310] b920: df38b808 00000020 df801e00 00000015 c0004000 00000000 def84000 c0014580
[ 145.546503] b940: 00000005 00000015 c0014518 c077a81c efe8f259 c0008394 df25d800 c044adb4
[ 145.554696] b960: 00000003 dee546b8 00001e72 c07a7e70 00002d82 0000332a dfb7e530 00000000
[ 145.562889] b980: 000005a8 00000042 0000008e 00000000 00000001 dfa84540 000000d0 000005a8
[ 145.571084] b9a0: 00000000 00000042 00000001 ffffffbe dfa84540 00010000 00000000 c04a861c
[ 145.579277] b9c0: 00000000 dfb7e530 00005b27 df38b800 dee1aad0 c04b42a8 dee54654 000061dc
[ 145.587470] b9e0: c0087ed8 a00f0113 ffffffff dfa5ba2c 00e2879e c00110d8 df801e00 00000020
[ 145.595663] ba00: 00000000 00000000 df801e00 efe8f259 00000020 c044829c 00e2879e 00000004
[ 145.603857] ba20: dfa84540 c05a2474 0b50a8c0 dfa5ba40 c044829c c0087ed8 a00f0113 ffffffff
[ 145.612050] ba40: dfa84540 00000020 c0774620 df1ff800 00000000 c044829c ded01c00 ded01f0c
[ 145.620243] ba60: 00000000 c0451c94 df38a074 df1ff800 c05a2474 c0454ff0 00000004 ded01f20
[ 145.628437] ba80: c0774618 c0774620 dfa84540 c077c368 dfb7e530 df38a074 df1ff800 c0455364
[ 145.636630] baa0: 00000001 c0471e64 c0494634 df1ff800 00000000 00000000 00000000 ded57700
[ 145.644823] bac0: df1ff800 dfb7e530 df1ff800 df38a074 00000010 c046bd18 ded57700 00000000
[ 145.653017] bae0: 00000042 00000000 df38a074 df1ff800 dfb7e530 c04557dc ded57760 0002018a
[ 145.661210] bb00: 00000000 dd44cb40 dd44cbbc 0000000e 00000000 dfb7e530 df1ff800 df0a6e00
[ 145.669403] bb20: 00000010 c0494828 80000000 0b50a8c0 00000000 dfb7e530 cf781400 00000000
[ 145.677596] bb40: cf781604 df0a6e00 00000000 009c0000 00000000 c0494c50 dfb7e530 c0494d80
[ 145.685789] bb60: dfb7e480 cf781400 dfb7e480 00000020 00000000 ffffc33b 00000020 cf781400
[ 145.693983] bb80: dfb7e530 c077c368 00000000 df0a6e00 00000000 c04a990c efe8f259 134d4ee2
[ 145.702176] bba0: df801780 00000000 00000002 00000000 00000000 ffffc33b 001995f3 00000000
[ 145.710369] bbc0: cf781400 cf781400 dfb7e480 000005a8 df1bc480 00004988 00000000 2c79279e
[ 145.718562] bbe0: 00000000 c04a9f8c 00000000 00000000 0000000d 0000000c 0000000c 00000018
[ 145.726755] bc00: cf781400 cf7814bc 00000002 d08210e4 d08210d0 c04a3f20 dfa84540 cf781400
[ 145.734949] bc20: d08210e4 dfa84540 cf781400 d08210d0 dfa84540 000033b8 c0774618 c04aa8fc
[ 145.743143] bc40: 00000020 cf781400 cf781400 c04a6988 00000000 00000014 00000001 00000002
[ 145.751336] bc60: dfa84540 cf781400 df0a6480 cf781400 d08210d0 dfa84540 000033b8 c04ae840
[ 145.759530] bc80: c048fc40 c0471e64 c048fc40 c0471e64 dec1b300 c0774b64 dfa84540 dfa84540
[ 145.767724] bca0: c07a7e70 00000000 cf781400 c04b1004 df1ff800 c0471ee4 00000000 dfa5bcd4
[ 145.775918] bcc0: c048fc40 80000000 c048f958 c0774b64 00000010 c0774b64 3050a8c0 c05accb4
[ 145.784111] bce0: c0777470 00000000 c07a7e70 dfa84540 dfa84540 00000000 c0774618 c048fcd4
[ 145.792305] bd00: d08210d0 c07779e8 c0774628 df1ff800 dfa84540 c048fa80 ded01c00 c0774614
[ 145.800498] bd20: c0774614 c07779e8 c0774628 df1ff800 00000008 c045123c 00000003 00000000
[ 145.808691] bd40: e1448080 42000000 df1ff800 dfa84540 00000001 c0774628 00000000 dfa84540
[ 145.816884] bd60: 00000003 df3bd400 e1448080 42000000 df1ff800 dfa84540 00000001 c0453760
[ 145.825078] bd80: 00000004 c00194b0 e1448000 c03841c0 df5aca80 00020040 dedfa248 dee89c00
[ 145.833271] bda0: 00000001 df1ffbe0 00000001 0000004e 00000000 00000000 00001000 00000040
[ 145.841464] bdc0: df1ffbe0 00000100 00000000 00000100 df3bd400 c079f71c 00000000 c03842dc
[ 145.849658] bde0: c0dbe240 c00ad218 00020040 df1ff800 00000100 df1ffbfc 000038d0 00000000
[ 145.857852] be00: dfa5be48 c00ad2b8 00000000 dfa5be48 dfb4c600 c0384238 df1ffbfc 00000040
[ 145.866045] be20: 0000012c c07afbc0 c07afbc8 c077c368 c07afbc0 c04534ac 00000000 ffffc33d
[ 145.874239] be40: dfb4c600 00000001 0000000c c07b0950 c07b0940 dfa5a000 00000003 00000100
[ 145.882432] be60: 0000000c c001ec54 52e6c1c4 1ee3afbb de8a4760 0000000a ffffc33c 00404140
[ 145.890625] be80: 000003ff c078ef20 00000018 00000000 000003ff c07fb040 c0774048 0000ffff
[ 145.898819] bea0: 00000000 c001ef98 c078ef20 c000eac4 c008bf04 c07fb040 dfa5bee8 c00084dc
[ 145.907013] bec0: c008bee8 c008bf04 400f0013 ffffffff dfa5bf1c 00000000 dd423780 dfa5bf88
[ 145.915206] bee0: 00000000 c0011140 df5acaa0 00000002 dd423788 00000000 df5acaa0 00000002
[ 145.923401] bf00: dd423000 00032e80 00000000 dd423780 dfa5bf88 00000000 dd423788 dfa5bf30
[ 145.931594] bf20: c008bee8 c008bf04 400f0013 ffffffff 00000000 00000000 df5acaa0 de8a4760
[ 145.939787] bf40: dd423788 00000000 0066d8d0 00000000 00000000 00000000 00000000 00000000
[ 145.947980] bf60: 00000000 bed61258 dfa5a000 0000000a dfa5a000 00000000 00000000 c008cca8
[ 145.956174] bf80: ffffffff 000007ff 0063aa50 00000000 bed61258 00000000 00a29cf0 000000ef
[ 145.964367] bfa0: c000e384 c000e200 bed61258 00000000 00000008 0000000a bed61258 3f9c55b0
[ 145.972561] bfc0: bed61258 00000000 00a29cf0 000000ef 7fffefff 00000000 3f9c55b0 00000000
[ 145.980754] bfe0: 0008b3b0 bed611cc 000251a3 b6b5298c 000f0010 00000008 00000000 00000000
[ 145.988952] [<c0345c9c>] (ata_scsi_qc_complete+0x24/0x360) from [<c033fc78>] (__ata_qc_complete+0x94/0x13c)
[ 145.998714] [<c033fc78>] (__ata_qc_complete+0x94/0x13c) from [<c033ffd0>] (ata_qc_complete_multiple+0x98/0xd0)
[ 146.008741] [<c033ffd0>] (ata_qc_complete_multiple+0x98/0xd0) from [<c0352808>] (ahci_handle_port_interrupt+0x120/0x5b8)
[ 146.019634] [<c0352808>] (ahci_handle_port_interrupt+0x120/0x5b8) from [<c0353988>] (ahci_interrupt+0x60/0xe0)
[ 146.029663] [<c0353988>] (ahci_interrupt+0x60/0xe0) from [<c0042480>] (handle_irq_event_percpu+0x50/0x1b4)
[ 146.039338] [<c0042480>] (handle_irq_event_percpu+0x50/0x1b4) from [<c004260c>] (handle_irq_event+0x28/0x38)
[ 146.049186] [<c004260c>] (handle_irq_event+0x28/0x38) from [<c00443f8>] (handle_simple_irq+0x60/0x98)
[ 146.058426] [<c00443f8>] (handle_simple_irq+0x60/0x98) from [<c0041df8>] (generic_handle_irq+0x20/0x30)
[ 146.067839] [<c0041df8>] (generic_handle_irq+0x20/0x30) from [<c000eac0>] (handle_IRQ+0x30/0x84)
[ 146.076642] [<c000eac0>] (handle_IRQ+0x30/0x84) from [<c0008540>] (armada_370_xp_handle_irq+0xb0/0xbc)
[ 146.085969] [<c0008540>] (armada_370_xp_handle_irq+0xb0/0xbc) from [<c0011140>] (__irq_svc+0x40/0x50)
[ 146.095203] Exception stack(0xdfa5b818 to 0xdfa5b860)
[ 146.100262] b800: 0000019b 00000000
[ 146.108456] b820: c07b32cc 00000000 c07b04a8 c07b04a8 dfa5a000 00000000 00000000 dfa5a000
[ 146.116649] b840: c07b04a8 c07b0304 600f0193 dfa5b860 c0040394 c0558b98 600f0113 ffffffff
[ 146.124846] [<c0011140>] (__irq_svc+0x40/0x50) from [<c0558b98>] (panic+0x158/0x1c8)
[ 146.132606] [<c0558b98>] (panic+0x158/0x1c8) from [<c00108b8>] (die+0x194/0x350)
[ 146.140019] [<c00108b8>] (die+0x194/0x350) from [<c0558a20>] (__do_kernel_fault.part.10+0x54/0x74)
[ 146.148999] [<c0558a20>] (__do_kernel_fault.part.10+0x54/0x74) from [<c0014518>] (do_translation_fault+0x0/0xa0)
[ 146.159192] [<c0014518>] (do_translation_fault+0x0/0xa0) from [<00000000>] ( (null))
[ 146.167038] Code: e5907000 e5962030 e2955000 13a05001 (e5d23000)
[ 146.173140] ---[ end trace 26c398308530643e ]---
[ 146.177764] Kernel panic - not syncing: Fatal exception in interrupt
Cheers,
a+
^ permalink raw reply
* Re: [PATCH 1/3] net: ethoc: don't advertise gigabit speed on attached PHY
From: Florian Fainelli @ 2014-01-27 22:31 UTC (permalink / raw)
To: Max Filippov
Cc: Ben Hutchings, linux-xtensa@linux-xtensa.org, netdev,
devicetree@vger.kernel.org, LKML, Chris Zankel, Marc Gauthier,
David S. Miller, Grant Likely, Rob Herring
In-Reply-To: <CAMo8BfLx9iVTqW9fQonF=7C=oDG1RpU5iyGUXf_wFnk7TEvShA@mail.gmail.com>
(fixing Rob's email)
2014-01-27 Max Filippov <jcmvbkbc@gmail.com>:
> On Mon, Jan 27, 2014 at 11:36 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>> 2014-01-27 Max Filippov <jcmvbkbc@gmail.com>:
>>> On Mon, Jan 27, 2014 at 2:18 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
>>>> On Mon, 2014-01-27 at 07:59 +0400, Max Filippov wrote:
>>>>> OpenCores 10/100 Mbps MAC does not support speeds above 100 Mbps, but does
>>>>> not disable advertisement when PHY supports them. This results in
>>>>> non-functioning network when the MAC is connected to a gigabit PHY connected
>>>>> to a gigabit switch.
>>>>>
>>>>> The fix is to disable gigabit speed advertisement on attached PHY
>>>>> unconditionally.
>>>>>
>>>>> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
>>>>> ---
>>>>> drivers/net/ethernet/ethoc.c | 2 ++
>>>>> 1 file changed, 2 insertions(+)
>>>>>
>>>>> diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c
>>>>> index 4de8cfd..0aa1a05 100644
>>>>> --- a/drivers/net/ethernet/ethoc.c
>>>>> +++ b/drivers/net/ethernet/ethoc.c
>>>>> @@ -712,6 +712,8 @@ static int ethoc_open(struct net_device *dev)
>>>>> netif_start_queue(dev);
>>>>> }
>>>>>
>>>>> + priv->phy->advertising &= ~(ADVERTISED_1000baseT_Full |
>>>>> + ADVERTISED_1000baseT_Half);
>>>>> phy_start(priv->phy);
>>>>> napi_enable(&priv->napi);
>>>>>
>>>>
>>>> This is not sufficient to disable gigabit speeds; the supported mask
>>>> should also be limited. And it should be done even before the net
>>>
>>> I tried that, but when I also limit supported mask the phy driver doesn't
>>> touch gigabit advertising register int the genphy_config_advert at all.
>>> That's probably right for ethtool interface, but ethoc doesn't support
>>> ethtool.
>>
>> This is not right for libphy either, phydev->supported must reflect
>> that you support Gigabit or not.
>
> I'm sorry, does that mean that I must not touch phydev->supported,
> or that I must update it too and somehow fix genphy_config_advert?
What I meant is that your driver has to set both phydev->advertising
and phydev->supported. genphy_config_advert() is doing
phdev->advertising &= phydev->supported, leaving phydev->supported to
something more restrictive will produce unexpected results. This is
also important if phy_driver::config_aneg() is not using the generic
implementation and directly uses/modifies phydev->advertising and
phydev->supported.
It seems like there is room for improvements in that area regardless
of how we access things. For instance, specifying the PHY interface
mode (MII, GMII etc...) should already provide a hint of what
phydev->supported should look like. You cannot do Gigabit with MII for
instance.
>
>> Since ethoc supports libphy, there really is no reason not to
>> implement the ethtool_{get,set}_settings callbacks using
>> phy_mii_ioctl().
>
> Ok, I'll add that.
>
>>>> device is registered.
>>>>
>>>> Rather than poking into the phy_device structure directly from this
>>>> driver, I think you should add a function in phylib for this purpose.
>>
>> All drivers are currently modifying phydev->advertising and
>> phydev->supported directly, most of them do it correctly as far as I
>> checked. It does make some sense to add a helper function though.
>
> [...]
>
>>> diff --git a/include/linux/phy.h b/include/linux/phy.h
>>> index 48a4dc3..0282a8d 100644
>>> --- a/include/linux/phy.h
>>> +++ b/include/linux/phy.h
>>> @@ -559,6 +559,11 @@ static inline int phy_read_status(struct phy_device *phydev) {
>>> return phydev->drv->read_status(phydev);
>>> }
>>>
>>> +static inline void phy_update_adv(struct phy_device *phydev, u32 mask, u32 set)
>>> +{
>>> + phydev->advertising = (phydev->advertising & mask) | set;
>>> +}
>>> +
>>
>> This should be a preliminary patch to this patchset, so you first
>> introduce the function, then use it in the driver, but the idea looks
>> good. There is room for updating quite some drivers out there since
>> those used to modify phydev->advertising and phydev->supported
>> directly without using an accessor.
>
> What about those that do something like this:
>
> phydev->advertising = phydev->supported;
>
> leave them as is, or provide read accessor for phydev->supported?
Those should be just fine since genphy_config_advert() does
phydev->advertising &= phydev->supported, so the end result will be
identical. You mean a write accessor instead of a read accessor?
--
Florian
^ permalink raw reply
* Re: linux-next: manual merge of the bluetooth tree with the net/net-next trees
From: Stephen Rothwell @ 2014-01-27 22:54 UTC (permalink / raw)
To: Gustavo Padovan, David Miller, netdev
Cc: linux-next, linux-kernel, Daniel Borkmann, Jukka Rissanen
In-Reply-To: <20140107125418.986ae20298ddc55e5e657447@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1638 bytes --]
Hi all,
On Tue, 7 Jan 2014 12:54:18 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the bluetooth tree got a conflict in
> net/ieee802154/6lowpan.c between commit 965801e1eb62 ("net: 6lowpan: fix
> lowpan_header_create non-compression memcpy call") from the tree and
> commit 8df8c56a5abc ("6lowpan: Moving generic compression code into
> 6lowpan_iphc.c") from the bluetooth tree.
>
> I fixed it up (I applied the following patch to move the fix into
> 6lowpan_iphc.c) and can carry the fix as necessary (no action is
> required).
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 7 Jan 2014 12:52:43 +1100
> Subject: [PATCH] net: 6lowpan: fixup for code movement
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> net/ieee802154/6lowpan_iphc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ieee802154/6lowpan_iphc.c b/net/ieee802154/6lowpan_iphc.c
> index 11840f9e46da..e14fe8b2c054 100644
> --- a/net/ieee802154/6lowpan_iphc.c
> +++ b/net/ieee802154/6lowpan_iphc.c
> @@ -677,7 +677,7 @@ int lowpan_header_compress(struct sk_buff *skb, struct net_device *dev,
> hc06_ptr += 3;
> } else {
> /* compress nothing */
> - memcpy(hc06_ptr, &hdr, 4);
> + memcpy(hc06_ptr, hdr, 4);
> /* replace the top byte with new ECN | DSCP format */
> *hc06_ptr = tmp;
> hc06_ptr += 4;
> --
> 1.8.5.2
I think this fix patch got missed when bluetooth was merged ... so it
should probably go into the net tree.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] DT: net: davinci_emac: "ti,davinci-rmii-en" property is actually optional
From: Florian Fainelli @ 2014-01-27 22:57 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: netdev, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Rob Landley, devicetree@vger.kernel.org,
linux-doc@vger.kernel.org, davinci-linux-open-source
In-Reply-To: <201401280247.42415.sergei.shtylyov@cogentembedded.com>
2014-01-27 Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>:
> Though described as required, the "ti,davinci-rmii-en" property for the DaVinci
> EMAC binding seems actually optional, as the driver should happily work without
> it; the property is not specified either in the example device node or in the
> actual EMAC device node for DA850 device tree, only AM3517 one.
>
> While at it, document the property better...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
> Actually I think this property should have been boolean...
>
> Documentation/devicetree/bindings/net/davinci_emac.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: net/Documentation/devicetree/bindings/net/davinci_emac.txt
> ===================================================================
> --- net.orig/Documentation/devicetree/bindings/net/davinci_emac.txt
> +++ net/Documentation/devicetree/bindings/net/davinci_emac.txt
> @@ -10,7 +10,6 @@ Required properties:
> - ti,davinci-ctrl-mod-reg-offset: offset to control module register
> - ti,davinci-ctrl-ram-offset: offset to control module ram
> - ti,davinci-ctrl-ram-size: size of control module ram
> -- ti,davinci-rmii-en: use RMII
> - ti,davinci-no-bd-ram: has the emac controller BD RAM
> - interrupts: interrupt mapping for the davinci emac interrupts sources:
> 4 sources: <Receive Threshold Interrupt
> @@ -22,6 +21,7 @@ Optional properties:
> - phy-handle: Contains a phandle to an Ethernet PHY.
> If absent, davinci_emac driver defaults to 100/FULL.
> - local-mac-address : 6 bytes, mac address
> +- ti,davinci-rmii-en: 1 byte, 1 means use RMII
This just made me look at the actual DT binding documentation and the
driver, but there is support for specifying a PHY device tree node,
but no corresponding 'phy-connection-type' property which would tell
whether the connection is Reduced MII, MII or something else.
'phy-connection-type' would convey much more information about what is
happening, and once know, should also make the driver automatically
configure for Reduced MII or anything else, hence making
"ti,davinc-rmii-en" obsolete.
--
Florian
^ permalink raw reply
* [PATCH net-next] hyperv: Add support for physically discontinuous receive buffer
From: Haiyang Zhang @ 2014-01-27 23:03 UTC (permalink / raw)
To: davem, netdev; +Cc: olaf, jasowang, driverdev-devel, linux-kernel, haiyangz
This will allow us to use bigger receive buffer, and prevent allocation failure
due to fragmented memory.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
---
drivers/hv/channel.c | 14 ++++++++------
drivers/net/hyperv/hyperv_net.h | 2 +-
drivers/net/hyperv/netvsc.c | 7 ++-----
3 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index cea623c..69ea36f 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -209,7 +209,6 @@ static int create_gpadl_header(void *kbuffer, u32 size,
{
int i;
int pagecount;
- unsigned long long pfn;
struct vmbus_channel_gpadl_header *gpadl_header;
struct vmbus_channel_gpadl_body *gpadl_body;
struct vmbus_channel_msginfo *msgheader;
@@ -219,7 +218,6 @@ static int create_gpadl_header(void *kbuffer, u32 size,
int pfnsum, pfncount, pfnleft, pfncurr, pfnsize;
pagecount = size >> PAGE_SHIFT;
- pfn = virt_to_phys(kbuffer) >> PAGE_SHIFT;
/* do we need a gpadl body msg */
pfnsize = MAX_SIZE_CHANNEL_MESSAGE -
@@ -248,7 +246,8 @@ static int create_gpadl_header(void *kbuffer, u32 size,
gpadl_header->range[0].byte_offset = 0;
gpadl_header->range[0].byte_count = size;
for (i = 0; i < pfncount; i++)
- gpadl_header->range[0].pfn_array[i] = pfn+i;
+ gpadl_header->range[0].pfn_array[i] = slow_virt_to_phys(
+ kbuffer + PAGE_SIZE * i) >> PAGE_SHIFT;
*msginfo = msgheader;
*messagecount = 1;
@@ -301,7 +300,9 @@ static int create_gpadl_header(void *kbuffer, u32 size,
* so the hypervisor gurantees that this is ok.
*/
for (i = 0; i < pfncurr; i++)
- gpadl_body->pfn[i] = pfn + pfnsum + i;
+ gpadl_body->pfn[i] = slow_virt_to_phys(
+ kbuffer + PAGE_SIZE * (pfnsum + i)) >>
+ PAGE_SHIFT;
/* add to msg header */
list_add_tail(&msgbody->msglistentry,
@@ -327,7 +328,8 @@ static int create_gpadl_header(void *kbuffer, u32 size,
gpadl_header->range[0].byte_offset = 0;
gpadl_header->range[0].byte_count = size;
for (i = 0; i < pagecount; i++)
- gpadl_header->range[0].pfn_array[i] = pfn+i;
+ gpadl_header->range[0].pfn_array[i] = slow_virt_to_phys(
+ kbuffer + PAGE_SIZE * i) >> PAGE_SHIFT;
*msginfo = msgheader;
*messagecount = 1;
@@ -344,7 +346,7 @@ nomem:
* vmbus_establish_gpadl - Estabish a GPADL for the specified buffer
*
* @channel: a channel
- * @kbuffer: from kmalloc
+ * @kbuffer: from kmalloc or vmalloc
* @size: page-size multiple
* @gpadl_handle: some funky thing
*/
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index a26eecb..7b594ce 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -462,7 +462,7 @@ struct nvsp_message {
#define NETVSC_MTU 65536
-#define NETVSC_RECEIVE_BUFFER_SIZE (1024*1024*2) /* 2MB */
+#define NETVSC_RECEIVE_BUFFER_SIZE (1024*1024*16) /* 16MB */
#define NETVSC_RECEIVE_BUFFER_ID 0xcafe
diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index 93b485b..03a2c6e 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -136,8 +136,7 @@ static int netvsc_destroy_recv_buf(struct netvsc_device *net_device)
if (net_device->recv_buf) {
/* Free up the receive buffer */
- free_pages((unsigned long)net_device->recv_buf,
- get_order(net_device->recv_buf_size));
+ vfree(net_device->recv_buf);
net_device->recv_buf = NULL;
}
@@ -163,9 +162,7 @@ static int netvsc_init_recv_buf(struct hv_device *device)
return -ENODEV;
ndev = net_device->ndev;
- net_device->recv_buf =
- (void *)__get_free_pages(GFP_KERNEL|__GFP_ZERO,
- get_order(net_device->recv_buf_size));
+ net_device->recv_buf = vzalloc(net_device->recv_buf_size);
if (!net_device->recv_buf) {
netdev_err(ndev, "unable to allocate receive "
"buffer of size %d\n", net_device->recv_buf_size);
--
1.7.4.1
^ permalink raw reply related
* Re: Many USB ethernet devices are broken over xhci
From: Sarah Sharp @ 2014-01-27 23:16 UTC (permalink / raw)
To: David Laight; +Cc: netdev@vger.kernel.org, linux-usb@vger.kernel.org
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D46624F@AcuExch.aculab.com>
David, you are overwhelming my capacity to handle patches right now. I
appreciate that you would like to clean up the driver, but the bug fixes
you're sending me are getting lost in the noise of random cleanup
patches.
Can you please limit the xHCI patches you send to bug fixes for now?
Also, can you resend all the patches you consider to be serious bug
fixes in one single patchset?
Thanks,
Sarah Sharp
On Mon, Jan 27, 2014 at 04:06:22PM +0000, David Laight wrote:
> Many of the net/usb ethernet drivers (including common ones like
> the smsc95xx) will fail to transmit all packet length properly
> when connected to a USB3 port (ie using the xhci driver).
>
> The underlying problem is that they assume the host controller
> will honour the URB_ZERO_PACKET flag - which usbnet sets because
> they specify FLAG_SEND_ZLP.
>
> However no one has ever added support for URB_ZERO_PACKET to
> the xhci driver - so packets that need padding (probably 512
> bytes after any header is added) will not be sent correctly
> and may have very adverse effects on the usb target.
>
> The ax179_178a driver avoids this by not setting FLAG_SEND_ZLP,
> modifying the packet header, and appending an extra zero byte.
> (Which has been responsible for its own set of panics.)
>
> I don't think this can be fixed by just clearing (or ignoring)
> FLAG_SEND_ZLP as the extra byte will also confuse things.
>
> It needs to be fixed in the xhci code.
>
> I wrote this patch a while ago - worked for me with the ax179_178a
> driver. http://www.spinics.net/lists/linux-usb/msg97370.html
>
> The patch is a bit difficult to read, the v1 version contained a copy of
> the new function. http://www.spinics.net/lists/linux-usb/msg97183.html
>
> I don't think anything significant has changed (in the main kernel
> sources) since I wrote the patch.
>
> David
>
>
>
>
^ permalink raw reply
* Re: [PATCH net-next 0/7] qlcnic: Refactoring and enhancements for all adapters.
From: David Miller @ 2014-01-27 23:24 UTC (permalink / raw)
To: zoltan.kiss; +Cc: himanshu.madhani, netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <52E6D7E1.90204@citrix.com>
From: Zoltan Kiss <zoltan.kiss@citrix.com>
Date: Mon, 27 Jan 2014 22:04:17 +0000
> On 24/01/14 00:14, David Miller wrote:
>> From: Himanshu Madhani <himanshu.madhani@qlogic.com>
>> Date: Thu, 23 Jan 2014 17:18:27 -0500
>>
>>> This patch series contains following patches.
>>>
>>> o Enhanced debug data collection when we are in Tx-timeout situation.
>>> o Enhanced MSI-x vector calculation for defualt load path as well
>>> as for TSS/RSS ring change path.
>>> o Refactored interrupt coalescing code for all adapters.
>>> o Refactored interrupt handling as well as cleanup of poll controller
>>> code patch for all adapters.
>>> o changed rx_mac_learn type to boolean.
>>>
>>> Please apply to net-next.
>>
>> Series applied, thanks.
>
> Not that I reject fame, but the commit message contains my name as
> sign-off, while I've never seen a bit of that code :)
Sorry about that. What happens is that I build the merge commit
messages from a template, and I used a template for a previous
serious with your signoff by accident :-/
^ permalink raw reply
* Re: Many USB ethernet devices are broken over xhci
From: Greg KH @ 2014-01-27 23:33 UTC (permalink / raw)
To: David Laight
Cc: netdev@vger.kernel.org, linux-usb@vger.kernel.org, Sarah Sharp
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D46624F@AcuExch.aculab.com>
On Mon, Jan 27, 2014 at 04:06:22PM +0000, David Laight wrote:
> Many of the net/usb ethernet drivers (including common ones like
> the smsc95xx) will fail to transmit all packet length properly
> when connected to a USB3 port (ie using the xhci driver).
That's odd, as I've never had a problem with my USB 3.0 ethernet device
(sorry, don't remember what driver it uses), and I stress it all the
time.
I've also run two different USB 2 ethernet devices on xhci with no
issues at all, so perhaps the "many" statement might not be true?
> The underlying problem is that they assume the host controller
> will honour the URB_ZERO_PACKET flag - which usbnet sets because
> they specify FLAG_SEND_ZLP.
>
> However no one has ever added support for URB_ZERO_PACKET to
> the xhci driver - so packets that need padding (probably 512
> bytes after any header is added) will not be sent correctly
> and may have very adverse effects on the usb target.
Really? How has things been working so well up to now without this
support? Doesn't the hardware automatically add this padding with no
explicit need for the xhci driver to do something?
> The ax179_178a driver avoids this by not setting FLAG_SEND_ZLP,
> modifying the packet header, and appending an extra zero byte.
> (Which has been responsible for its own set of panics.)
>
> I don't think this can be fixed by just clearing (or ignoring)
> FLAG_SEND_ZLP as the extra byte will also confuse things.
>
> It needs to be fixed in the xhci code.
>
> I wrote this patch a while ago - worked for me with the ax179_178a
> driver. http://www.spinics.net/lists/linux-usb/msg97370.html
Doing multiple things in a patch is generally considered bad-form, and
this is quite hard to follow.
> The patch is a bit difficult to read, the v1 version contained a copy of
> the new function. http://www.spinics.net/lists/linux-usb/msg97183.html
That's not helpful to the people having to review the v2 patch :)
> I don't think anything significant has changed (in the main kernel
> sources) since I wrote the patch.
Then resubmit it, don't post links to it on the web, there's nothing we
can do with them, sorry.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 3/3] net: via-rhine: add OF bus binding
From: Ben Hutchings @ 2014-01-27 23:40 UTC (permalink / raw)
To: Alexey Charkov
Cc: netdev, Tony Prisk, devicetree, Roger Luethi,
linux-kernel@vger.kernel.org
In-Reply-To: <CABjd4Yz2Kfed_qBfSAEXoAcVxfsmhTBA-83YJ9_iSwPZ+r1qYQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1638 bytes --]
On Mon, 2014-01-27 at 19:34 +0400, Alexey Charkov wrote:
> 2014/1/27 Ben Hutchings <ben@decadent.org.uk>:
> > On Mon, 2014-01-27 at 15:51 +0400, Alexey Charkov wrote:
> >> This should make the driver usable with VIA/WonderMedia ARM-based
> >> Systems-on-Chip integrated Rhine III adapters. Note that these
> >> are always in MMIO mode, and don't have any known EEPROM.
> > [...]
> >> --- a/drivers/net/ethernet/via/Kconfig
> >> +++ b/drivers/net/ethernet/via/Kconfig
> >> @@ -19,7 +19,7 @@ if NET_VENDOR_VIA
> >>
> >> config VIA_RHINE
> >> tristate "VIA Rhine support"
> >> - depends on PCI
> >> + depends on (PCI || USE_OF)
> >> select CRC32
> >> select MII
> >> ---help---
> >
> > This seems like the right thing to do, but it means you need to add
> > #ifdef CONFIG_PCI and #ifdef CONFIG_USE_OF around the driver structures
> > and related functions.
>
> Frankly, I would like to avoid that if possible (as pointed out in the
> cover email), as I believe we would get a cleaner driver without
> #ifdef. This is also the way it was done in via-velocity, and it works
> just fine.
OK, I'm surprised that all the PCI functions have dummy definitions.
> > You should compile-test in configurations that have just one of those
> > dependencies enabled.
>
> This has been compile-tested and runtime-tested in OF-only
> configuration on WM8950, and Roger also tested it in PCI-only
> configuration, so it seems to work fine.
[...]
Good, then I have no objection.
Ben.
--
Ben Hutchings
If at first you don't succeed, you're doing about average.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* [PATCH 0/2] DT: net: davinci_emac: couple more properties actually optional
From: Sergei Shtylyov @ 2014-01-27 23:45 UTC (permalink / raw)
To: netdev, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak,
rob, devicetree
Cc: linux-doc, davinci-linux-open-source
Hello.
Though described as required, couple more properties in the DaVinci EMAC
binding are actually optional, as the driver will happily function without them.
The patchset is against DaveM's 'net.git' tree this time.
[1/2] DT: net: davinci_emac: "ti,davinci-rmii-en" property is actually optional
[2/2] DT: net: davinci_emac: "ti,davinci-no-bd-ram" property is actually optional
WBR, Sergei
^ permalink raw reply
* [PATCH 1/2] DT: net: davinci_emac: "ti,davinci-rmii-en" property is actually optional
From: Sergei Shtylyov @ 2014-01-27 23:47 UTC (permalink / raw)
To: netdev, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak,
rob, devicetree
Cc: linux-doc, davinci-linux-open-source
Though described as required, the "ti,davinci-rmii-en" property for the DaVinci
EMAC binding seems actually optional, as the driver should happily work without
it; the property is not specified either in the example device node or in the
actual EMAC device node for DA850 device tree, only AM3517 one.
While at it, document the property better...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Actually I think this property should have been boolean...
Documentation/devicetree/bindings/net/davinci_emac.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: net/Documentation/devicetree/bindings/net/davinci_emac.txt
===================================================================
--- net.orig/Documentation/devicetree/bindings/net/davinci_emac.txt
+++ net/Documentation/devicetree/bindings/net/davinci_emac.txt
@@ -10,7 +10,6 @@ Required properties:
- ti,davinci-ctrl-mod-reg-offset: offset to control module register
- ti,davinci-ctrl-ram-offset: offset to control module ram
- ti,davinci-ctrl-ram-size: size of control module ram
-- ti,davinci-rmii-en: use RMII
- ti,davinci-no-bd-ram: has the emac controller BD RAM
- interrupts: interrupt mapping for the davinci emac interrupts sources:
4 sources: <Receive Threshold Interrupt
@@ -22,6 +21,7 @@ Optional properties:
- phy-handle: Contains a phandle to an Ethernet PHY.
If absent, davinci_emac driver defaults to 100/FULL.
- local-mac-address : 6 bytes, mac address
+- ti,davinci-rmii-en: 1 byte, 1 means use RMII
Example (enbw_cmc board):
eth0: emac@1e20000 {
^ permalink raw reply
* [PATCH 2/2] DT: net: davinci_emac: "ti,davinci-no-bd-ram" property is actually optional
From: Sergei Shtylyov @ 2014-01-27 23:49 UTC (permalink / raw)
To: netdev, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak,
rob, devicetree
Cc: linux-doc, davinci-linux-open-source
The "ti,davinci-no-bd-ram" property for the DaVinci EMAC binding simply can't be
required one, as it's boolean (which means it's absent if false).
While at it, document the property better...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Documentation/devicetree/bindings/net/davinci_emac.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: net/Documentation/devicetree/bindings/net/davinci_emac.txt
===================================================================
--- net.orig/Documentation/devicetree/bindings/net/davinci_emac.txt
+++ net/Documentation/devicetree/bindings/net/davinci_emac.txt
@@ -10,7 +10,6 @@ Required properties:
- ti,davinci-ctrl-mod-reg-offset: offset to control module register
- ti,davinci-ctrl-ram-offset: offset to control module ram
- ti,davinci-ctrl-ram-size: size of control module ram
-- ti,davinci-no-bd-ram: has the emac controller BD RAM
- interrupts: interrupt mapping for the davinci emac interrupts sources:
4 sources: <Receive Threshold Interrupt
Receive Interrupt
@@ -22,6 +21,7 @@ Optional properties:
If absent, davinci_emac driver defaults to 100/FULL.
- local-mac-address : 6 bytes, mac address
- ti,davinci-rmii-en: 1 byte, 1 means use RMII
+- ti,davinci-no-bd-ram: boolean, does EMAC has BD RAM?
Example (enbw_cmc board):
eth0: emac@1e20000 {
^ permalink raw reply
* Re: [PATCH 2/2] DT: net: davinci_emac: "ti,davinci-no-bd-ram" property is actually optional
From: Sergei Shtylyov @ 2014-01-27 23:59 UTC (permalink / raw)
To: netdev, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak,
rob, devicetree
Cc: linux-doc, davinci-linux-open-source
In-Reply-To: <201401280249.40451.sergei.shtylyov@cogentembedded.com>
Hello.
On 01/28/2014 02:49 AM, Sergei Shtylyov wrote:
> The "ti,davinci-no-bd-ram" property for the DaVinci EMAC binding simply can't be
> required one, as it's boolean (which means it's absent if false).
> While at it, document the property better...
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> ---
> Documentation/devicetree/bindings/net/davinci_emac.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> Index: net/Documentation/devicetree/bindings/net/davinci_emac.txt
> ===================================================================
> --- net.orig/Documentation/devicetree/bindings/net/davinci_emac.txt
> +++ net/Documentation/devicetree/bindings/net/davinci_emac.txt
> @@ -10,7 +10,6 @@ Required properties:
> - ti,davinci-ctrl-mod-reg-offset: offset to control module register
> - ti,davinci-ctrl-ram-offset: offset to control module ram
> - ti,davinci-ctrl-ram-size: size of control module ram
> -- ti,davinci-no-bd-ram: has the emac controller BD RAM
> - interrupts: interrupt mapping for the davinci emac interrupts sources:
> 4 sources: <Receive Threshold Interrupt
> Receive Interrupt
> @@ -22,6 +21,7 @@ Optional properties:
> If absent, davinci_emac driver defaults to 100/FULL.
> - local-mac-address : 6 bytes, mac address
> - ti,davinci-rmii-en: 1 byte, 1 means use RMII
> +- ti,davinci-no-bd-ram: boolean, does EMAC has BD RAM?
Too hasty, s/has/have/. Do I need to resend or this could be fixed when
applying?
WBR, Sergei
^ permalink raw reply
* Re: [BUG PATCH] Memory leak on tcp_prot slab with TPROXY and TCP early demux
From: David Miller @ 2014-01-28 0:23 UTC (permalink / raw)
To: holger; +Cc: netdev, netfilter-devel, fw
In-Reply-To: <20140127093317.GU7176@imap.eitzenberger.org>
From: Holger Eitzenberger <holger@eitzenberger.org>
Date: Mon, 27 Jan 2014 10:33:18 +0100
> Please have a look, there could be smarter ways of fixing that.
Looks good, applied and queued up for -stable.
Thanks!
^ permalink raw reply
* Re: [PATCH 2/2] net: ip, ipv6: handle gso skbs in forwarding path
From: Hannes Frederic Sowa @ 2014-01-28 0:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Florian Westphal, netdev
In-Reply-To: <1390846967.27806.75.camel@edumazet-glaptop2.roam.corp.google.com>
On Mon, Jan 27, 2014 at 10:22:47AM -0800, Eric Dumazet wrote:
> On Mon, 2014-01-27 at 09:22 +0100, Florian Westphal wrote:
>
> > +/* called if GSO skb needs to be fragmented on forward. */
> > +static int ip_forward_finish_gso(struct sk_buff *skb)
> > +{
> > + netdev_features_t features = netif_skb_features(skb);
netif_skb_features uses skb->dev for determination of offloading features but
we actually need rt->dst.dev, no?
> > + struct sk_buff *segs;
> > + int ret = 0;
> > +
> > + segs = skb_gso_segment(skb, features & ~NETIF_F_GSO_MASK);
> > + if (IS_ERR(segs)) {
> > + kfree_skb(skb);
> > + return -ENOMEM;
> > + }
> > +
> > + consume_skb(skb);
> > +
> > + do {
> > + struct sk_buff *nskb = segs->next;
> > + int err;
> > +
> > + segs->next = NULL;
> > + err = dst_output(segs);
> > +
> > + if (err && ret == 0)
> > + ret = err;
> > + segs = nskb;
> > + } while (segs);
> > +
> > + return ret;
> > +}
> > +
>
> Its still unclear if this is the best strategy.
>
> TCP stream not using DF flag are very unlikely to care if we adjust
> their MTU (lowering gso_size) at this point ?
UDP shouldn't be a problem, too.
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH RFC v3 0/12] vti4: prepare namespace and interfamily support.
From: David Miller @ 2014-01-28 0:35 UTC (permalink / raw)
To: steffen.klassert; +Cc: netdev, christophe.gouault, saurabh.mohan
In-Reply-To: <1390818577-19589-1-git-send-email-steffen.klassert@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Mon, 27 Jan 2014 11:29:25 +0100
> This patchset prepares vti4 for proper namespace and interfamily
> support.
No major objections from me, this looks good.
^ permalink raw reply
* Re: [PATCH] sky2: initialize napi before registering device
From: David Miller @ 2014-01-28 0:40 UTC (permalink / raw)
To: stf_xl; +Cc: netdev, mlindner, stephen
In-Reply-To: <20140125103454.GA2490@localhost.localdomain>
From: Stanislaw Gruszka <stf_xl@wp.pl>
Date: Sat, 25 Jan 2014 11:34:54 +0100
> There is race condition when call netif_napi_add() after
> register_netdevice(), as ->open() can be called without napi initialized
> and trigger BUG_ON() on napi_enable(), like on below messages:
...
> To fix the problem patch changes the order of initialization.
>
> Bug report:
> https://bugzilla.kernel.org/show_bug.cgi?id=67151
>
> Reported-and-tested-by: ebrahim.azarisooreh@gmail.com
> Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Applied, thanks a lot.
^ permalink raw reply
* Re: [PATCH net-next] hyperv: Add support for physically discontinuous receive buffer
From: David Miller @ 2014-01-28 0:41 UTC (permalink / raw)
To: haiyangz; +Cc: olaf, netdev, jasowang, driverdev-devel, linux-kernel
In-Reply-To: <1390863822-3509-1-git-send-email-haiyangz@microsoft.com>
From: Haiyang Zhang <haiyangz@microsoft.com>
Date: Mon, 27 Jan 2014 15:03:42 -0800
> This will allow us to use bigger receive buffer, and prevent allocation failure
> due to fragmented memory.
>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
Applied, thanks.
^ permalink raw reply
* Re: linux-next: manual merge of the bluetooth tree with the net/net-next trees
From: David Miller @ 2014-01-28 0:43 UTC (permalink / raw)
To: sfr; +Cc: gustavo, netdev, linux-next, linux-kernel, dborkman,
jukka.rissanen
In-Reply-To: <20140128095415.8382335c33545ad14d4be067@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 28 Jan 2014 09:54:15 +1100
> On Tue, 7 Jan 2014 12:54:18 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
...
>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>> Date: Tue, 7 Jan 2014 12:52:43 +1100
>> Subject: [PATCH] net: 6lowpan: fixup for code movement
>>
>> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
...
> I think this fix patch got missed when bluetooth was merged ... so it
> should probably go into the net tree.
Good catch, applied, thanks Stephen!
^ permalink raw reply
* Re: [PATCH V2 0/4] misc: xgene: Add support for APM X-Gene SoC Queue Manager/Traffic Manager
From: Ravi Patel @ 2014-01-28 0:58 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greg KH, Loc Ho, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Jon Masters, patches-qTEPVZfXA3Y@public.gmane.org, Keyur Chudgar
In-Reply-To: <201401141615.55820.arnd-r2nGTMty4D4@public.gmane.org>
On Tue, Jan 14, 2014 at 7:15 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> Now that I have a better understanding of what the driver is good for and
> how it's used, let's have a look at how we can make it fit into the Linux
> driver APIs and the DT bindings. We don't have anything exactly like this
> yet, but I think the "mailbox" framework is a close enough match that we
> can fit it in there, with some extensions. This framework is still in the
> process of being created (so far there is only a TI OMAP specific driver,
> and one for pl320), and I've not seen any mailboxes that support IRQ
> mitigation or multiple software interfaces per hardware mailbox, but those
> should be easy enough to add.
OK. We will put Queue Manager driver under drivers/mailbox directory along
with TI OMAP and pl320 drivers.
> For the DT binding, I would suggest using something along the lines of
> what we have for clocks, pinctrl and dmaengine. OMAP doesn't use this
> (yet), but now would be a good time to standardize it. The QMTM node
> should define a "#mailbox-cells" property that indicates how many
> 32-bit cells a qmtm needs to describe the connection between the
> controller and the slave. My best guess is that this would be hardcoded
> to <3>, using two cells for a 64-bit FIFO bus address, and a 32-bit cell
> for the slave-id signal number. All other parameters that you have in
> the big table in the qmtm driver at the moment can then get moved into
> the slave drivers, as they are constant per type of slave. This will
> simplify the QMTM driver.
>
> In the slave, you should have a "mailboxes" property with a phandle
> to the qmtm followed by the three cells to identify the actual
> queue. If it's possible that a device uses more than one rx and
> one tx queue, we also need a "mailbox-names" property to identify
> the individual queues.
We explored on DT bindings suggestion given by you. We have come
up with a sample DT binding for how it will look like. Herewith we have
provided the same. Would you please review and give us your
comments before we change our driver and DTS file to accomodate it?
Sample DTS node for QM:
qmlite: qmtm@17030000 {
compatible = "apm,xgene-qmtm-lite";
reg = <0x0 0x17030000 0x0 0x10000>,
<0x0 0x10000000 0x0 0x400000>;
interrupts = <0x0 0x40 0x4>,
<0x0 0x3c 0x4>;
status = "ok";
#clock-cells = <1>;
clocks = <&qmlclk 0>;
#mailbox-cells = <3>;
};
Sample DTS node for Ethernet:
menet: ethernet@17020000 {
compatible = "apm,xgene-enet";
status = "disabled";
reg = <0x0 0x17020000 0x0 0x30>,
<0x0 0x17020000 0x0 0x10000>,
<0x0 0x17020000 0x0 0x20>;
mailboxes = <&qmlite 0x0 0x1000002c 0x0000>,
<&qmlite 0x0 0x10000052 0x0020>,
<&qmlite 0x0 0x10000060 0x0f00>
mailbox-names = "mb-tx", "mb-fp", "mb-rx";
interrupts = <0x0 0x38 0x4>,
<0x0 0x39 0x4>,
<0x0 0x3a 0x4>;
#clock-cells = <1>;
clocks = <ð8clk 0>;
local-mac-address = <0x0 0x11 0x3a 0x8a 0x5a 0x78>;
max-frame-size = <0x233a>;
phyid = <3>;
phy-mode = "rgmii";
};
The mailbox node in DTS has following format:
mailbox = <&parent 'higher 32 bit bus address' 'lower 32 bit bus
address' 'signal id'>
Ethernet driver will call following function in platform_probe:
mailbox_get(dev, "mb-tx");
mailbox_get API will return the the context of allocated and configured mailbox.
For now, mailbox_get API will be implemented in xgene QMTM driver.
Eventually when mailbox framework in Linux will be standardized, we
will use it instead.
> For the in-kernel interfaces, we should probably start a conversation
> with the owners of the mailbox drivers to get a common API, for now
> I'd suggest you just leave it as it is, and only adapt for the new
> binding.
Sure. For now we will put our driver mostly as is in the
drivers/mailbox. Can you please help us identify the owners of the
mailbox drivers? As you suggested, we can start conversation with them
to define common in kernel APIs.
Ravi
On Tue, Jan 14, 2014 at 7:15 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Monday 13 January 2014, Ravi Patel wrote:
>> > Examples for local resource management (I had to think about this
>> > a long time, but probably some of these are wrong) would be
>> > * balancing between multiple non-busmaster devices connected to
>> > a dma-engine
>> > * distributing incoming ethernet data to the available CPUs based on
>> > a flow classifier in the MAC, e.g. by IOV MAC address, VLAN tag
>> > or even individual TCP connection depending on the NIC's capabilities.
>> > * 802.1p flow control for incoming ethernet data based on the amount
>> > of data queued up between the MAC and the driver
>> > * interrupt mitigation for both inbound data and outbound completion,
>> > by delaying the IRQ to the OS until multiple messages have arrived
>> > or a queue specific amount of time has passed.
>> > * controlling the amount of outbound buffer space per flow to minimize
>> > buffer-bloat between an ethernet driver and the NIC hardware.
>> > * reordering data from outbound flows based on priority.
>> >
>> > This is basically my current interpretation, I hope I got at least
>> > some of it right this time ;-)
>>
>> You have got them right. Although we have taken Ethernet examples here,
>> most of the local resource management apply to other slave devices also.
>
> I'm very suprised I got all those right, it seems it's a quite sophisticated
> piece of hardware then. I guess most other slave devices only use a subset
> of the capabilities that ethernet wants.
>
> Now that I have a better understanding of what the driver is good for and
> how it's used, let's have a look at how we can make it fit into the Linux
> driver APIs and the DT bindings. We don't have anything exactly like this
> yet, but I think the "mailbox" framework is a close enough match that we
> can fit it in there, with some extensions. This framework is still in the
> process of being created (so far there is only a TI OMAP specific driver,
> and one for pl320), and I've not seen any mailboxes that support IRQ
> mitigation or multiple software interfaces per hardware mailbox, but those
> should be easy enough to add.
>
> For the DT binding, I would suggest using something along the lines of
> what we have for clocks, pinctrl and dmaengine. OMAP doesn't use this
> (yet), but now would be a good time to standardize it. The QMTM node
> should define a "#mailbox-cells" property that indicates how many
> 32-bit cells a qmtm needs to describe the connection between the
> controller and the slave. My best guess is that this would be hardcoded
> to <3>, using two cells for a 64-bit FIFO bus address, and a 32-bit cell
> for the slave-id signal number. All other parameters that you have in
> the big table in the qmtm driver at the moment can then get moved into
> the slave drivers, as they are constant per type of slave. This will
> simplify the QMTM driver.
>
> In the slave, you should have a "mailboxes" property with a phandle
> to the qmtm followed by the three cells to identify the actual
> queue. If it's possible that a device uses more than one rx and
> one tx queue, we also need a "mailbox-names" property to identify
> the individual queues.
>
> For the in-kernel interfaces, we should probably start a conversation
> with the owners of the mailbox drivers to get a common API, for now
> I'd suggest you just leave it as it is, and only adapt for the new
> binding.
>
> Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Freescale FEC packet loss
From: Marek Vasut @ 2014-01-28 1:01 UTC (permalink / raw)
To: Ben Hutchings
Cc: netdev@vger.kernel.org, Frank Li, fugang.duan,
fabio.estevam@freescale.com, Hector Palacios, linux-arm-kernel,
Detlev Zundel, Eric Nelson, Matthew Garrett
In-Reply-To: <1390772013.2735.47.camel@deadeye.wl.decadent.org.uk>
On Sunday, January 26, 2014 at 10:33:33 PM, Ben Hutchings wrote:
> On Sun, 2014-01-26 at 20:12 +0100, Marek Vasut wrote:
> > On Sunday, January 26, 2014 at 07:56:30 PM, Ben Hutchings wrote:
> > > On Wed, 2014-01-22 at 22:55 +0100, Marek Vasut wrote:
> > > > Hi guys,
> > > >
> > > > I am running stock Linux 3.13 on i.MX6Q SabreLite board. The CPU is
> > > > i.MX6Q TO 1.0 .
> > > >
> > > > I am hitting a WARNING when I use the FEC ethernet to transfer data,
> > > > thus I started investigating this problem. TL;DR I am not able to
> > > > figure this problem out, so I am not attaching a patch :-(
> > > >
> > > > Steps to reproduce:
> > > > -------------------
> > > > 1) Boot stock Linux 3.13 on i.MX6Q SabreLite board
> > > > 2) Plug in an SD card into one of the SD slots (I use the full-size
> > > > one) 3) Plug in an USB stick into one of the USB ports (I use the
> > > > upper one) 4) Plug in an ethernet cable into the board
> > > >
> > > > -> Connect the other side into a gigabit-capable PC
> > >
> > > [...]
> > >
> > > I think there are known problems with 1000BASE-T on the Sabre Lite
> > > board.
> >
> > This is MX6-wide thing, not sabrelite specific actually.
> >
> > > Two possible workarounds are to limit the PHY to 100BASE-TX
> > > (should be doable with ethtool) or force it to be clock master for
> > > 1000BASE-T (requires a driver patch).
> >
> > Can you please elaborate on the later ? I don't quite understand that.
>
> 1000BASE-T uses all 4 pairs in both directions at the same time, which
> requires that both ends transmit symbols synchronously. As part of the
> autonegotiation protocol, they decide which is the clock master (using a
> local clock generator) and which is the clock slave (generating a clock
> from the received signal). A PHY can be configured to support only one
> of these roles.
I checked the patch you pointed me to. The patch basically messes with the
CTL1000 (0x9) register of the PHY, right ? I did the adjustments to the PHY
register manually , but the result is still the same (backtrace).
I did two different kinds of adjustment:
1) reg 0x9 |= 0x1800;
2) reg 0x9 |= 0x1000;
In both cases, the crash did happen. I verified the PHY register was configured
as necessary. The KSZ9021 PHY bit 12 configures the master/slave override, same
as the patch does. The bit 11 forces either master or slave mode for the PHY. In
both cases the crash was there.
I think this patch won't help in this case, sorry.
Best regards,
Marek Vasut
^ permalink raw reply
* Hi
From: a8kef58kbi @ 2014-01-28 1:25 UTC (permalink / raw)
To: a8kef58kbi
Diploma?
http://tiny.cc/2ww2cz4evf
^ permalink raw reply
* Re: [PATCH] AF_PACKET: Add documentation for queue mapping fanout mode
From: Neil Horman @ 2014-01-28 2:15 UTC (permalink / raw)
To: Andi Kleen; +Cc: netdev, David S. Miller, Daniel Borkmann
In-Reply-To: <87d2jdqepa.fsf@tassilo.jf.intel.com>
On Mon, Jan 27, 2014 at 01:48:01PM -0800, Andi Kleen wrote:
> Neil Horman <nhorman@tuxdriver.com> writes:
>
> > Recently I added a new AF_PACKET fanout operation mode in commit
> > 2d36097, but I forgot to document it. Add PACKET_FANOUT_QM as an available mode
> > in the af_packet documentation. Applies to net-next.
>
> Please also send a man page patch.
>
> -Andi
>
I'll take care of it in the am. Thanks for the reminder!
Neil
> --
> ak@linux.intel.com -- Speaking for myself only
>
^ permalink raw reply
* Re: [PATCH RFC 00/73] tree-wide: clean up some no longer required #include <linux/init.h>
From: Benjamin Herrenschmidt @ 2014-01-28 3:13 UTC (permalink / raw)
To: Paul Gortmaker
Cc: Stephen Rothwell, linux-arch, linux-mips, linux-m68k, rusty,
linux-ia64, kvm, linux-s390, netdev, x86, linux-kernel, torvalds,
gregkh, linux-alpha, sparclinux, akpm, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20140123003838.GA10182@windriver.com>
On Wed, 2014-01-22 at 19:38 -0500, Paul Gortmaker wrote:
> Thanks, it was a great help as it uncovered a few issues in fringe arch
> that I didn't have toolchains for, and I've fixed all of those up.
>
> I've noticed that powerpc has been un-buildable for a while now; I have
> used this hack patch locally so I could run the ppc defconfigs to check
> that I didn't break anything. Maybe useful for linux-next in the
> interim? It is a hack patch -- Not-Signed-off-by: Paul Gortmaker. :)
Can you and/or Aneesh submit that as a proper patch (with S-O-B
etc...) ?
Thanks !
Cheers,
Ben.
> Paul.
> --
>
> diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h b/arch/powerpc/include/asm/pgtable-ppc64.h
> index d27960c89a71..d0f070a2b395 100644
> --- a/arch/powerpc/include/asm/pgtable-ppc64.h
> +++ b/arch/powerpc/include/asm/pgtable-ppc64.h
> @@ -560,9 +560,9 @@ extern void pmdp_invalidate(struct vm_area_struct *vma, unsigned long address,
> pmd_t *pmdp);
>
> #define pmd_move_must_withdraw pmd_move_must_withdraw
> -typedef struct spinlock spinlock_t;
> -static inline int pmd_move_must_withdraw(spinlock_t *new_pmd_ptl,
> - spinlock_t *old_pmd_ptl)
> +struct spinlock;
> +static inline int pmd_move_must_withdraw(struct spinlock *new_pmd_ptl,
> + struct spinlock *old_pmd_ptl)
> {
> /*
> * Archs like ppc64 use pgtable to store per pmd
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
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