* Re: [RFC PATCH v3 1/5] irq: add tracepoint to softirq_raise
From: Neil Horman @ 2010-07-21 13:56 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: Koki Sanagi, netdev, linux-kernel, davem, kaneshige.kenji,
izumi.taku, laijs, scott.a.mcmillan, rostedt, eric.dumazet,
fweisbec, mathieu.desnoyers
In-Reply-To: <20100721215836.86F9.A69D9226@jp.fujitsu.com>
On Wed, Jul 21, 2010 at 10:01:34PM +0900, KOSAKI Motohiro wrote:
> > > >> #endif /* _TRACE_IRQ_H */
> > > >> diff --git a/kernel/softirq.c b/kernel/softirq.c
> > > >> index 825e112..6790599 100644
> > > >> --- a/kernel/softirq.c
> > > >> +++ b/kernel/softirq.c
> > > >> @@ -215,9 +215,9 @@ restart:
> > > >> int prev_count = preempt_count();
> > > >> kstat_incr_softirqs_this_cpu(h - softirq_vec);
> > > >>
> > > >> - trace_softirq_entry(h, softirq_vec);
> > > >> + trace_softirq_entry(h - softirq_vec);
> > > >> h->action(h);
> > > >> - trace_softirq_exit(h, softirq_vec);
> > > >> + trace_softirq_exit(h - softirq_vec);
> > > >
> > > > You're loosing information here by reducing the numbers of parameters in this
> > > > tracepoint. How many other tracepoint scripts rely on having both pointers
> > > > handy? Why not just do the pointer math inside your tracehook instead?
> > >
> > > In __raise_softirq_irqoff macro there is no method to refer softirq_vec, so it
> > > can't use softirq DECLARE_EVENT_CLASS as is.
> > > Currently, there is no script using softirq_entry or softirq_exit.
> > >
> > That shouldn't matter, just pass in NULL for softirq_vec in
> > __raise_softirq_irqoff as the second argument to the trace function. You may
> > need to fix up the class definition so that the assignment or printk doesn't try
> > to dereference that pointer when its NULL, but thats easy enough, and it avoids
> > breaking any other perf scripts floating out there.
>
> please see 5 lines above. we already have 'h - softirq_vec' calculation in
> this function. so, Sanagi-san's change don't makes any overhead.
>
> So, if the overhead is zero, I'd prefer simplest tracepoint definition :)
>
I never complained about performance here, I complained about information loss.
You have a tracepoint that provides two arguments here, and you're eliminating
one of them. That will potentially break other users of this tracepoint. I
understand we don't normally care about that with tracepoints as much, but if we
can avoid it, why don't we?
Neil
>
>
> --
> 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
* 2.6.34.1, e1000e, VLAN's and kernel BUG
From: Denys Fedoryshchenko @ 2010-07-21 14:03 UTC (permalink / raw)
To: netdev, jeffrey.t.kirsher; +Cc: Jesse Brandeburg, Bruce Allan, Alex Duyck
I experience similar issue with router , also e1000e and VLAN's, now crashed
completely different server, with different job (on this interface only
PPPoE) but same was : VLAN's on one of interfaces and e1000e driver for
network card on this interface.
Old report is at
http://marc.info/?l=linux-netdev&m=127101842721222&w=2
Hardware is very different, old one was 04:00.0 Ethernet controller: Intel
Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) (rev 01)
and Sun server with Xeon amd64, new one is just Core 2 Quad with 32-bit
kernel.
MASTER_PPPOE_WORLDNET ~ # ethtool -i eth1
driver: e1000e
version: 1.0.2-k2
firmware-version: 1.8-5
bus-info: 0000:00:19.0
00:19.0 Ethernet controller: Intel Corporation 82567LF-2 Gigabit Network
Connection
IRQ's
24: 1290189 1312386 1289973 1310347 PCI-MSI-edge eth1
Jul 21 16:45:45 PPPOE kernel: [938915.369647] BUG: unable to handle kernel
NULL pointer dereference at (null)
Jul 21 16:45:45 PPPOE kernel: [938915.369750] IP: [<c0297733>]
dev_queue_xmit+0x279/0x410
Jul 21 16:45:45 PPPOE kernel: [938915.369822] *pdpt = 0000000022435001 *pde =
0000000000000000
Jul 21 16:45:45 PPPOE kernel: [938915.369890] Oops: 0000 [#1] SMP
Jul 21 16:45:45 PPPOE kernel: [938915.369953] last sysfs file:
/sys/devices/system/cpu/online
Jul 21 16:45:45 PPPOE kernel: [938915.370039] Modules linked in:
nf_conntrack_netlink nfnetlink rtc_cmos rtc_core rtc_lib act_skbedit
sch_ingress sch_prio netconsole co
nfigfs cls_flow cls_u32 em_meta cls_basic xt_dscp ipt_REJECT ts_bm xt_string
xt_hl ifb cl
Jul 21 16:45:45 PPPOE kernel: [938915.370253]
Jul 21 16:45:45 PPPOE kernel: [938915.370253] Pid: 10, comm: ksoftirqd/2
Tainted: G W 2.6.34.1-build-0053 #2 DG45ID/
Jul 21 16:45:45 PPPOE kernel: [938915.370253] EIP: 0060:[<c0297733>] EFLAGS:
00010202 CPU: 2
Jul 21 16:45:45 PPPOE kernel: [938915.370253] EIP is at
dev_queue_xmit+0x279/0x410
Jul 21 16:45:45 PPPOE kernel: [938915.370253] EAX: e9f72000 EBX: 00000000 ECX:
e9f786b0 EDX: f6e8c000
Jul 21 16:45:45 PPPOE kernel: [938915.370253] ESI: f74af180 EDI: 000000eb EBP:
c5301b74 ESP: c5301b5c
Jul 21 16:45:45 PPPOE kernel: [938915.370253] DS: 007b ES: 007b FS: 00d8 GS:
0000 SS: 0068
Jul 21 16:45:45 PPPOE kernel: [938915.370253] Process ksoftirqd/2 (pid: 10,
ti=c5301000 task=f7480000 task.ti=f7461000)
Jul 21 16:45:45 PPPOE kernel: [938915.370253] Stack:
Jul 21 16:45:45 PPPOE kernel: [938915.370253] e9f786b0 f6e8c000 f6fabe40
f614ea00 e9f786b0 000000eb c5301b88 f8817062
Jul 21 16:45:45 PPPOE kernel: [938915.370253] <0> f6184800 e9f786b0 c0410540
c5301bb0 c0297307 f614ea00 f6184800 f88184cc
Jul 21 16:45:45 PPPOE kernel: [938915.370253] <0> 00000003 00008864 00000002
f614ea00 00000000 c5301bd0 c029781c e9f786b0
Jul 21 16:45:45 PPPOE kernel: [938915.370253] Call Trace:
Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<f8817062>] ?
vlan_dev_hwaccel_hard_start_xmit+0x58/0x6c [8021q]
Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c0297307>] ?
dev_hard_start_xmit+0x210/0x2dd
Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c029781c>] ?
dev_queue_xmit+0x362/0x410
Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02a48be>] ?
eth_header+0x0/0x92
Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<f8c21e53>] ?
__pppoe_xmit+0x11c/0x132 [pppoe]
Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<f8c21e73>] ?
pppoe_xmit+0xa/0xc [pppoe]
Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<f8c06579>] ?
ppp_push+0x67/0x4bf [ppp_generic]
Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<f88947ae>] ?
tcp_manip_pkt+0xb4/0xc6 [nf_nat]
Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02907b5>] ?
__kfree_skb+0x6e/0x71
Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02900c1>] ?
skb_dequeue+0x45/0x4c
Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<f8c070e8>] ?
ppp_xmit_process+0x3c6/0x427 [ppp_generic]
Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c028fff9>] ?
skb_queue_tail+0x2d/0x32
Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<f8c0725c>] ?
ppp_start_xmit+0x113/0x12c [ppp_generic]
Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c0297307>] ?
dev_hard_start_xmit+0x210/0x2dd
Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02a53e2>] ?
sch_direct_xmit+0x4c/0x122
Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02a554a>] ?
__qdisc_run+0x92/0xa8
Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02977d4>] ?
dev_queue_xmit+0x31a/0x410
Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02b60fc>] ?
ip_finish_output2+0x188/0x1b3
Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02b6179>] ?
ip_finish_output+0x52/0x54
Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02b61fc>] ?
ip_output+0x81/0x8a
Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02b5685>] ?
ip_local_out+0x18/0x1b
Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02b5e00>] ?
ip_queue_xmit+0x2c3/0x2f9
Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c01ac33e>] ?
ep_poll_callback+0x8d/0xa4
Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c0120cb3>] ?
__wake_up_common+0x35/0x5b
Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02c82b2>] ?
tcp_v4_send_check+0x7d/0xb7
Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02c4db8>] ?
tcp_transmit_skb+0x623/0x65a
Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02c4eb8>] ?
tcp_send_ack+0x25/0xd9
Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02c4f64>] ?
tcp_send_ack+0xd1/0xd9
Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02c29ea>] ?
__tcp_ack_snd_check+0x5e/0x73
Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02c3483>] ?
tcp_rcv_established+0x5b2/0x5e1
Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02c90fd>] ?
tcp_v4_do_rcv+0x24/0x171
Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c013169b>] ?
local_bh_enable+0xb/0xd
Jul 21 16:45:45 PPPOE kernel: [938915.374483] [<c02c95f0>] ?
tcp_v4_rcv+0x3a6/0x582
Jul 21 16:45:45 PPPOE kernel: [938915.374483] [<c02b266c>] ?
ip_local_deliver_finish+0xba/0x10b
Jul 21 16:45:45 PPPOE kernel: [938915.374483] [<c02b271e>] ?
ip_local_deliver+0x61/0x6a
Jul 21 16:45:45 PPPOE kernel: [938915.374483] [<c02b237b>] ?
ip_rcv_finish+0x25b/0x271
Jul 21 16:45:45 PPPOE kernel: [938915.374483] [<c02b2593>] ?
ip_rcv+0x202/0x221
Jul 21 16:45:45 PPPOE kernel: [938915.374483] [<c0296889>] ?
netif_receive_skb+0x3e4/0x403
Jul 21 16:45:45 PPPOE kernel: [938915.374483] [<c029690c>] ?
process_backlog+0x64/0x8a
Jul 21 16:45:45 PPPOE kernel: [938915.374483] [<c0296a93>] ?
net_rx_action+0x8d/0x14a
Jul 21 16:45:45 PPPOE kernel: [938915.374483] [<c013177c>] ?
__do_softirq+0x77/0xe7
Jul 21 16:45:45 PPPOE kernel: [938915.374483] [<c0131705>] ?
__do_softirq+0x0/0xe7
Jul 21 16:45:45 PPPOE kernel: [938915.374483] <IRQ>
Jul 21 16:45:45 PPPOE kernel: [938915.374483] [<c0131365>] ?
run_ksoftirqd+0x56/0xde
Jul 21 16:45:45 PPPOE kernel: [938915.374483] [<c013130f>] ?
run_ksoftirqd+0x0/0xde
Jul 21 16:45:45 PPPOE kernel: [938915.374483] [<c013d5bd>] ?
kthread+0x61/0x66
Jul 21 16:45:45 PPPOE kernel: [938915.374483] [<c013d55c>] ? kthread+0x0/0x66
Jul 21 16:45:45 PPPOE kernel: [938915.374483] [<c0102c76>] ?
kernel_thread_helper+0x6/0x10
Jul 21 16:45:45 PPPOE kernel: [938915.374483] Code: 0c 8b 45 e8 0f b7 f2 c1 e6
07 66 89 50 7c 8b 55 ec 8b 4d e8 03 b2 00 02 00 00 66 8b 41 7a 8b 5e 04 80 e4
cf 80 cc 20
66 89 41 7a <83> 3b 00 0f 84 a0 00 00 00 8d 7b 5c 89 f8 e8 5c de 05 00 f6 43
^ permalink raw reply
* Re: 2.6.34.1, e1000e, VLAN's and kernel BUG
From: Eric Dumazet @ 2010-07-21 14:30 UTC (permalink / raw)
To: Denys Fedoryshchenko
Cc: netdev, jeffrey.t.kirsher, Jesse Brandeburg, Bruce Allan,
Alex Duyck
In-Reply-To: <201007211703.23093.nuclearcat@nuclearcat.com>
Le mercredi 21 juillet 2010 à 17:03 +0300, Denys Fedoryshchenko a
écrit :
> I experience similar issue with router , also e1000e and VLAN's, now crashed
> completely different server, with different job (on this interface only
> PPPoE) but same was : VLAN's on one of interfaces and e1000e driver for
> network card on this interface.
>
> Old report is at
> http://marc.info/?l=linux-netdev&m=127101842721222&w=2
>
> Hardware is very different, old one was 04:00.0 Ethernet controller: Intel
> Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) (rev 01)
> and Sun server with Xeon amd64, new one is just Core 2 Quad with 32-bit
> kernel.
>
> MASTER_PPPOE_WORLDNET ~ # ethtool -i eth1
> driver: e1000e
> version: 1.0.2-k2
> firmware-version: 1.8-5
> bus-info: 0000:00:19.0
>
> 00:19.0 Ethernet controller: Intel Corporation 82567LF-2 Gigabit Network
> Connection
>
> IRQ's
> 24: 1290189 1312386 1289973 1310347 PCI-MSI-edge eth1
>
>
> Jul 21 16:45:45 PPPOE kernel: [938915.369647] BUG: unable to handle kernel
> NULL pointer dereference at (null)
> Jul 21 16:45:45 PPPOE kernel: [938915.369750] IP: [<c0297733>]
> dev_queue_xmit+0x279/0x410
> Jul 21 16:45:45 PPPOE kernel: [938915.369822] *pdpt = 0000000022435001 *pde =
> 0000000000000000
> Jul 21 16:45:45 PPPOE kernel: [938915.369890] Oops: 0000 [#1] SMP
> Jul 21 16:45:45 PPPOE kernel: [938915.369953] last sysfs file:
> /sys/devices/system/cpu/online
> Jul 21 16:45:45 PPPOE kernel: [938915.370039] Modules linked in:
> nf_conntrack_netlink nfnetlink rtc_cmos rtc_core rtc_lib act_skbedit
> sch_ingress sch_prio netconsole co
> nfigfs cls_flow cls_u32 em_meta cls_basic xt_dscp ipt_REJECT ts_bm xt_string
> xt_hl ifb cl
> Jul 21 16:45:45 PPPOE kernel: [938915.370253]
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] Pid: 10, comm: ksoftirqd/2
> Tainted: G W 2.6.34.1-build-0053 #2 DG45ID/
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] EIP: 0060:[<c0297733>] EFLAGS:
> 00010202 CPU: 2
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] EIP is at
> dev_queue_xmit+0x279/0x410
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] EAX: e9f72000 EBX: 00000000 ECX:
> e9f786b0 EDX: f6e8c000
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] ESI: f74af180 EDI: 000000eb EBP:
> c5301b74 ESP: c5301b5c
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] DS: 007b ES: 007b FS: 00d8 GS:
> 0000 SS: 0068
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] Process ksoftirqd/2 (pid: 10,
> ti=c5301000 task=f7480000 task.ti=f7461000)
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] Stack:
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] e9f786b0 f6e8c000 f6fabe40
> f614ea00 e9f786b0 000000eb c5301b88 f8817062
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] <0> f6184800 e9f786b0 c0410540
> c5301bb0 c0297307 f614ea00 f6184800 f88184cc
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] <0> 00000003 00008864 00000002
> f614ea00 00000000 c5301bd0 c029781c e9f786b0
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] Call Trace:
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<f8817062>] ?
> vlan_dev_hwaccel_hard_start_xmit+0x58/0x6c [8021q]
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c0297307>] ?
> dev_hard_start_xmit+0x210/0x2dd
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c029781c>] ?
> dev_queue_xmit+0x362/0x410
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02a48be>] ?
> eth_header+0x0/0x92
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<f8c21e53>] ?
> __pppoe_xmit+0x11c/0x132 [pppoe]
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<f8c21e73>] ?
> pppoe_xmit+0xa/0xc [pppoe]
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<f8c06579>] ?
> ppp_push+0x67/0x4bf [ppp_generic]
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<f88947ae>] ?
> tcp_manip_pkt+0xb4/0xc6 [nf_nat]
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02907b5>] ?
> __kfree_skb+0x6e/0x71
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02900c1>] ?
> skb_dequeue+0x45/0x4c
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<f8c070e8>] ?
> ppp_xmit_process+0x3c6/0x427 [ppp_generic]
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c028fff9>] ?
> skb_queue_tail+0x2d/0x32
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<f8c0725c>] ?
> ppp_start_xmit+0x113/0x12c [ppp_generic]
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c0297307>] ?
> dev_hard_start_xmit+0x210/0x2dd
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02a53e2>] ?
> sch_direct_xmit+0x4c/0x122
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02a554a>] ?
> __qdisc_run+0x92/0xa8
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02977d4>] ?
> dev_queue_xmit+0x31a/0x410
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02b60fc>] ?
> ip_finish_output2+0x188/0x1b3
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02b6179>] ?
> ip_finish_output+0x52/0x54
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02b61fc>] ?
> ip_output+0x81/0x8a
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02b5685>] ?
> ip_local_out+0x18/0x1b
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02b5e00>] ?
> ip_queue_xmit+0x2c3/0x2f9
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c01ac33e>] ?
> ep_poll_callback+0x8d/0xa4
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c0120cb3>] ?
> __wake_up_common+0x35/0x5b
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02c82b2>] ?
> tcp_v4_send_check+0x7d/0xb7
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02c4db8>] ?
> tcp_transmit_skb+0x623/0x65a
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02c4eb8>] ?
> tcp_send_ack+0x25/0xd9
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02c4f64>] ?
> tcp_send_ack+0xd1/0xd9
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02c29ea>] ?
> __tcp_ack_snd_check+0x5e/0x73
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02c3483>] ?
> tcp_rcv_established+0x5b2/0x5e1
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c02c90fd>] ?
> tcp_v4_do_rcv+0x24/0x171
> Jul 21 16:45:45 PPPOE kernel: [938915.370253] [<c013169b>] ?
> local_bh_enable+0xb/0xd
> Jul 21 16:45:45 PPPOE kernel: [938915.374483] [<c02c95f0>] ?
> tcp_v4_rcv+0x3a6/0x582
> Jul 21 16:45:45 PPPOE kernel: [938915.374483] [<c02b266c>] ?
> ip_local_deliver_finish+0xba/0x10b
> Jul 21 16:45:45 PPPOE kernel: [938915.374483] [<c02b271e>] ?
> ip_local_deliver+0x61/0x6a
> Jul 21 16:45:45 PPPOE kernel: [938915.374483] [<c02b237b>] ?
> ip_rcv_finish+0x25b/0x271
> Jul 21 16:45:45 PPPOE kernel: [938915.374483] [<c02b2593>] ?
> ip_rcv+0x202/0x221
> Jul 21 16:45:45 PPPOE kernel: [938915.374483] [<c0296889>] ?
> netif_receive_skb+0x3e4/0x403
> Jul 21 16:45:45 PPPOE kernel: [938915.374483] [<c029690c>] ?
> process_backlog+0x64/0x8a
> Jul 21 16:45:45 PPPOE kernel: [938915.374483] [<c0296a93>] ?
> net_rx_action+0x8d/0x14a
> Jul 21 16:45:45 PPPOE kernel: [938915.374483] [<c013177c>] ?
> __do_softirq+0x77/0xe7
> Jul 21 16:45:45 PPPOE kernel: [938915.374483] [<c0131705>] ?
> __do_softirq+0x0/0xe7
> Jul 21 16:45:45 PPPOE kernel: [938915.374483] <IRQ>
> Jul 21 16:45:45 PPPOE kernel: [938915.374483] [<c0131365>] ?
> run_ksoftirqd+0x56/0xde
> Jul 21 16:45:45 PPPOE kernel: [938915.374483] [<c013130f>] ?
> run_ksoftirqd+0x0/0xde
> Jul 21 16:45:45 PPPOE kernel: [938915.374483] [<c013d5bd>] ?
> kthread+0x61/0x66
> Jul 21 16:45:45 PPPOE kernel: [938915.374483] [<c013d55c>] ? kthread+0x0/0x66
> Jul 21 16:45:45 PPPOE kernel: [938915.374483] [<c0102c76>] ?
> kernel_thread_helper+0x6/0x10
> Jul 21 16:45:45 PPPOE kernel: [938915.374483] Code: 0c 8b 45 e8 0f b7 f2 c1 e6
> 07 66 89 50 7c 8b 55 ec 8b 4d e8 03 b2 00 02 00 00 66 8b 41 7a 8b 5e 04 80 e4
> cf 80 cc 20
> 66 89 41 7a <83> 3b 00 0f 84 a0 00 00 00 8d 7b 5c 89 f8 e8 5c de 05 00 f6 43
> --
You might need patch provided by commit b0f77d0eae0c58a5a
http://git2.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b0f77d0eae0c58a5a
^ permalink raw reply
* [PATCH for-2.6.35] tun: avoid BUG, dump packet on GSO errors
From: Michael S. Tsirkin @ 2010-07-21 14:32 UTC (permalink / raw)
To: netdev
There are still some LRO cards that cause GSO errors in tun,
and BUG on this is an unfriendly way to tell the admin
to disable LRO.
Further, experience shows we might have more GSO bugs lurking.
See https://bugzilla.kernel.org/show_bug.cgi?id=16413
as a recent example.
dumping a packet will make it easier to figure it out.
Replace BUG with warning+dump+drop the packet to make
GSO errors in tun less critical and easier to debug.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: Alex Unigovsky <unik@compot.ru>
---
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 6ad6fe7..6304259 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -736,8 +736,18 @@ static __inline__ ssize_t tun_put_user(struct tun_struct *tun,
gso.gso_type = VIRTIO_NET_HDR_GSO_TCPV6;
else if (sinfo->gso_type & SKB_GSO_UDP)
gso.gso_type = VIRTIO_NET_HDR_GSO_UDP;
- else
- BUG();
+ else {
+ printk(KERN_ERR "tun: unexpected GSO type: "
+ "0x%x, gso_size %d, hdr_len %d\n",
+ sinfo->gso_type, gso.gso_size,
+ gso.hdr_len);
+ print_hex_dump(KERN_ERR, "tun: ",
+ DUMP_PREFIX_NONE,
+ 16, 1, skb->head,
+ min((int)gso.hdr_len, 64), true);
+ WARN_ON_ONCE(1);
+ return -EINVAL;
+ }
if (sinfo->gso_type & SKB_GSO_TCP_ECN)
gso.gso_type |= VIRTIO_NET_HDR_GSO_ECN;
} else
^ permalink raw reply related
* Re: 2.6.34.1, e1000e, VLAN's and kernel BUG
From: Denys Fedoryshchenko @ 2010-07-21 14:38 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, jeffrey.t.kirsher, Jesse Brandeburg, Bruce Allan,
Alex Duyck
In-Reply-To: <1279722611.2452.49.camel@edumazet-laptop>
On Wednesday 21 July 2010 17:30:11 Eric Dumazet wrote:
> >
> > 66 89 41 7a <83> 3b 00 0f 84 a0 00 00 00 8d 7b 5c 89 f8 e8 5c de 05 00
> > f6 43
> >
> > --
>
> You might need patch provided by commit b0f77d0eae0c58a5a
>
> http://git2.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;
> h=b0f77d0eae0c58a5a
Thanks, i will try it.
^ permalink raw reply
* Re: [PATCH 1/2] net: dsa: introduce STPID switch tagging handling code
From: Lennert Buytenhek @ 2010-07-21 15:02 UTC (permalink / raw)
To: Mike Frysinger
Cc: netdev, David S. Miller, uclinux-dist-devel, Karl Beldan,
Graf Yang, Bryan Wu
In-Reply-To: <1279719442-10174-1-git-send-email-vapier@gentoo.org>
On Wed, Jul 21, 2010 at 09:37:21AM -0400, Mike Frysinger wrote:
> diff --git a/net/dsa/tag_stpid.c b/net/dsa/tag_stpid.c
> new file mode 100644
> index 0000000..b5d9829
> --- /dev/null
> +++ b/net/dsa/tag_stpid.c
> @@ -0,0 +1,147 @@
> +/*
> + * net/dsa/tag_stpid.c - special tag identifier,
> + * 0x810 + 4 bit "port mask" + 3 bit 8021p + 1 bit CFI + 12 bit VLAN ID
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <linux/etherdevice.h>
> +#include <linux/list.h>
> +#include <linux/netdevice.h>
> +#include "dsa_priv.h"
> +
> +#define ETH_P_8021QH (ETH_P_8021Q >> 8)
> +#define ETH_P_8021QL (ETH_P_8021Q & 0xFF)
> +#define STPID_HLEN 4
> +
> +#define ZERO_VID 0
> +#define RESERVED_VID 0xFFF
> +#define STPID_VID ZERO_VID
> +
> +int stpid_xmit(struct sk_buff *skb, struct net_device *dev)
> +{
> + struct dsa_slave_priv *p = netdev_priv(dev);
> + u8 *dsa_header;
> +
> + dev->stats.tx_packets++;
> + dev->stats.tx_bytes += skb->len;
Everything up to this point looks OK, but..
> + /*
> + * For 802.1Q frames, convert to STPID tagged frames,
> + * do nothing for common frames.
> + */
> + if (skb->protocol == htons(ETH_P_8021Q)) {
> + if (skb_cow_head(skb, 0) < 0)
> + goto out_free;
> +
> + dsa_header = skb->data + 2 * ETH_ALEN;
> + dsa_header[1] = p->port & 0x03;
> + }
This is almost certainly wrong -- according to the KSZ8893ML datasheet,
this means that VLAN tagged frames will be switched explicitly (by
sending them to p->port), but non-VLAN tagged frames will be switched
according to the switch's MAC address database. You want explicit (i.e.
host kernel-side MAC address database lookup) switching in both cases.
> +{
> + struct dsa_switch_tree *dst = dev->dsa_ptr;
> + struct dsa_switch *ds = dst->ds[0];
> + u8 *dsa_header;
> + int source_port;
> + int vid;
> +
> + if (unlikely(ds == NULL))
> + goto out_drop;
> +
> + skb = skb_unshare(skb, GFP_ATOMIC);
> + if (skb == NULL)
> + goto out;
> +
> + /* The ether_head has been pulled by master driver */
> + dsa_header = skb->data - 2;
> +
> + vid = ((dsa_header[2] & 0x0f)<<8 | dsa_header[3]);
Coding style (need spaces around '<<').
> +
> + source_port = dsa_header[1] & 0x03;
> + if (source_port >= DSA_MAX_PORTS || ds->ports[source_port] == NULL)
> + goto out_drop;
> +
> + if (((dsa_header[0] & ETH_P_8021QH) == ETH_P_8021QH) &&
This is bogus -- what it does is:
if ((dsa_header[0] & 0x81) == 0x81)
It doesn't look like you need to mask here at all.
^ permalink raw reply
* Re: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address
From: Andy Gospodarek @ 2010-07-21 15:07 UTC (permalink / raw)
To: Harald Hoyer
Cc: David Miller, shemminger, bhutchings, sassmann, netdev,
linux-kernel, gospo, gregory.v.rose, alexander.h.duyck, leedom
In-Reply-To: <4C469808.5060308@redhat.com>
On Wed, Jul 21, 2010 at 08:47:36AM +0200, Harald Hoyer wrote:
> On 07/21/2010 08:34 AM, David Miller wrote:
>> From: Harald Hoyer<harald@redhat.com>
>> Date: Wed, 21 Jul 2010 08:26:27 +0200
>>
>>> On 07/20/2010 11:20 PM, David Miller wrote:
>>>> From: Stephen Hemminger<shemminger@vyatta.com>
>>>> Date: Tue, 20 Jul 2010 14:18:16 -0700
>>>>
>>>>> No one mentioned that the first octet of an Ethernet address already
>>>>> indicates "software generated" Ethernet address. Per the standard,
>>>>> if bit 1 is set it means address is locally assigned.
>>>>>
>>>>> static inline bool is_locally_assigned_ether(const u8 *addr)
>>>>> {
>>>>> return (addr[0]& 0x2) != 0;
>>>>> }
>>>>
>>>> W00t!
>>>>
>>>> Indeed, can udev just use that? :-)
>>>
>>> It already does:
>>> see /lib/udev/rules.d/75-persistent-net-generator.rules
>>
>> So... why doesn't this work?
>
> It works.. but the information, that the MAC is randomly generated would
> be valuable. So, for the non-random locally assigned MAC (with bit 1), we
> could easily make persistent rules based on the MAC, instead of
> completely ignoring them, like we do currently.
Agreed. The subtle difference between a locally assigned address that
is persistent and one that is random would be helpful.
^ permalink raw reply
* Re: [PATCH 2/2] net: dsa: introduce MICREL KSZ8893MQL/BL ethernet switch chip support
From: Lennert Buytenhek @ 2010-07-21 15:16 UTC (permalink / raw)
To: Mike Frysinger
Cc: netdev, David S. Miller, uclinux-dist-devel, Karl Beldan,
Graf Yang, Bryan Wu
In-Reply-To: <1279719442-10174-2-git-send-email-vapier@gentoo.org>
On Wed, Jul 21, 2010 at 09:37:22AM -0400, Mike Frysinger wrote:
> From: Graf Yang <graf.yang@analog.com>
Hurray for the first non-Marvell switch chip support in net/dsa!
> +#define pr_fmt(fmt) "ksz8893m: " fmt
This has no users.
> +static int ksz8893m_setup(struct dsa_switch *ds)
> +{
> + int i;
> + int ret;
> +
> + ret = ksz8893m_switch_reset(ds);
> + if (ret < 0)
> + return ret;
It's pretty ugly that the mdiobus is passed in via the normal means,
but a reference to the SPI bus to use is just stuffed into some global
variable.
Can you not access all registers via MII?
(If not, struct dsa_chip_data will need go be extended with another
struct device pointer that we can use to find the spi bus with.)
> +static int ksz8893m_port_to_phy_addr(int port)
> +{
> + if (port >= 1 && port <= KSZ8893M_PORT_NUM)
> + return port;
> +
> + pr_warning("use default phy addr 3\n");
> + return 3;
Does this ever happen? You should just be able to return -1 here, IMHO.
> +static int __devinit spi_switch_probe(struct spi_device *spi)
> +{
> + if (sw.dev) {
> + pr_err("only one instance supported at a time\n");
> + return 1;
> + }
> + memset(&sw.xfer, 0, sizeof(sw.xfer));
> + sw.dev = spi;
> + return 0;
> +}
> +
> +static int __devexit spi_switch_remove(struct spi_device *spi)
> +{
> + sw.dev = NULL;
> + return 0;
> +}
> +
> +static struct spi_driver spi_switch_driver = {
> + .driver = {
> + .name = "ksz8893m",
> + .bus = &spi_bus_type,
> + .owner = THIS_MODULE,
> + },
> + .probe = spi_switch_probe,
> + .remove = __devexit_p(spi_switch_remove),
> +};
I'm not entirely happy with this.
Then again, there isn't really a clean way to deal with devices that
have multiple different host interfaces as far as I know..
> +#define KSZ8893M_PORT_NUM 3
> +#define KSZ8893M_CPU_PORT 3
> +
> +#define DEFAULT_PORT_VID 0
> +
> +#define SPI_READ 3
> +#define SPI_WRITE 2
>
> [snip]
Something tells me that half the defines (and register index definitions)
in this file aren't used. Also:
> +/* MII Basic Control */
> +#define SOFT_RESET 0x8000
> +#define LOOPBACK 0x4000
> +#define FORCE_100 0x2000
> +#define AN_ENABLE 0x1000
> +#define POWER_DOWN 0x0800
> +#define ISOLATE 0x0400
> +#define RESTART_AN 0x0200
> +#define FORCE_FULL_DUPLEX 0x0100
> +#define COLLISION_TEST 0x0080
This part of the MII register is standard, and there are BMCR_*
definitions for this in mii.h, no need to duplicate them.
> +#define Force_MDI 0x0010
And please don't use mixed case.
> +#define FAMILY_ID 0x88
> +#define START_SWITCH 0x01
> +#define TAG_INSERTION 0x04
> +#define SPECIAL_TPID_MODE 0x01
It would be nice to mention what registers these bitfields are part of.
> +enum switch_phy_reg {
> + /* Global Registers: 0-15 */
> + ChipID0 = 0,
> + ChipID1_StartSwitch,
> + GlobalControl0,
And here, just define the registers you need only.
^ permalink raw reply
* Re: [Uclinux-dist-devel] [PATCH 1/2] net: dsa: introduce STPID switch tagging handling code
From: Mike Frysinger @ 2010-07-21 15:29 UTC (permalink / raw)
To: Lennert Buytenhek
Cc: Karl Beldan, netdev, Graf Yang, uclinux-dist-devel,
David S. Miller
In-Reply-To: <20100721150251.GL21121@mail.wantstofly.org>
On Wed, Jul 21, 2010 at 11:02, Lennert Buytenhek wrote:
> On Wed, Jul 21, 2010 at 09:37:21AM -0400, Mike Frysinger wrote:
>> + source_port = dsa_header[1] & 0x03;
>> + if (source_port >= DSA_MAX_PORTS || ds->ports[source_port] == NULL)
>> + goto out_drop;
>> +
>> + if (((dsa_header[0] & ETH_P_8021QH) == ETH_P_8021QH) &&
>
> This is bogus -- what it does is:
>
> if ((dsa_header[0] & 0x81) == 0x81)
>
> It doesn't look like you need to mask here at all.
where does it say dsa_header[0] will always have 0x81 set ?
-mike
^ permalink raw reply
* Re: [PATCH 2/2] net: dsa: introduce MICREL KSZ8893MQL/BL ethernet switch chip support
From: Eric Dumazet @ 2010-07-21 15:33 UTC (permalink / raw)
To: Lennert Buytenhek
Cc: Mike Frysinger, netdev, David S. Miller, uclinux-dist-devel,
Karl Beldan, Graf Yang, Bryan Wu
In-Reply-To: <20100721151608.GM21121@mail.wantstofly.org>
Le mercredi 21 juillet 2010 à 17:16 +0200, Lennert Buytenhek a écrit :
> > +#define pr_fmt(fmt) "ksz8893m: " fmt
>
> This has no users.
>
Dont tell this to Joe Perches ;)
It is used by all pr_err() friends
#define pr_emerg(fmt, ...) \
printk(KERN_EMERG pr_fmt(fmt), ##__VA_ARGS__)
#define pr_alert(fmt, ...) \
printk(KERN_ALERT pr_fmt(fmt), ##__VA_ARGS__)
#define pr_crit(fmt, ...) \
printk(KERN_CRIT pr_fmt(fmt), ##__VA_ARGS__)
#define pr_err(fmt, ...) \
printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
#define pr_warning(fmt, ...) \
printk(KERN_WARNING pr_fmt(fmt), ##__VA_ARGS__)
#define pr_warn pr_warning
#define pr_notice(fmt, ...) \
printk(KERN_NOTICE pr_fmt(fmt), ##__VA_ARGS__)
#define pr_info(fmt, ...) \
printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
#define pr_cont(fmt, ...) \
printk(KERN_CONT fmt, ##__VA_ARGS__)
^ permalink raw reply
* Re: [Uclinux-dist-devel] [PATCH 1/2] net: dsa: introduce STPID switch tagging handling code
From: Lennert Buytenhek @ 2010-07-21 15:35 UTC (permalink / raw)
To: Mike Frysinger
Cc: Karl Beldan, netdev, Graf Yang, uclinux-dist-devel,
David S. Miller
In-Reply-To: <AANLkTim1gbnH99GC_dVL8uevRgCRsn7dvAJ_rX-2Xgon@mail.gmail.com>
On Wed, Jul 21, 2010 at 11:29:30AM -0400, Mike Frysinger wrote:
> >> + source_port = dsa_header[1] & 0x03;
> >> + if (source_port >= DSA_MAX_PORTS || ds->ports[source_port] == NULL)
> >> + goto out_drop;
> >> +
> >> + if (((dsa_header[0] & ETH_P_8021QH) == ETH_P_8021QH) &&
> >
> > This is bogus -- what it does is:
> >
> > if ((dsa_header[0] & 0x81) == 0x81)
> >
> > It doesn't look like you need to mask here at all.
>
> where does it say dsa_header[0] will always have 0x81 set ?
Eh?
This code is checking whether the packet has a STPID tag on it or not.
A STPID tag exists if the first 12 nibbles are 0x810.
You are checking whether the first 8 nibbles of this are equal to 0x81
by doing:
if ((byte & 0x81) == 0x81)
What if the first byte is 0x93? Or 0xc5?
^ permalink raw reply
* Re: [PATCH 2/2] net: dsa: introduce MICREL KSZ8893MQL/BL ethernet switch chip support
From: Lennert Buytenhek @ 2010-07-21 15:36 UTC (permalink / raw)
To: Eric Dumazet
Cc: Mike Frysinger, netdev, David S. Miller, uclinux-dist-devel,
Karl Beldan, Graf Yang, Bryan Wu
In-Reply-To: <1279726393.2452.60.camel@edumazet-laptop>
On Wed, Jul 21, 2010 at 05:33:13PM +0200, Eric Dumazet wrote:
> > > +#define pr_fmt(fmt) "ksz8893m: " fmt
> >
> > This has no users.
>
> Dont tell this to Joe Perches ;)
>
> It is used by all pr_err() friends
Oops, my bad!
^ permalink raw reply
* [PATCH 0/3 net-2.6] bnx2x: Bug fixes in statistics handling
From: Vladislav Zolotarov @ 2010-07-21 15:58 UTC (permalink / raw)
To: Dave Miller; +Cc: netdev list, Eilon Greenstein, dmitry
Dave, pls., consider applying the following patches to the net-2.6 tree.
They include 2 bugs fixes in the statistics handling flow:
1) Protect the statistics state machine state update with a spinlock.
Otherwise there was a race condition that would cause the statistics
stay enabled despite they were disabled in the LINK_DOWN event handler.
2) Protect statistics ramrod sending code and a statistics counter
update with a spin lock. Otherwise there was a race condition that would
allow sending a statistics ramrods with the same sequence number or with
sequence numbers not in a natural order, which would cause a FW assert.
Thanks,
vlad
^ permalink raw reply
* [PATCH 1/3 net-2.6] bnx2x: Protect a SM state change
From: Vladislav Zolotarov @ 2010-07-21 15:59 UTC (permalink / raw)
To: Dave Miller; +Cc: netdev list, Eilon Greenstein, Dmitry Kravkov
Bug fix: Protect the statistics state machine state update with a spinlock.
Otherwise there was a race condition that would cause the statistics stay
enabled despite they were disabled in the LINK_DOWN event handler.
Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x.h | 4 ++++
drivers/net/bnx2x_main.c | 11 +++++++----
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/net/bnx2x.h b/drivers/net/bnx2x.h
index 8bd2368..bb0872a 100644
--- a/drivers/net/bnx2x.h
+++ b/drivers/net/bnx2x.h
@@ -1062,6 +1062,10 @@ struct bnx2x {
/* used to synchronize stats collecting */
int stats_state;
+
+ /* used for synchronization of concurrent threads statistics handling */
+ spinlock_t stats_lock;
+
/* used by dmae command loader */
struct dmae_command stats_dmae;
int executer_idx;
diff --git a/drivers/net/bnx2x_main.c b/drivers/net/bnx2x_main.c
index 57ff5b3..3dc876c 100644
--- a/drivers/net/bnx2x_main.c
+++ b/drivers/net/bnx2x_main.c
@@ -4849,16 +4849,18 @@ static const struct {
static void bnx2x_stats_handle(struct bnx2x *bp, enum bnx2x_stats_event event)
{
- enum bnx2x_stats_state state = bp->stats_state;
+ enum bnx2x_stats_state state;
if (unlikely(bp->panic))
return;
- bnx2x_stats_stm[state][event].action(bp);
+ /* Protect a state change flow */
+ spin_lock_bh(&bp->stats_lock);
+ state = bp->stats_state;
bp->stats_state = bnx2x_stats_stm[state][event].next_state;
+ spin_unlock_bh(&bp->stats_lock);
- /* Make sure the state has been "changed" */
- smp_wmb();
+ bnx2x_stats_stm[state][event].action(bp);
if ((event != STATS_EVENT_UPDATE) || netif_msg_timer(bp))
DP(BNX2X_MSG_STATS, "state %d -> event %d -> state %d\n",
@@ -9908,6 +9910,7 @@ static int __devinit bnx2x_init_bp(struct bnx2x *bp)
mutex_init(&bp->port.phy_mutex);
mutex_init(&bp->fw_mb_mutex);
+ spin_lock_init(&bp->stats_lock);
#ifdef BCM_CNIC
mutex_init(&bp->cnic_mutex);
#endif
--
1.7.1
^ permalink raw reply related
* [PATCH 2/3 net-2.6] bnx2x: Protect statistics ramrod and sequence number
From: Vladislav Zolotarov @ 2010-07-21 15:59 UTC (permalink / raw)
To: Dave Miller; +Cc: netdev list, Eilon Greenstein, Dmitry Kravkov
Bug fix: Protect statistics ramrod sending code and a statistics counter update
with a spinlock. Otherwise there was a race condition that would allow sending
a statistics ramrods with the same sequence number or with sequence numbers not
in a natural order, which would cause a FW assert.
Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x_main.c | 27 ++++++++++++++++++---------
1 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/net/bnx2x_main.c b/drivers/net/bnx2x_main.c
index 3dc876c..b86e47b 100644
--- a/drivers/net/bnx2x_main.c
+++ b/drivers/net/bnx2x_main.c
@@ -3789,6 +3789,8 @@ static void bnx2x_storm_stats_post(struct bnx2x *bp)
struct eth_query_ramrod_data ramrod_data = {0};
int i, rc;
+ spin_lock_bh(&bp->stats_lock);
+
ramrod_data.drv_counter = bp->stats_counter++;
ramrod_data.collect_port = bp->port.pmf ? 1 : 0;
for_each_queue(bp, i)
@@ -3802,6 +3804,8 @@ static void bnx2x_storm_stats_post(struct bnx2x *bp)
bp->spq_left++;
bp->stats_pending = 1;
}
+
+ spin_unlock_bh(&bp->stats_lock);
}
}
@@ -4367,6 +4371,14 @@ static int bnx2x_storm_stats_update(struct bnx2x *bp)
struct host_func_stats *fstats = bnx2x_sp(bp, func_stats);
struct bnx2x_eth_stats *estats = &bp->eth_stats;
int i;
+ u16 cur_stats_counter;
+
+ /* Make sure we use the value of the counter
+ * used for sending the last stats ramrod.
+ */
+ spin_lock_bh(&bp->stats_lock);
+ cur_stats_counter = bp->stats_counter - 1;
+ spin_unlock_bh(&bp->stats_lock);
memcpy(&(fstats->total_bytes_received_hi),
&(bnx2x_sp(bp, func_stats_base)->total_bytes_received_hi),
@@ -4394,25 +4406,22 @@ static int bnx2x_storm_stats_update(struct bnx2x *bp)
u32 diff;
/* are storm stats valid? */
- if ((u16)(le16_to_cpu(xclient->stats_counter) + 1) !=
- bp->stats_counter) {
+ if (le16_to_cpu(xclient->stats_counter) != cur_stats_counter) {
DP(BNX2X_MSG_STATS, "[%d] stats not updated by xstorm"
" xstorm counter (0x%x) != stats_counter (0x%x)\n",
- i, xclient->stats_counter, bp->stats_counter);
+ i, xclient->stats_counter, cur_stats_counter + 1);
return -1;
}
- if ((u16)(le16_to_cpu(tclient->stats_counter) + 1) !=
- bp->stats_counter) {
+ if (le16_to_cpu(tclient->stats_counter) != cur_stats_counter) {
DP(BNX2X_MSG_STATS, "[%d] stats not updated by tstorm"
" tstorm counter (0x%x) != stats_counter (0x%x)\n",
- i, tclient->stats_counter, bp->stats_counter);
+ i, tclient->stats_counter, cur_stats_counter + 1);
return -2;
}
- if ((u16)(le16_to_cpu(uclient->stats_counter) + 1) !=
- bp->stats_counter) {
+ if (le16_to_cpu(uclient->stats_counter) != cur_stats_counter) {
DP(BNX2X_MSG_STATS, "[%d] stats not updated by ustorm"
" ustorm counter (0x%x) != stats_counter (0x%x)\n",
- i, uclient->stats_counter, bp->stats_counter);
+ i, uclient->stats_counter, cur_stats_counter + 1);
return -4;
}
--
1.7.1
^ permalink raw reply related
* [PATCH 3/3 net-2.6] bnx2x: Advance a module version
From: Vladislav Zolotarov @ 2010-07-21 15:59 UTC (permalink / raw)
To: Dave Miller; +Cc: netdev list, Eilon Greenstein, Dmitry Kravkov
Advance a module version to 1.52.53-2.
Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x_main.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bnx2x_main.c b/drivers/net/bnx2x_main.c
index b86e47b..46167c0 100644
--- a/drivers/net/bnx2x_main.c
+++ b/drivers/net/bnx2x_main.c
@@ -57,8 +57,8 @@
#include "bnx2x_init_ops.h"
#include "bnx2x_dump.h"
-#define DRV_MODULE_VERSION "1.52.53-1"
-#define DRV_MODULE_RELDATE "2010/18/04"
+#define DRV_MODULE_VERSION "1.52.53-2"
+#define DRV_MODULE_RELDATE "2010/21/07"
#define BNX2X_BC_VER 0x040200
#include <linux/firmware.h>
--
1.7.1
^ permalink raw reply related
* Re: [Uclinux-dist-devel] [PATCH 2/2] net: dsa: introduce MICREL KSZ8893MQL/BL ethernet switch chip support
From: Mike Frysinger @ 2010-07-21 16:05 UTC (permalink / raw)
To: Lennert Buytenhek
Cc: Karl Beldan, netdev, uclinux-dist-devel, David S. Miller
In-Reply-To: <20100721151608.GM21121@mail.wantstofly.org>
On Wed, Jul 21, 2010 at 11:16, Lennert Buytenhek wrote:
> On Wed, Jul 21, 2010 at 09:37:22AM -0400, Mike Frysinger wrote:
>> +static int ksz8893m_setup(struct dsa_switch *ds)
>> +{
>> + int i;
>> + int ret;
>> +
>> + ret = ksz8893m_switch_reset(ds);
>> + if (ret < 0)
>> + return ret;
>
> It's pretty ugly that the mdiobus is passed in via the normal means,
> but a reference to the SPI bus to use is just stuffed into some global
> variable.
>
> Can you not access all registers via MII?
it depends on the host mdio bus. if it supports the semi-standard
behavior of toggling the OP field of MDIO frames, then yes, you can do
it via MII. but i dont think the current mdio framework in the kernel
keeps track of that functionality, so there isnt a way in the driver
to say "is this possible, else fall back to SPI".
certainly the part that was used to develop this driver does not
support this behavior thus SPI is the only way of accessing the
extended registers. i guess the driver could be extended so that
people could pick which mode they want to program the registers via
platform resources, but we have no way of testing that, so i say let
the person who actually can use & wants that functionality implement
it.
> (If not, struct dsa_chip_data will need go be extended with another
> struct device pointer that we can use to find the spi bus with.)
if the framework supports, i can convert the driver to it, but i'm not
sure we have the time atm to tackle reworking common frameworks.
>> +static int ksz8893m_port_to_phy_addr(int port)
>> +{
>> + if (port >= 1 && port <= KSZ8893M_PORT_NUM)
>> + return port;
>> +
>> + pr_warning("use default phy addr 3\n");
>> + return 3;
>
> Does this ever happen? You should just be able to return -1 here, IMHO.
i dont recall seeing a warning, but presumably if it it did occur,
something else needs fixing. so -1 is OK.
>> +/* MII Basic Control */
>> +#define SOFT_RESET 0x8000
>> +#define LOOPBACK 0x4000
>> +#define FORCE_100 0x2000
>> +#define AN_ENABLE 0x1000
>> +#define POWER_DOWN 0x0800
>> +#define ISOLATE 0x0400
>> +#define RESTART_AN 0x0200
>> +#define FORCE_FULL_DUPLEX 0x0100
>> +#define COLLISION_TEST 0x0080
>
> This part of the MII register is standard, and there are BMCR_*
> definitions for this in mii.h, no need to duplicate them.
most are copies of the MII headers, so i just converted them all and
punted the rest
>> +#define FAMILY_ID 0x88
>> +#define START_SWITCH 0x01
>> +#define TAG_INSERTION 0x04
>> +#define SPECIAL_TPID_MODE 0x01
>
> It would be nice to mention what registers these bitfields are part of.
done
>> +enum switch_phy_reg {
>> + /* Global Registers: 0-15 */
>> + ChipID0 = 0,
>> + ChipID1_StartSwitch,
>> + GlobalControl0,
>
> And here, just define the registers you need only.
i'm not sure that's necessary ... having the complete register layout
is useful for people who want to extend in the future
-mike
^ permalink raw reply
* Re: [PATCH] LSM: Add post accept() hook.
From: Paul Moore @ 2010-07-21 16:06 UTC (permalink / raw)
To: Tetsuo Handa
Cc: davem, eric.dumazet, jmorris, sam, serge, netdev,
linux-security-module
In-Reply-To: <201007210200.o6L20qjv025112@www262.sakura.ne.jp>
On 07/20/10 22:00, Tetsuo Handa wrote:
> Paul Moore wrote:
>> On Monday, July 19, 2010 09:36:31 pm Tetsuo Handa wrote:
>>> One is for dropping connections from unwanted hosts. Administrators define
>>> policy before enabling enforcing mode (the mode which connections are
>>> dropped if operation was not granted by policy). Administrators specify
>>> acceptable hosts (i.e. hosts which this host needs to communicate with)
>>> and unacceptable hosts (i.e. hosts which this host needn't to communicate
>>> with).
>>
>> You can enforce per-host access controls without the need for a post-accept()
>> hooks, e.g. security_sock_rcv_skb() and the netfilter hooks
>> (NF_INET_POST_ROUTING, NF_INET_FORWARD, NF_INET_LOCAL_OUT). Or are you
>> interested in controlling which hosts an _application_ can communicate with?
>
> I'm interested in controlling which ports on which hosts a _process_ can
> communicate with. In TOMOYO's words, "processes that belong to which TOMOYO's
> domain can communicate with which ports on which hosts".
...
>>> Dropping connections would happen if some process was hijacked and the
>>> process attempted to communicate with other processes using TCP
>>> connections. But dropping connections should not happen in normal
>>> circumstance.
>>
>> It doesn't matter if dropping connections is normal or not, what matters is
>> that it can happen.
>>
>>> The other is for updating process's state variable upon accept() operation.
>>> LKM version of TOMOYO has per a task_struct variable that is used for
>>> implementing stateful permissions. (As of now, not implemented for LSM
>>> version of TOMOYO.)
>>
>> I'm open to re-introducing a post-accept() hook that does not have a return
>> value, in other words, a hook that can only be used to update LSM state and
>> not affect the connection. Although I do think you could probably achieve the
>> same thing using some of the existing LSM hooks (look at how SELinux updates
>> its state upon accept()) but that is something you would have to look it and
>> see if it works for TOMOYO.
>
> I can't figure out why the hook must not affect the connection.
> Is it possible to clarify using below players?
I understand what you are trying to accomplish and my concern is that
(using the example below) ClientApp1 has it's connection with Server1
dropped suddenly _after_ Server1 successfully completes the TCP
handshake. I've stated this concern several times. I would much prefer
you reject the incoming connection during the initial TCP handshake.
> Server1 and Client1 are hosts which are connected on TCP/IP network.
> ServerApp1 and ServerApp2 are applications running on Server1 which might call
> socket(), bind(), listen(), accept(), send(), recv(), shutdown(), close() and
> execute().
> ClientApp1 and ClientApp2 are applications running on Client1 which might call
> socket(), connect(), send(), recv(), shutdown(), close().
> Router1 and Router2 are routers which exist between Server1 and Client1.
>
> +-------+ +-------+ +-------+ +-------+
> |Server1|---|Router1|---|Router2|---|Client1|
> +-------+ +-------+ +-------+ +-------+
...
> Router1 and Router2 can inject RST into the already established connections
> at any time (if they are IDS/IPS or broken or malicious).
> How does security_socket_post_accept() returning an error differs from these
> routers injecting RST?
We can't control all of the different intermediate nodes on a given
network path and it is true that some of these intermediate nodes
sometimes do "Bad Things" to network traffic (due either to limitations
in the design, placement in the network or poor implementation).
However, just because other nodes do "Bad Things" does not mean we need
to allow "Bad Things" to happen in the Linux end nodes.
--
paul moore
linux @ hp
^ permalink raw reply
* Re: [Uclinux-dist-devel] [PATCH 1/2] net: dsa: introduce STPID switch tagging handling code
From: Mike Frysinger @ 2010-07-21 16:08 UTC (permalink / raw)
To: Lennert Buytenhek
Cc: Karl Beldan, netdev, uclinux-dist-devel, David S. Miller
In-Reply-To: <20100721153531.GN21121@mail.wantstofly.org>
On Wed, Jul 21, 2010 at 11:35, Lennert Buytenhek wrote:
> On Wed, Jul 21, 2010 at 11:29:30AM -0400, Mike Frysinger wrote:
>> >> + source_port = dsa_header[1] & 0x03;
>> >> + if (source_port >= DSA_MAX_PORTS || ds->ports[source_port] == NULL)
>> >> + goto out_drop;
>> >> +
>> >> + if (((dsa_header[0] & ETH_P_8021QH) == ETH_P_8021QH) &&
>> >
>> > This is bogus -- what it does is:
>> >
>> > if ((dsa_header[0] & 0x81) == 0x81)
>> >
>> > It doesn't look like you need to mask here at all.
>>
>> where does it say dsa_header[0] will always have 0x81 set ?
>
> Eh?
>
> This code is checking whether the packet has a STPID tag on it or not.
> A STPID tag exists if the first 12 nibbles are 0x810.
>
> You are checking whether the first 8 nibbles of this are equal to 0x81
> by doing:
>
> if ((byte & 0x81) == 0x81)
>
> What if the first byte is 0x93? Or 0xc5?
that was my point. should it be masking or doing a raw compare ?
i have nfc as i had nothing to do with the creation of this code. i
dont know the first thing about VLAN tags or anything else at that
level.
-mike
^ permalink raw reply
* [PATCH] Add missing read memory barrier to Intel Ethernet device drivers
From: Sonny Rao @ 2010-07-21 16:22 UTC (permalink / raw)
To: netdev; +Cc: e1000-devel
From: Milton Miller <miltonm@bga.com>
The PowerPC architecture does not require loads to independent bytes to be
ordered without adding an explicit barrier.
In ixgbe_clean_rx_irq we load the status bit then load the packet data.
With packet split disabled if these loads go out of order we get a
stale packet, but we will notice the bad sequence numbers and drop it.
The problem occurs with packet split enabled where the TCP/IP header and data
are in different descriptors. If the reads go out of order we may have data
that doesn't match the TCP/IP header. Since we use hardware checksumming this
bad data is never verified and it makes it all the way to the application.
This bug was found during stress testing and adding this barrier has been shown
to fix it. The bug can manifest as a data integrity issue (bad payload data)
or as a BUG in skb_pull().
This was a nasty bug to hunt down, if people agree with the fix I think
it's a candidate for stable.
Previously Submitted to e1000-devel only for ixgbe
http://marc.info/?l=e1000-devel&m=126593062701537&w=3
We've now seen this problem hit with other device drivers (e1000e mostly)
So I'm resubmitting with fixes for other Intel Device Drivers with
similar issues: ixgb, e100, e1000, and e1000e
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Sonny Rao <sonnyrao@us.ibm.com>
cc: stable <stable@kernel.org>
---
Index: linux-2.6.35-rc5/drivers/net/e1000/e1000_main.c
===================================================================
--- linux-2.6.35-rc5.orig/drivers/net/e1000/e1000_main.c 2010-07-21 11:19:47.000000000 -0500
+++ linux-2.6.35-rc5/drivers/net/e1000/e1000_main.c 2010-07-21 11:19:58.000000000 -0500
@@ -3448,6 +3448,7 @@ static bool e1000_clean_tx_irq(struct e1
while ((eop_desc->upper.data & cpu_to_le32(E1000_TXD_STAT_DD)) &&
(count < tx_ring->count)) {
bool cleaned = false;
+ rmb(); /* read buffer_info after eop_desc */
for ( ; !cleaned; count++) {
tx_desc = E1000_TX_DESC(*tx_ring, i);
buffer_info = &tx_ring->buffer_info[i];
Index: linux-2.6.35-rc5/drivers/net/e1000e/netdev.c
===================================================================
--- linux-2.6.35-rc5.orig/drivers/net/e1000e/netdev.c 2010-07-21 11:19:47.000000000 -0500
+++ linux-2.6.35-rc5/drivers/net/e1000e/netdev.c 2010-07-21 11:19:58.000000000 -0500
@@ -984,6 +984,7 @@ static bool e1000_clean_tx_irq(struct e1
while ((eop_desc->upper.data & cpu_to_le32(E1000_TXD_STAT_DD)) &&
(count < tx_ring->count)) {
bool cleaned = false;
+ rmb(); /* read buffer_info after eop_desc */
for (; !cleaned; count++) {
tx_desc = E1000_TX_DESC(*tx_ring, i);
buffer_info = &tx_ring->buffer_info[i];
Index: linux-2.6.35-rc5/drivers/net/ixgb/ixgb_main.c
===================================================================
--- linux-2.6.35-rc5.orig/drivers/net/ixgb/ixgb_main.c 2010-07-21 11:19:47.000000000 -0500
+++ linux-2.6.35-rc5/drivers/net/ixgb/ixgb_main.c 2010-07-21 11:19:58.000000000 -0500
@@ -1816,6 +1816,7 @@ ixgb_clean_tx_irq(struct ixgb_adapter *a
while (eop_desc->status & IXGB_TX_DESC_STATUS_DD) {
+ rmb(); /* read buffer_info after eop_desc */
for (cleaned = false; !cleaned; ) {
tx_desc = IXGB_TX_DESC(*tx_ring, i);
buffer_info = &tx_ring->buffer_info[i];
Index: linux-2.6.35-rc5/drivers/net/e100.c
===================================================================
--- linux-2.6.35-rc5.orig/drivers/net/e100.c 2010-07-21 11:19:47.000000000 -0500
+++ linux-2.6.35-rc5/drivers/net/e100.c 2010-07-21 11:20:04.000000000 -0500
@@ -1779,6 +1779,7 @@ static int e100_tx_clean(struct nic *nic
for (cb = nic->cb_to_clean;
cb->status & cpu_to_le16(cb_complete);
cb = nic->cb_to_clean = cb->next) {
+ rmb(); /* read skb after status */
netif_printk(nic, tx_done, KERN_DEBUG, nic->netdev,
"cb[%d]->status = 0x%04X\n",
(int)(((void*)cb - (void*)nic->cbs)/sizeof(struct cb)),
Index: linux-2.6.35-rc5/drivers/net/ixgbe/ixgbe_main.c
===================================================================
--- linux-2.6.35-rc5.orig/drivers/net/ixgbe/ixgbe_main.c 2010-07-21 11:19:47.000000000 -0500
+++ linux-2.6.35-rc5/drivers/net/ixgbe/ixgbe_main.c 2010-07-21 11:19:58.000000000 -0500
@@ -748,6 +748,7 @@ static bool ixgbe_clean_tx_irq(struct ix
while ((eop_desc->wb.status & cpu_to_le32(IXGBE_TXD_STAT_DD)) &&
(count < tx_ring->work_limit)) {
bool cleaned = false;
+ rmb(); /* read buffer_info after eop_desc */
for ( ; !cleaned; count++) {
struct sk_buff *skb;
tx_desc = IXGBE_TX_DESC_ADV(*tx_ring, i);
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* [PATCH 2/2 v2] net: dsa: introduce MICREL KSZ8893MQL/BL ethernet switch chip support
From: Mike Frysinger @ 2010-07-21 16:29 UTC (permalink / raw)
To: netdev, David S. Miller
Cc: uclinux-dist-devel, Karl Beldan, Lennert Buytenhek, Graf Yang,
Bryan Wu
In-Reply-To: <1279719442-10174-2-git-send-email-vapier@gentoo.org>
From: Graf Yang <graf.yang@analog.com>
Signed-off-by: Graf Yang <graf.yang@analog.com>
Signed-off-by: Bryan Wu <cooloney@kernel.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
v2
- clean up header duplication
net/dsa/Kconfig | 7 +
net/dsa/Makefile | 1 +
net/dsa/ksz8893m.c | 341 ++++++++++++++++++++++++++++++++++++++++++++++++++++
net/dsa/ksz8893m.h | 163 +++++++++++++++++++++++++
4 files changed, 512 insertions(+), 0 deletions(-)
create mode 100644 net/dsa/ksz8893m.c
create mode 100644 net/dsa/ksz8893m.h
diff --git a/net/dsa/Kconfig b/net/dsa/Kconfig
index ee8d705..4a87436 100644
--- a/net/dsa/Kconfig
+++ b/net/dsa/Kconfig
@@ -60,4 +60,11 @@ config NET_DSA_MV88E6123_61_65
This enables support for the Marvell 88E6123/6161/6165
ethernet switch chips.
+config NET_DSA_KSZ8893M
+ bool "MICREL KSZ8893MQL/BL ethernet switch chip support"
+ select NET_DSA_TAG_STPID
+ ---help---
+ This enables support for the Micrel KSZ8893MQL/BL
+ ethernet switch chips.
+
endif
diff --git a/net/dsa/Makefile b/net/dsa/Makefile
index 4881577..c4295e3 100644
--- a/net/dsa/Makefile
+++ b/net/dsa/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_NET_DSA_MV88E6XXX) += mv88e6xxx.o
obj-$(CONFIG_NET_DSA_MV88E6060) += mv88e6060.o
obj-$(CONFIG_NET_DSA_MV88E6123_61_65) += mv88e6123_61_65.o
obj-$(CONFIG_NET_DSA_MV88E6131) += mv88e6131.o
+obj-$(CONFIG_NET_DSA_KSZ8893M) += ksz8893m.o
# the core
obj-$(CONFIG_NET_DSA) += dsa.o slave.o
diff --git a/net/dsa/ksz8893m.c b/net/dsa/ksz8893m.c
new file mode 100644
index 0000000..0bfa193
--- /dev/null
+++ b/net/dsa/ksz8893m.c
@@ -0,0 +1,341 @@
+/*
+ * Integrated 3-Port 10/100 Managed Switch with PHYs
+ *
+ * - KSZ8893M support
+ *
+ * Copyright 2008-2010 Analog Devices Inc.
+ *
+ * Licensed under the GPL-2 or later.
+ */
+
+#define pr_fmt(fmt) "ksz8893m: " fmt
+
+#include <linux/list.h>
+#include <linux/netdevice.h>
+#include <linux/phy.h>
+#include <linux/spi/spi.h>
+#include "dsa_priv.h"
+#include "ksz8893m.h"
+
+#define BUF_LEN 6
+
+static struct _spi_switch {
+ struct spi_transfer xfer;
+ struct spi_device *dev;
+} sw;
+
+static int ksz8893m_read(unsigned char *din, unsigned char reg, int len)
+{
+ int i, ret;
+ struct spi_message message;
+ unsigned char dout[BUF_LEN];
+ struct spi_transfer *t = &sw.xfer;
+
+ t->len = len;
+ t->tx_buf = dout;
+ t->rx_buf = din;
+ dout[0] = SPI_READ;
+ dout[1] = reg;
+ for (i = 2; i < len; i++)
+ dout[i] = 0;
+
+ spi_message_init(&message);
+ spi_message_add_tail(t, &message);
+ ret = spi_sync(sw.dev, &message);
+ if (!ret)
+ return message.status;
+
+ pr_err("read reg%d failed, ret=%d\n", reg, ret);
+ return ret;
+}
+
+static int ksz8893m_write(unsigned char *dout, unsigned char reg, int len)
+{
+ int ret;
+ struct spi_message message;
+ unsigned char din[BUF_LEN];
+ struct spi_transfer *t = &sw.xfer;
+
+ t->len = len;
+ t->tx_buf = dout;
+ t->rx_buf = din;
+ dout[0] = SPI_WRITE;
+ dout[1] = reg;
+
+ spi_message_init(&message);
+ spi_message_add_tail(t, &message);
+ ret = spi_sync(sw.dev, &message);
+ if (!ret)
+ return message.status;
+
+ pr_err("write reg%d failed, ret=%d\n", reg, ret);
+ return ret;
+}
+
+static char *ksz8893m_probe(struct mii_bus *bus, int sw_addr)
+{
+ int ret, phyid_low, phyid_high;
+ unsigned char din[BUF_LEN];
+
+ phyid_high = mdiobus_read(bus, KSZ8893M_CPU_PORT, MII_PHYSID1);
+ phyid_low = mdiobus_read(bus, KSZ8893M_CPU_PORT, MII_PHYSID2);
+ if (phyid_high != PHYID_HIGH || phyid_low != PHYID_LOW)
+ return NULL;
+
+ ret = ksz8893m_read(din, ChipID0, 3);
+
+ if (!ret && FAMILY_ID == din[2])
+ return "KSZ8893M";
+
+ return NULL;
+}
+
+static int ksz8893m_switch_reset(struct dsa_switch *ds)
+{
+ return 0;
+}
+
+static int ksz8893m_setup_global(struct dsa_switch *ds)
+{
+ int ret;
+ unsigned char dout[BUF_LEN];
+ unsigned char din[BUF_LEN];
+
+ /* Set VLAN VID of port1 */
+ ret = ksz8893m_read(din, Port1Control3, 3);
+ if (ret)
+ return ret;
+ din[2] &= 0xf0;
+ dout[2] = (DEFAULT_PORT_VID & 0xfff) >> 8 | din[2];
+ dout[3] = DEFAULT_PORT_VID & 0xff;
+ ret = ksz8893m_write(dout, Port1Control3, 4);
+ if (ret)
+ return ret;
+
+ /* Set VLAN VID of port2 */
+ ret = ksz8893m_read(din, Port2Control3, 3);
+ if (ret)
+ return ret;
+ din[2] &= 0xf0;
+ dout[2] = (DEFAULT_PORT_VID & 0xfff) >> 8 | din[2];
+ dout[3] = DEFAULT_PORT_VID & 0xff;
+ ret = ksz8893m_write(dout, Port2Control3, 4);
+ if (ret)
+ return ret;
+
+ /* Set VLAN VID of port3 */
+ ret = ksz8893m_read(din, Port3Control3, 3);
+ if (ret)
+ return ret;
+ din[2] &= 0xf0;
+ dout[2] = (DEFAULT_PORT_VID & 0xfff) >> 8 | din[2];
+ dout[3] = DEFAULT_PORT_VID & 0xff;
+ ret = ksz8893m_write(dout, Port3Control3, 4);
+ if (ret)
+ return ret;
+
+ /* Insert VLAN tag that egress Port3 */
+ ret = ksz8893m_read(din, Port3Control0, 3);
+ if (ret)
+ return ret;
+ dout[2] = TAG_INSERTION | din[2];
+ ret = ksz8893m_write(dout, Port3Control0, 3);
+ if (ret)
+ return ret;
+
+ /* Enable STPID Mode */
+ ret = ksz8893m_read(din, GlobalControl9, 3);
+ if (ret)
+ return ret;
+ dout[2] = SPECIAL_TPID_MODE | din[2];
+ ret = ksz8893m_write(dout, GlobalControl9, 3);
+ if (ret)
+ return ret;
+
+ /* Start switch */
+ dout[2] = START_SWITCH;
+ ret = ksz8893m_write(dout, ChipID1_StartSwitch, 3);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int ksz8893m_setup_port(struct dsa_switch *ds, int p)
+{
+ int val, ret;
+ val = mdiobus_read(ds->master_mii_bus, p, MII_BMCR);
+ if (val < 0)
+ return val;
+ val |= BMCR_ANENABLE | BMCR_SPEED100 | BMCR_FULLDPLX;
+ val &= ~(BMCR_PDOWN | DISABLE_MDIX | DIS_FAR_END_FAULT |
+ DISABLE_TRANSMIT | DISABLE_LED);
+ ret = mdiobus_write(ds->master_mii_bus, p, MII_BMCR, val);
+ if (ret < 0)
+ return ret;
+
+ val = mdiobus_read(ds->master_mii_bus, p, MII_ADVERTISE);
+ if (val < 0)
+ return val;
+ val |= ADVERTISE_10HALF | ADVERTISE_10FULL |
+ ADVERTISE_100HALF | ADVERTISE_100FULL;
+ ret = mdiobus_write(ds->master_mii_bus, p, MII_ADVERTISE, val);
+ if (ret < 0)
+ return ret;
+ return 0;
+}
+
+static int ksz8893m_setup(struct dsa_switch *ds)
+{
+ int i;
+ int ret;
+
+ ret = ksz8893m_switch_reset(ds);
+ if (ret < 0)
+ return ret;
+
+ ret = ksz8893m_setup_global(ds);
+ if (ret < 0)
+ return ret;
+
+ for (i = 1; i < KSZ8893M_PORT_NUM; i++) {
+ ret = ksz8893m_setup_port(ds, i);
+ if (ret < 0)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int ksz8893m_set_addr(struct dsa_switch *ds, u8 *addr)
+{
+ return 0;
+}
+
+static int ksz8893m_port_to_phy_addr(int port)
+{
+ if (port >= 1 && port <= KSZ8893M_PORT_NUM)
+ return port;
+ return -1;
+}
+
+static int
+ksz8893m_phy_read(struct dsa_switch *ds, int port, int regnum)
+{
+ int phy_addr = ksz8893m_port_to_phy_addr(port);
+ return mdiobus_read(ds->master_mii_bus, phy_addr, regnum);
+}
+
+static int
+ksz8893m_phy_write(struct dsa_switch *ds,
+ int port, int regnum, u16 val)
+{
+ int phy_addr = ksz8893m_port_to_phy_addr(port);
+ return mdiobus_write(ds->master_mii_bus, phy_addr, regnum, val);
+}
+
+static void ksz8893m_poll_link(struct dsa_switch *ds)
+{
+ int i;
+
+ for (i = 1; i < KSZ8893M_PORT_NUM; i++) {
+ struct net_device *dev;
+ int val, link;
+
+ dev = ds->ports[i];
+ if (dev == NULL)
+ continue;
+
+ link = 0;
+ if (dev->flags & IFF_UP) {
+ val = mdiobus_read(ds->master_mii_bus, i, MII_BMSR);
+ if (val < 0)
+ continue;
+
+ link = val & BMSR_LSTATUS;
+ }
+
+ if (!link) {
+ if (netif_carrier_ok(dev)) {
+ printk(KERN_INFO "%s: link down\n", dev->name);
+ netif_carrier_off(dev);
+ }
+ continue;
+ }
+
+ val = mdiobus_read(ds->master_mii_bus, i, MII_BMSR);
+ if (val < 0)
+ continue;
+
+ if (!netif_carrier_ok(dev)) {
+ printk(KERN_INFO "%s: link up, %d Mb/s, %s duplex\n",
+ dev->name,
+ (val & LPA_100) ? 100 : 10,
+ (val & LPA_DUPLEX) ? "half" : "full");
+ netif_carrier_on(dev);
+ }
+ }
+}
+
+static int __devinit spi_switch_probe(struct spi_device *spi)
+{
+ if (sw.dev) {
+ pr_err("only one instance supported at a time\n");
+ return 1;
+ }
+ memset(&sw.xfer, 0, sizeof(sw.xfer));
+ sw.dev = spi;
+ return 0;
+}
+
+static int __devexit spi_switch_remove(struct spi_device *spi)
+{
+ sw.dev = NULL;
+ return 0;
+}
+
+static struct spi_driver spi_switch_driver = {
+ .driver = {
+ .name = "ksz8893m",
+ .bus = &spi_bus_type,
+ .owner = THIS_MODULE,
+ },
+ .probe = spi_switch_probe,
+ .remove = __devexit_p(spi_switch_remove),
+};
+
+static struct dsa_switch_driver ksz8893m_switch_driver = {
+ .tag_protocol = __constant_htons(ETH_P_STPID),
+ .probe = ksz8893m_probe,
+ .setup = ksz8893m_setup,
+ .set_addr = ksz8893m_set_addr,
+ .phy_read = ksz8893m_phy_read,
+ .phy_write = ksz8893m_phy_write,
+ .poll_link = ksz8893m_poll_link,
+};
+
+static int __init ksz8893m_init(void)
+{
+ int ret;
+
+ ret = spi_register_driver(&spi_switch_driver);
+ if (ret) {
+ pr_err("can't register driver\n");
+ return ret;
+ }
+
+ register_switch_driver(&ksz8893m_switch_driver);
+ return 0;
+}
+module_init(ksz8893m_init);
+
+static void __exit ksz8893m_cleanup(void)
+{
+ spi_unregister_driver(&spi_switch_driver);
+ unregister_switch_driver(&ksz8893m_switch_driver);
+}
+module_exit(ksz8893m_cleanup);
+
+MODULE_AUTHOR("Graf Yang <graf.yang@analog.com>");
+MODULE_DESCRIPTION("KSZ8893M driver for DSA");
+MODULE_LICENSE("GPL");
diff --git a/net/dsa/ksz8893m.h b/net/dsa/ksz8893m.h
new file mode 100644
index 0000000..30e0df0
--- /dev/null
+++ b/net/dsa/ksz8893m.h
@@ -0,0 +1,163 @@
+/*
+ * Integrated 3-Port 10/100 Managed Switch with PHYs
+ *
+ * - KSZ8893M support
+ *
+ * Copyright 2008-2010 Analog Devices Inc.
+ *
+ * Licensed under the GPL-2 or later.
+ */
+
+#ifndef __KSZ8893M_H__
+#define __KSZ8893M_H__
+
+#define KSZ8893M_PORT_NUM 3
+#define KSZ8893M_CPU_PORT 3
+
+#define DEFAULT_PORT_VID 0
+
+/* Simple SPI command set for poking registers */
+#define SPI_READ 3
+#define SPI_WRITE 2
+
+/* Expected value for MII_PHYSID1 */
+#define PHYID_HIGH 0x22
+/* Expected value for MII_PHYSID2 */
+#define PHYID_LOW 0x1430
+
+/* ChipID0 defines */
+#define FAMILY_ID 0x88
+
+/* ChipID1_StartSwitch defines */
+#define START_SWITCH 0x01
+
+/* Port3Control0 defines */
+#define TAG_INSERTION 0x04
+
+/* GlobalControl9 defines */
+#define SPECIAL_TPID_MODE 0x01
+
+/* BMCR Reserved Bits */
+#define HP_MDIX 0x0020
+#define FORCE_MDI 0x0010
+#define DISABLE_MDIX 0x0008
+#define DIS_FAR_END_FAULT 0x0004
+#define DISABLE_TRANSMIT 0x0002
+#define DISABLE_LED 0x0001
+
+/* BMSCR Reserved Bits */
+#define PREAMBLE_SUPPRESS 0x0040
+
+enum switch_phy_reg {
+ /* Global Registers: 0-15 */
+ ChipID0 = 0,
+ ChipID1_StartSwitch,
+ GlobalControl0,
+ GlobalControl1,
+ GlobalControl2, /* 4 */
+ GlobalControl3,
+ GlobalControl4,
+ GlobalControl5,
+ GlobalControl6, /* 8 */
+ GlobalControl7,
+ GlobalControl8,
+ GlobalControl9,
+ GlobalControl10, /* 12 */
+ GlobalControl11,
+ GlobalControl12,
+ GlobalControl13,
+ /* Port Registers: 16-95 */
+ Port1Control0 = 16,
+ Port1Control1,
+ Port1Control2,
+ Port1Control3,
+ Port1Control4, /* 20 */
+ Port1Control5,
+ Port1Control6,
+ Port1Control7,
+ Port1Control8, /* 24 */
+ Port1Control9,
+ Port1PHYSpecialControl_Status,
+ Port1LinkMDResult,
+ Port1Control12, /* 28 */
+ Port1Control13,
+ Port1Status0,
+ Port1Status1,
+ Port2Control0, /* 32 */
+ Port2Control1,
+ Port2Control2,
+ Port2Control3,
+ Port2Control4, /* 36 */
+ Port2Control5,
+ Port2Control6,
+ Port2Control7,
+ Port2Control8, /* 40 */
+ Port2Control9,
+ Port2PHYSpecialControl_Status,
+ Port2LinkMDResult,
+ Port2Control12, /* 44 */
+ Port2Control13,
+ Port2Status0,
+ Port2Status1,
+ Port3Control0, /* 48 */
+ Port3Control1,
+ Port3Control2,
+ Port3Control3,
+ Port3Control4, /* 52 */
+ Port3Control5,
+ Port3Control6,
+ Port3Control7,
+ Port3Control8, /* 56 */
+ Port3Control9,
+ Reservednotappliedtoport3, /* 58-62 */
+ Port3Status1 = 63,
+ /* Advanced Control Registers: 96-141 */
+ TOSPriorityControlRegister0 = 96,
+ TOSPriorityControlRegister1,
+ TOSPriorityControlRegister2,
+ TOSPriorityControlRegister3,
+ TOSPriorityControlRegister4, /* 100 */
+ TOSPriorityControlRegister5,
+ TOSPriorityControlRegister6,
+ TOSPriorityControlRegister7,
+ TOSPriorityControlRegister8, /* 104 */
+ TOSPriorityControlRegister9,
+ TOSPriorityControlRegister10,
+ TOSPriorityControlRegister11,
+ TOSPriorityControlRegister12, /* 108 */
+ TOSPriorityControlRegister13,
+ TOSPriorityControlRegister14,
+ TOSPriorityControlRegister15,
+ MACAddressRegister0 = 112,
+ MACAddressRegister1,
+ MACAddressRegister2,
+ MACAddressRegister3,
+ MACAddressRegister4,
+ MACAddressRegister5,
+ UserDefinedRegister1 = 118,
+ UserDefinedRegister2,
+ UserDefinedRegister3,
+ IndirectAccessControl0 = 121,
+ IndirectAccessControl1,
+ IndirectDataRegister8 = 123,
+ IndirectDataRegister7,
+ IndirectDataRegister6,
+ IndirectDataRegister5,
+ IndirectDataRegister4,
+ IndirectDataRegister3,
+ IndirectDataRegister2,
+ IndirectDataRegister1,
+ IndirectDataRegister0,
+ DigitalTestingStatus0 = 132,
+ DigitalTestingControl0,
+ AnalogTestingControl0,
+ AnalogTestingControl1,
+ AnalogTestingControl2,
+ AnalogTestingControl3,
+ AnalogTestingStatus,
+ AnalogTestingControl4,
+ QMDebug1,
+ QMDebug2,
+};
+
+#endif
--
1.7.1.1
^ permalink raw reply related
* Re: [PATCH net-next] sysfs: add entry to indicate network interfaces with random MAC address
From: Casey Leedom @ 2010-07-21 16:34 UTC (permalink / raw)
To: Andy Gospodarek
Cc: Harald Hoyer, David Miller, shemminger, bhutchings, sassmann,
netdev, linux-kernel, gospo, gregory.v.rose, alexander.h.duyck
In-Reply-To: <20100721150732.GR7497@gospo.rdu.redhat.com>
| From: Andy Gospodarek <andy@greyhouse.net>
| Date: Wednesday, July 21, 2010 08:07 am
|
| Agreed. The subtle difference between a locally assigned address that
| is persistent and one that is random would be helpful.
And just to point out that this case _does_ exist: the igb/igbvf drivers use
random_ether_addr() to generate a random, locally assigned MAC address for the
PCI-E SR-IOV Virtual Function MAC Addresses while the cxgb4/cxgb4vf drivers use
a persistent, non-random locally assigned MAC Addresses.
Note that I am neither arguing for nor against the proposal. I'm just
pointing out an existence case for the distinction. And yes, bit 1 being set in
the first octet of a MAC address for locally assigned MAC Addresses is part of
the IEEE 802 specification just as bit 0 being set in the same octet indicates
that it's a multi-station address.
Casey
^ permalink raw reply
* [PATCH net-2.6] ixgbe/igb: catch invalid VF settings
From: Andy Gospodarek @ 2010-07-21 16:40 UTC (permalink / raw)
To: netdev; +Cc: chrisw
Some ixgbe cards put an invalid VF device ID in the PCIe SR-IOV
capability. The ixgbe driver is only valid for PFs or non SR-IOV
hardware. It seems that the same problem could occur on igb hardware as
well, so if we discover we are trying to initialize a VF in ixbge_probe
or igb_probe, print an error and exit.
Based on a patch for ixgbe from Chris Wright <chrisw@sous-sol.org>.
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Cc: Chris Wright <chrisw@sous-sol.org>
---
drivers/net/igb/igb_main.c | 9 +++++++++
drivers/net/ixgbe/ixgbe_main.c | 9 +++++++++
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
index 3881918..cea37e0 100644
--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -1722,6 +1722,15 @@ static int __devinit igb_probe(struct pci_dev *pdev,
u16 eeprom_apme_mask = IGB_EEPROM_APME;
u32 part_num;
+ /* Catch broken hardware that put the wrong VF device ID in
+ * the PCIe SR-IOV capability.
+ */
+ if (pdev->is_virtfn) {
+ WARN(1, KERN_ERR "%s (%hx:%hx) should not be a VF!\n",
+ pci_name(pdev), pdev->vendor, pdev->device);
+ return -EINVAL;
+ }
+
err = pci_enable_device_mem(pdev);
if (err)
return err;
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index 7b5d976..74d9b6d 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -6492,6 +6492,15 @@ static int __devinit ixgbe_probe(struct pci_dev *pdev,
#endif
u32 part_num, eec;
+ /* Catch broken hardware that put the wrong VF device ID in
+ * the PCIe SR-IOV capability.
+ */
+ if (pdev->is_virtfn) {
+ WARN(1, KERN_ERR "%s (%hx:%hx) should not be a VF!\n",
+ pci_name(pdev), pdev->vendor, pdev->device);
+ return -EINVAL;
+ }
+
err = pci_enable_device_mem(pdev);
if (err)
return err;
--
1.6.2.5
^ permalink raw reply related
* Re: [PATCH 2/2] net: dsa: introduce MICREL KSZ8893MQL/BL ethernet switch chip support
From: Joe Perches @ 2010-07-21 16:40 UTC (permalink / raw)
To: Eric Dumazet
Cc: Lennert Buytenhek, Mike Frysinger, netdev, David S. Miller,
uclinux-dist-devel, Karl Beldan, Graf Yang, Bryan Wu
In-Reply-To: <1279726393.2452.60.camel@edumazet-laptop>
On Wed, 2010-07-21 at 17:33 +0200, Eric Dumazet wrote:
> It is used by all pr_err() friends
Shouldn't these drivers be moved into
something like drivers/net/dsa/ rather
than be kept in net?
The #define pr_fmt would be more standard as
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
The printks could be netdev_<level>
Suggested patches:
diff --git a/net/dsa/ksz8893m.c b/net/dsa/ksz8893m.c
index 98cce04..80fb0ac 100644
--- a/net/dsa/ksz8893m.c
+++ b/net/dsa/ksz8893m.c
@@ -8,7 +8,7 @@
* Licensed under the GPL-2 or later.
*/
-#define pr_fmt(fmt) "ksz8893m: " fmt
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/list.h>
#include <linux/netdevice.h>
@@ -42,11 +42,14 @@ static int ksz8893m_read(unsigned char *din, unsigned char reg, int len)
spi_message_init(&message);
spi_message_add_tail(t, &message);
ret = spi_sync(sw.dev, &message);
- if (!ret)
- return message.status;
+ if (ret) {
+ pr_err("read reg%d failed, ret=%d\n", reg, ret);
+ return ret;
+ }
+ if (message.status)
+ pr_err("read reg%d failed, status=%d\n", reg, message.status);
- pr_err("read reg%d failed, ret=%d\n", reg, ret);
- return ret;
+ return message.status;
}
static int ksz8893m_write(unsigned char *dout, unsigned char reg, int len)
@@ -65,11 +68,14 @@ static int ksz8893m_write(unsigned char *dout, unsigned char reg, int len)
spi_message_init(&message);
spi_message_add_tail(t, &message);
ret = spi_sync(sw.dev, &message);
- if (!ret)
- return message.status;
+ if (ret) {
+ pr_err("write reg%d failed, ret=%d\n", reg, ret);
+ return ret;
+ }
+ if (message.status)
+ pr_err("write reg%d failed, status=%d\n", reg, message.status);
- pr_err("write reg%d failed, ret=%d\n", reg, ret);
- return ret;
+ return message.status;
}
static char *ksz8893m_probe(struct mii_bus *bus, int sw_addr)
@@ -168,8 +174,8 @@ static int ksz8893m_setup_port(struct dsa_switch *ds, int p)
if (val < 0)
return val;
val |= AN_ENABLE | FORCE_100 | FORCE_FULL_DUPLEX;
- val &= ~(POWER_DOWN | DISABLE_MDIX | DIS_FAR_END_FAULT |\
- DISABLE_TRANSMIT | DISABLE_LED);
+ val &= ~(POWER_DOWN | DISABLE_MDIX | DIS_FAR_END_FAULT |
+ DISABLE_TRANSMIT | DISABLE_LED);
ret = mdiobus_write(ds->master_mii_bus, p, MII_BMCR, val);
if (ret < 0)
return ret;
@@ -228,8 +234,7 @@ ksz8893m_phy_read(struct dsa_switch *ds, int port, int regnum)
}
static int
-ksz8893m_phy_write(struct dsa_switch *ds,
- int port, int regnum, u16 val)
+ksz8893m_phy_write(struct dsa_switch *ds, int port, int regnum, u16 val)
{
int phy_addr = ksz8893m_port_to_phy_addr(port);
return mdiobus_write(ds->master_mii_bus, phy_addr, regnum, val);
@@ -263,7 +268,7 @@ static void ksz8893m_poll_link(struct dsa_switch *ds)
if (!link) {
if (netif_carrier_ok(dev)) {
- printk(KERN_INFO "%s: link down\n", dev->name);
+ netdev_info(dev, "link down\n");
netif_carrier_off(dev);
}
continue;
@@ -274,8 +279,8 @@ static void ksz8893m_poll_link(struct dsa_switch *ds)
val = mdiobus_read(ds->master_mii_bus, i, MII_BMSR);
if (val < 0)
continue;
- val &= HALF_10_CAPABLE | FULL_10_CAPABLE |\
- HALF_100_CAPABLE | FULL_100_CAPABLE;
+ val &= (HALF_10_CAPABLE | FULL_10_CAPABLE |
+ HALF_100_CAPABLE | FULL_100_CAPABLE);
if (val & FULL_100_CAPABLE) {
speed = 100;
duplex = 1;
@@ -288,8 +293,8 @@ static void ksz8893m_poll_link(struct dsa_switch *ds)
}
if (!netif_carrier_ok(dev)) {
- printk(KERN_INFO "%s: link up, %d Mb/s, %s duplex\n",
- dev->name, speed, duplex ? "full" : "half");
+ netdev_info(dev, "link up, %d Mb/s, %s duplex\n",
+ speed, duplex ? "full" : "half");
netif_carrier_on(dev);
}
}
^ permalink raw reply related
* Re: [PATCH net-2.6] ixgbe/igb: catch invalid VF settings
From: Chris Wright @ 2010-07-21 16:50 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: netdev, chrisw
In-Reply-To: <1279730431-17156-1-git-send-email-andy@greyhouse.net>
* Andy Gospodarek (andy@greyhouse.net) wrote:
> Some ixgbe cards put an invalid VF device ID in the PCIe SR-IOV
> capability. The ixgbe driver is only valid for PFs or non SR-IOV
> hardware. It seems that the same problem could occur on igb hardware as
> well, so if we discover we are trying to initialize a VF in ixbge_probe
> or igb_probe, print an error and exit.
>
> Based on a patch for ixgbe from Chris Wright <chrisw@sous-sol.org>.
>
> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
> Cc: Chris Wright <chrisw@sous-sol.org>
Acked-by: Chris Wright <chrisw@sous-sol.org>
Only seen this on ixgbe, but since the result there is a kernel panic
makes sense to be defensive.
thanks,
-chris
^ 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