* Re: NULL pointer dereference at skb_queue_tail()
From: Tetsuo Handa @ 2015-01-09 13:20 UTC (permalink / raw)
To: cwang; +Cc: netdev
In-Reply-To: <CAHA+R7Mq=vhSCqJsE5dn7PGg39R8Nh+m1RT0F-KcoBU99GdpWA@mail.gmail.com>
Cong Wang wrote:
> On Mon, Jan 5, 2015 at 4:50 AM, Tetsuo Handa
> <penguin-kernel@i-love.sakura.ne.jp> wrote:
> > Tetsuo Handa wrote:
> >> I can reproduce below oops when testing Linux 3.18 with memory allocation
> >> failure injection module at https://lkml.org/lkml/2014/12/25/64 .
> >
> > I can reliably reproduce this oops with current linux.git using memory
> > allocation failure injection module. There is a possibility of memory
> > corruption since this oops always occurs immediately after memory
> > allocation failure within GPU/DRM code. I want to check whether
> > fields of structures have expected values or not.
>
> Looks like the skb->prev and/or skb->next in the skb queue is corrupted,
> but I don't see why. We do play some magic on these pointers recently,
> but it should not be related with unix socket at all.
Yes, I saw skb->prev == NULL while skb->next != NULL. And I saw various
different oops shown below depending on timing.
Is there code which set skb->prev or skb->next to NULL after it was
initialized with non-NULL? If there is no such code, this could be
memory corruption.
>
> Is it possible for you to check if this is a regression of recent kernel?
> We only have few changes in unix socket recently, and I don't see they
> could cause this bug.
Would you tell me which versions to test?
I confirmed that this problem exists at least since 3.14.
I haven't hit this problem with 3.12 because I hit different problem
before hitting this problem. So far I didn't hit this problem with 3.10.
[ 244.389630] BUG: unable to handle kernel paging request at 00000000bf38b1f5
[ 244.391428] IP: [<ffffffff81646a51>] unix_detach_fds.isra.25+0x21/0x50
[ 244.393050] PGD 7aabf067 PUD 0
[ 244.393865] Oops: 0000 [#1] SMP
[ 244.394694] Modules linked in: stap_1d434baec036a3abf082a3f3fc53e337_9804(OE) ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_mangle ip6table_raw ip6table_filter ip6_tables iptable_mangle iptable_raw iptable_filter ip_tables coretemp crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel dm_mirror aesni_intel dm_region_hash dm_log glue_helper dm_mod lrw gf128mul ablk_helper cryptd ppdev vmw_balloon parport_pc microcode pcspkr serio_raw vmw_vmci parport shpchp i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc uinput sd_mod ata_generic pata_acpi e1000 ata_piix mptspi libata scsi_transport_spi m
ptscsih mptbase floppy
[ 244.413886] CPU: 2 PID: 9936 Comm: Xorg Tainted: G W OE 3.19.0-rc3+ #9
[ 244.415807] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
[ 244.418438] task: ffff88007a7d3d40 ti: ffff88007ab88000 task.ti: ffff88007ab88000
[ 244.420269] RIP: 0010:[<ffffffff81646a51>] [<ffffffff81646a51>] unix_detach_fds.isra.25+0x21/0x50
[ 244.422517] RSP: 0018:ffff88007ab8bb48 EFLAGS: 00010206
[ 244.423823] RAX: 00000000bf38b1f5 RBX: 0000000000000000 RCX: 0000000000000014
[ 244.425580] RDX: 0000000000000004 RSI: ffff88007b4b4800 RDI: ffff88007ab8bbf8
[ 244.427312] RBP: ffff88007ab8bb58 R08: 0000000000000014 R09: ffff88007ae54000
[ 244.429070] R10: ffff88007ae54000 R11: ffff88007a7d3d40 R12: ffff88007ab8bbf8
[ 244.430816] R13: ffff88007b4b4800 R14: ffff88003a806990 R15: ffff88003a806900
[ 244.432555] FS: 00007fe2e1976980(0000) GS:ffff88007fc80000(0000) knlGS:0000000000000000
[ 244.434477] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 244.435859] CR2: 00000000bf38b1f5 CR3: 000000007aa31000 CR4: 00000000000407e0
[ 244.437626] Stack:
[ 244.438124] 0000000000000000 0000000000000000 ffff88007ab8bc68 ffffffff816486cb
[ 244.439987] dead000000200200 ffff88001db00700 ffff88007a7d3d40 ffff88007ab8bc28
[ 244.441889] ffff88007a7d3d40 ffff88003a806bb0 0000000000000001 ffff88007ae54000
[ 244.443778] Call Trace:
[ 244.444376] [<ffffffff816486cb>] unix_stream_recvmsg+0x57b/0x840
[ 244.445850] [<ffffffff811c7530>] ? poll_select_copy_remaining+0x130/0x130
[ 244.447504] [<ffffffff81589c96>] sock_recvmsg+0x76/0x90
[ 244.448777] [<ffffffff8158b8fe>] ? copy_msghdr_from_user+0x15e/0x1f0
[ 244.450331] [<ffffffff8158bd84>] ___sys_recvmsg+0xe4/0x200
[ 244.451660] [<ffffffff81337180>] ? timerqueue_add+0x60/0xb0
[ 244.453018] [<ffffffff810ce4c9>] ? enqueue_hrtimer+0x29/0x90
[ 244.454390] [<ffffffff810cea70>] ? __hrtimer_start_range_ns+0x260/0x360
[ 244.455995] [<ffffffff811d0745>] ? __fget_light+0x25/0x70
[ 244.457313] [<ffffffff8158c762>] __sys_recvmsg+0x42/0x80
[ 244.458625] [<ffffffff8158c7b2>] SyS_recvmsg+0x12/0x20
[ 244.459871] [<ffffffff816a52e9>] system_call_fastpath+0x12/0x17
[ 244.461334] Code: 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 48 8b 46 38 48 89 e5 41 54 49 89 fc 53 48 89 07 48 c7 46 38 00 00 00 00 48 8b 07 <0f> bf 18 83 eb 01 79 0b eb 1e 0f 1f 44 00 00 49 8b 04 24 48 63
[ 244.467598] RIP [<ffffffff81646a51>] unix_detach_fds.isra.25+0x21/0x50
[ 244.469201] RSP <ffff88007ab8bb48>
[ 244.470055] CR2: 00000000bf38b1f5
[ 1511.728498] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
[ 1511.730551] IP: [<ffffffff8159342b>] skb_dequeue+0x4b/0x80
[ 1511.731987] PGD 0
[ 1511.732523] Oops: 0002 [#1] SMP
[ 1511.733406] Modules linked in: stap_1d434baec036a3abf082a3f3fc53e337_2788(OE) ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_mangle ip6table_raw ip6table_filter ip6_tables iptable_mangle iptable_raw iptable_filter ip_tables coretemp crct10dif_pclmul crc32_pclmul crc32c_intel dm_mirror ghash_clmulni_intel dm_region_hash dm_log aesni_intel dm_mod glue_helper lrw gf128mul ablk_helper cryptd vmw_balloon ppdev microcode serio_raw pcspkr parport_pc vmw_vmci parport shpchp i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc uinput sd_mod ata_generic pata_acpi mptspi ata_piix e1000 scsi_transport_spi libata m
ptscsih mptbase floppy
[ 1511.752609] CPU: 2 PID: 2972 Comm: pool Tainted: G W OE 3.19.0-rc3+ #9
[ 1511.754400] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
[ 1511.757001] task: ffff880036d29180 ti: ffff8800791bc000 task.ti: ffff8800791bc000
[ 1511.758830] RIP: 0010:[<ffffffff8159342b>] [<ffffffff8159342b>] skb_dequeue+0x4b/0x80
[ 1511.760787] RSP: 0018:ffff8800791bfb78 EFLAGS: 00010082
[ 1511.762047] RAX: 0000000000000296 RBX: ffff88007a8d7380 RCX: 0000000000000000
[ 1511.763765] RDX: 0000000000000000 RSI: 0000000000000296 RDI: ffff88007a8d77a4
[ 1511.765583] RBP: ffff8800791bfb98 R08: 0000000000000296 R09: 0000000000000000
[ 1511.767359] R10: ffff8800799cb4b0 R11: ffff88007a22b410 R12: ffff88007a8d7790
[ 1511.769116] R13: ffff88007a8d77a4 R14: ffff88007a8d7790 R15: 0000000000000001
[ 1511.770866] FS: 0000000000000000(0000) GS:ffff88007fc80000(0000) knlGS:0000000000000000
[ 1511.772854] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1511.774239] CR2: 0000000000000008 CR3: 0000000001c14000 CR4: 00000000000407e0
[ 1511.776042] Stack:
[ 1511.776558] ffff88007a8d776c ffff88007a8d7700 ffff88007a8d776c ffff88007a8d7a80
[ 1511.778449] ffff8800791bfbf8 ffffffff81648030 0000000100c2e630 ffff880000000000
[ 1511.780372] 0000000000000000 0000000000000000 0000000000000000 ffff8800799cb480
[ 1511.782290] Call Trace:
[ 1511.782921] [<ffffffff81648030>] unix_release_sock+0x1d0/0x2b0
[ 1511.784410] [<ffffffff81648131>] unix_release+0x21/0x40
[ 1511.785721] [<ffffffff8158ab8f>] sock_release+0x1f/0x90
[ 1511.787029] [<ffffffff8158ac12>] sock_close+0x12/0x20
[ 1511.788323] [<ffffffff811b531f>] __fput+0xdf/0x1e0
[ 1511.789514] [<ffffffff811b546e>] ____fput+0xe/0x10
[ 1511.790720] [<ffffffff81087dac>] task_work_run+0xcc/0xf0
[ 1511.792072] [<ffffffff8106eae8>] do_exit+0x2d8/0xb40
[ 1511.793290] [<ffffffff810779af>] ? recalc_sigpending+0x1f/0x60
[ 1511.794718] [<ffffffff8106f3df>] do_group_exit+0x3f/0xa0
[ 1511.796074] [<ffffffff8107a6f2>] get_signal+0x1d2/0x6f0
[ 1511.797396] [<ffffffff810134e8>] do_signal+0x28/0x720
[ 1511.798653] [<ffffffff81013c2c>] do_notify_resume+0x4c/0x90
[ 1511.800057] [<ffffffff816a5587>] int_signal+0x12/0x17
[ 1511.801334] Code: 00 49 8b 1c 24 4c 39 e3 74 46 48 85 db 74 23 41 83 6c 24 10 01 48 8b 0b 48 8b 53 08 48 c7 03 00 00 00 00 48 c7 43 08 00 00 00 00 <48> 89 51 08 48 89 0a 48 89 c6 4c 89 ef e8 53 17 11 00 48 83 c4
[ 1511.807711] RIP [<ffffffff8159342b>] skb_dequeue+0x4b/0x80
[ 1511.809118] RSP <ffff8800791bfb78>
[ 1511.809995] CR2: 0000000000000008
[ 149.357455] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
[ 149.359965] IP: [<ffffffff8159342b>] skb_dequeue+0x4b/0x80
[ 149.361412] PGD 0
[ 149.361931] Oops: 0002 [#1] SMP
[ 149.362787] Modules linked in: stap_1d434baec036a3abf082a3f3fc53e337_2459(OE) ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_mangle ip6table_raw ip6table_filter ip6_tables iptable_mangle iptable_raw iptable_filter ip_tables coretemp crct10dif_pclmul crc32_pclmul crc32c_intel dm_mirror ghash_clmulni_intel dm_region_hash dm_log aesni_intel dm_mod glue_helper lrw gf128mul ablk_helper cryptd ppdev vmw_balloon microcode parport_pc pcspkr serio_raw parport vmw_vmci shpchp i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc uinput ata_generic pata_acpi sd_mod ata_piix mptspi e1000 scsi_transport_spi mptscsih
libata mptbase floppy
[ 149.382152] CPU: 0 PID: 2608 Comm: gnome-shell Tainted: G W OE 3.19.0-rc3+ #9
[ 149.384226] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
[ 149.386705] task: ffff88007ad5d780 ti: ffff88007a630000 task.ti: ffff88007a630000
[ 149.388606] RIP: 0010:[<ffffffff8159342b>] [<ffffffff8159342b>] skb_dequeue+0x4b/0x80
[ 149.390496] RSP: 0018:ffff88007a633b78 EFLAGS: 00010097
[ 149.391740] RAX: 0000000000000296 RBX: ffff88007ad6ad80 RCX: 0000000000000000
[ 149.393627] RDX: ffff88003a87fae8 RSI: 0000000000000292 RDI: ffff88007ad6e624
[ 149.395312] RBP: ffff88007a633b98 R08: 0000000000000296 R09: 0000000000000000
[ 149.397071] R10: ffff88003eeb4030 R11: ffff88007a2dfc10 R12: ffff88007ad6e610
[ 149.398745] R13: ffff88007ad6e624 R14: ffff88007ad6e610 R15: 0000000000000001
[ 149.400434] FS: 0000000000000000(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000
[ 149.402266] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 149.403924] CR2: 0000000000000008 CR3: 0000000001c14000 CR4: 00000000000407f0
[ 149.405701] Stack:
[ 149.406206] ffff88007ad6e5ec ffff88007ad6e580 ffff88007ad6e5ec ffff88007ad6b480
[ 149.408086] ffff88007a633bf8 ffffffff81647fc4 000000013eeb2dc8 ffff880000000000
[ 149.409863] 0000000000000000 0000000000000000 0000000000000000 ffff88003eeb4000
[ 149.411670] Call Trace:
[ 149.412242] [<ffffffff81647fc4>] unix_release_sock+0x164/0x2b0
[ 149.413838] [<ffffffff81648131>] unix_release+0x21/0x40
[ 149.415089] [<ffffffff8158ab8f>] sock_release+0x1f/0x90
[ 149.416382] [<ffffffff8158ac12>] sock_close+0x12/0x20
[ 149.417581] [<ffffffff811b531f>] __fput+0xdf/0x1e0
[ 149.418869] [<ffffffff811b546e>] ____fput+0xe/0x10
[ 149.420026] [<ffffffff81087dac>] task_work_run+0xcc/0xf0
[ 149.421313] [<ffffffff8106eae8>] do_exit+0x2d8/0xb40
[ 149.422495] [<ffffffff810779af>] ? recalc_sigpending+0x1f/0x60
[ 149.423925] [<ffffffff8106f3df>] do_group_exit+0x3f/0xa0
[ 149.425173] [<ffffffff8107a6f2>] get_signal+0x1d2/0x6f0
[ 149.426408] [<ffffffff810134e8>] do_signal+0x28/0x720
[ 149.427573] [<ffffffff8101fe4b>] ? __restore_xstate_sig+0x8b/0x680
[ 149.429030] [<ffffffff81013c2c>] do_notify_resume+0x4c/0x90
[ 149.430351] [<ffffffff816a5587>] int_signal+0x12/0x17
[ 149.431511] Code: 00 49 8b 1c 24 4c 39 e3 74 46 48 85 db 74 23 41 83 6c 24 10 01 48 8b 0b 48 8b 53 08 48 c7 03 00 00 00 00 48 c7 43 08 00 00 00 00 <48> 89 51 08 48 89 0a 48 89 c6 4c 89 ef e8 53 17 11 00 48 83 c4
[ 149.437473] RIP [<ffffffff8159342b>] skb_dequeue+0x4b/0x80
[ 149.438803] RSP <ffff88007a633b78>
[ 149.439599] CR2: 0000000000000008
[ 144.274609] BUG: unable to handle kernel NULL pointer dereference at 0000000000000002
[ 144.276557] IP: [<ffffffff81599f40>] skb_copy_datagram_iter+0xe0/0x260
[ 144.278178] PGD 7a26e067 PUD 7a26b067 PMD 0
[ 144.279300] Oops: 0000 [#1] SMP
[ 144.280129] Modules linked in: stap_1d434baec036a3abf082a3f3fc53e337_2457(OE) ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_mangle ip6table_raw ip6table_filter ip6_tables iptable_mangle iptable_raw iptable_filter ip_tables coretemp crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel dm_mirror aesni_intel dm_region_hash glue_helper dm_log lrw gf128mul dm_mod ablk_helper cryptd ppdev vmw_balloon microcode parport_pc serio_raw pcspkr vmw_vmci parport shpchp i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc uinput sd_mod ata_generic pata_acpi mptspi scsi_transport_spi e1000 mptscsih ata_piix
mptbase libata floppy
[ 144.299002] CPU: 2 PID: 2348 Comm: gnome-shell Tainted: G W OE 3.19.0-rc3+ #9
[ 144.300902] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
[ 144.303443] task: ffff880078008000 ti: ffff88007a298000 task.ti: ffff88007a298000
[ 144.305231] RIP: 0010:[<ffffffff81599f40>] [<ffffffff81599f40>] skb_copy_datagram_iter+0xe0/0x260
[ 144.307397] RSP: 0018:ffff88007a29bbc8 EFLAGS: 00010202
[ 144.308726] RAX: 0000000000000002 RBX: 0000000000001000 RCX: 00000000c698e000
[ 144.310443] RDX: ffff88007a29be78 RSI: 0000000039672000 RDI: ffff88007a139180
[ 144.312144] RBP: ffff88007a29bc18 R08: 0000000000001000 R09: ffff88007b1e0c80
[ 144.313834] R10: 0000000000000000 R11: ffff880078008000 R12: 0000000000000000
[ 144.315559] R13: ffff88007a139180 R14: 0000000039672000 R15: ffff88007a138a80
[ 144.317261] FS: 00007fc870c36a00(0000) GS:ffff88007fc80000(0000) knlGS:0000000000000000
[ 144.319169] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 144.320562] CR2: 0000000000000002 CR3: 000000007b5f5000 CR4: 00000000000407e0
[ 144.322289] Stack:
[ 144.322784] 0000000000000008 ffff88007a151000 00000000c698e000 ffff88007a29be78
[ 144.324668] ffff88007a29bca8 0000000000000000 0000000000000000 ffff88007a139180
[ 144.326564] ffff88007a138b10 ffff88007a138a80 ffff88007a29bd28 ffffffff8164865b
[ 144.328422] Call Trace:
[ 144.329021] [<ffffffff8164865b>] unix_stream_recvmsg+0x50b/0x840
[ 144.330484] [<ffffffff811c7530>] ? poll_select_copy_remaining+0x130/0x130
[ 144.332121] [<ffffffff81589c96>] sock_recvmsg+0x76/0x90
[ 144.333389] [<ffffffff811d0745>] ? __fget_light+0x25/0x70
[ 144.334714] [<ffffffff811d07a3>] ? __fdget+0x13/0x20
[ 144.335934] [<ffffffff8158a1c7>] ? sockfd_lookup_light+0x17/0x70
[ 144.337383] [<ffffffff8158a860>] SYSC_recvfrom+0xe0/0x160
[ 144.338693] [<ffffffff81103264>] ? __audit_syscall_entry+0xb4/0x110
[ 144.340222] [<ffffffff8102140c>] ? do_audit_syscall_entry+0x6c/0x70
[ 144.341753] [<ffffffff810227b3>] ? syscall_trace_enter_phase1+0x123/0x180
[ 144.343385] [<ffffffff8158c2ee>] SyS_recvfrom+0xe/0x10
[ 144.344651] [<ffffffff816a52e9>] system_call_fastpath+0x12/0x17
[ 144.346100] Code: 83 c7 10 89 da 4c 89 ee ff d1 49 8b 0f 48 85 c9 75 e9 8b 4d c0 85 c9 0f 8f 76 ff ff ff 41 8b 85 cc 00 00 00 49 03 85 d0 00 00 00 <80> 38 00 0f 84 98 00 00 00 45 31 ff 0f 1f 40 00 49 63 d7 48 83
[ 144.352303] RIP [<ffffffff81599f40>] skb_copy_datagram_iter+0xe0/0x260
[ 144.353900] RSP <ffff88007a29bbc8>
[ 144.354829] CR2: 0000000000000002
[ 141.981007] BUG: unable to handle kernel paging request at ffff88013b831cc0
[ 141.982931] IP: [<ffffffff81594dd5>] __alloc_skb+0x165/0x2b0
[ 141.984465] PGD 1f2b067 PUD 0
[ 141.985334] Oops: 0002 [#1] SMP
[ 141.986357] Modules linked in: stap_1d434baec036a3abf082a3f3fc53e337_4681(OE) ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_mangle ip6table_raw ip6table_filter ip6_tables iptable_mangle iptable_raw iptable_filter ip_tables coretemp crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel dm_mirror glue_helper dm_region_hash dm_log lrw dm_mod gf128mul ablk_helper cryptd ppdev vmw_balloon parport_pc microcode serio_raw vmw_vmci pcspkr parport shpchp i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc uinput ata_generic sd_mod pata_acpi ata_piix libata mptspi e1000 scsi_transport_spi m
ptscsih mptbase floppy
[ 142.006491] CPU: 3 PID: 610 Comm: Xorg Tainted: G W OE 3.19.0-rc3+ #9
[ 142.008230] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
[ 142.010776] task: ffff880078898000 ti: ffff88007be24000 task.ti: ffff88007be24000
[ 142.012551] RIP: 0010:[<ffffffff81594dd5>] [<ffffffff81594dd5>] __alloc_skb+0x165/0x2b0
[ 142.014522] RSP: 0018:ffff88007be27aa8 EFLAGS: 00010246
[ 142.015810] RAX: 00000000ffffffff RBX: ffff88003b831c00 RCX: 00000000ffffffff
[ 142.017512] RDX: ffff88013b831cc0 RSI: 0000000000000000 RDI: ffff88003b831cc8
[ 142.019255] RBP: ffff88007be27af8 R08: 00000000ffffffc0 R09: 0000000000000200
[ 142.020966] R10: ffffffff81594cbe R11: ffff88007f803700 R12: ffff88003b831d00
[ 142.022673] R13: 00000000ffffffff R14: ffff88007f803700 R15: 0000000000000100
[ 142.024378] FS: 00007fae44c35980(0000) GS:ffff88007fcc0000(0000) knlGS:0000000000000000
[ 142.026300] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 142.027657] CR2: ffff88013b831cc0 CR3: 00000000780ea000 CR4: 00000000000407e0
[ 142.029383] Stack:
[ 142.029865] ffff880000000000 0000000000000001 ffff88007b232ec0 0000000000000000
[ 142.031710] ffff8800780483c8 0000000000000003 0000000000000000 ffff88007be27ba8
[ 142.033531] ffff880078f06200 0000000000000000 ffff88007be27b58 ffffffff8159567c
[ 142.035344] Call Trace:
[ 142.035950] [<ffffffff8159567c>] alloc_skb_with_frags+0x5c/0x1e0
[ 142.037356] [<ffffffff81096440>] ? wake_up_state+0x20/0x20
[ 142.038865] [<ffffffff8158f9d6>] sock_alloc_send_pskb+0x196/0x250
[ 142.040323] [<ffffffff810aaeb4>] ? __wake_up_sync_key+0x54/0x70
[ 142.041769] [<ffffffff8164a237>] ? wait_for_unix_gc+0x27/0xa0
[ 142.043181] [<ffffffff81647aba>] unix_stream_sendmsg+0x2aa/0x430
[ 142.044582] [<ffffffff8158a9e3>] sock_aio_write+0x103/0x140
[ 142.045979] [<ffffffff811b2fbc>] do_sync_readv_writev+0x4c/0x80
[ 142.047370] [<ffffffff811b4965>] do_readv_writev+0x1e5/0x280
[ 142.048756] [<ffffffff810ce4c9>] ? enqueue_hrtimer+0x29/0x90
[ 142.050119] [<ffffffff811d0745>] ? __fget_light+0x25/0x70
[ 142.051432] [<ffffffff81103264>] ? __audit_syscall_entry+0xb4/0x110
[ 142.052891] [<ffffffff811b4a89>] vfs_writev+0x39/0x50
[ 142.054119] [<ffffffff811b4bba>] SyS_writev+0x4a/0xd0
[ 142.055307] [<ffffffff811034f6>] ? __audit_syscall_exit+0x236/0x2e0
[ 142.056821] [<ffffffff816a52e9>] system_call_fastpath+0x12/0x17
[ 142.058259] Code: b6 83 90 00 00 00 83 e0 f7 09 c8 b9 ff ff ff ff 85 f6 88 83 90 00 00 00 b8 ff ff ff ff 66 89 8b c2 00 00 00 66 89 83 c6 00 00 00 <48> c7 02 00 00 00 00 48 c7 42 08 00 00 00 00 48 c7 42 10 00 00
[ 142.064326] RIP [<ffffffff81594dd5>] __alloc_skb+0x165/0x2b0
[ 142.065719] RSP <ffff88007be27aa8>
[ 142.066536] CR2: ffff88013b831cc0
[ 202.125577] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 202.127781] IP: [<ffffffff81593577>] skb_queue_tail+0x37/0x60
[ 202.129471] PGD 7909a067 PUD 7c0ab067 PMD 0
[ 202.130709] Oops: 0002 [#1] SMP
[ 202.131655] Modules linked in: stap_1d434baec036a3abf082a3f3fc53e337_4681(OE) ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_mangle ip6table_raw ip6table_filter ip6_tables iptable_mangle iptable_raw iptable_filter ip_tables coretemp crct10dif_pclmul dm_mirror crc32_pclmul crc32c_intel dm_region_hash dm_log ghash_clmulni_intel aesni_intel dm_mod glue_helper lrw gf128mul ablk_helper cryptd ppdev vmw_balloon parport_pc microcode pcspkr vmw_vmci serio_raw parport shpchp i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc uinput sd_mod ata_generic pata_acpi mptspi scsi_transport_spi e1000 mptscsih ata_piix
mptbase libata floppy [last unloaded: stap_1d434baec036a3abf082a3f3fc53e337_4681]
[ 202.154006] CPU: 0 PID: 2884 Comm: Xorg Tainted: G W OE 3.19.0-rc3+ #9
[ 202.155953] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
[ 202.158788] task: ffff88004b048000 ti: ffff88007b590000 task.ti: ffff88007b590000
[ 202.160770] RIP: 0010:[<ffffffff81593577>] [<ffffffff81593577>] skb_queue_tail+0x37/0x60
[ 202.162999] RSP: 0018:ffff88007b593bc8 EFLAGS: 00010046
[ 202.164409] RAX: 0000000000000292 RBX: ffff88007a426990 RCX: 0000000000000000
[ 202.166246] RDX: 0000000000000000 RSI: 0000000000000292 RDI: ffff88007a4269a4
[ 202.168089] RBP: ffff88007b593be8 R08: 0000000000000292 R09: 0000000000000300
[ 202.169992] R10: ffffffff81594cbe R11: ffff88007f803600 R12: ffff88007a426990
[ 202.171916] R13: ffff88007a4269a4 R14: 0000000000000000 R15: ffff88007a426900
[ 202.173815] FS: 00007f8233198980(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000
[ 202.175936] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 202.177467] CR2: 0000000000000000 CR3: 000000004eb73000 CR4: 00000000000407f0
[ 202.179411] Stack:
[ 202.179967] 0000000000000020 ffff88007a426990 0000000000000020 0000000000000000
[ 202.182006] ffff88007b593ca8 ffffffff816479ed ffff88007a426990 ffff88007b593d10
[ 202.184061] 0000002000000000 ffff88007b593cc8 0000000000000020 ffff88007a426bf8
[ 202.186124] Call Trace:
[ 202.186817] [<ffffffff816479ed>] unix_stream_sendmsg+0x1dd/0x430
[ 202.188440] [<ffffffff8158a9e3>] sock_aio_write+0x103/0x140
[ 202.189938] [<ffffffff811b2fbc>] do_sync_readv_writev+0x4c/0x80
[ 202.191531] [<ffffffff811b4965>] do_readv_writev+0x1e5/0x280
[ 202.193053] [<ffffffff811d0745>] ? __fget_light+0x25/0x70
[ 202.194496] [<ffffffff81103264>] ? __audit_syscall_entry+0xb4/0x110
[ 202.196181] [<ffffffff811b4a89>] vfs_writev+0x39/0x50
[ 202.197506] [<ffffffff811b4bba>] SyS_writev+0x4a/0xd0
[ 202.198855] [<ffffffff811034f6>] ? __audit_syscall_exit+0x236/0x2e0
[ 202.200550] [<ffffffff816a52e9>] system_call_fastpath+0x12/0x17
[ 202.202137] Code: 8d 6f 14 41 54 49 89 f4 53 48 89 fb 4c 89 ef 48 83 ec 08 e8 dc 19 11 00 48 8b 53 08 49 89 1c 24 4c 89 ef 48 89 c6 49 89 54 24 08 <4c> 89 22 83 43 10 01 4c 89 63 08 e8 09 16 11 00 48 83 c4 08 5b
[ 202.208943] RIP [<ffffffff81593577>] skb_queue_tail+0x37/0x60
[ 202.210471] RSP <ffff88007b593bc8>
[ 202.211382] CR2: 0000000000000000
[ 313.016314] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 313.018432] IP: [<ffffffff81593577>] skb_queue_tail+0x37/0x60
[ 313.019982] PGD 79fe4067 PUD 7879b067 PMD 0
[ 313.021183] Oops: 0002 [#1] SMP
[ 313.022081] Modules linked in: stap_1d434baec036a3abf082a3f3fc53e337_4681(OE) ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_mangle ip6table_raw ip6table_filter ip6_tables iptable_mangle iptable_raw iptable_filter ip_tables coretemp crct10dif_pclmul dm_mirror crc32_pclmul dm_region_hash crc32c_intel dm_log ghash_clmulni_intel aesni_intel dm_mod glue_helper lrw gf128mul ablk_helper cryptd ppdev vmw_balloon microcode serio_raw parport_pc pcspkr vmw_vmci shpchp parport i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc uinput sd_mod ata_generic pata_acpi ata_piix libata mptspi scsi_transport_spi mptscsi
h e1000 mptbase floppy
[ 313.041970] CPU: 0 PID: 2928 Comm: Xorg Tainted: G W OE 3.19.0-rc3+ #9
[ 313.043692] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
[ 313.046200] task: ffff88007a3fa300 ti: ffff880079f08000 task.ti: ffff880079f08000
[ 313.047972] RIP: 0010:[<ffffffff81593577>] [<ffffffff81593577>] skb_queue_tail+0x37/0x60
[ 313.049940] RSP: 0018:ffff880079f0bbc8 EFLAGS: 00010046
[ 313.051209] RAX: 0000000000000292 RBX: ffff88007a0c3510 RCX: 0000000000000000
[ 313.052892] RDX: 0000000000000000 RSI: 0000000000000292 RDI: ffff88007a0c3524
[ 313.054572] RBP: ffff880079f0bbe8 R08: 0000000000000292 R09: 0000000000000300
[ 313.056254] R10: ffffffff81594cbe R11: ffff88007f803600 R12: ffff88007a0c3510
[ 313.057957] R13: ffff88007a0c3524 R14: 0000000000000000 R15: ffff88007a0c3480
[ 313.059642] FS: 00007fa68e9b5980(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000
[ 313.061536] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 313.062881] CR2: 0000000000000000 CR3: 000000007c026000 CR4: 00000000000407f0
[ 313.064617] Stack:
[ 313.065110] 0000000000000020 ffff88007a0c3510 0000000000000020 0000000000000000
[ 313.066962] ffff880079f0bca8 ffffffff816479ed ffff88007a0c3510 ffff880079f0bd10
[ 313.068809] 0000002000000000 ffff880079f0bcc8 0000000000000020 ffff88007a0c3778
[ 313.070667] Call Trace:
[ 313.071263] [<ffffffff816479ed>] unix_stream_sendmsg+0x1dd/0x430
[ 313.072710] [<ffffffff8158a9e3>] sock_aio_write+0x103/0x140
[ 313.074281] [<ffffffff811b2fbc>] do_sync_readv_writev+0x4c/0x80
[ 313.075706] [<ffffffff811b4965>] do_readv_writev+0x1e5/0x280
[ 313.077070] [<ffffffff810ce4c9>] ? enqueue_hrtimer+0x29/0x90
[ 313.078437] [<ffffffff811d0745>] ? __fget_light+0x25/0x70
[ 313.079731] [<ffffffff81103264>] ? __audit_syscall_entry+0xb4/0x110
[ 313.081225] [<ffffffff811b4a89>] vfs_writev+0x39/0x50
[ 313.082450] [<ffffffff811b4bba>] SyS_writev+0x4a/0xd0
[ 313.083680] [<ffffffff811034f6>] ? __audit_syscall_exit+0x236/0x2e0
[ 313.085186] [<ffffffff816a52e9>] system_call_fastpath+0x12/0x17
[ 313.086609] Code: 8d 6f 14 41 54 49 89 f4 53 48 89 fb 4c 89 ef 48 83 ec 08 e8 dc 19 11 00 48 8b 53 08 49 89 1c 24 4c 89 ef 48 89 c6 49 89 54 24 08 <4c> 89 22 83 43 10 01 4c 89 63 08 e8 09 16 11 00 48 83 c4 08 5b
[ 313.093012] RIP [<ffffffff81593577>] skb_queue_tail+0x37/0x60
[ 313.094408] RSP <ffff880079f0bbc8>
[ 313.095233] CR2: 0000000000000000
[ 207.542992] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 207.545125] IP: [<ffffffff81536cc3>] skb_queue_tail+0x33/0x50
[ 207.546719] PGD 49067 PUD 1a3067 PMD 0
[ 207.547815] Oops: 0002 [#1] SMP
[ 207.548725] Modules linked in: stap_a22ae6d0c4bc77fa650b27434e28e712_2992(OF) ip6t_rpfilter ip6t_REJECT ipt_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_raw iptable_filter ip_tables coretemp crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel dm_mirror glue_helper dm_region_hash lrw gf128mul dm_log ablk_helper dm_mod cryptd microcode vmw_balloon ppdev parport_pc serio_raw pcspkr vmw_vmci parport shpchp i2c_piix4 nfsd auth_rpcgss nfs_acl lockd sunrpc uinput sd_mod ata_generic pata_acpi mptspi scsi_transport_spi mpt
scsih mptbase ata_piix libata e1000 floppy
[ 207.568456] CPU: 3 PID: 3016 Comm: Xorg Tainted: GF W O 3.14.0+ #12
[ 207.570127] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
[ 207.572653] task: ffff88007bf4baa0 ti: ffff88007a230000 task.ti: ffff88007a230000
[ 207.574431] RIP: 0010:[<ffffffff81536cc3>] [<ffffffff81536cc3>] skb_queue_tail+0x33/0x50
[ 207.576378] RSP: 0018:ffff88007a231c70 EFLAGS: 00010046
[ 207.577655] RAX: 0000000000000246 RBX: ffff8800221c4190 RCX: 0000000000000000
[ 207.579361] RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff8800221c41a4
[ 207.581034] RBP: ffff88007a231c88 R08: 0000000000000246 R09: 0000000000000300
[ 207.582752] R10: ffff88003c3cc900 R11: 0000000000000020 R12: ffff8800221c4190
[ 207.584445] R13: ffff8800221c41a4 R14: ffff8800221c4100 R15: 0000000000000000
[ 207.586114] FS: 00007f91fc263980(0000) GS:ffff88007fcc0000(0000) knlGS:0000000000000000
[ 207.588011] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 207.589752] CR2: 0000000000000000 CR3: 0000000000139000 CR4: 00000000000407e0
[ 207.591514] Stack:
[ 207.592046] ffff8800221c4190 0000000000000020 0000000000000000 ffff88007a231d30
[ 207.594108] ffffffff815e2018 ffff8800221c4190 0000002000000059 ffff88007a231d40
[ 207.596194] 0000000000000020 ffff8800221c43e8 ffff88007a231d78 ffff88007b22ef80
[ 207.598156] Call Trace:
[ 207.598774] [<ffffffff815e2018>] unix_stream_sendmsg+0x1b8/0x3f0
[ 207.600297] [<ffffffff8152dde7>] sock_aio_write+0xd7/0xf0
[ 207.601750] [<ffffffff811d1eb8>] ? fsnotify+0x228/0x2f0
[ 207.603077] [<ffffffff81190e9c>] do_sync_readv_writev+0x4c/0x80
[ 207.604638] [<ffffffff81192300>] do_readv_writev+0xb0/0x220
[ 207.606030] [<ffffffff8108c91a>] ? __hrtimer_start_range_ns+0x1aa/0x380
[ 207.607678] [<ffffffff8142154e>] ? vmw_unlocked_ioctl+0x4e/0x70
[ 207.609322] [<ffffffff811a3e60>] ? do_vfs_ioctl+0x2e0/0x4c0
[ 207.610728] [<ffffffff811924f0>] vfs_writev+0x30/0x60
[ 207.612081] [<ffffffff8119263a>] SyS_writev+0x4a/0xd0
[ 207.613369] [<ffffffff81645da9>] system_call_fastpath+0x16/0x1b
[ 207.614896] Code: e5 41 55 4c 8d 6f 14 41 54 49 89 f4 53 48 89 fb 4c 89 ef e8 00 7c 10 00 48 8b 53 08 49 89 1c 24 4c 89 ef 48 89 c6 49 89 54 24 08 <4c> 89 22 83 43 10 01 4c 89 63 08 e8 dd 79 10 00 5b 41 5c 41 5d
[ 207.621107] RIP [<ffffffff81536cc3>] skb_queue_tail+0x33/0x50
[ 207.622519] RSP <ffff88007a231c70>
[ 207.623354] CR2: 0000000000000000
^ permalink raw reply
* Re: [PATCH net-next 16/16] tipc: make netlink support net namespace
From: Sergei Shtylyov @ 2015-01-09 13:42 UTC (permalink / raw)
To: Ying Xue, davem
Cc: jon.maloy, Tero.Aho, Paul.Gortmaker, erik.hugne, richard.alpe,
netdev, tipc-discussion
In-Reply-To: <1420788433-17960-17-git-send-email-ying.xue@windriver.com>
Hello.
On 1/9/2015 10:27 AM, Ying Xue wrote:
> Currently tipc module only allows users sitting on "init_net" namespace
> to configure it through netlink interface. But now almost each tipc
> component is able to be aware of net namespace, so it's time to open
> the permission for users residing in other namespaces, allowing them
> to configure their own tipc stack instance through netlink interface.
> Signed-off-by: Ying Xue <ying.xue@windriver.com>
> Tested-by: Tero Aho <Tero.Aho@coriant.com>
> Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
> ---
> net/tipc/netlink.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
> diff --git a/net/tipc/netlink.c b/net/tipc/netlink.c
> index 282b596..fe0f513 100644
> --- a/net/tipc/netlink.c
> +++ b/net/tipc/netlink.c
> @@ -54,7 +54,8 @@ static int handle_cmd(struct sk_buff *skb, struct genl_info *info)
> int hdr_space = nlmsg_total_size(GENL_HDRLEN + TIPC_GENL_HDRLEN);
> u16 cmd;
>
> - if ((req_userhdr->cmd & 0xC000) && (!netlink_capable(skb, CAP_NET_ADMIN)))
> + if ((req_userhdr->cmd & 0xC000) &&
> + (!netlink_net_capable(skb, CAP_NET_ADMIN)))
Why? Also, it seems like unrelated change...
[...]
WBR, Sergei
^ permalink raw reply
* Re: Winning Notification !!!
From: UK FREE LOTTO @ 2015-01-09 13:27 UTC (permalink / raw)
Your email ID has made you a bonafide winner of the sum of $2,000,000.00 USD, Provide your Name,Country,Occupation and Tel. So that your winning will be activate and open to your name.
^ permalink raw reply
* Re: [PATCH] ethernet: atheros: Add nss-gmac driver
From: Mark Rutland @ 2015-01-09 13:50 UTC (permalink / raw)
To: Stephen Wang
Cc: jcliburn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1420754626-30121-1-git-send-email-wstephen-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Thu, Jan 08, 2015 at 10:03:46PM +0000, Stephen Wang wrote:
> This driver adds support for the internal GMACs on IPQ806x SoCs.
> It supports the device-tree and will register up to 4 ethernet
> interfaces.
>
> Signed-off-by: Stephen Wang <wstephen-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> ---
> drivers/net/ethernet/atheros/Kconfig | 10 +
> drivers/net/ethernet/atheros/Makefile | 1 +
> drivers/net/ethernet/atheros/nss-gmac/LICENSE.txt | 14 +
> drivers/net/ethernet/atheros/nss-gmac/Makefile | 19 +
> .../atheros/nss-gmac/exports/nss_gmac_api_if.h | 126 ++
> .../atheros/nss-gmac/include/msm_nss_gmac.h | 338 ++++
> .../atheros/nss-gmac/include/msm_nss_macsec.h | 73 +
> .../atheros/nss-gmac/include/nss_gmac_clocks.h | 100 +
> .../atheros/nss-gmac/include/nss_gmac_dev.h | 2136 ++++++++++++++++++++
> .../nss-gmac/include/nss_gmac_network_interface.h | 63 +
> .../net/ethernet/atheros/nss-gmac/nss_gmac_ctrl.c | 1210 +++++++++++
> .../net/ethernet/atheros/nss-gmac/nss_gmac_dev.c | 1963 ++++++++++++++++++
> .../ethernet/atheros/nss-gmac/nss_gmac_ethtool.c | 526 +++++
> .../net/ethernet/atheros/nss-gmac/nss_gmac_init.c | 1131 +++++++++++
> .../ethernet/atheros/nss-gmac/nss_gmac_mdiobus.c | 187 ++
> .../atheros/nss-gmac/nss_gmac_tx_rx_offload.c | 1175 +++++++++++
Device tree bindings _must_ be documented, yet this standalone patch
adds nothing to Documentation/devicetree/bindings per the diffstat
above. So trivial NAK until there's a patch documenting that.
See Documentation/devicetree/bindings/submitting-patches.txt
Thanks,
Mark.
--
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: [PATCH v3 4/4] can: kvaser_usb: Add support for the Usbcan-II family
From: Marc Kleine-Budde @ 2015-01-09 14:05 UTC (permalink / raw)
To: Ahmed S. Darwish
Cc: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger,
David S. Miller, Paul Gortmaker, Linux-CAN, netdev, LKML
In-Reply-To: <20150109030657.GA1791@vivalin-002>
[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]
On 01/09/2015 04:06 AM, Ahmed S. Darwish wrote:
>>>
>>> cf->can_id |= CAN_ERR_CRTL;
>>> cf->data[1] = CAN_ERR_CRTL_RX_OVERFLOW;
>>>
>>> stats->rx_over_errors++;
>>> stats->rx_errors++;
>>>
>>> netif_rx(skb);
>>>
>>> stats->rx_packets++;
>>> stats->rx_bytes += cf->can_dlc;
>>
>> Another patch would be not to touch cf after netif_rx(), please
>> move the stats handling before calling netif_rx(). Same applies to
>> the kvaser_usb_rx_can_msg() function.
> BTW, is it guaranteed from the SocketCAN stack that netif_rx()
netif_rx() is the generic networking stack already.
> will never return NET_RX_DROPPED? Because if no guarantee
> exists, I guess below fragment cannot be completely correct?
No, it's not guaranteed...
>
> stats->rx_packets++;
> stats->rx_bytes += cf->can_dlc;
> netif_rx(skb);
>
> On the other hand, I don't see evan a single CAN driver checking
> netif_rx() return value, so maybe such a check is an overkill...
A quick look shows that almost no ethernet or wireless drivers take care
about the return value. In case of a RX_DROPPED some increase a drop
counter, though.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH iproute2 3/3] ip netns: Delete all netns
From: Nicolas Dichtel @ 2015-01-09 14:24 UTC (permalink / raw)
To: Vadim Kochan, Jiri Benc; +Cc: Brian Haley, netdev@vger.kernel.org
In-Reply-To: <CAMw6YJLx0O6dVnD2XcmF+qz+=m51TyZOqJWSYGKQ-XrMHP8z3w@mail.gmail.com>
Le 09/01/2015 10:54, Vadim Kochan a écrit :
> Ok,
>
> If I will re-work to use new option, would it be useful ? So it will look:
>
> $ ip -all netns del
> $ ip -all netns exec ip link
> $ ip -all netns exec ip route add ...
>
> Seems not so weird to me ?
What about making this new option only for the 'netns' subsystem?
Something like: 'ip netns -all exec'?
Regards,
Nicolas
^ permalink raw reply
* [PATCH 1/1] openvswitch: Remove unnecessary version.h inclusion
From: Syam Sidhardhan @ 2015-01-09 14:56 UTC (permalink / raw)
To: netdev, syamsidhardh, pshelar, davem, dev; +Cc: Syam Sidhardhan
version.h inclusion is not necessary as detected by versioncheck.
Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
---
net/openvswitch/vport-geneve.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/openvswitch/vport-geneve.c b/net/openvswitch/vport-geneve.c
index 347fa23..70e2aae 100644
--- a/net/openvswitch/vport-geneve.c
+++ b/net/openvswitch/vport-geneve.c
@@ -9,8 +9,6 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-#include <linux/version.h>
-
#include <linux/in.h>
#include <linux/ip.h>
#include <linux/net.h>
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] mdio-mux-gpio: use new gpiod_get_array and gpiod_put_array functions
From: Rojhalat Ibrahim @ 2015-01-09 15:19 UTC (permalink / raw)
To: linux-gpio@vger.kernel.org
Cc: Alexandre Courbot, Linus Walleij, David Miller, netdev
Use the new gpiod_get_array and gpiod_put_array functions for obtaining and
disposing of GPIO descriptors.
Signed-off-by: Rojhalat Ibrahim <imr@rtschenk.de>
---
This patch depends on my previous patch "gpiolib: add gpiod_get_array and
gpiod_put_array functions".
drivers/net/phy/mdio-mux-gpio.c | 28 ++++++++--------------------
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/drivers/net/phy/mdio-mux-gpio.c b/drivers/net/phy/mdio-mux-gpio.c
index 1eaf81e..35c37da 100644
--- a/drivers/net/phy/mdio-mux-gpio.c
+++ b/drivers/net/phy/mdio-mux-gpio.c
@@ -47,7 +47,6 @@ static int mdio_mux_gpio_probe(struct platform_device *pdev)
{
struct mdio_mux_gpio_state *s;
int num_gpios;
- unsigned int n;
int r;
if (!pdev->dev.of_node)
@@ -63,16 +62,10 @@ static int mdio_mux_gpio_probe(struct platform_device *pdev)
s->num_gpios = num_gpios;
- for (n = 0; n < num_gpios; ) {
- struct gpio_desc *gpio = gpiod_get_index(&pdev->dev, NULL, n,
- GPIOD_OUT_LOW);
- if (IS_ERR(gpio)) {
- r = PTR_ERR(gpio);
- goto err;
- }
- s->gpio[n] = gpio;
- n++;
- }
+ r = gpiod_get_array(&pdev->dev, NULL, s->gpio, num_gpios,
+ GPIOD_OUT_LOW);
+ if (r != num_gpios)
+ return r;
r = mdio_mux_init(&pdev->dev,
mdio_mux_gpio_switch_fn, &s->mux_handle, s);
@@ -80,22 +73,17 @@ static int mdio_mux_gpio_probe(struct platform_device *pdev)
if (r == 0) {
pdev->dev.platform_data = s;
return 0;
+ } else {
+ gpiod_put_array(s->gpio, num_gpios);
+ return r;
}
-err:
- while (n) {
- n--;
- gpiod_put(s->gpio[n]);
- }
- return r;
}
static int mdio_mux_gpio_remove(struct platform_device *pdev)
{
- unsigned int n;
struct mdio_mux_gpio_state *s = dev_get_platdata(&pdev->dev);
mdio_mux_uninit(s->mux_handle);
- for (n = 0; n < s->num_gpios; n++)
- gpiod_put(s->gpio[n]);
+ gpiod_put_array(s->gpio, s->num_gpios);
return 0;
}
--
2.0.5
^ permalink raw reply related
* [PATCH net-next v2 0/8]r8169:update hardware parameter
From: Chunhao Lin @ 2015-01-09 15:25 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
These series of patch include the pcie ephy parameter update of
following adapters.
rtl8411
rtl8168f
rtl8168evl
rtl8168dp
rtl8105
rtl8402
And include jumbo frame patch update of following adapters.
rtl8168dp
rtl8168e
rtl8168evl
Also remove unnecessary function rtl_hw_start_8168dp and add function
rtl_hw_start_8168f_2 to set rtl8168f rev.b pcie ephy parameters.
In v2 patch, give more explanation about pcie ephy parameter update.
Chunhao Lin (8):
r8169:change rtl8168dp jumbo frame patch
r8169:update rtl8168e and rtl8168evl jumbo frame patch
r8169:correct the way of setting rtl8168dp pcie ephy parameters
r8169:rtl8168dp rev.c pcie ephy setting is the same as rtl8168dp rev.b
r8169:update rtl8168dp pcie ephy parameters to improve power
consumption
r8169:update pcie ephy parameters to decrease the resume time from L0s
to L0
r8169:update rtl8402 pcie ephy parameter
r8169:update rtl8168f rev.b pcie ephy parameter
drivers/net/ethernet/realtek/r8169.c | 112 +++++++++++++++--------------------
1 file changed, 49 insertions(+), 63 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH net-next v2 1/8] r8169:change rtl8168dp jumbo frame patch
From: Chunhao Lin @ 2015-01-09 15:25 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
In-Reply-To: <1420817166-9868-1-git-send-email-hau@realtek.com>
RTL8168DP jumbo frame patch is the same as RTL8168C. So, for RTL8168DP,
change to use RTL8168C jumbo frame patch. Also reomve uncessary function
"r8168dp_hw_jumbo_enable" and "r8168dp_hw_jumbo_disable".
Signed-off-by: Chunhao Lin <hau@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 28 ++++++----------------------
1 file changed, 6 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 3a28059..72d15b8 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4927,20 +4927,6 @@ static void r8168c_hw_jumbo_disable(struct rtl8169_private *tp)
rtl_tx_performance_tweak(tp->pci_dev, 0x5 << MAX_READ_REQUEST_SHIFT);
}
-static void r8168dp_hw_jumbo_enable(struct rtl8169_private *tp)
-{
- void __iomem *ioaddr = tp->mmio_addr;
-
- RTL_W8(Config3, RTL_R8(Config3) | Jumbo_En0);
-}
-
-static void r8168dp_hw_jumbo_disable(struct rtl8169_private *tp)
-{
- void __iomem *ioaddr = tp->mmio_addr;
-
- RTL_W8(Config3, RTL_R8(Config3) & ~Jumbo_En0);
-}
-
static void r8168e_hw_jumbo_enable(struct rtl8169_private *tp)
{
void __iomem *ioaddr = tp->mmio_addr;
@@ -5014,16 +5000,13 @@ static void rtl_init_jumbo_ops(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_24:
case RTL_GIGA_MAC_VER_25:
case RTL_GIGA_MAC_VER_26:
- ops->disable = r8168c_hw_jumbo_disable;
- ops->enable = r8168c_hw_jumbo_enable;
- break;
case RTL_GIGA_MAC_VER_27:
case RTL_GIGA_MAC_VER_28:
- ops->disable = r8168dp_hw_jumbo_disable;
- ops->enable = r8168dp_hw_jumbo_enable;
+ case RTL_GIGA_MAC_VER_31:
+ ops->disable = r8168c_hw_jumbo_disable;
+ ops->enable = r8168c_hw_jumbo_enable;
break;
- case RTL_GIGA_MAC_VER_31: /* Wild guess. Needs info from Realtek. */
- case RTL_GIGA_MAC_VER_32:
+ case RTL_GIGA_MAC_VER_32: /* Wild guess. Needs info from Realtek. */
case RTL_GIGA_MAC_VER_33:
case RTL_GIGA_MAC_VER_34:
ops->disable = r8168e_hw_jumbo_disable;
@@ -5758,7 +5741,8 @@ static void rtl_hw_start_8168d_4(struct rtl8169_private *tp)
rtl_csi_access_enable_1(tp);
- rtl_tx_performance_tweak(pdev, 0x5 << MAX_READ_REQUEST_SHIFT);
+ if (tp->dev->mtu <= ETH_DATA_LEN)
+ rtl_tx_performance_tweak(pdev, 0x5 << MAX_READ_REQUEST_SHIFT);
RTL_W8(MaxTxPacketSize, TxPacketMax);
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v2 2/8] r8169:update rtl8168e and rtl8168evl jumbo frame patch
From: Chunhao Lin @ 2015-01-09 15:26 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
In-Reply-To: <1420817166-9868-1-git-send-email-hau@realtek.com>
RTL8168E and RTL8168EVL do not need to change pcie max read request size
when jumbo frame is enabled. So remove setting pcie max read request
size from their jumbo frame patch.
Signed-off-by: Chunhao Lin <hau@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 72d15b8..991bda5 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4934,7 +4934,6 @@ static void r8168e_hw_jumbo_enable(struct rtl8169_private *tp)
RTL_W8(MaxTxPacketSize, 0x3f);
RTL_W8(Config3, RTL_R8(Config3) | Jumbo_En0);
RTL_W8(Config4, RTL_R8(Config4) | 0x01);
- rtl_tx_performance_tweak(tp->pci_dev, 0x2 << MAX_READ_REQUEST_SHIFT);
}
static void r8168e_hw_jumbo_disable(struct rtl8169_private *tp)
@@ -4944,7 +4943,6 @@ static void r8168e_hw_jumbo_disable(struct rtl8169_private *tp)
RTL_W8(MaxTxPacketSize, 0x0c);
RTL_W8(Config3, RTL_R8(Config3) & ~Jumbo_En0);
RTL_W8(Config4, RTL_R8(Config4) & ~0x01);
- rtl_tx_performance_tweak(tp->pci_dev, 0x5 << MAX_READ_REQUEST_SHIFT);
}
static void r8168b_0_hw_jumbo_enable(struct rtl8169_private *tp)
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v2 3/8] r8169:correct the way of setting rtl8168dp pcie ephy parameters
From: Chunhao Lin @ 2015-01-09 15:26 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
In-Reply-To: <1420817166-9868-1-git-send-email-hau@realtek.com>
The original way is wrong, it always sets the ephy reg 0x03. Correct it
in this patch.
Signed-off-by: Chunhao Lin <hau@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 15 ++++-----------
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 991bda5..540a6b8 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -5731,11 +5731,10 @@ static void rtl_hw_start_8168d_4(struct rtl8169_private *tp)
void __iomem *ioaddr = tp->mmio_addr;
struct pci_dev *pdev = tp->pci_dev;
static const struct ephy_info e_info_8168d_4[] = {
- { 0x0b, ~0, 0x48 },
- { 0x19, 0x20, 0x50 },
- { 0x0c, ~0, 0x20 }
+ { 0x0b, 0x0000, 0x0048 },
+ { 0x19, 0x0020, 0x0050 },
+ { 0x0c, 0x0100, 0x0020 }
};
- int i;
rtl_csi_access_enable_1(tp);
@@ -5744,13 +5743,7 @@ static void rtl_hw_start_8168d_4(struct rtl8169_private *tp)
RTL_W8(MaxTxPacketSize, TxPacketMax);
- for (i = 0; i < ARRAY_SIZE(e_info_8168d_4); i++) {
- const struct ephy_info *e = e_info_8168d_4 + i;
- u16 w;
-
- w = rtl_ephy_read(tp, e->offset);
- rtl_ephy_write(tp, 0x03, (w & e->mask) | e->bits);
- }
+ rtl_ephy_init(tp, e_info_8168d_4, ARRAY_SIZE(e_info_8168d_4));
rtl_enable_clock_request(pdev);
}
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v2 5/8] r8169:update rtl8168dp pcie ephy parameters to improve power consumption
From: Chunhao Lin @ 2015-01-09 15:26 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
In-Reply-To: <1420817166-9868-1-git-send-email-hau@realtek.com>
The following parameter will disable more pcie ephy block (like pcie ephy
read/write clock.....etc ) to save more power when in aspm+clkreq mode.
{ 0x10, 0x0004, 0x0000 }
Signed-off-by: Chunhao Lin <hau@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 928e35a..ade7144 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -5718,7 +5718,8 @@ static void rtl_hw_start_8168d_4(struct rtl8169_private *tp)
static const struct ephy_info e_info_8168d_4[] = {
{ 0x0b, 0x0000, 0x0048 },
{ 0x19, 0x0020, 0x0050 },
- { 0x0c, 0x0100, 0x0020 }
+ { 0x0c, 0x0100, 0x0020 },
+ { 0x10, 0x0004, 0x0000 }
};
rtl_csi_access_enable_1(tp);
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v2 7/8] r8169:update rtl8402 pcie ephy parameter
From: Chunhao Lin @ 2015-01-09 15:26 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
In-Reply-To: <1420817166-9868-1-git-send-email-hau@realtek.com>
Remove following unnecessary ephy parameter.
{ 0x1e, 0, 0x4000 }
Signed-off-by: Chunhao Lin <hau@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 483fa40..aa12833 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -6431,8 +6431,7 @@ static void rtl_hw_start_8402(struct rtl8169_private *tp)
{
void __iomem *ioaddr = tp->mmio_addr;
static const struct ephy_info e_info_8402[] = {
- { 0x19, 0xffff, 0xff64 },
- { 0x1e, 0, 0x4000 }
+ { 0x19, 0xffff, 0xff64 }
};
rtl_csi_access_enable_2(tp);
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v2 8/8] r8169:update rtl8168f rev.b pcie ephy parameter
From: Chunhao Lin @ 2015-01-09 15:26 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
In-Reply-To: <1420817166-9868-1-git-send-email-hau@realtek.com>
RTL8168F rev.B does not have to set following two ephy parameters.
{ 0x06, 0x00c0, 0x0020 }
{ 0x08, 0x0001, 0x0002 }
Add function rtl_hw_start_8168f_2 to set RTL8168F rev.B ephy parameters,
instead of using function rtl_hw_start_8168f_1.
Signed-off-by: Chunhao Lin <hau@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index aa12833..0c870f5 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -5867,6 +5867,26 @@ static void rtl_hw_start_8168f_1(struct rtl8169_private *tp)
RTL_W8(EEE_LED, RTL_R8(EEE_LED) & ~0x07);
}
+static void rtl_hw_start_8168f_2(struct rtl8169_private *tp)
+{
+ void __iomem *ioaddr = tp->mmio_addr;
+ static const struct ephy_info e_info_8168f_2[] = {
+ { 0x09, 0x0000, 0x0080 },
+ { 0x19, 0x0000, 0x0224 },
+ { 0x00, 0x0000, 0x0008 },
+ { 0x0c, 0x3df0, 0x0200 }
+ };
+
+ rtl_hw_start_8168f(tp);
+
+ rtl_ephy_init(tp, e_info_8168f_2, ARRAY_SIZE(e_info_8168f_2));
+
+ rtl_w0w1_eri(tp, 0x0d4, ERIAR_MASK_0011, 0x0c00, 0xff00, ERIAR_EXGMAC);
+
+ /* Adjust EEE LED frequency */
+ RTL_W8(EEE_LED, RTL_R8(EEE_LED) & ~0x07);
+}
+
static void rtl_hw_start_8411(struct rtl8169_private *tp)
{
static const struct ephy_info e_info_8411[] = {
@@ -6276,9 +6296,11 @@ static void rtl_hw_start_8168(struct net_device *dev)
break;
case RTL_GIGA_MAC_VER_35:
- case RTL_GIGA_MAC_VER_36:
rtl_hw_start_8168f_1(tp);
break;
+ case RTL_GIGA_MAC_VER_36:
+ rtl_hw_start_8168f_2(tp);
+ break;
case RTL_GIGA_MAC_VER_38:
rtl_hw_start_8411(tp);
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v2 4/8] r8169:rtl8168dp rev.c pcie ephy setting is the same as rtl8168dp rev.b
From: Chunhao Lin @ 2015-01-09 15:26 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
In-Reply-To: <1420817166-9868-1-git-send-email-hau@realtek.com>
Thease two chips should use the same pcie ephy parameters. So only need
function rtl_hw_start_8168d_4. Function rtl_hw_start_8168dp is uncessary.
Signed-off-by: Chunhao Lin <hau@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 20 +-------------------
1 file changed, 1 insertion(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 540a6b8..928e35a 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -5711,21 +5711,6 @@ static void rtl_hw_start_8168d(struct rtl8169_private *tp)
RTL_W16(CPlusCmd, RTL_R16(CPlusCmd) & ~R8168_CPCMD_QUIRK_MASK);
}
-static void rtl_hw_start_8168dp(struct rtl8169_private *tp)
-{
- void __iomem *ioaddr = tp->mmio_addr;
- struct pci_dev *pdev = tp->pci_dev;
-
- rtl_csi_access_enable_1(tp);
-
- if (tp->dev->mtu <= ETH_DATA_LEN)
- rtl_tx_performance_tweak(pdev, 0x5 << MAX_READ_REQUEST_SHIFT);
-
- RTL_W8(MaxTxPacketSize, TxPacketMax);
-
- rtl_disable_clock_request(pdev);
-}
-
static void rtl_hw_start_8168d_4(struct rtl8169_private *tp)
{
void __iomem *ioaddr = tp->mmio_addr;
@@ -6271,11 +6256,8 @@ static void rtl_hw_start_8168(struct net_device *dev)
break;
case RTL_GIGA_MAC_VER_28:
- rtl_hw_start_8168d_4(tp);
- break;
-
case RTL_GIGA_MAC_VER_31:
- rtl_hw_start_8168dp(tp);
+ rtl_hw_start_8168d_4(tp);
break;
case RTL_GIGA_MAC_VER_32:
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v2 6/8] r8169:update pcie ephy parameters to decrease the resume time from L0s to L0
From: Chunhao Lin @ 2015-01-09 15:26 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
In-Reply-To: <1420817166-9868-1-git-send-email-hau@realtek.com>
For RTL8168EVL, RTL8168F, RTL8411, and RTL8105E, their pcie ephy will have bit
error check reset after receive FTS and cause pcie ephy enter recovery mode.
This will cause pcie ephy resume from L0s to L0 too slow.
This patch adjust the pcie ephy parameter to decrease the resume time from L0s
to L0.
Signed-off-by: Chunhao Lin <hau@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index ade7144..483fa40 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -5778,7 +5778,9 @@ static void rtl_hw_start_8168e_2(struct rtl8169_private *tp)
struct pci_dev *pdev = tp->pci_dev;
static const struct ephy_info e_info_8168e_2[] = {
{ 0x09, 0x0000, 0x0080 },
- { 0x19, 0x0000, 0x0224 }
+ { 0x19, 0x0000, 0x0224 },
+ { 0x00, 0x0000, 0x0008 },
+ { 0x0c, 0x3df0, 0x0200 }
};
rtl_csi_access_enable_1(tp);
@@ -5850,7 +5852,9 @@ static void rtl_hw_start_8168f_1(struct rtl8169_private *tp)
{ 0x06, 0x00c0, 0x0020 },
{ 0x08, 0x0001, 0x0002 },
{ 0x09, 0x0000, 0x0080 },
- { 0x19, 0x0000, 0x0224 }
+ { 0x19, 0x0000, 0x0224 },
+ { 0x00, 0x0000, 0x0008 },
+ { 0x0c, 0x3df0, 0x0200 }
};
rtl_hw_start_8168f(tp);
@@ -5865,17 +5869,19 @@ static void rtl_hw_start_8168f_1(struct rtl8169_private *tp)
static void rtl_hw_start_8411(struct rtl8169_private *tp)
{
- static const struct ephy_info e_info_8168f_1[] = {
+ static const struct ephy_info e_info_8411[] = {
{ 0x06, 0x00c0, 0x0020 },
{ 0x0f, 0xffff, 0x5200 },
{ 0x1e, 0x0000, 0x4000 },
- { 0x19, 0x0000, 0x0224 }
+ { 0x19, 0x0000, 0x0224 },
+ { 0x00, 0x0000, 0x0008 },
+ { 0x0c, 0x3df0, 0x0200 }
};
rtl_hw_start_8168f(tp);
rtl_pcie_state_l2l3_enable(tp, false);
- rtl_ephy_init(tp, e_info_8168f_1, ARRAY_SIZE(e_info_8168f_1));
+ rtl_ephy_init(tp, e_info_8411, ARRAY_SIZE(e_info_8411));
rtl_w0w1_eri(tp, 0x0d4, ERIAR_MASK_0011, 0x0c00, 0x0000, ERIAR_EXGMAC);
}
@@ -6397,7 +6403,8 @@ static void rtl_hw_start_8105e_1(struct rtl8169_private *tp)
{ 0x03, 0, 0x0001 },
{ 0x19, 0, 0x0100 },
{ 0x19, 0, 0x0004 },
- { 0x0a, 0, 0x0020 }
+ { 0x0a, 0, 0x0020 },
+ { 0x05, 0, 0x2000 }
};
/* Force LAN exit from ASPM if Rx/Tx are not idle */
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net-next v2 1/8] r8169:change rtl8168dp jumbo frame patch
From: Sergei Shtylyov @ 2015-01-09 15:41 UTC (permalink / raw)
To: Chunhao Lin, netdev; +Cc: nic_swsd, linux-kernel
In-Reply-To: <1420817166-9868-2-git-send-email-hau@realtek.com>
Hello.
On 1/9/2015 6:25 PM, Chunhao Lin wrote:
> RTL8168DP jumbo frame patch is the same as RTL8168C. So, for RTL8168DP,
> change to use RTL8168C jumbo frame patch. Also reomve uncessary function
s/reomve uncessary/remove unnecessary/.
> "r8168dp_hw_jumbo_enable" and "r8168dp_hw_jumbo_disable".
>
> Signed-off-by: Chunhao Lin <hau@realtek.com>
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] net: unisys: adding unisys virtnic driver
From: Jes Sorensen @ 2015-01-09 15:44 UTC (permalink / raw)
To: Erik Arfvidson
Cc: benjamin.romer, netdev, dzickus, davem, Bruce.Vessey,
sparmaintainer, prarit, Neil Horman
In-Reply-To: <1418842340-29894-1-git-send-email-earfvids@redhat.com>
Erik Arfvidson <earfvids@redhat.com> writes:
> The purpose of this patch is to add Unisys virtual network driver
> into the network directory and also to start a discussion about
> the requirements needed.
>
> Signed-off-by: Erik Arfvidson <earfvids@redhat.com>
Erik,
I was discussing this with colleagues and I want to give you some
general comments on this. My comments are not specific to virtnic.c
itself.
Looking over the logs of drivers/staging/unisys, I noticed a fair amount
of cleanups has been applied, but not a lot of fixes addressing what I
would consider the real issues.
The first thing you should work on is to get rid of
drivers/staging/unisys/uislib - it looks to provide a lot of wrappers
and utility functions which already exist. You need to address things
like:
- Custom atomic primitives (uisqueue.c)
- List handlers (use list.h) and all the utility functions we provide
- Functions for launching killing kernel threads (uisthread)
- There is most of a bus implementation in there - is this really
needed, ie. are the devices sitting on a PCI bus, or is this some
special bus type?
- Use proper data types - your code should contain no 'long long' ever!
If you need data types of a specific size, use u8/u16/u32/u64, and
please get rid of broken Windows stuff such as BOOL and #pragma.
- /proc handlers - you should most likely be using /sys
(configs/debugfs) and don't wrap things in libraries, do it near the
code using it.
Basically I recommend you start working your way through uislib, and
once you have eliminated 90% of it, you should be a lot closer to code
that can go into mainline.
I know my colleague Neil has some issues on this specific driver, which
I have less insight into, so I think he'll post some comments on that
too.
I hope this is helpful!
Cheers,
Jes
^ permalink raw reply
* Re: NULL pointer dereference at skb_queue_tail()
From: Eric Dumazet @ 2015-01-09 15:45 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: cwang, netdev
In-Reply-To: <201501092220.DIB43754.FFMQOSJLOOHVtF@I-love.SAKURA.ne.jp>
On Fri, 2015-01-09 at 22:20 +0900, Tetsuo Handa wrote:
> Would you tell me which versions to test?
Could you do a bisection ?
I do not see obvious bugs in af_unix.c, so it might be a corruption from
another part of the code, reusing a freed skb.
^ permalink raw reply
* Re: [PATCH net] ipv6: Prevent ipv6_find_hdr() from returning ENOENT for valid non-first fragments
From: Hannes Frederic Sowa @ 2015-01-09 15:50 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: Rahul Sharma, netdev, linux-kernel, netfilter-devel
In-Reply-To: <20150109114506.GA4857@salvia>
On Fr, 2015-01-09 at 12:45 +0100, Pablo Neira Ayuso wrote:
> Hi Hannes,
>
> On Fri, Jan 09, 2015 at 12:34:15PM +0100, Hannes Frederic Sowa wrote:
> > On Fri, Jan 9, 2015, at 08:18, Rahul Sharma wrote:
> > > Hi Pablo,
> > >
> > > On Fri, Jan 9, 2015 at 5:35 AM, Pablo Neira Ayuso <pablo@netfilter.org>
> > > wrote:
> > > > On Thu, Jan 08, 2015 at 11:39:16PM +0100, Hannes Frederic Sowa wrote:
> > > >> Hi Pablo,
> > > >>
> > > >> On Thu, Jan 8, 2015, at 21:53, Pablo Neira Ayuso wrote:
> > > >> > I'm afraid we cannot just get rid of that !ipv6_ext_hdr() check. The
> > > >> > ipv6_find_hdr() function is designed to return the transport protocol.
> > > >> > After the proposed change, it will return extension header numbers.
> > > >> > This will break existing ip6tables rulesets since the `-p' option
> > > >> > relies on this function to match the transport protocol.
> > > >> >
> > > >> > Note that the AH header is skipped (see code a bit below this
> > > >> > problematic fragmentation handling) so the follow up header after the
> > > >> > AH header is returned as the transport header.
> > > >> >
> > > >> > We can probably return the AH protocol number for non-1st fragments.
> > > >> > However, that would be something new to ip6tables since nobody has
> > > >> > ever seen packet matching `-p ah' rules. Thus, we restore control to
> > > >> > the user to allow this, but we would accept all kind of fragmented AH
> > > >> > traffic through the firewall since we cannot know what transport
> > > >> > protocol contains from non-1st fragments (unless I'm missing anything,
> > > >> > I need to have a closer look at this again tomorrow with fresher
> > > >> > mind).
> > > >>
> > > >> The code in question is guarded by (_frag_off != 0), so we are
> > > >> definitely processing a non-1st fragment currently. The -p match would
> > > >> happen at the time when the packet is reassembled and thus ipv6_find_hdr
> > > >> will find the real transport (final) header at this point (I hope I
> > > >> followed the code correctly here).
> > > >
> > > > Then, Rahul should get things working by modprobing nf_defrag_ipv6.
> > >
> > > I already had nf_defrag_ipv6 installed when the issue occured. But I
> > > see ip6table_raw_hook returning NF_DROP for the second fragment.
> >
> > That's what I expected. I think the change only affects hooks before
> > reassembly.
>
> reassembly happens at NF_IP6_PRI_CONNTRACK_DEFRAG (-400), so that
> happens before NF_IP6_PRI_RAW (-300) in IPv6 which is where the raw
> table is placed.
I tried to reproduce it, but couldn't get non-1st fragments getting
dropped during traversal of the raw table. They get dropped earlier at
during reassembly or pass.
I agree with Pablo, I also would like to see more data.
Thanks,
Hannes
^ permalink raw reply
* [PATCH 1/1] csiostor:fix sparse warnings
From: Praveen Madhavan @ 2015-01-09 15:55 UTC (permalink / raw)
To: netdev, linux-scsi; +Cc: davem, JBottomley, hch, hariprasad, praveenm
This patch fixes sparse warning reported by kbuild.
Apply this on net-next since it depends on previous commit.
drivers/scsi/csiostor/csio_hw.c:259:17: sparse: cast to restricted __le32
drivers/scsi/csiostor/csio_hw.c:536:31: sparse: incorrect type in assignment
(different base types)
drivers/scsi/csiostor/csio_hw.c:536:31: expected unsigned int [unsigned]
[usertype] <noident>
drivers/scsi/csiostor/csio_hw.c:536:31: got restricted __be32 [usertype]
<noident>
>> drivers/scsi/csiostor/csio_hw.c:2012:5: sparse: symbol 'csio_hw_prep_fw' was
not declared. Should it be static?
Signed-off-by: Praveen Madhavan <praveenm@chelsio.com>
---
drivers/scsi/csiostor/csio_hw.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/csiostor/csio_hw.c b/drivers/scsi/csiostor/csio_hw.c
index b70c15f..5c31fa6 100644
--- a/drivers/scsi/csiostor/csio_hw.c
+++ b/drivers/scsi/csiostor/csio_hw.c
@@ -256,7 +256,7 @@ csio_hw_seeprom_read(struct csio_hw *hw, uint32_t addr, uint32_t *data)
}
pci_read_config_dword(hw->pdev, base + PCI_VPD_DATA, data);
- *data = le32_to_cpu(*data);
+ *data = le32_to_cpu(*(__le32 *)data);
return 0;
}
@@ -533,7 +533,7 @@ csio_hw_read_flash(struct csio_hw *hw, uint32_t addr, uint32_t nwords,
if (ret)
return ret;
if (byte_oriented)
- *data = htonl(*data);
+ *data = (__force __u32) htonl(*data);
}
return 0;
}
@@ -2009,7 +2009,7 @@ static struct fw_info *find_fw_info(int chip)
return NULL;
}
-int csio_hw_prep_fw(struct csio_hw *hw, struct fw_info *fw_info,
+static int csio_hw_prep_fw(struct csio_hw *hw, struct fw_info *fw_info,
const u8 *fw_data, unsigned int fw_size,
struct fw_hdr *card_fw, enum csio_dev_state state,
int *reset)
--
2.0.2
^ permalink raw reply related
* Re: [PATCH v2 1/3] dtb: xgene: fix: Backward compatibility with older firmware
From: Ian Campbell @ 2015-01-09 15:59 UTC (permalink / raw)
To: Iyappan Subramanian
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
patches-qTEPVZfXA3Y, kchudgar-qTEPVZfXA3Y
In-Reply-To: <1415044796-5081-2-git-send-email-isubramanian-qTEPVZfXA3Y@public.gmane.org>
Hi Iyappan,
On Mon, 2014-11-03 at 11:59 -0800, Iyappan Subramanian wrote:
> The following kernel crash was reported when using older firmware (<= 1.13.28).
>
> [ 0.980000] libphy: APM X-Gene MDIO bus: probed
> [ 1.130000] Unhandled fault: synchronous external abort (0x96000010) at 0xffffff800009a17c
> [ 1.140000] Internal error: : 96000010 [#1] SMP
> [ 1.140000] Modules linked in:
> [ 1.140000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.17.0+ #21
> [ 1.140000] task: ffffffc3f0110000 ti: ffffffc3f0064000 task.ti: ffffffc3f0064000
> [ 1.140000] PC is at ioread32+0x58/0x68
> [ 1.140000] LR is at xgene_enet_setup_ring+0x18c/0x1cc
I'm seeing what appears to be a similar crash (see the end) when booting
using UEFI firmware, which provides the DTB itself (as opposed to using
the kernel provided one like with u-boot).
Trying to boot using the kernel DTB instead of the firmware provided one
fails, I think because the UEFI firmware normally updates a bunch of
stuff at runtime in what it provides, but it can't in the external one.
(i.e. it has the wrong spintable stuff for cpu bringup)
This is running Debian's 3.16 kernel, which has the APM Ethernet related
stuff backported:
$ git log --oneline v3.16.7..debian/jessie/xgene
b2553d6 arm64: removed using of the mask attribute in the dts for reset bit.
2d209a4 arm64: add missing dts entry for X-Gene platform.
60651f8 dtb: Add SGMII based 1GbE node to APM X-Gene SoC device tree
3f3c3da dtb: Add 10GbE node to APM X-Gene SoC device tree
33b5408 drivers: net: xgene: fix: Use separate resources
092e35e drivers: net: xgene: Backward compatibility with older firmware
9f2bc2c drivers: net: xgene: Rewrite buggy loop in xgene_enet_ecc_init()
c566829 drivers: net: xgene: Add SGMII based 1GbE ethtool support
30bf224 drivers: net: xgene: Add SGMII based 1GbE support
0d03931 drivers: net: xgene: Preparing for adding SGMII based 1GbE
23a92cd drivers: net: xgene: Add 10GbE ethtool support
226068a drivers: net: xgene: Add 10GbE support
33f8dba drivers: net: xgene: Preparing for adding 10GbE support
a7b5fd0 dts: Add bindings for APM X-Gene SoC ethernet driver
82df3ba drivers: net: NET_XGENE should depend on HAS_DMA
0dcba55 net: xgene: fix possible NULL dereference in xgene_enet_free_desc_rings()
2aa3e0d net: xgene: Check negative return value of xgene_enet_get_ring_size()
589e045 drivers: net: Add APM X-Gene SoC ethernet driver support.
With the builtin DTB I see:
(initramfs) od -A x -t x4 /proc/device-tree/soc/ethernet@17020000/reg
000000 00000000 00000217 00000000 00d10000
000010 00000000 00000317 00000000 00040000
000020 00000000 00000010 00000000 00020000
Which seems to correspond to before your patch.
I'm running mustang_sw_1.13.29-beta, using the mustang_tianocore_ubt.fd
method to launch from u-boot.
Ian.
[ 7.662085] Unhandled fault: synchronous external abort (0x96000010) at 0xffffff800009a208
[ 7.670332] Internal error: : 96000010 [#1] SMP
[ 7.674839] Modules linked in: xgene_enet(+) of_mdio libphy dm_mod(+)
[ 7.681300] CPU: 0 PID: 97 Comm: systemd-udevd Not tainted 3.16.0-4-arm64 #1 Debian 3.16.7-ckt2-1
[ 7.690126] task: ffffffc3f9ca0c80 ti: ffffffc3f9d2c000 task.ti: ffffffc3f9d2c000
[ 7.697571] PC is at ioread32+0x58/0x68
[ 7.701388] LR is at xgene_ring_mgr_init+0x28/0x58 [xgene_enet]
[ 7.707276] pc : [<ffffffc0002e5318>] lr : [<ffffffbffc035d18>] pstate: a0000145
[ 7.714632] sp : ffffffc3f9d2f9c0
[ 7.717926] x29: ffffffc3f9d2f9c0 x28: 0000000000000001
[ 7.723229] x27: ffffffc0006fa000 x26: 0000000000000000
[ 7.728533] x25: ffffffc3f9ce9000 x24: ffffffc3f9ce9000
[ 7.733836] x23: ffffffc3eb876010 x22: ffffffc3eb876000
[ 7.739138] x21: ffffffc000763000 x20: ffffffc3f9ce98c0
[ 7.744443] x19: ffffffc3f9ce98c0 x18: 00000000c3663f63
[ 7.749745] x17: 00000000c14123be x16: 00000000ca92bd38
[ 7.755048] x15: 00000000d02a0bde x14: 0000000000000000
[ 7.760350] x13: 0000000000000000 x12: 0000000000000000
[ 7.765652] x11: 0000000000000000 x10: 0000000000000000
[ 7.770955] x9 : 0000000000000000 x8 : 0000000000000000
[ 7.776257] x7 : 0000000000000000 x6 : 0000000000000000
[ 7.781559] x5 : ffffffc00074b310 x4 : 0000000000000000
[ 7.786861] x3 : 0000000000000000 x2 : 000000000003ffff
[ 7.792165] x1 : ffffff800009a208 x0 : ffffff800009a208
[ 7.797467]
[ 7.798948] Process systemd-udevd (pid: 97, stack limit = 0xffffffc3f9d2c058)
[ 7.806046] Stack: (0xffffffc3f9d2f9c0 to 0xffffffc3f9d30000)
[ 7.811762] f9c0: f9d2f9d0 ffffffc3 fc035d18 ffffffbf f9d2f9f0 ffffffc3 fc035d6c ffffffbf
[ 7.819897] f9e0: f9ce98c0 ffffffc3 f9d2f9e0 ffffffc3 f9d2fa30 ffffffc3 fc038110 ffffffbf
[ 7.828032] fa00: f9ce98c0 ffffffc3 f9ce9000 ffffffc3 00763000 ffffffc0 f9ce9000 ffffffc3
[ 7.836167] fa20: 0000005c 00000000 00000000 00000000 f9d2fa80 ffffffc3 00343d24 ffffffc0
[ 7.844302] fa40: eb876010 ffffffc3 fc039f38 ffffffbf 0075d000 ffffffc0 00000000 00000000
[ 7.852436] fa60: fc039f60 ffffffbf 00000000 00000000 00000001 00000000 00000000 00000000
[ 7.860571] fa80: f9d2faa0 ffffffc3 00341ad0 ffffffc0 eb876010 ffffffc3 007cb000 ffffffc0
[ 7.868706] faa0: f9d2faf0 ffffffc3 00341edc ffffffc0 eb876010 ffffffc3 fc039f60 ffffffbf
[ 7.876840] fac0: eb876070 ffffffc3 00000000 00000000 0073d000 ffffffc0 00000000 00000000
[ 7.884974] fae0: fec449c0 ffffffc0 0033fa04 ffffffc0 f9d2fb20 ffffffc3 0033f9f8 ffffffc0
[ 7.893109] fb00: 00000000 00000000 fc039f60 ffffffbf 00341e30 ffffffc0 00000000 00000000
[ 7.901244] fb20: f9d2fb70 ffffffc3 003414f8 ffffffc0 fc039f60 ffffffbf f9c5d100 ffffffc3
[ 7.909378] fb40: 0073dd40 ffffffc0 ffffffe0 00000000 f9d2fb70 ffffffc3 00000000 00000000
[ 7.917512] fb60: eba48aa8 ffffffc3 ff4328e8 ffffffc3 f9d2fb90 ffffffc3 003410b4 ffffffc0
[ 7.925647] fb80: fc039f60 ffffffbf fc039f60 ffffffbf f9d2fbd0 ffffffc3 0034276c ffffffc0
[ 7.933781] fba0: fc039f60 ffffffbf fec4df00 ffffffc0 00000000 00000000 fc03d000 ffffffbf
[ 7.941916] fbc0: f9d2c000 ffffffc3 0073dd40 ffffffc0 f9d2fc00 ffffffc3 00343cec ffffffc0
[ 7.950050] fbe0: fc039f38 ffffffbf fec4df00 ffffffc0 006e07a0 ffffffc0 f9d2fc40 ffffffc3
[ 7.958185] fc00: f9d2fc30 ffffffc3 fc03d01c ffffffbf 006e07a0 ffffffc0 00081490 ffffffc0
[ 7.966319] fc20: 006e07a0 ffffffc0 fc03a240 ffffffbf f9d2fc40 ffffffc3 000814a0 ffffffc0
[ 7.974453] fc40: f9d2fcc0 ffffffc3 00109f30 ffffffc0 f9d2fe70 ffffffc3 00000001 00000000
[ 7.982588] fc60: fc03a258 ffffffbf f9d2c000 ffffffc3 fc03a290 ffffffbf fc03a240 ffffffbf
[ 7.990723] fc80: 0007d000 ffffff80 00000001 00000000 fc03a258 ffffffbf f9d2c000 ffffffc3
[ 7.998857] fca0: f9d2fcc0 ffffffc3 00109efc ffffffc0 f9d2fe70 ffffffc3 0010a264 ffffffc0
[ 8.006992] fcc0: f9d2fe40 ffffffc3 0010a8d8 ffffffc0 00000000 00000000 00000009 00000000
[ 8.015126] fce0: 94b29108 0000007f 94c78ee4 0000007f 60000000 00000000 00000015 00000000
[ 8.023261] fd00: 00000118 00000000 00000111 00000000 006e4000 ffffffc0 f9d2c000 ffffffc3
[ 8.031395] fd20: ff588500 ffffffc3 00106ad8 ffffffc0 fec449d0 ffffffc0 00000072 00000000
[ 8.039530] fd40: 0000006e 00000000 005e7140 ffffffc0 0000003f 00000000 0000feff 00000000
[ 8.047664] fd60: 0000fff1 00000000 0000001b 00000000 f9d2fde0 ffffffc3 0075a648 ffffffc0
[ 8.055799] fd80: 0075a3c8 ffffffc0 fc03d028 ffffffbf f9d2fec4 ffffffc3 000000f1 ffffff80
[ 8.063933] fda0: f9d2fe80 ffffffc3 94b29108 0000007f 006fa5b0 ffffffc0 007641a0 ffffffc0
[ 8.072068] fdc0: 60000000 00000000 00000015 00000000 00000010 00000000 0000138c 00000000
[ 8.080203] fde0: 00000001 ffff81a4 00000001 00000000 00000000 00000000 00000000 00000000
[ 8.088337] fe00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 8.096471] fe20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 8.104605] fe40: fb748da0 0000007f 0008421c ffffffc0 00000000 00000000 00000000 00000000
[ 8.112740] fe60: ffffffff ffffffff 00000009 00000000 0007d000 ffffff80 0000e3b8 00000000
[ 8.120874] fe80: 0008acb8 ffffff80 00083c8e ffffff80 00085428 ffffff80 00005478 00000000
[ 8.129009] fea0: 00005c40 00000000 fc03a178 ffffffbf 00000005 00000000 0000001a 0000001b
[ 8.137143] fec0: 00000012 0000000d 0000000c 00000000 00000009 00000000 94b29108 0000007f
[ 8.145278] fee0: 00000000 00000000 00000009 00000000 00000000 00000000 00000041 00000000
[ 8.153412] ff00: 00000001 00000000 00000001 00000000 00000111 00000000 6dff7364 644d3965
[ 8.161547] ff20: 00000000 00000000 0000000a 00000000 00000004 00000000 00000004 00000000
[ 8.169681] ff40: 67782f65 2d656e65 94cfa588 0000007f 94b3b290 0000007f 94c78ec0 0000007f
[ 8.177816] ff60: fb748b00 0000007f 74bd9070 00000055 00000000 00000000 94b29108 0000007f
[ 8.185950] ff80: 00020000 00000000 fb7493c8 0000007f 74bd9200 00000055 74be13e0 00000055
[ 8.194084] ffa0: 00000000 00000000 00000000 00000000 00020000 00000000 fb748da0 0000007f
[ 8.202219] ffc0: 94b22d44 0000007f fb748da0 0000007f 94c78ee4 0000007f 60000000 00000000
[ 8.210353] ffe0: 00000009 00000000 00000111 00000000 00000000 00000000 00000000 00000000
[ 8.218487] Call trace:
[ 8.220920] [<ffffffc0002e5318>] ioread32+0x58/0x68
[ 8.225773] [<ffffffbffc035d14>] xgene_ring_mgr_init+0x24/0x58 [xgene_enet]
[ 8.232699] [<ffffffbffc035d68>] xgene_enet_reset+0x20/0x17c [xgene_enet]
[ 8.239452] [<ffffffbffc03810c>] xgene_enet_probe+0x2c4/0x784 [xgene_enet]
[ 8.246292] [<ffffffc000343d20>] platform_drv_probe+0x28/0x60
[ 8.252008] [<ffffffc000341acc>] driver_probe_device+0xa4/0x3ac
[ 8.257896] [<ffffffc000341ed8>] __driver_attach+0xa8/0xb0
[ 8.263352] [<ffffffc00033f9f4>] bus_for_each_dev+0x68/0xac
[ 8.268895] [<ffffffc0003414f4>] driver_attach+0x2c/0x38
[ 8.274177] [<ffffffc0003410b0>] bus_add_driver+0x16c/0x248
[ 8.279720] [<ffffffc000342768>] driver_register+0x6c/0x138
[ 8.285262] [<ffffffc000343ce8>] __platform_driver_register+0x74/0x84
[ 8.291670] [<ffffffbffc03d018>] $x+0x18/0x24 [xgene_enet]
[ 8.297127] [<ffffffc00008149c>] do_one_initcall+0xcc/0x1bc
[ 8.302671] [<ffffffc000109f2c>] load_module+0x1a20/0x220c
[ 8.308127] [<ffffffc00010a8d4>] SyS_finit_module+0x94/0xc0
[ 8.313670] Code: 97ffffa5 12800000 a8c17bfd d65f03c0 (b9400000)
[ 8.319746] ---[ end trace f59ed15aa4f2049f ]---
--
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
* [PATCH] net: unisys: adding unisys virtnic driver
From: Neil Horman @ 2015-01-09 16:13 UTC (permalink / raw)
To: earfvids; +Cc: netdev
In-Reply-To: <1418842340-29894-1-git-send-email-earfvids@redhat.com>
>The purpose of this patch is to add Unisys virtual network driver
>into the network directory and also to start a discussion about
>the requirements needed.
>
>Signed-off-by: Erik Arfvidson <earfvids@redhat.com>
>---
> drivers/net/virtnic.c | 2475 +++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 2475 insertions(+)
> create mode 100644 drivers/net/virtnic.c
><driver mostly snipped>
>+
>+/*****************************************************/
>+/* Module init & exit functions */
>+/*****************************************************/
>+
>+static int __init
>+virtnic_mod_init(void)
>+{
>+ int error, i;
>+
>+ LOGINF("entering virtnic_mod_init");
>+ /* ASSERT RCVPOST_BUF_SIZE < 4K */
>+ if (RCVPOST_BUF_SIZE > PI_PAGE_SIZE) {
>+ LOGERR("**** FAILED RCVPOST_BUF_SIZE:%d larger than a page\n",
>+ RCVPOST_BUF_SIZE);
>+ return -1;
>+ }
>+ /* ASSERT RCVPOST_BUF_SIZE is big enough to hold eth header */
>+ if (RCVPOST_BUF_SIZE < ETH_HEADER_SIZE) {
>+ LOGERR("**** FAILED RCVPOST_BUF_SIZE:%d is <
ETH_HEADER_SIZE:%d\n",
>+ RCVPOST_BUF_SIZE, ETH_HEADER_SIZE);
>+ return -1;
>+ }
>+
>+ /* clear out array */
>+ for (i = 0; i < VIRTNICSOPENMAX; i++) {
>+ num_virtnic_open[i].netdev = NULL;
>+ num_virtnic_open[i].vnicinfo = NULL;
>+ }
>+ /* create workqueue for serverdown completion */
>+ virtnic_serverdown_workqueue =
>+ create_singlethread_workqueue("virtnic_serverdown");
>+ if (virtnic_serverdown_workqueue == NULL) {
>+ LOGERR("**** FAILED virtnic_serverdown_workqueue creation\n");
>+ return -1;
>+ }
>+ /* create workqueue for tx timeout reset */
>+ virtnic_timeout_reset_workqueue =
>+ create_singlethread_workqueue("virtnic_timeout_reset");
>+ if (virtnic_timeout_reset_workqueue == NULL) {
>+ LOGERR
>+ ("**** FAILED virtnic_timeout_reset_workqueue creation\n");
>+ return -1;
>+ }
>+ virtnic_debugfs_dir = debugfs_create_dir("virtnic", NULL);
>+ debugfs_create_file("info", S_IRUSR, virtnic_debugfs_dir,
>+ NULL, &debugfs_info_fops);
>+ debugfs_create_file("enable_ints", S_IWUSR,
>+ virtnic_debugfs_dir, NULL,
>+ &debugfs_enable_ints_fops);
>+
>+ error = virtpci_register_driver(&virtnic_driver);
>+ if (error < 0) {
So, I've been trying to puzzle out what the architecture of this driver is.
>From what I've been able to gather:
1) The device this driver interfaces too is not a real device, but rather some
multipurpose chip that can expose network functions as well as several other
devices.
2) It's (the hardware's) device exposure is driven by some sideband interface
outside of the purview of the operating system
3) The virtpci driver that you have in the staging tree is responsible for
interfacing the root pci bridge to your hardware so that it (again your
hardware) can act like a pci bus to interface to these administratively plumbed
devices.
4) The net devices that this driver registers are typically meant (though not
required) to be used by guests via pci passthrough.
Is that all about correct? Just trying to get a handle on what all is going on
here.
Operating under the assumption that the above is correct (please correct me if
I'm wrong), I've got a few comments.
A) This isn't going to be accepted until the bus driver that provides access to
the pci interface for this hardware is merged. Without that bit, this driver
can't do anything.
B) Looking at the virtpci driver, it neds alot of cleanup before it has a hope
of going in. On the upside though, I think most of the code that needs cleaning
up, really just needs removal. 90% of that file in staging isn't called by
anything that I can tell. Thats not completely accrurate, in that you seem to
have a side band input path via virtpci_ctrlchan_func, which gets called from
the uisctrl library that appears to be used to create and manage devices, but it
all deadends there. See uislib_client_inject_add_vhba or
uislib_client_inject_add_vnic for examples. So I don't see a whole lot of need
for (at least not yet). I presume that, if this stuff works, theres some other
method of plumbing devices on the hardware asside from the uislib in staging.
As such, you can remove it for now. If thats not the case, then you have much
bigger problems, as I'm not sure how any of this works at all, since I don't see
a path for plumbing devices.
C) This isn't really a virtio driver, in the sense that virtio_net or veth is,
its more of an SRIOV device by another name, in that it drives real hardware, or
at least a virtual function on a real pci device.
I think, if you want to get it accepted, the fastest road forward would be to do
the following:
1) Gut virtpci.c. Remove anything non-functional from it. That would separate
you from your uislib, and make virtpci both fairly standalone and reasonably
small. That (I think) should make virtpci more amenable to mainline acceptance
if you repost it (I'll have to let the linux-pci list review that
more closely however). If thats accepted it should allow the pci core to
properly probe devices belonging to the above virtnic driver
2) rework virtnic to register with the pci core, not the redundant
virtpci_driver_register api. There should be no need for that. That will make
this a full fledged pci driver, which will be nice. Perhaps also rename it
(unisys_vfnic or something more indicative of its nature, so as to separate it
from the virtio family of devices. There may be other cleanups to do in the
driver as well (I've not looked at it in depth yet)
That should put you in a position where you have a functioning nic driver for
your hardware that you can either pass to a guest via pci passthrough, or use as
backing for a virtio_nic or veth device. It will be much more lean, and
maintainable, and from there you can start adding management bits back in.
Regards
Neil
^ permalink raw reply
* RE: Clarification regarding IFLA_BRPORT_LEARNING_SYNC and aging of fdb entries learnt via br_fdb_external_learn_add()
From: Arad, Ronen @ 2015-01-09 16:15 UTC (permalink / raw)
To: Scott Feldman, Jiri Pirko; +Cc: Siva Mannem, Netdev
In-Reply-To: <CAE4R7bBRboCfhRKFKgVVAGt1f-m6wkXNfaej4RjuaCKPypABeA@mail.gmail.com>
>-----Original Message-----
>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
>Behalf Of Scott Feldman
>Sent: Friday, January 09, 2015 3:47 AM
>To: Jiri Pirko
>Cc: Siva Mannem; Netdev
>Subject: Re: Clarification regarding IFLA_BRPORT_LEARNING_SYNC and aging of
>fdb entries learnt via br_fdb_external_learn_add()
>
>On Wed, Jan 7, 2015 at 4:53 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>> Tue, Dec 30, 2014 at 07:20:21PM CET, siva.mannem.lnx@gmail.com wrote:
>>>Hi,
>>>
>>>I am trying to understand the ongoing switch device offload effort and
>>>am following the discussions. I have a question regarding
>>>IFLA_BRPORT_LEARNING_SYNC flag and how aging happens when this flag is
>>>enabled on a port that is attached to a bridge that has vlan filtering
>>>enabled.
>>>
>>>If I understand correctly, when IFLA_BRPORT_LEARNING_SYNC is set on a
>>>bridge port, fdb entries that are learnt externally(may be learnt by
>>>hardware and driver is notified) are synced to bridges fdb using
>>>br_fdb_external_learn_add(). The fdb
>>>entries(fdb->added_by_external_learn set to true) that are learnt via
>>>this method are also deleted by the aging logic after the aging time
>>>even though L2 data forwadring happens in hardware.
>
>This is correct...
>
>>> Is there a way
>>>where aging can be disabled for these entries? and let the entries be
>>>removed only via br_fdb_external_learn_delete()? or am I missing
>>>something?
>>
>> Currently extenaly learned fdb entries are indeed removed during aging
>> cleanup. I believe that br_fdb_cleanup should check added_by_external_learn
>> and not remove that fdbs. What do you think Scott?
>
>Something like that would work, if we added another brport flag to
>control that. With the current arrangement, using bridge for aging
>out entries, we want br_fdb_cleanup removing the external_learned
>fdbs, but if there was another brport flag we could fine tune that.
>Say new flag is IFLA_BRPORT_AGING_OFFLOAD or something like that. I'm
>not sure how aging settings for the bridge are pushed down to offload
>hw, or if there is a different set for hw.
>
>But, isn't it nice to let Linux bridge control aging? That way,
>bridge -s fdb dump shows nice statistics on fdb entries. Hardware
>isn't involved in the aging processes (other than being told to remove
>an entry). Simple hardware equals simple driver. Linux remains
>control point.
>
It is indeed simpler. However, if the overhead of reading hit bits from the HW
and updating freshness of entries using br_fdb_external_learn_add() is too
expensive, it would force such platforms to disable learning sync altogether.
Therefore, I believe aging offload flag (could be sufficient at bridge level)
and external aging interval (possibly longer than the software aging interval)
will encourage drivers to use leaning sync.
>-scott
>--
>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
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