* Re: [RFC 2/4] [flexcan] Introduce a flexcan_clk set of functions.
From: Robin Holt @ 2011-08-05 12:44 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, U Bhaskar-B22300,
Wolfgang Grandegger
In-Reply-To: <4E3BE23A.5080706-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Fri, Aug 05, 2011 at 02:29:46PM +0200, Marc Kleine-Budde wrote:
> On 08/05/2011 01:36 PM, Robin Holt wrote:
> > I implemented the coding style changes below (Sorry I missed the two
> > the first time).
>
> np :)
>
> > As for a better implementation, I guess I would need to understand what
> > is being attempted here. I only marginally understand the flexcan
> > hardware on the Freescale P1010 and certainly am clueless about arm
> > implementations of flexcan. I just skimmed over freescale's site
>
> The arm side is working already :)
> However we just support the busclock on ARM [1]. For the first shot
> stick to that clock, too.
>
> [1] (http://lxr.linux.no/linux+v3.0/drivers/net/can/flexcan.c#L857)
>
> > and it looks like I would be looking at their i.MX25, i.MX28, i.MX35,
> > and i.MX53 family of processors. I will attempt to find some useful
> > documentation of those and look at the kernel sources for what the clk_*
> > functions are trying to accomplish.
> >
> > I _THINK_ I understand. It looks like I could implement this as a powerpc
> > p1010 specific thing and get the same effect without impacting flexcan.c.
> > I also think I understand that the i.MX25 family of processors do
> > essentially the same thing the p1010 is doing for determining the
> > clock rate.
>
> It seems that arch/powerpc/platforms/512x/clock.c implements a clock
> interface. I think the p1010 should implement something similar. (Note:
> I'm not a ppc guy :)
>
> I'm looking forward for new patches.
I agree. I think I will have that implemented shortly after I get to the
office (about an hour for drive, etc). I think I am going to implement
a simple match on the dev_id of flexcan.0 or flexcan.1 and otherwise
return failure.
I also looked at implementing the CLOCKDEV_LOOKUP but think that is
going to drive me to drink.
Thanks,
Robin
^ permalink raw reply
* Re: [Bugme-new] [Bug 39742] New: 3.0.0 (2.6.39.3 also) kernel BUG at include/linux/skbuff.h:1189!
From: Rustam Afanasyev @ 2011-08-05 12:55 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, bugme-daemon, Patrick McHardy
In-Reply-To: <20110722144214.577718f0.akpm@linux-foundation.org>
New kernel, with "gre: fix improper error handling" applied - result
same. Please Help! Which new git tree you recommend me to testing?
------------------------------------------------
[ 4081.605966] ------------[ cut here ]------------
[ 4081.609919] kernel BUG at include/linux/skbuff.h:1189!
[ 4081.609919] invalid opcode: 0000 [#1] PREEMPT SMP
[ 4081.609919] CPU 1
[ 4081.609919] Modules linked in: cls_fw sch_sfq arc4 ecb ppp_mppe
act_mirred act_skbedit cls_u32 sch_ingress l2tp_ppp l2t
p_netlink l2tp_core pptp pppox ppp_generic slhc gre 8021q garp stp
cls_flow sch_htb ifb ipt_NETFLOW xt_mark nf_conntrack_i
pv4 nf_defrag_ipv4 xt_state xt_TCPMSS ipt_LOG xt_recent xt_NOTRACK
nf_conntrack xt_statistic ts_kmp xt_tcpudp xt_string xt
_multiport xt_set iptable_raw iptable_mangle iptable_filter ip_tables
x_tables ip_set_hash_ip ip_set_hash_net ip_set nfnet
link dm_multipath scsi_dh dm_mod psmouse sr_mod evdev pcspkr rtc_cmos
cdrom sg serio_raw i2c_i801 ehci_hcd tg3 uhci_hcd i2
c_core i3000_edac igb usbcore edac_core dca processor button ext3 jbd
mbcache sd_mod crc_t10dif ide_pci_generic ide_core p
ata_acpi ata_generic ata_piix libata scsi_mod
[ 4081.609919]
[ 4081.609919] Pid: 0, comm: kworker/0:0 Not tainted 3.0.0-un-def-alt2
#1 ASUS RS100-E4/PI2/P5M2-M/RS100-E4
[ 4081.609919] RIP: 0010:[<ffffffff8136ca2b>] [<ffffffff8136ca2b>]
skb_pull+0x2b/0x30
[ 4081.609919] RSP: 0018:ffff88011fc83ab0 EFLAGS: 00010283
[ 4081.609919] RAX: 000000000000057e RBX: ffff88011378db80 RCX:
0000000000000179
[ 4081.609919] RDX: 0000000000000179 RSI: 0000000000000002 RDI:
ffff88011378db80
[ 4081.609919] RBP: ffff88011fc83ab0 R08: 0000000000000000 R09:
0000000000000102
[ 4081.609919] R10: 0000000000000000 R11: 0000000000000001 R12:
ffff88010d0a8800
[ 4081.609919] R13: ffff88010dc4186e R14: 000000000000002f R15:
ffffffff8168dd80
[ 4081.609919] FS: 0000000000000000(0000) GS:ffff88011fc80000(0000)
knlGS:0000000000000000
[ 4081.609919] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 4081.609919] CR2: 0000000000fc10fc CR3: 0000000001625000 CR4:
00000000000006e0
[ 4081.609919] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[ 4081.609919] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[ 4081.609919] Process kworker/0:0 (pid: 0, threadinfo ffff880118f5c000,
task ffff880118f5a480)
[ 4081.609919] Stack:
[ 4081.609919] ffff88011fc83ae0 ffffffffa03267fa ffff88011fc83ae0
ffff88010d0a8800
[ 4081.609919] ffff88011378db80 ffff88010d0a8850 ffff88011fc83b10
ffffffff8136bddc
[ 4081.609919] ffff88011fc83b40 ffff88011378db80 ffff88010d0a8800
000000008b55000a
[ 4081.609919] Call Trace:
[ 4081.609919] <IRQ>
[ 4081.609919] [<ffffffffa03267fa>] pptp_rcv_core+0x21a/0x220 [pptp]
[ 4081.609919] [<ffffffff8136bddc>] sk_receive_skb+0x13c/0x160
[ 4081.609919] [<ffffffffa03261be>] pptp_rcv+0x15e/0x1b0 [pptp]
[ 4081.609919] [<ffffffffa03080e3>] gre_rcv+0x73/0xa0 [gre]
[ 4081.609919] [<ffffffff813af10d>] ip_local_deliver_finish+0xed/0x2c0
[ 4081.609919] [<ffffffff813af360>] ip_local_deliver+0x80/0x90
[ 4081.609919] [<ffffffff813ae959>] ip_rcv_finish+0x119/0x3b0
[ 4081.609919] [<ffffffff813aef4d>] ip_rcv+0x21d/0x2f0
[ 4081.609919] [<ffffffff8137cffc>] __netif_receive_skb+0x20c/0x6c0
[ 4081.609919] [<ffffffff8137dbcd>] netif_receive_skb+0xbd/0xd0
[ 4081.609919] [<ffffffff8125fcfc>] ? is_swiotlb_buffer+0x3c/0x50
[ 4081.609919] [<ffffffff8137dd30>] napi_skb_finish+0x50/0x70
[ 4081.609919] [<ffffffff8137e315>] napi_gro_receive+0xc5/0xd0
[ 4081.609919] [<ffffffffa01dbe0f>] igb_poll+0x6cf/0xb50 [igb]
[ 4081.609919] [<ffffffff8137d004>] ? __netif_receive_skb+0x214/0x6c0
[ 4081.609919] [<ffffffff8137d004>] ? __netif_receive_skb+0x214/0x6c0
[ 4081.609919] [<ffffffff8137f0d4>] net_rx_action+0x164/0x340
[ 4081.609919] [<ffffffff810684b5>] __do_softirq+0xd5/0x270
[ 4081.609919] [<ffffffff8143c89c>] call_softirq+0x1c/0x30
[ 4081.609919] [<ffffffff8100e6c5>] do_softirq+0x95/0xe0
[ 4081.609919] [<ffffffff81068305>] irq_exit+0xd5/0xf0
[ 4081.609919] [<ffffffff8100dec1>] do_IRQ+0x61/0xd0
[ 4081.609919] [<ffffffff81434753>] common_interrupt+0x13/0x13
[ 4081.609919] <EOI>
[ 4081.609919] [<ffffffff8108af60>] ? sched_clock_cpu+0xd0/0x140
[ 4081.609919] [<ffffffff81015936>] ? mwait_idle+0xe6/0x2b0
[ 4081.609919] [<ffffffff8101589a>] ? mwait_idle+0x4a/0x2b0
[ 4081.609919] [<ffffffff8100bb76>] cpu_idle+0x66/0xd0
[ 4081.609919] [<ffffffff8142c8f9>] start_secondary+0x1bf/0x1c4
[ 4081.609919] Code: 8b 47 68 55 48 89 e5 39 c6 77 1c 29 f0 3b 47 6c 89
47 68 72 16 89 f0 48 03 87 e0 00 00 00 48 89 87 e0
00 00 00 c9 c3 31 c0 c9 c3 <0f> 0b eb fe 90 55 39 77 68 48 89 e5 76 1c
8b 47 6c 85 c0 75 17
[ 4081.609919] RIP [<ffffffff8136ca2b>] skb_pull+0x2b/0x30
[ 4081.609919] RSP <ffff88011fc83ab0>
[ 4082.825070] ---[ end trace d6baf8611ae0f359 ]---
[ 4082.838992] Kernel panic - not syncing: Fatal exception in interrupt
[ 4082.858102] Pid: 0, comm: kworker/0:0 Tainted: G D
3.0.0-un-def-alt2 #1
[ 4082.881241] Call Trace:
[ 4082.888651] <IRQ> [<ffffffff81430b2a>] panic+0x96/0x1bb
[ 4082.904981] [<ffffffff8143577a>] oops_end+0x10a/0x120
[ 4082.920451] [<ffffffff8100fbf6>] die+0x56/0x90
[ 4082.934102] [<ffffffff81434e64>] do_trap+0xc4/0x170
[ 4082.949051] [<ffffffff8100d801>] do_invalid_op+0xa1/0xb0
[ 4082.965301] [<ffffffff8136ca2b>] ? skb_pull+0x2b/0x30
[ 4082.980772] [<ffffffff8106837c>] ? local_bh_enable+0x5c/0xc0
[ 4082.998067] [<ffffffffa026935a>] ? ipt_do_table+0x22a/0x640 [ip_tables]
[ 4083.018212] [<ffffffff8143c61b>] invalid_op+0x1b/0x20
[ 4083.033683] [<ffffffff8136ca2b>] ? skb_pull+0x2b/0x30
[ 4083.049153] [<ffffffffa03267fa>] pptp_rcv_core+0x21a/0x220 [pptp]
[ 4083.067742] [<ffffffff8136bddc>] sk_receive_skb+0x13c/0x160
[ 4083.084774] [<ffffffffa03261be>] pptp_rcv+0x15e/0x1b0 [pptp]
[ 4083.102064] [<ffffffffa03080e3>] gre_rcv+0x73/0xa0 [gre]
[ 4083.118314] [<ffffffff813af10d>] ip_local_deliver_finish+0xed/0x2c0
[ 4083.137425] [<ffffffff813af360>] ip_local_deliver+0x80/0x90
[ 4083.154453] [<ffffffff813ae959>] ip_rcv_finish+0x119/0x3b0
[ 4083.171223] [<ffffffff813aef4d>] ip_rcv+0x21d/0x2f0
[ 4083.186174] [<ffffffff8137cffc>] __netif_receive_skb+0x20c/0x6c0
[ 4083.204504] [<ffffffff8137dbcd>] netif_receive_skb+0xbd/0xd0
[ 4083.221795] [<ffffffff8125fcfc>] ? is_swiotlb_buffer+0x3c/0x50
[ 4083.239605] [<ffffffff8137dd30>] napi_skb_finish+0x50/0x70
[ 4083.256374] [<ffffffff8137e315>] napi_gro_receive+0xc5/0xd0
[ 4083.273412] [<ffffffffa01dbe0f>] igb_poll+0x6cf/0xb50 [igb]
[ 4083.290436] [<ffffffff8137d004>] ? __netif_receive_skb+0x214/0x6c0
[ 4083.309286] [<ffffffff8137d004>] ? __netif_receive_skb+0x214/0x6c0
[ 4083.328136] [<ffffffff8137f0d4>] net_rx_action+0x164/0x340
[ 4083.344906] [<ffffffff810684b5>] __do_softirq+0xd5/0x270
[ 4083.361157] [<ffffffff8143c89c>] call_softirq+0x1c/0x30
[ 4083.377147] [<ffffffff8100e6c5>] do_softirq+0x95/0xe0
[ 4083.392618] [<ffffffff81068305>] irq_exit+0xd5/0xf0
[ 4083.407565] [<ffffffff8100dec1>] do_IRQ+0x61/0xd0
[ 4083.421998] [<ffffffff81434753>] common_interrupt+0x13/0x13
[ 4083.439027] <EOI> [<ffffffff8108af60>] ? sched_clock_cpu+0xd0/0x140
[ 4083.458477] [<ffffffff81015936>] ? mwait_idle+0xe6/0x2b0
[ 4083.474725] [<ffffffff8101589a>] ? mwait_idle+0x4a/0x2b0
[ 4083.490976] [<ffffffff8100bb76>] cpu_idle+0x66/0xd0
[ 4083.505927] [<ffffffff8142c8f9>] start_secondary+0x1bf/0x1c4
[ 4083.523225] Rebooting in 30 seconds..
------------------------------------------------
^ permalink raw reply
* Re: return of ip_rt_bug()
From: Tom London @ 2011-08-05 13:18 UTC (permalink / raw)
To: Julian Anastasov; +Cc: Dave Jones, netdev
In-Reply-To: <alpine.LFD.2.00.1108051048160.1494@ja.ssi.bg>
On Fri, Aug 5, 2011 at 12:56 AM, Julian Anastasov <ja@ssi.bg> wrote:
>
> Hello,
>
> On Thu, 4 Aug 2011, Tom London wrote:
>
>> So, my router is just giving my wired NIC different addresses....
>>
>> More I can provide?
>
> Thanks! Can you check in dmesg or in another log
> about the first IP address in such line:
>
> printk(KERN_DEBUG "ip_rt_bug: %pI4 -> %pI4, %s\n"
>
> Is it now 192.168.2.6 ?
>
> Regards
>
> --
> Julian Anastasov <ja@ssi.bg>
>
Sorry, don't see those messages. I guess I'll have to reboot with
'debug' to see that.
Before I do that, I booted this time with the RFKILL switch set to
kill the radio (both BT and WIFI), and reran the above tests.
Here is what 'ip monitor' said:
[root@tlondon ~]# ip monitor
192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 REACHABLE
192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
ff02::fb via ff02::fb dev eth0 metric 0
cache
192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
Here is what 'inotail -f /var/log/messages' said:
Aug 5 06:12:21 tlondon kernel: [ 536.727187] usb 3-1: new full speed
USB device number 2 using uhci_hcd
Aug 5 06:12:21 tlondon kernel: [ 537.315296] usb 3-1: New USB device
found, idVendor=04b8, idProduct=010a
Aug 5 06:12:21 tlondon kernel: [ 537.315308] usb 3-1: New USB device
strings: Mfr=1, Product=2, SerialNumber=0
Aug 5 06:12:21 tlondon kernel: [ 537.315317] usb 3-1: Product: Perfection1640
Aug 5 06:12:21 tlondon kernel: [ 537.315323] usb 3-1: Manufacturer: EPSON
Aug 5 06:12:21 tlondon mtp-probe: checking bus 3, device 2:
"/sys/devices/pci0000:00/0000:00:1a.0/usb3/3-1"
Aug 5 06:12:22 tlondon mtp-probe: bus: 3, device: 2 was not an MTP device
So, no WARN_ON messages.
I'd like to conclude that this is due to UDP casting on the wlan.
I'll reboot with the radio on and in debug mode to see what happens.
tom
--
Tom London
^ permalink raw reply
* Re: return of ip_rt_bug()
From: Tom London @ 2011-08-05 13:30 UTC (permalink / raw)
To: Julian Anastasov; +Cc: Dave Jones, netdev
In-Reply-To: <CAFiZG+Wmv_FEx2ZX3qZt0tAr-QVQD_javX1gbRWujr9xyf7nbQ@mail.gmail.com>
On Fri, Aug 5, 2011 at 6:18 AM, Tom London <selinux@gmail.com> wrote:
> On Fri, Aug 5, 2011 at 12:56 AM, Julian Anastasov <ja@ssi.bg> wrote:
>>
>> Hello,
>>
>> On Thu, 4 Aug 2011, Tom London wrote:
>>
>>> So, my router is just giving my wired NIC different addresses....
>>>
>>> More I can provide?
>>
>> Thanks! Can you check in dmesg or in another log
>> about the first IP address in such line:
>>
>> printk(KERN_DEBUG "ip_rt_bug: %pI4 -> %pI4, %s\n"
>>
>> Is it now 192.168.2.6 ?
>>
>> Regards
>>
>> --
>> Julian Anastasov <ja@ssi.bg>
>>
>
> Sorry, don't see those messages. I guess I'll have to reboot with
> 'debug' to see that.
>
> Before I do that, I booted this time with the RFKILL switch set to
> kill the radio (both BT and WIFI), and reran the above tests.
>
> Here is what 'ip monitor' said:
>
> [root@tlondon ~]# ip monitor
> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 REACHABLE
> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
> ff02::fb via ff02::fb dev eth0 metric 0
> cache
> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
>
> Here is what 'inotail -f /var/log/messages' said:
>
>
> Aug 5 06:12:21 tlondon kernel: [ 536.727187] usb 3-1: new full speed
> USB device number 2 using uhci_hcd
> Aug 5 06:12:21 tlondon kernel: [ 537.315296] usb 3-1: New USB device
> found, idVendor=04b8, idProduct=010a
> Aug 5 06:12:21 tlondon kernel: [ 537.315308] usb 3-1: New USB device
> strings: Mfr=1, Product=2, SerialNumber=0
> Aug 5 06:12:21 tlondon kernel: [ 537.315317] usb 3-1: Product: Perfection1640
> Aug 5 06:12:21 tlondon kernel: [ 537.315323] usb 3-1: Manufacturer: EPSON
> Aug 5 06:12:21 tlondon mtp-probe: checking bus 3, device 2:
> "/sys/devices/pci0000:00/0000:00:1a.0/usb3/3-1"
> Aug 5 06:12:22 tlondon mtp-probe: bus: 3, device: 2 was not an MTP device
>
> So, no WARN_ON messages.
>
> I'd like to conclude that this is due to UDP casting on the wlan.
> I'll reboot with the radio on and in debug mode to see what happens.
>
> tom
> --
> Tom London
>
Hmmm, first attempt at recreating in debug mode didn't actually
produce any WARN_ON reports.
'ip monitor' did say:
[root@tlondon ~]# ip monitor
239.255.255.250 dev eth0 lladdr 01:00:5e:7f:ff:fa NOARP
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
link/ether
ff02::2 dev wlan0 lladdr 33:33:00:00:00:02 NOARP
ff02::16 dev wlan0 lladdr 33:33:00:00:00:16 NOARP
ff02::1:ffac:c692 dev wlan0 lladdr 33:33:ff:ac:c6:92 NOARP
192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
link/ether
Will try one more time.
tom
--
Tom London
^ permalink raw reply
* Re: [PATCH 1/5] Define the function to write sock's security context to seq_file.
From: Stephen Smalley @ 2011-08-05 13:32 UTC (permalink / raw)
To: rongqing.li-CWA4WttNNZF54TAoqtyWWQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, selinux-+05T5uksL2qpZYMLLGbcSA,
lsm
In-Reply-To: <1312534686-4099-2-git-send-email-rongqing.li-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org>
On Fri, 2011-08-05 at 16:58 +0800, rongqing.li-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org wrote:
> From: Roy.Li <rongqing.li-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org>
>
> This function will write the sock's security context to a seq_file
> and return the error code, and the number of characters successfully
> written is written in int pointers parameter.
>
> This function will be called when export socket information to proc.
>
> Signed-off-by: Roy.Li <rongqing.li-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org>
> ---
> include/net/sock.h | 1 +
> net/core/sock.c | 26 ++++++++++++++++++++++++++
> 2 files changed, 27 insertions(+), 0 deletions(-)
>
> diff --git a/net/core/sock.c b/net/core/sock.c
> index bc745d0..1126a49 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -2254,6 +2254,32 @@ void sk_common_release(struct sock *sk)
> }
> EXPORT_SYMBOL(sk_common_release);
>
> +int sock_write_secctx(struct sock *sk, struct seq_file *seq, int *len)
> +{
> + struct flowi fl;
> + char *ctx = NULL;
> + u32 ctxlen;
> + int res = 0;
> +
> + *len = 0;
> +
> + if (sk == NULL)
> + return -EINVAL;
> + res = security_socket_getsockname(sk->sk_socket);
> + if (res)
> + return res;
> +
> + security_sk_classify_flow(sk, &fl);
Rather than using a fake flowi, just define and use
security_sk_getsecid(). There is already a security_ops->sk_getsecid()
hook, so you just need the wrapper function.
> +
> + res = security_secid_to_secctx(fl.flowi_secid, &ctx, &ctxlen);
> + if (res)
> + return res;
> +
> + seq_printf(seq, " %s%n", ctx, len);
> + security_release_secctx(ctx, ctxlen);
> + return res;
> +}
> +
> static DEFINE_RWLOCK(proto_list_lock);
> static LIST_HEAD(proto_list);
>
--
Stephen Smalley
National Security Agency
^ permalink raw reply
* Re: return of ip_rt_bug()
From: Tom London @ 2011-08-05 13:37 UTC (permalink / raw)
To: Julian Anastasov; +Cc: Dave Jones, netdev
In-Reply-To: <CAFiZG+Ve9Y4v9CWCrbGsR+7C79AyoiWncVSVbeqApDuKaPm_jA@mail.gmail.com>
On Fri, Aug 5, 2011 at 6:30 AM, Tom London <selinux@gmail.com> wrote:
> On Fri, Aug 5, 2011 at 6:18 AM, Tom London <selinux@gmail.com> wrote:
>> On Fri, Aug 5, 2011 at 12:56 AM, Julian Anastasov <ja@ssi.bg> wrote:
>>>
>>> Hello,
>>>
>>> On Thu, 4 Aug 2011, Tom London wrote:
>>>
>>>> So, my router is just giving my wired NIC different addresses....
>>>>
>>>> More I can provide?
>>>
>>> Thanks! Can you check in dmesg or in another log
>>> about the first IP address in such line:
>>>
>>> printk(KERN_DEBUG "ip_rt_bug: %pI4 -> %pI4, %s\n"
>>>
>>> Is it now 192.168.2.6 ?
>>>
>>> Regards
>>>
>>> --
>>> Julian Anastasov <ja@ssi.bg>
>>>
>>
>> Sorry, don't see those messages. I guess I'll have to reboot with
>> 'debug' to see that.
>>
>> Before I do that, I booted this time with the RFKILL switch set to
>> kill the radio (both BT and WIFI), and reran the above tests.
>>
>> Here is what 'ip monitor' said:
>>
>> [root@tlondon ~]# ip monitor
>> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
>> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 REACHABLE
>> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
>> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
>> ff02::fb via ff02::fb dev eth0 metric 0
>> cache
>> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
>>
>> Here is what 'inotail -f /var/log/messages' said:
>>
>>
>> Aug 5 06:12:21 tlondon kernel: [ 536.727187] usb 3-1: new full speed
>> USB device number 2 using uhci_hcd
>> Aug 5 06:12:21 tlondon kernel: [ 537.315296] usb 3-1: New USB device
>> found, idVendor=04b8, idProduct=010a
>> Aug 5 06:12:21 tlondon kernel: [ 537.315308] usb 3-1: New USB device
>> strings: Mfr=1, Product=2, SerialNumber=0
>> Aug 5 06:12:21 tlondon kernel: [ 537.315317] usb 3-1: Product: Perfection1640
>> Aug 5 06:12:21 tlondon kernel: [ 537.315323] usb 3-1: Manufacturer: EPSON
>> Aug 5 06:12:21 tlondon mtp-probe: checking bus 3, device 2:
>> "/sys/devices/pci0000:00/0000:00:1a.0/usb3/3-1"
>> Aug 5 06:12:22 tlondon mtp-probe: bus: 3, device: 2 was not an MTP device
>>
>> So, no WARN_ON messages.
>>
>> I'd like to conclude that this is due to UDP casting on the wlan.
>> I'll reboot with the radio on and in debug mode to see what happens.
>>
>> tom
>> --
>> Tom London
>>
>
> Hmmm, first attempt at recreating in debug mode didn't actually
> produce any WARN_ON reports.
>
> 'ip monitor' did say:
>
> [root@tlondon ~]# ip monitor
> 239.255.255.250 dev eth0 lladdr 01:00:5e:7f:ff:fa NOARP
> 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
> link/ether
> ff02::2 dev wlan0 lladdr 33:33:00:00:00:02 NOARP
> ff02::16 dev wlan0 lladdr 33:33:00:00:00:16 NOARP
> ff02::1:ffac:c692 dev wlan0 lladdr 33:33:ff:ac:c6:92 NOARP
> 192.168.2.1 dev eth0 lladdr 00:1c:df:e2:3e:e9 STALE
> 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
> link/ether
>
> Will try one more time.
>
> tom
>
> --
> Tom London
>
Can't seem to reproduce this when I boot with 'debug' on the boot line.
Here is what 'ip monitor' says:
[root@tlondon ~]# ip monitor
ff02::1:ffac:c692 dev wlan0 lladdr 33:33:ff:ac:c6:92 NOARP
ff02::16 dev wlan0 lladdr 33:33:00:00:00:16 NOARP
ff02::2 dev wlan0 lladdr 33:33:00:00:00:02 NOARP
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
link/ether
tom
--
Tom London
^ permalink raw reply
* Re: [PATCH 2/5] Export the raw sock's security context to proc.
From: Stephen Smalley @ 2011-08-05 13:51 UTC (permalink / raw)
To: rongqing.li; +Cc: netdev, selinux, lsm
In-Reply-To: <1312534686-4099-3-git-send-email-rongqing.li@windriver.com>
On Fri, 2011-08-05 at 16:58 +0800, rongqing.li@windriver.com wrote:
> From: Roy.Li <rongqing.li@windriver.com>
>
> The element sk_security of struct sock represents the socket
> security context ID, which is inheriting from the process when
> creates this socket on most of the time.
>
> but when SELinux type_transition rule is applied to socket, or
> application sets /proc/xxx/attr/createsock, the socket security
> context would be different from the creating process. on this
> condition, the "netstat -Z" will return wrong value, since
> "netstat -Z" only returns the process security context as socket
> process security.
>
> Export the raw sock's security context to proc, so that "netstat -Z"
> could be fixed by reading procfs.
>
> Signed-off-by: Roy.Li <rongqing.li@windriver.com>
> ---
> net/ipv4/raw.c | 9 +++++++--
> 1 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
> index 1457acb..645d373 100644
> --- a/net/ipv4/raw.c
> +++ b/net/ipv4/raw.c
> @@ -972,6 +972,7 @@ EXPORT_SYMBOL_GPL(raw_seq_stop);
>
> static void raw_sock_seq_show(struct seq_file *seq, struct sock *sp, int i)
> {
> + int sclen;
> struct inet_sock *inet = inet_sk(sp);
> __be32 dest = inet->inet_daddr,
> src = inet->inet_rcv_saddr;
> @@ -979,12 +980,15 @@ static void raw_sock_seq_show(struct seq_file *seq, struct sock *sp, int i)
> srcp = inet->inet_num;
>
> seq_printf(seq, "%4d: %08X:%04X %08X:%04X"
> - " %02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %pK %d\n",
> + " %02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %pK %d",
> i, src, srcp, dest, destp, sp->sk_state,
> sk_wmem_alloc_get(sp),
> sk_rmem_alloc_get(sp),
> 0, 0L, 0, sock_i_uid(sp), 0, sock_i_ino(sp),
> atomic_read(&sp->sk_refcnt), sp, atomic_read(&sp->sk_drops));
> +
> + sock_write_secctx(sp, seq, &sclen);
You don't seem to use the return value or the sclen. If that's
intentional, then why does sclen exist and why isn't the function void?
> + seq_putc(seq, '\n');
> }
>
> static int raw_seq_show(struct seq_file *seq, void *v)
> @@ -992,7 +996,8 @@ static int raw_seq_show(struct seq_file *seq, void *v)
> if (v == SEQ_START_TOKEN)
> seq_printf(seq, " sl local_address rem_address st tx_queue "
> "rx_queue tr tm->when retrnsmt uid timeout "
> - "inode ref pointer drops\n");
> + "inode ref pointer drops %s",
> + (selinux_is_enabled() ? " scontext\n" : "\n"));
The rest of your code isn't SELinux-specific and should work for other
security modules, so there is no reason to make this SELinux-specific
either. The audit system may provide a useful example. I'd just always
include the field header (otherwise how can we add any further fields
unambiguously?), and make it something more general, like "seclabel".
> else
> raw_sock_seq_show(seq, v, raw_seq_private(seq)->bucket);
> return 0;
--
Stephen Smalley
National Security Agency
^ permalink raw reply
* Re: [PATCH 1/5] Define the function to write sock's security context to seq_file.
From: Stephen Smalley @ 2011-08-05 13:56 UTC (permalink / raw)
To: rongqing.li; +Cc: netdev, selinux, lsm
In-Reply-To: <1312534686-4099-2-git-send-email-rongqing.li@windriver.com>
On Fri, 2011-08-05 at 16:58 +0800, rongqing.li@windriver.com wrote:
> From: Roy.Li <rongqing.li@windriver.com>
>
> This function will write the sock's security context to a seq_file
> and return the error code, and the number of characters successfully
> written is written in int pointers parameter.
>
> This function will be called when export socket information to proc.
>
> Signed-off-by: Roy.Li <rongqing.li@windriver.com>
> ---
> include/net/sock.h | 1 +
> net/core/sock.c | 26 ++++++++++++++++++++++++++
> 2 files changed, 27 insertions(+), 0 deletions(-)
> diff --git a/net/core/sock.c b/net/core/sock.c
> index bc745d0..1126a49 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -2254,6 +2254,32 @@ void sk_common_release(struct sock *sk)
> }
> EXPORT_SYMBOL(sk_common_release);
>
> +int sock_write_secctx(struct sock *sk, struct seq_file *seq, int *len)
> +{
> + struct flowi fl;
> + char *ctx = NULL;
> + u32 ctxlen;
> + int res = 0;
> +
> + *len = 0;
> +
> + if (sk == NULL)
> + return -EINVAL;
Is this ever possible?
> + res = security_socket_getsockname(sk->sk_socket);
> + if (res)
> + return res;
I'm not sure it is a good idea to output nothing if permission is denied
to the socket, as opposed to some well-defined string indicating that
condition. Particularly if someone later adds another field to
the /proc files after the context; we don't want the contents of that
field to be interpreted as the context if permission was denied.
> +
> + security_sk_classify_flow(sk, &fl);
> +
> + res = security_secid_to_secctx(fl.flowi_secid, &ctx, &ctxlen);
> + if (res)
> + return res;
Likewise, if we couldn't map the secid to a secctx for some reason, we
likely ought to output some well-defined string indicating that
condition.
> +
> + seq_printf(seq, " %s%n", ctx, len);
> + security_release_secctx(ctx, ctxlen);
> + return res;
> +}
> +
> static DEFINE_RWLOCK(proto_list_lock);
> static LIST_HEAD(proto_list);
>
--
Stephen Smalley
National Security Agency
^ permalink raw reply
* Re: [RFC 4/4] [flexcan] Add support for FLEXCAN_DEBUG
From: Robin Holt @ 2011-08-05 14:01 UTC (permalink / raw)
To: Marc Kleine-Budde, Wolfgang Grandegger
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, Wolfgang Grandegger
In-Reply-To: <4E3B98B6.4040003-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Fri, Aug 05, 2011 at 09:16:06AM +0200, Marc Kleine-Budde wrote:
> On 08/05/2011 04:06 AM, Robin Holt wrote:
> > Add a wrapper function for a register dump when a developer defines
> > FLEXCAN_DEBUG
>
> Comments inline..however I'm not sure if we need this patch.
I really do like the ability to dump the registers. It has come in handy
a couple of times while bringing up the board. I do not know how hard
I would push for them, but I do not see them as having much down side
and I do know they have proven useful for me.
At this point, I have interpretted both your's and Wolfgang's comment as
a suggestion. I do not know how this group of developers works and if
I should be taking that suggestion as a dope-slap indicating I should
drop this right now because I am an idiot or if the patch just leaves
a bad taste in your mouth. Would either or both of you please clarify.
> > +#if defined(FLEXCAN_DEBUG)
> > +void _flexcan_reg_dump(struct net_device *dev, const char *file, int line,
> > + const char *func)
> > +{
> > + const struct flexcan_priv *priv = netdev_priv(dev);
> > + struct flexcan_regs __iomem *regs = priv->base;
> > +
> > + printk(KERN_INFO "flexcan_reg_dump:%s:%d:%s()\n", file, line, func);
>
> Use netdev_$LEVEL, please.
> If you use dbg, you can remove the ifdef altogether.
I assume you mean netdev_dbg. If that were the case, then setting
CONFIG_CAN_DEBUG_DEVICES would bring these printks back and that was
explicitly stated as undesirable. Am I understanding this wrong?
If not, I am going to fall back to netdev_info instead and leave the
#ifdef FLEXCAN_DEBUG. Will that work?
Thanks,
Robin
^ permalink raw reply
* Re: r8169 driver crashes in 2.6.32.43
From: Kasper Dupont @ 2011-08-05 14:08 UTC (permalink / raw)
To: Francois Romieu; +Cc: ivecera, hayeswang, gregkh, netdev
In-Reply-To: <20110728210112.GA25953@colin.search.kasperd.net>
I did a bit more of experiments. I took the unmodified
2.6.32.43 kernel and added printk statements to see when
it entered the interrupt handler and when it left it.
That way I was able to confirm that the system locked
up inside the interrupt handler.
Next I added printk statements to see how many times the
loop in the interrupt handler was run. It seemed that
when it locked up inside the handler it would run the
loop just two times and then lock up before leaving the
handler.
I added more printk statements to see which branches were
taken inside the loop. Unfortunately those printk
statements changed the timing enough that the crashes
were no longer as reproducable.
I saw a pattern repeating. It would do the stop queue
thing, then leave the handler and while not inside this
interrupt handler there would be a message about the
interface coming up again. Seems like it was doing stop
queue calls much more frequently than it should be.
After a few attempts I managed to get it to lock up again
with all the printk statements in place. What I found was
that in the beginning of the loop status was 0x85. It
would then call the napi event code. At the end of the
first itteration of the loop status was 0.
At that point it did not itterate through the loop again
and it did not leave the interrupt handler either. I'll
power cycle the machine and take a closer look on the
source to see what could possible be happening at that
point.
I also did a bit of testing with the patches that causes
it to drop the network instead of crashing. On those I
am able to bring up the second interface and get data off
the machine for debugging, so if there is any debug info
you think would be useful in those cases, let me know.
--
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,11,_+2,_+7,_+6);
^ permalink raw reply
* Re: [forcedeth bug] Re: [GIT] Networking
From: Jiri Pirko @ 2011-08-05 14:37 UTC (permalink / raw)
To: Ingo Molnar; +Cc: David Miller, torvalds, akpm, netdev, linux-kernel
In-Reply-To: <20110805123136.GF1928@minipsycho.orion>
Fri, Aug 05, 2011 at 02:31:37PM CEST, jpirko@redhat.com wrote:
>Fri, Aug 05, 2011 at 02:18:55PM CEST, mingo@elte.hu wrote:
>>
>>* Jiri Pirko <jpirko@redhat.com> wrote:
>>
>>> >> Is DEV_HAS_VLAN set in id->driver_data (L5344) ?
>>> >
>>> >How do i tell that without hacking the driver?
>>>
>>> look in dmesg for line like:
>>> "forcedeth 0000:00:08.0: highdma csum vlan pwrctl mgmt gbit lnktim msi
>>> desc-v3"
>>>
>>> if "vlan" is there, DEV_HAS_VLAN is set
>>
>>[ 3.534489] forcedeth 0000:00:0a.0: highdma csum gbit lnktim desc-v3
>>
>>Note, this is a pretty old system with an old nvidia chipset and
>>on-board ethernet:
>>
>>00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
>> Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard
>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
>> Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>> Latency: 0 (250ns min, 5000ns max)
>> Interrupt: pin A routed to IRQ 11
>> Region 0: Memory at da100000 (32-bit, non-prefetchable) [size=4K]
>> Region 1: I/O ports at d000 [size=8]
>> Capabilities: [44] Power Management version 2
>> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
>> Status: D0 PME-Enable+ DSel=0 DScale=0 PME-
>
>Please do lspci -nn
>
>There are two CK804 chips:
>0x10DE, 0x0056
>0x10DE, 0x0057
>
>I have only the second one handy - Getting the machine as we speak.
I'm unable to see problems you are referring to on my machine.
Would you please try following patch if it fixes your issue? It's
in fact returning everything back to the original state (for your card).
diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index e55df30..d7d43d4 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -2763,18 +2763,18 @@ static int nv_rx_process_optimized(struct net_device *dev, int limit)
skb->protocol = eth_type_trans(skb, dev);
prefetch(skb->data);
- vlanflags = le32_to_cpu(np->get_rx.ex->buflow);
-
/*
* There's need to check for NETIF_F_HW_VLAN_RX here.
* Even if vlan rx accel is disabled,
* NV_RX3_VLAN_TAG_PRESENT is pseudo randomly set.
*/
- if (dev->features & NETIF_F_HW_VLAN_RX &&
- vlanflags & NV_RX3_VLAN_TAG_PRESENT) {
- u16 vid = vlanflags & NV_RX3_VLAN_TAG_MASK;
+ if (dev->features & NETIF_F_HW_VLAN_RX) {
+ vlanflags = le32_to_cpu(np->get_rx.ex->buflow);
+ if (vlanflags & NV_RX3_VLAN_TAG_PRESENT) {
+ u16 vid = vlanflags & NV_RX3_VLAN_TAG_MASK;
- __vlan_hwaccel_put_tag(skb, vid);
+ __vlan_hwaccel_put_tag(skb, vid);
+ }
}
napi_gro_receive(&np->napi, skb);
@@ -5615,7 +5615,7 @@ static int __devinit nv_probe(struct pci_dev *pci_dev, const struct pci_device_i
goto out_error;
}
- nv_vlan_mode(dev, dev->features);
+ //nv_vlan_mode(dev, dev->features);
netif_carrier_off(dev);
^ permalink raw reply related
* Re: r8169 driver crashes in 2.6.32.43
From: Kasper Dupont @ 2011-08-05 14:40 UTC (permalink / raw)
To: Francois Romieu; +Cc: ivecera, hayeswang, gregkh, netdev
In-Reply-To: <20110805140047.GA19758@colin.search.kasperd.net>
On 05/08/11 16.08, Kasper Dupont wrote:
> At that point it did not itterate through the loop again
> and it did not leave the interrupt handler either. I'll
> power cycle the machine and take a closer look on the
> source to see what could possible be happening at that
> point.
I looked at the source around the place where that lockup
happened. There was absolutely no I/O or loops happening
between the two printk calls. It seemed the only real
candidate for a culprit responsible for that lockup was
the printk calls themselves.
Is it plausible that in 2.6.32.43 it is not safe to call
printk from within an interrupt handler?
I added some more printk statements in an attempt to find
out how it was possible for the code to lock up between
the end of the loop and the exit from the interrupt handler.
I wasn't able to reproduce the lockup in the same spot, but
instead I saw a lockup inside the loop in the branch where
it does netif_stop_queue.
Right now I suspect those builds where I added printk
statements lockup due to the printk statements. But does
the plain 2.6.32.43 kernel then also lockup due to printk
statements in the interrupt handler, or is it something
else?
--
Kasper Dupont -- Rigtige mænd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,11,_+2,_+7,_+6);
^ permalink raw reply
* Re: [PATCH 1/3] net: sendmmsg should only return an error if no messages were sent
From: Arnaldo Carvalho de Melo @ 2011-08-05 14:40 UTC (permalink / raw)
To: Steven Whitehouse; +Cc: Tetsuo Handa, rdenis, netdev
In-Reply-To: <1312532408.2762.4.camel@menhir>
Em Fri, Aug 05, 2011 at 09:20:08AM +0100, Steven Whitehouse escreveu:
> On Fri, 2011-08-05 at 12:57 +0900, Tetsuo Handa wrote:
> > Anton Blanchard wrote:
> > > sendmmsg uses a similar error return strategy as recvmmsg but it
> > > turns out to be a confusing way to communicate errors.
> > >
> > > The current code stores the error code away and returns it on the next
> > > sendmmsg call. This means a call with completely valid arguments could
> > > get an error from a previous call.
> > >
> > > Change things so we only return an error if no datagrams could be sent.
> > > If less than the requested number of messages were sent, the application
> > > must retry starting at the first failed one and if the problem is
> > > persistent the error will be returned.
> > >
> > > This matches the behaviour of other syscalls like read/write - it
> > > is not an error if less than the requested number of elements are sent.
> >
> > OK. David S. Miller suggested this behavior and Anton Blanchard agreed with
> > this behavior.
> >
> > Quoting from commit a2e27255 "net: Introduce recvmmsg socket syscall":
> > | . R?mi Denis-Courmont & Steven Whitehouse: If we receive N < vlen
> > | datagrams and then recvmsg returns an error, recvmmsg will return
> > | the successfully received datagrams, store the error and return it
> > | in the next call.
> >
> > R?mi Denis-Courmont, Steven Whitehouse and Arnaldo Carvalho de Melo, do you
> > want to change recvmmsg()'s behaviour as well?
>
> Since I've joined this part way through it seems, I'm assuming that if
> something was sent/received then that will be returned and the error
> stored until the next call. If nothing was sent/received then the error
> can be returned immediately.
>
> That is what I'd expect to be the case, since otherwise it is impossible
> to know how much has been successfully sent/received in the partial
> failure case, I think. Also it means that sendmmesg/recvmmsg matches
> sendmsg/recvmsg in terms of expected return values and thus the
> principle of least surprise.
>
> So if thats what is being proposed, then it sounds good to me,
Sounds sane to me too.
- Arnaldo
^ permalink raw reply
* Re: Fw: [Bug 39132] Starting with 3.0.0-rc6, masquerading seems to be broken.
From: Julian Anastasov @ 2011-08-05 15:16 UTC (permalink / raw)
To: David Hill; +Cc: Florian Mickler, netdev, David Miller, bugzilla-daemon
In-Reply-To: <8A188C9C23A54337A5A276BAE29DC6E0@delorimier>
Hello,
On Fri, 5 Aug 2011, David Hill wrote:
> I'm not using TPROXY and I've used a blank firewall with only masquerading
> and reproduced the issue.
> Nothing is in NAT/mangle nor OUTPUT but the rules mentionned in the attached
> files to this bug.
>
> Francis Whittle (Comment #18) has the same issue.
I compiled 3.0 kernel, added one -j MASQUERADE and
tried TCP connection - it works. I'm not sure ip_route_me_harder
is called for masqueraded traffic, usually it is called
from LOCAL_OUT handlers or to send TCP RST (-j REJECT) via
LOCAL_OUT, not for forwarded traffic.
Can you show lines of tcpdump output with addresses and
ports, so that I can understand what kind of traffic is
dropped, is it initial forwarded packet or its response,
is it problem with some ICMP packets, I assume there is
no problem with locally generated traffic.
Can you show output from:
# grep . /proc/sys/net/ipv4/conf/*/rp_filter
# grep . /proc/sys/net/ipv4/conf/*/send_redirects
If it works with -rc5 it should not be rp_filter,
for NAT, problem can be with ICMP redirects or something else.
Can you tell us if the internal and external devices are
same or may be many.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: return of ip_rt_bug()
From: Julian Anastasov @ 2011-08-05 16:36 UTC (permalink / raw)
To: Tom London; +Cc: Dave Jones, netdev
In-Reply-To: <CAFiZG+Wmv_FEx2ZX3qZt0tAr-QVQD_javX1gbRWujr9xyf7nbQ@mail.gmail.com>
Hello,
On Fri, 5 Aug 2011, Tom London wrote:
> I'd like to conclude that this is due to UDP casting on the wlan.
> I'll reboot with the radio on and in debug mode to see what happens.
Sending to 255.255.255.255 without binding to source address
or output device will succeed only if there is a route that matches
the 255.255.255.255 address (default route as last option).
If no route matches, the result is ENETUNREACH and packet
should be dropped. But how input route is attached, I still don't know.
Your ip monitor does not show fatal event that can
invalidate the source address or the default route (that
will match for 255.255.255.255) while sending packet.
It is almost impossible such problem to occur, i.e. between routing
and following re-routing the address/route to disappear.
Such events:
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
link/ether
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
link/ether
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
link/ether
are may be for link, not sure. Events for addresses/routes
would show addresses and routes in a way similar to
ip addr and ip route list.
Not sure where your logs go, may be you can add
"kern.* /var/log/kernel.log" in your /etc/rsyslog.conf. But if
you don't see the WARNING then the problem does not happen.
You can also see the ip_rt_bug line with 'dmesg'. So, can
you confirm the problem occurs only when default route
points to wlan? Even if so, I still don't see good explanation
for the error message.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Fix bridge MAC change notification.
From: Andrei Warkentin @ 2011-08-05 1:55 UTC (permalink / raw)
To: netdev
This is my first time on netdev. I am writing about the ensuring
that upper network layers are aware of bridge MAC changes due
to re-configuration or port addition/removal.
It seems this topic has cropped up before, with one patch by
Stephen Hemminger already in 3.0, and a fix for it (sent 7/22)
(http://marc.info/?l=linux-netdev&m=131135705613958&w=2) pending.
The existing patches don't cover the br_del_if case, the case of
a changing MAC address on a port associated with the bridge, and
the case of manually setting the MAC address, which the following
patch remedies.
Table of Contents:
[PATCH] Bridge: Always send NETDEV_CHANGEADDR up on br MAC change.
Thank you,
A
^ permalink raw reply
* Re: [PATCHv3] Bridge: Always send NETDEV_CHANGEADDR up on br MAC change.
From: Andrei Warkentin @ 2011-08-05 6:13 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20110804213605.31be6131@nehalam.ftrdhcpuser.net>
Hi Stephen,
On Thu, Aug 4, 2011 at 11:36 PM, Stephen Hemminger
<shemminger@vyatta.com> wrote:
> On Thu, 4 Aug 2011 21:17:05 -0500
> Andrei Warkentin <andreiw@motorola.com> wrote:
>
> Half ok, half not.
>
>> diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
>> index cf09fe5..ef18070 100644
>> --- a/net/bridge/br_device.c
>> +++ b/net/bridge/br_device.c
>> @@ -162,6 +162,7 @@ static int br_set_mac_address(struct net_device *dev, void *p)
>> br->flags |= BR_SET_MAC_ADDR;
>> spin_unlock_bh(&br->lock);
>>
>> + call_netdevice_notifiers(NETDEV_CHANGEADDR, dev);
>> return 0;
>> }
>
> This is unnecessary since already done by dev_set_mac_address.
>
>> diff --git a/net/bridge/br_stp_if.c b/net/bridge/br_stp_if.c
>> index c0990ba..4528e9a 100644
>> --- a/net/bridge/br_stp_if.c
>> +++ b/net/bridge/br_stp_if.c
>> @@ -213,7 +213,7 @@ bool br_stp_recalculate_bridge_id(struct net_bridge *br)
>>
>> /* user has chosen a value so keep it */
>> if (br->flags & BR_SET_MAC_ADDR)
>> - return;
>> + return false;
>>
>> list_for_each_entry(p, &br->port_list, list) {
>> if (addr == br_mac_zero ||
>
> This is already in net-next.
>
Thank you for your feedback. I will clean this up and resubmit tomorrow.
A
^ permalink raw reply
* [PATCH] slip: fix NOHZ local_softirq_pending 08 warning
From: Matvejchikov Ilya @ 2011-08-05 19:23 UTC (permalink / raw)
To: netdev
When using nanosleep() in an userspace application we get a ratelimit warning:
NOHZ: local_softirq_pending 08
According to 481a8199142c050b72bff8a1956a49fd0a75bbe0 the problem is caused by
netif_rx() function. This patch replaces netif_rx() with netif_rx_ni() which
has to be used from process/softirq context.
Signed-off-by: Matvejchikov Ilya <matvejchikov@gmail.com>
---
drivers/net/slip.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/slip.c b/drivers/net/slip.c
index f11b3f3..4c61753 100644
--- a/drivers/net/slip.c
+++ b/drivers/net/slip.c
@@ -367,7 +367,7 @@ static void sl_bump(struct slip *sl)
memcpy(skb_put(skb, count), sl->rbuff, count);
skb_reset_mac_header(skb);
skb->protocol = htons(ETH_P_IP);
- netif_rx(skb);
+ netif_rx_ni(skb);
dev->stats.rx_packets++;
}
--
1.7.4.1
^ permalink raw reply related
* [PATCH net-next 1/6] be2net: set wrb.hdr.domain in be_cmd_link_status_query
From: Ajit Khaparde @ 2011-08-05 19:59 UTC (permalink / raw)
To: davem; +Cc: netdev
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
---
drivers/net/benet/be_cmds.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/benet/be_cmds.c b/drivers/net/benet/be_cmds.c
index 4278595..8d178d2 100644
--- a/drivers/net/benet/be_cmds.c
+++ b/drivers/net/benet/be_cmds.c
@@ -1282,6 +1282,8 @@ int be_cmd_link_status_query(struct be_adapter *adapter, u8 *mac_speed,
be_cmd_hdr_prepare(&req->hdr, CMD_SUBSYSTEM_COMMON,
OPCODE_COMMON_NTWK_LINK_STATUS_QUERY, sizeof(*req));
+ req->hdr.domain = dom;
+
status = be_mcc_notify_wait(adapter);
if (!status) {
struct be_cmd_resp_link_status *resp = embedded_payload(wrb);
--
1.7.4.1
^ permalink raw reply related
* [PATCH net-next 0/6] be2net: patch series
From: Ajit Khaparde @ 2011-08-05 19:59 UTC (permalink / raw)
To: davem; +Cc: netdev
Series of 6 patches against net-next-2.6
Please apply.
Thanks
-Ajit
[1/6] be2net: set wrb.hdr.domain in be_cmd_link_status_query
[2/6] be2net: add be_cmd_set_port_speed_v1 to set port speed
[3/6] be2net: add be_cmd_get_port_speed to get port speed
[4/6] be2net: add ethtool::set_settings support
[5/6] be2net: Disable RSS for VF interfaces
[6/6] be2net: fix to set ecmd->autoneg correctly
^ permalink raw reply
* [PATCH net-next 2/6] be2net: add be_cmd_set_port_speed_v1 to set port speed
From: Ajit Khaparde @ 2011-08-05 19:59 UTC (permalink / raw)
To: davem; +Cc: netdev
Signed-off-by: Suresh Reddy <suresh.reddy@emulex.com>
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
---
drivers/net/benet/be_cmds.c | 35 +++++++++++++++++++++++++++++++++++
drivers/net/benet/be_cmds.h | 37 ++++++++++++++++++++++++++++++++++++-
2 files changed, 71 insertions(+), 1 deletions(-)
diff --git a/drivers/net/benet/be_cmds.c b/drivers/net/benet/be_cmds.c
index 8d178d2..863ae67 100644
--- a/drivers/net/benet/be_cmds.c
+++ b/drivers/net/benet/be_cmds.c
@@ -2367,3 +2367,38 @@ err:
mutex_unlock(&adapter->mbox_lock);
return status;
}
+
+int be_cmd_set_port_speed_v1(struct be_adapter *adapter,
+ u8 port_num, u16 mac_speed,
+ u16 dac_cable_len)
+{
+ struct be_mcc_wrb *wrb;
+ struct be_cmd_req_set_port_speed_v1 *req;
+ int status = 0;
+
+ spin_lock_bh(&adapter->mcc_lock);
+
+ wrb = wrb_from_mccq(adapter);
+ if (!wrb) {
+ status = -EBUSY;
+ goto err;
+ }
+ req = embedded_payload(wrb);
+ be_wrb_hdr_prepare(wrb, sizeof(*req), true, 0,
+ OPCODE_COMMON_NTWK_SET_LINK_SPEED);
+
+ be_cmd_hdr_prepare(&req->hdr, CMD_SUBSYSTEM_COMMON,
+ OPCODE_COMMON_NTWK_SET_LINK_SPEED,
+ sizeof(*req));
+ req->hdr.version = 1;
+
+ req->port_num = port_num;
+ req->virt_port = port_num;
+ req->mac_speed = cpu_to_le16(mac_speed);
+ req->dac_cable_length = cpu_to_le16(dac_cable_len);
+ status = be_mcc_notify_wait(adapter);
+err:
+ spin_unlock_bh(&adapter->mcc_lock);
+ return status;
+}
+
diff --git a/drivers/net/benet/be_cmds.h b/drivers/net/benet/be_cmds.h
index b61eac7..4a6a959 100644
--- a/drivers/net/benet/be_cmds.h
+++ b/drivers/net/benet/be_cmds.h
@@ -178,6 +178,7 @@ struct be_mcc_mailbox {
#define OPCODE_COMMON_MCC_DESTROY 53
#define OPCODE_COMMON_CQ_DESTROY 54
#define OPCODE_COMMON_EQ_DESTROY 55
+#define OPCODE_COMMON_NTWK_SET_LINK_SPEED 57
#define OPCODE_COMMON_QUERY_FIRMWARE_CONFIG 58
#define OPCODE_COMMON_NTWK_PMAC_ADD 59
#define OPCODE_COMMON_NTWK_PMAC_DEL 60
@@ -1237,6 +1238,8 @@ enum {
PHY_TYPE_KX4_10GB,
PHY_TYPE_BASET_10GB,
PHY_TYPE_BASET_1GB,
+ PHY_TYPE_BASEX_1GB,
+ PHY_TYPE_SGMII,
PHY_TYPE_DISABLED = 255
};
@@ -1301,6 +1304,37 @@ struct be_cmd_resp_set_func_cap {
u8 rsvd[212];
};
+/* MAC speed valid values */
+#define SPEED_DEFAULT 0x0
+#define SPEED_FORCED_10GB 0x1
+#define SPEED_FORCED_1GB 0x2
+#define SPEED_AUTONEG_10GB 0x3
+#define SPEED_AUTONEG_1GB 0x4
+#define SPEED_AUTONEG_100MB 0x5
+#define SPEED_AUTONEG_10GB_1GB 0x6
+#define SPEED_AUTONEG_10GB_1GB_100MB 0x7
+#define SPEED_AUTONEG_1GB_100MB 0x8
+#define SPEED_AUTONEG_10MB 0x9
+#define SPEED_AUTONEG_1GB_100MB_10MB 0xa
+#define SPEED_AUTONEG_100MB_10MB 0xb
+#define SPEED_FORCED_100MB 0xc
+#define SPEED_FORCED_10MB 0xd
+
+/*************** Set speed ********************/
+struct be_cmd_req_set_port_speed_v1 {
+ struct be_cmd_req_hdr hdr;
+ u8 port_num;
+ u8 virt_port;
+ u16 mac_speed;
+ u16 dac_cable_length;
+ u16 rsvd0;
+};
+
+struct be_cmd_resp_set_port_speed_v1 {
+ struct be_cmd_resp_hdr hdr;
+ u32 rsvd0;
+};
+
/*************** HW Stats Get v1 **********************************/
#define BE_TXP_SW_SZ 48
struct be_port_rxf_stats_v1 {
@@ -1499,4 +1533,5 @@ extern int be_cmd_get_cntl_attributes(struct be_adapter *adapter);
extern int be_cmd_req_native_mode(struct be_adapter *adapter);
extern int be_cmd_get_reg_len(struct be_adapter *adapter, u32 *log_size);
extern void be_cmd_get_regs(struct be_adapter *adapter, u32 buf_len, void *buf);
-
+extern int be_cmd_set_port_speed_v1(struct be_adapter *adapter, u8 port_num,
+ u16 mac_speed, u16 dac_cable_len);
--
1.7.4.1
^ permalink raw reply related
* [PATCH net-next 3/6] be2net: add be_cmd_get_port_speed to get port speed
From: Ajit Khaparde @ 2011-08-05 20:00 UTC (permalink / raw)
To: davem; +Cc: netdev
Signed-off-by: Suresh Reddy <suresh.reddy@emulex.com>
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
---
drivers/net/benet/be_cmds.c | 35 +++++++++++++++++++++++++++++++++++
drivers/net/benet/be_cmds.h | 15 +++++++++++++++
2 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/drivers/net/benet/be_cmds.c b/drivers/net/benet/be_cmds.c
index 863ae67..ee6d274 100644
--- a/drivers/net/benet/be_cmds.c
+++ b/drivers/net/benet/be_cmds.c
@@ -2368,6 +2368,41 @@ err:
return status;
}
+int be_cmd_get_port_speed(struct be_adapter *adapter,
+ u8 port_num, u16 *dac_cable_len, u16 *port_speed)
+{
+ struct be_mcc_wrb *wrb;
+ struct be_cmd_req_get_port_speed *req;
+ int status = 0;
+
+ spin_lock_bh(&adapter->mcc_lock);
+
+ wrb = wrb_from_mccq(adapter);
+ if (!wrb) {
+ status = -EBUSY;
+ goto err;
+ }
+
+ req = embedded_payload(wrb);
+ be_wrb_hdr_prepare(wrb, sizeof(*req), true, 0,
+ OPCODE_COMMON_NTWK_GET_LINK_SPEED);
+ be_cmd_hdr_prepare(&req->hdr, CMD_SUBSYSTEM_COMMON,
+ OPCODE_COMMON_NTWK_GET_LINK_SPEED,
+ sizeof(*req));
+ req->port_num = port_num;
+ status = be_mcc_notify_wait(adapter);
+ if (!status) {
+ struct be_cmd_resp_get_port_speed *resp =
+ embedded_payload(wrb);
+ *dac_cable_len = le16_to_cpu(resp->dac_cable_length);
+ *port_speed = le16_to_cpu(resp->mac_speed);
+ }
+
+err:
+ spin_unlock_bh(&adapter->mcc_lock);
+ return status;
+}
+
int be_cmd_set_port_speed_v1(struct be_adapter *adapter,
u8 port_num, u16 mac_speed,
u16 dac_cable_len)
diff --git a/drivers/net/benet/be_cmds.h b/drivers/net/benet/be_cmds.h
index 4a6a959..40ce808 100644
--- a/drivers/net/benet/be_cmds.h
+++ b/drivers/net/benet/be_cmds.h
@@ -190,6 +190,7 @@ struct be_mcc_mailbox {
#define OPCODE_COMMON_GET_PHY_DETAILS 102
#define OPCODE_COMMON_SET_DRIVER_FUNCTION_CAP 103
#define OPCODE_COMMON_GET_CNTL_ADDITIONAL_ATTRIBUTES 121
+#define OPCODE_COMMON_NTWK_GET_LINK_SPEED 134
#define OPCODE_COMMON_WRITE_OBJECT 172
#define OPCODE_ETH_RSS_CONFIG 1
@@ -1335,6 +1336,18 @@ struct be_cmd_resp_set_port_speed_v1 {
u32 rsvd0;
};
+/************** get port speed *******************/
+struct be_cmd_req_get_port_speed {
+ struct be_cmd_req_hdr hdr;
+ u8 port_num;
+};
+
+struct be_cmd_resp_get_port_speed {
+ struct be_cmd_resp_hdr hdr;
+ u16 mac_speed;
+ u16 dac_cable_length;
+};
+
/*************** HW Stats Get v1 **********************************/
#define BE_TXP_SW_SZ 48
struct be_port_rxf_stats_v1 {
@@ -1535,3 +1548,5 @@ extern int be_cmd_get_reg_len(struct be_adapter *adapter, u32 *log_size);
extern void be_cmd_get_regs(struct be_adapter *adapter, u32 buf_len, void *buf);
extern int be_cmd_set_port_speed_v1(struct be_adapter *adapter, u8 port_num,
u16 mac_speed, u16 dac_cable_len);
+extern int be_cmd_get_port_speed(struct be_adapter *adapter, u8 port_num,
+ u16 *dac_cable_len, u16 *port_speed);
--
1.7.4.1
^ permalink raw reply related
* [PATCH net-next 4/6] be2net: add ethtool::set_settings support
From: Ajit Khaparde @ 2011-08-05 20:00 UTC (permalink / raw)
To: davem; +Cc: netdev
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
---
drivers/net/benet/be_ethtool.c | 63 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/drivers/net/benet/be_ethtool.c b/drivers/net/benet/be_ethtool.c
index f144a6f..5dd3ed6 100644
--- a/drivers/net/benet/be_ethtool.c
+++ b/drivers/net/benet/be_ethtool.c
@@ -443,6 +443,68 @@ static int be_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
return 0;
}
+static int be_set_settings(struct net_device *netdev,
+ struct ethtool_cmd *ecmd)
+{
+ struct be_adapter *adapter = netdev_priv(netdev);
+ struct be_phy_info phy_info;
+ u16 mac_speed = 0;
+ u16 dac_cable_len = 0;
+ u16 port_speed = 0;
+ int status;
+
+ status = be_cmd_get_phy_info(adapter, &phy_info);
+ if (status) {
+ dev_err(&adapter->pdev->dev, "Get phy info cmd failed.\n");
+ return status;
+ }
+
+ if (ecmd->autoneg == AUTONEG_ENABLE) {
+ switch (phy_info.interface_type) {
+ case PHY_TYPE_SFP_1GB:
+ case PHY_TYPE_BASET_1GB:
+ case PHY_TYPE_BASEX_1GB:
+ case PHY_TYPE_SGMII:
+ mac_speed = SPEED_AUTONEG_1GB_100MB_10MB;
+ break;
+ case PHY_TYPE_SFP_PLUS_10GB:
+ dev_warn(&adapter->pdev->dev,
+ "Autoneg not supported on this module.\n");
+ return -EINVAL;
+ case PHY_TYPE_KR_10GB:
+ case PHY_TYPE_KX4_10GB:
+ mac_speed = SPEED_AUTONEG_10GB_1GB;
+ break;
+ case PHY_TYPE_BASET_10GB:
+ mac_speed = SPEED_AUTONEG_10GB_1GB_100MB;
+ break;
+ }
+ } else if (ecmd->autoneg == AUTONEG_DISABLE) {
+ if (ethtool_cmd_speed(ecmd) == SPEED_10)
+ mac_speed = SPEED_FORCED_10MB;
+ else if (ethtool_cmd_speed(ecmd) == SPEED_100)
+ mac_speed = SPEED_FORCED_100MB;
+ else if (ethtool_cmd_speed(ecmd) == SPEED_1000)
+ mac_speed = SPEED_FORCED_1GB;
+ else if (ethtool_cmd_speed(ecmd) == SPEED_10000)
+ mac_speed = SPEED_FORCED_10GB;
+ }
+
+ status = be_cmd_get_port_speed(adapter, adapter->port_num,
+ &dac_cable_len, &port_speed);
+ if (status) {
+ dev_err(&adapter->pdev->dev, "Get port speed cmd failed.\n");
+ return status;
+ }
+
+ status = be_cmd_set_port_speed_v1(adapter, adapter->port_num,
+ mac_speed, dac_cable_len);
+ if (status)
+ dev_err(&adapter->pdev->dev, "Set port speed cmd failed.\n");
+
+ return status;
+}
+
static void
be_get_ringparam(struct net_device *netdev, struct ethtool_ringparam *ring)
{
@@ -692,6 +754,7 @@ be_read_eeprom(struct net_device *netdev, struct ethtool_eeprom *eeprom,
const struct ethtool_ops be_ethtool_ops = {
.get_settings = be_get_settings,
+ .set_settings = be_set_settings,
.get_drvinfo = be_get_drvinfo,
.get_wol = be_get_wol,
.set_wol = be_set_wol,
--
1.7.4.1
^ permalink raw reply related
* [PATCH net-next 5/6] be2net: Disable RSS for VF interfaces
From: Ajit Khaparde @ 2011-08-05 20:00 UTC (permalink / raw)
To: davem; +Cc: netdev
Signed-off-by: Suresh Reddy <suresh.reddy@emulex.com>
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
---
drivers/net/benet/be_main.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index 1a3acca..c20e302 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -1685,7 +1685,8 @@ static void be_rx_queues_destroy(struct be_adapter *adapter)
static u32 be_num_rxqs_want(struct be_adapter *adapter)
{
if ((adapter->function_caps & BE_FUNCTION_CAPS_RSS) &&
- !adapter->sriov_enabled && !(adapter->function_mode & 0x400)) {
+ !adapter->sriov_enabled && !(adapter->function_mode & 0x400) &&
+ be_physfn(adapter)) {
return 1 + MAX_RSS_QS; /* one default non-RSS queue */
} else {
dev_warn(&adapter->pdev->dev,
--
1.7.4.1
^ permalink raw reply related
* [PATCH net-next 6/6] be2net: fix to set ecmd->autoneg correctly
From: Ajit Khaparde @ 2011-08-05 20:01 UTC (permalink / raw)
To: davem; +Cc: netdev
Set the autonegotation settings correctly based on the port speed.
Signed-off-by: Suresh Reddy <suresh.reddy@emulex.com>
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
---
drivers/net/benet/be_ethtool.c | 21 +++++++++++++++++----
1 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/net/benet/be_ethtool.c b/drivers/net/benet/be_ethtool.c
index 5dd3ed6..2177c8c 100644
--- a/drivers/net/benet/be_ethtool.c
+++ b/drivers/net/benet/be_ethtool.c
@@ -353,6 +353,8 @@ static int be_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
u8 mac_speed = 0;
u16 link_speed = 0;
int status;
+ u16 port_speed = 0;
+ u16 dac_cable_len = 0;
if ((adapter->link_speed < 0) || (!(netdev->flags & IFF_UP))) {
status = be_cmd_link_status_query(adapter, &mac_speed,
@@ -397,11 +399,9 @@ static int be_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
switch (phy_info.interface_type) {
case PHY_TYPE_KR_10GB:
case PHY_TYPE_KX4_10GB:
- ecmd->autoneg = AUTONEG_ENABLE;
ecmd->transceiver = XCVR_INTERNAL;
break;
default:
- ecmd->autoneg = AUTONEG_DISABLE;
ecmd->transceiver = XCVR_EXTERNAL;
break;
}
@@ -411,12 +411,25 @@ static int be_get_settings(struct net_device *netdev, struct ethtool_cmd *ecmd)
adapter->link_speed = ethtool_cmd_speed(ecmd);
adapter->port_type = ecmd->port;
adapter->transceiver = ecmd->transceiver;
- adapter->autoneg = ecmd->autoneg;
} else {
ethtool_cmd_speed_set(ecmd, adapter->link_speed);
ecmd->port = adapter->port_type;
ecmd->transceiver = adapter->transceiver;
- ecmd->autoneg = adapter->autoneg;
+ }
+
+ be_cmd_get_port_speed(adapter, adapter->port_num,
+ &dac_cable_len, &port_speed);
+ switch (port_speed) {
+ case SPEED_FORCED_10GB:
+ case SPEED_FORCED_1GB:
+ case SPEED_FORCED_100MB:
+ case SPEED_FORCED_10MB:
+ case SPEED_DEFAULT:
+ ecmd->autoneg = AUTONEG_DISABLE;
+ break;
+ default:
+ ecmd->autoneg = AUTONEG_ENABLE;
+ break;
}
ecmd->duplex = DUPLEX_FULL;
--
1.7.4.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox