* Re: [PATCH] net: meth: Add set_rx_mode hook to fix ICMPv6 neighbor discovery
From: David Miller @ 2011-12-18 2:56 UTC (permalink / raw)
To: kumba; +Cc: netdev, linux-mips
In-Reply-To: <4EED3A3D.9080503@gentoo.org>
From: Joshua Kinard <kumba@gentoo.org>
Date: Sat, 17 Dec 2011 19:56:29 -0500
> +/* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
> + * MACE Ethernet uses a 64 element hash table based on the Ethernet CRC.
> + */
> +static int multicast_filter_limit = 32;
> +
> +
Unnecessary empty line, only one is sufficient. I also don't see a reason
to even define this value. If it's a constant then use a const type.
> + /* Multicast filter. */
> + unsigned long mcast_filter;
> +
...
> + priv->mcast_filter = 0xffffffffffffffffUL;
You're assuming that unsigned long is 64-bits here. You need to use a
type which matches your expections regardless of the architecture that
the code is built on.
> + netdev_for_each_mc_addr(ha, dev)
> + set_bit((ether_crc(ETH_ALEN, ha->addr) >> 26),
> + (volatile long unsigned int *)&priv->mcast_filter);
This makes an assumption not only about the size of the "unsigned long"
type, but also of the endianness of the architecture this runs on.
Please recode this to remove both assumptions.
^ permalink raw reply
* Re: [PATCH] net: meth: Some code cleanups for meth
From: David Miller @ 2011-12-18 3:00 UTC (permalink / raw)
To: kumba; +Cc: netdev, linux-mips
In-Reply-To: <4EED418E.40501@gentoo.org>
From: Joshua Kinard <kumba@gentoo.org>
Date: Sat, 17 Dec 2011 20:27:42 -0500
> -#define WAIT_FOR_PHY(___rval) \
> - while ((___rval = mace->eth.phy_data) & MDIO_BUSY) { \
> - udelay(25); \
> +#define WAIT_FOR_PHY(___rval) \
> + while ((___rval = mace->eth.phy_data) & MDIO_BUSY) { \
> + udelay(25); \
I think using tabs at the end of the line to line up the "\" is much
better than what you're changing it to, that being spaces.
> - priv->phy_addr=i;
> - p2=mdio_read(priv,2);
> - p3=mdio_read(priv,3);
> +
> + for (i = 0; i < 32; i++){
> + priv->phy_addr = i;
> + p2 = mdio_read(priv,2);
> + p3 = mdio_read(priv,3);
If you're going to put forth the effort to put spaces around the
"=" characters, fix up the arguments to mdio_read() as well, there
needs to be a space after the "," and right before the second
argument.
> + if ((p2 != 0xffff) && (p2 != 0x0000)) {
There is no need for the new parenthesis you are adding here. It
doesn't change things semantically, and it does not improve
readability, it just makes for more characters a human has to parse in
his mind.
> - * Copyright (C) 2001 Alessandro Rubini and Jonathan Corbet
> - * Copyright (C) 2001 O'Reilly & Associates
> + * Copyright (C) 2001-2003 Ilya Volynets
> + * Copyright (C) 2011 Joshua Kinard
> *
> - * The source code in this file can be freely used, adapted,
> - * and redistributed in source or binary form, so long as an
> - * acknowledgment appears in derived source files. The citation
> - * should list that the code comes from the book "Linux Device
> - * Drivers" by Alessandro Rubini and Jonathan Corbet, published
> - * by O'Reilly & Associates. No warranty is attached;
> - * we cannot take responsibility for errors or fitness for use.
> + * 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.
> */
I'm not sure at all that you have the ability to make this kind of
change to the copyright and attributions here.
There are probably a lot more problems with this patch, but I'm
exhausted look at this stuff as-is.
^ permalink raw reply
* reproducible kernel freeze using r8169 in Linux 3.0
From: Matt Ginzton @ 2011-12-18 3:31 UTC (permalink / raw)
To: nic_swsd, romieu; +Cc: netdev
Hi r8169 maintainers,
I have a completely reproducible kernel freeze apparently in the r8169 driver. All I have to do is generate a decent network load in both directions, and the kernel will freeze hard, not responding to network requests or input from a local console including magic sysrq, necessitating a hard reboot.
Summary: r8169 from Linux 3.0 freezes reproducibly on my RTL8111/R8168B hardware. r8169 from Linux 3.1 is better -- no freeze, but it still responds with a kernel warning to my repro scenario.
Details:
Software: Ubuntu 11.10 Server, x86, all updates as of today.
Hardware: Fit-pc2i, specs at http://www.fit-pc.com/web/fit-pc2/fit-pc2i-specifications/
uname -a: Linux flux 3.0.0-14-generic #23-Ubuntu SMP
lspci | grep Realtek: 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet Controller (rev 02)
ethtool -i eth0 says: driver: r8169, version: 2.3LK-NAPI, firmware-version: N/A
How I can reproduce the freeze:
- configure pktgen to generate a lot of TX traffic on eth0. I started with pktgen config in ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/examples/pktgen.conf-1-1, and modified it to use 1500 byte packets. Leaving it at the default 10 million packet count, the test generates 15GB of outgoing packets and takes about 3 minutes to run.
- during that 3 minutes, generate some RX traffic too. On another box, I do "dd if=/dev/zero of=/tmp/foo bs=1048576 count=128". I then scp that file back to the target box. If this succeeds, I do it again.
- usually this will reproduce the freeze within a few seconds, and always within a minute or two.
- often but not always, before it freezes, I will see multiple "r8169 0000:02:00.0: eth0: link up" messages (with no intervening "link down"), if I'm watching the kernel log or appropriately configured console. This is kind of a canary for the impending freeze.
What happens when it freezes:
- apparently, nothing at all, though the other test box running the client side of the scp will notice the transfer stalling.
- at this point, the target box won't respond at all on the network.
- it also won't respond to keyboard input from a USB keyboard
- including the magic sysrq key, which is configured (i.e. it works before the freeze)
- even if I use sysrq+9 to set console loglevel to 9, nothing is printed to console when it freezes
- upon reboot, there's nothing interesting or recent in /var/log/kern.log
- the "eth0: link up" messages being the exception; they do show up on the console at log level 9, and do show up in kern.log if it was synced before the freeze.
- I tried configuring nmi watchdog but could not get it to work on this box. So, no info from where it's freezing.
So what then:
It was the multiple "eth0: link up" messages that drew my attention in the direction of the network. As soon as I started googling for "r8169 freeze", I found all sorts of reports of different problems with r8169, going back years, so it's hard to know what's still relevant now and on my hardware -- people complain about freezes, dropped packets, refusal to autonegotiate media type or to work at rates faster than 10mbit… I didn't have any of these problems except the freeze.
The fix usually suggested for problems with r8169 is to go to Realtek and get r8168 instead. I'm a little leery of this (why is there an apparently open-source driver but not in-tree, maintained only by Realtek but with modinfo reporting "author: Realtek and the Linux r8168 crew <netdev@vger.kernel.org>"?; also I noticed http://packages.debian.org/unstable/main/r8168-dkms which says "This driver should only be used for devices not yet supported by the in-kernel driver r8169") but hey, I gave it a try. I downloaded the 8.027 version of this, compiled it, installed, it, used it, and couldn't get it to crash, but also couldn't get it to work with vlan virtual interfaces, which I intend to use (and which work fine with r8169), so it's not much good to me. (I gather from, for example, http://patchwork.ozlabs.org/patch/28045/ that this list doesn't maintain r8168 and doesn't care about bugs in it and is annoyed by the author claim, so I'm not coming here to complain about r8168, but just to point out that I did try it.)
I was losing hope of getting reliable Linux networking on this fit-pc at all, but then I found https://bugs.launchpad.net/ubuntu/+source/linux-backports-modules-3.0.0/+bug/839393, wherein some enterprising souls have backported the r8169 driver from "Linux 3.1" (I don't know exactly what vintage 3.1) because it's more reliable. So I tried that backported one and it does indeed seem to work better. If I perform the same test as above (pktgen generating TX traffic and scp generating RX traffic), I still see the multiple "eth0: link up" messages, but now the kernel does not freeze, and I get a backtrace (once -- soon after the "link up" thing starts, probably corresponding to when the freeze would have happened).
A run of my test with this driver, including the kernel backtrace, looks something like:
Dec 17 19:20:22 flux kernel: [ 200.958872] pktgen: Packet Generator for packet performance testing. Version: 2.74
Dec 17 19:20:34 flux kernel: [ 213.029292] SysRq : Changing Loglevel
Dec 17 19:20:34 flux kernel: [ 213.029437] Loglevel set to 9
Dec 17 19:20:53 flux kernel: [ 232.052203] r8169 0000:02:00.0: eth0: link up
Dec 17 19:20:55 flux kernel: [ 233.772238] r8169 0000:02:00.0: eth0: link up
Dec 17 19:20:55 flux kernel: [ 233.788188] r8169 0000:02:00.0: eth0: link up
Dec 17 19:20:55 flux kernel: [ 234.196614] ------------[ cut here ]------------
Dec 17 19:20:55 flux kernel: [ 234.196802] WARNING: at /build/buildd/linux-3.0.0/net/core/dev.c:3809 net_rx_action+0x1f3/0x220()
Dec 17 19:20:55 flux kernel: [ 234.197053] Hardware name: CM-iAM/SBC-FITPC2i
Dec 17 19:20:55 flux kernel: [ 234.197181] Modules linked in: pktgen act_police cls_flow cls_fw cls_u32 sch_tbf sch_prio sch_htb sch_hfsc sch_ingress sch_sfq xt_time xt_connlimit xt_realm xt_addrtype iptable_raw xt_comment xt_recent xt_policy ipt_ULOG ipt_REJECT ipt_REDIRECT ipt_NETMAP ipt_MASQUERADE ipt_ECN ipt_ecn ipt_CLUSTERIP ipt_ah xt_set ip_set nf_nat_tftp nf_nat_snmp_basic nf_conntrack_snmp nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip nf_conntrack_proto_sctp nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp xt_TPROXY nf_tproxy_core ip6_tables nf_defrag_ipv6 xt_tcpmss xt_pkttype xt_physdev xt_owner xt_NFQUEUE xt_NFLOG nfnetlink_log xt_multiport xt_mark xt_mac xt_limit xt_length xt_iprange xt_helper xt_hashlimit xt_DSCP xt_dscp xt_dccp xt_conntrack xt_connmark xt_CLASSIFY xt
Dec 17 19:20:55 flux kernel: _AUDIT ipt_LOG xt_tcpudp xt_state iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack iptable_mangle nfnetlink iptable_filter ip_tables x_tables 8021q garp stp vesafb i2c_isch sch_gpio psb_gfx(C) snd_hda_codec_realtek psmouse drm_kms_helper snd_hda_intel serio_raw snd_hda_codec drm snd_hwdep lpc_sch snd_pcm snd_timer i2c_algo_bit snd soundcore snd_page_alloc poulsbo video lp parport usbhid hid pata_sch sdhci_pci sdhci r8169
Dec 17 19:20:55 flux kernel: [ 234.202347] Pid: 1550, comm: kpktgend_0 Tainted: G C 3.0.0-14-generic #23-Ubuntu
Dec 17 19:20:55 flux kernel: [ 234.202576] Call Trace:
Dec 17 19:20:55 flux kernel: [ 234.202664] [<c151a3f2>] ? printk+0x2d/0x2f
Dec 17 19:20:55 flux kernel: [ 234.202804] [<c1047a22>] warn_slowpath_common+0x72/0xa0
Dec 17 19:20:55 flux kernel: [ 234.202962] [<c143ba03>] ? net_rx_action+0x1f3/0x220
Dec 17 19:20:55 flux kernel: [ 234.203112] [<c143ba03>] ? net_rx_action+0x1f3/0x220
Dec 17 19:20:55 flux kernel: [ 234.203263] [<c1047a72>] warn_slowpath_null+0x22/0x30
Dec 17 19:20:55 flux kernel: [ 234.203417] [<c143ba03>] net_rx_action+0x1f3/0x220
Dec 17 19:20:55 flux kernel: [ 234.203567] [<c104e570>] ? local_bh_enable_ip+0x90/0x90
Dec 17 19:20:55 flux kernel: [ 234.203725] [<c104e5f1>] __do_softirq+0x81/0x1a0
Dec 17 19:20:55 flux kernel: [ 234.203868] [<c104e570>] ? local_bh_enable_ip+0x90/0x90
Dec 17 19:20:55 flux kernel: [ 234.204041] <IRQ> [<c104e559>] ? local_bh_enable_ip+0x79/0x90
Dec 17 19:20:55 flux kernel: [ 234.204244] [<c152dbd6>] ? _raw_spin_unlock_bh+0x16/0x20
Dec 17 19:20:55 flux kernel: [ 234.204411] [<f98430a4>] ? pktgen_xmit+0x144/0x270 [pktgen]
Dec 17 19:20:55 flux kernel: [ 234.204623] [<f80479c0>] ? rtl8169_close+0x210/0x210 [r8169]
Dec 17 19:20:55 flux kernel: [ 234.204795] [<f984007b>] ? pktgen_change_name+0x7b/0xa0 [pktgen]
Dec 17 19:20:55 flux kernel: [ 234.204974] [<f98432c4>] ? pktgen_thread_worker+0xf4/0x370 [pktgen]
Dec 17 19:20:55 flux kernel: [ 234.205167] [<c1066380>] ? add_wait_queue+0x50/0x50
Dec 17 19:20:55 flux kernel: [ 234.205316] [<c1066380>] ? add_wait_queue+0x50/0x50
Dec 17 19:20:55 flux kernel: [ 234.205467] [<f98431d0>] ? pktgen_xmit+0x270/0x270 [pktgen]
Dec 17 19:20:55 flux kernel: [ 234.205634] [<c1065b7d>] ? kthread+0x6d/0x80
Dec 17 19:20:55 flux kernel: [ 234.205767] [<c1065b10>] ? flush_kthread_worker+0x80/0x80
Dec 17 19:20:55 flux kernel: [ 234.205931] [<c153517e>] ? kernel_thread_helper+0x6/0x10
Dec 17 19:20:55 flux kernel: [ 234.217422] ---[ end trace 7229c628b96ddd29 ]---
Dec 17 19:20:55 flux kernel: [ 234.229519] r8169 0000:02:00.0: eth0: link up
Dec 17 19:20:56 flux kernel: [ 234.604219] r8169 0000:02:00.0: eth0: link up
Dec 17 19:21:00 flux kernel: [ 238.592202] r8169 0000:02:00.0: eth0: link up
Dec 17 19:21:03 flux kernel: [ 241.848236] r8169 0000:02:00.0: eth0: link up
Dec 17 19:21:05 flux kernel: [ 244.144217] r8169 0000:02:00.0: eth0: link up
Dec 17 19:21:07 flux kernel: [ 245.540217] r8169 0000:02:00.0: eth0: link up
Dec 17 19:21:14 flux kernel: [ 253.228245] r8169 0000:02:00.0: eth0: link up
Dec 17 19:21:14 flux kernel: [ 253.260220] r8169 0000:02:00.0: eth0: link up
Please let me know if I'm reporting this to the right place, or if there's any other helpful info I can provide.
thanks,
Matt
^ permalink raw reply
* Re: [PATCH] net: meth: Add set_rx_mode hook to fix ICMPv6 neighbor discovery
From: Joshua Kinard @ 2011-12-18 4:37 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-mips
In-Reply-To: <20111217.215630.640392276998191183.davem@davemloft.net>
On 12/17/2011 21:56, David Miller wrote:
> From: Joshua Kinard <kumba@gentoo.org>
> Date: Sat, 17 Dec 2011 19:56:29 -0500
>
>> +/* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
>> + * MACE Ethernet uses a 64 element hash table based on the Ethernet CRC.
>> + */
>> +static int multicast_filter_limit = 32;
>> +
>> +
>
> Unnecessary empty line, only one is sufficient. I also don't see a reason
> to even define this value. If it's a constant then use a const type.
Lifted straight out of another driver already in the tree and checked
against the docs. I can spin a new patch to constify it, but the same fix
is needed for several other drivers, too.
>> + /* Multicast filter. */
>> + unsigned long mcast_filter;
>> +
> ...
>> + priv->mcast_filter = 0xffffffffffffffffUL;
>
> You're assuming that unsigned long is 64-bits here. You need to use a
> type which matches your expections regardless of the architecture that
> the code is built on.
MACE Ethernet only ever appears on the SGI O2 systems. It's part of the
MACE chip and doesn't exist (as far as I know) in any kind of standalone
form. It's virtually impossible for it to appear outside of any other
architecture/machine.
That said, would using 'u64' over 'unsigned long' work? The O2 codebase is
far from pretty, and would need a LOT of cleanups along similar lines. This
code simply matches what is already existing in-tree.
>> + netdev_for_each_mc_addr(ha, dev)
>> + set_bit((ether_crc(ETH_ALEN, ha->addr) >> 26),
>> + (volatile long unsigned int *)&priv->mcast_filter);
>
> This makes an assumption not only about the size of the "unsigned long"
> type, but also of the endianness of the architecture this runs on.
>
> Please recode this to remove both assumptions.
See note above regarding the 'unsigned long' bit. The endian assumption is
not directly visible to me, however. What, specifically, is incorrect? The
call to ether_crc? The bitwise right-shift? set_bit?
I lifted this out of au1000_eth.c (which is a little-endian MIPS device, if
I recall correctly), and all the digging I could do states that the Ethernet
CRC algorithm is LE anyways (ether_crc() calls crc32_le, bitrev32, and
such). I couldn't find anything big-endian about it, even when I tested it
against several other code samples that computed the 6-bit hash key from the
Dst MAC address.
Thanks,
--
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28
"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
^ permalink raw reply
* Re: [PATCH] net: meth: Some code cleanups for meth
From: Joshua Kinard @ 2011-12-18 4:42 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-mips
In-Reply-To: <20111217.220032.683061606470374131.davem@davemloft.net>
On 12/17/2011 22:00, David Miller wrote:
> From: Joshua Kinard <kumba@gentoo.org>
> Date: Sat, 17 Dec 2011 20:27:42 -0500
>
>> -#define WAIT_FOR_PHY(___rval) \
>> - while ((___rval = mace->eth.phy_data) & MDIO_BUSY) { \
>> - udelay(25); \
>> +#define WAIT_FOR_PHY(___rval) \
>> + while ((___rval = mace->eth.phy_data) & MDIO_BUSY) { \
>> + udelay(25); \
>
> I think using tabs at the end of the line to line up the "\" is much
> better than what you're changing it to, that being spaces.
Mistake from when I still had my editor switched to spaces mode. I set it
to tab mode a little bit later and didn't think to go back and correct this.
>> - priv->phy_addr=i;
>> - p2=mdio_read(priv,2);
>> - p3=mdio_read(priv,3);
>> +
>> + for (i = 0; i < 32; i++){
>> + priv->phy_addr = i;
>> + p2 = mdio_read(priv,2);
>> + p3 = mdio_read(priv,3);
>
> If you're going to put forth the effort to put spaces around the
> "=" characters, fix up the arguments to mdio_read() as well, there
> needs to be a space after the "," and right before the second
> argument.
>
It's not that it took a lot of effort, I just simply missed the space after
the comma. It still looks better :)
>> + if ((p2 != 0xffff) && (p2 != 0x0000)) {
>
> There is no need for the new parenthesis you are adding here. It
> doesn't change things semantically, and it does not improve
> readability, it just makes for more characters a human has to parse in
> his mind.
>
It's a habit -- I blame math from grade school years ago. I'll remove them
in the next version.
>> - * Copyright (C) 2001 Alessandro Rubini and Jonathan Corbet
>> - * Copyright (C) 2001 O'Reilly & Associates
>> + * Copyright (C) 2001-2003 Ilya Volynets
>> + * Copyright (C) 2011 Joshua Kinard
>> *
>> - * The source code in this file can be freely used, adapted,
>> - * and redistributed in source or binary form, so long as an
>> - * acknowledgment appears in derived source files. The citation
>> - * should list that the code comes from the book "Linux Device
>> - * Drivers" by Alessandro Rubini and Jonathan Corbet, published
>> - * by O'Reilly & Associates. No warranty is attached;
>> - * we cannot take responsibility for errors or fitness for use.
>> + * 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.
>> */
>
> I'm not sure at all that you have the ability to make this kind of
> change to the copyright and attributions here.
Looking at the header file, I really cannot find anything that would bear in
common with sample code from a book. If it was an actual driver file,
maybe. But a header file containing specific definitions for hardware bits?
I tracked down the first commit back in 2001 and put in the guy who
initially submitted it. Is there a better way to handle this? I doubt that
book had SGI O2 MACE Ethernet-specific defines in it.
> There are probably a lot more problems with this patch, but I'm
> exhausted look at this stuff as-is.
Probably :)
--
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28
"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
^ permalink raw reply
* netem and multiple parameters
From: John A. Sullivan III @ 2011-12-18 5:03 UTC (permalink / raw)
To: netdev
Hello, all. When using netem and desiring multiple characteristics such
as delay and packet loss, is it appropriate to place them on one line?
I've seen examples of doing that while researching but it doesn't seem
to be working for me. I have a netem qdisc on both egress and ingress
(for a specific reason) each with 25ms delay and 0.1% packet loss:
tc qdisc add dev ifb1 root handle 2 netem delay 25ms 5ms distribution normal loss 0.1% 30%
tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 match u32 0 0 action mirred egress redirect dev ifb1
tc qdisc add dev ifb0 root handle 1: hfsc default 20
tc class add dev ifb0 parent 1: classid 1:1 hfsc sc rate 1490kbit ul rate 1490kbit
tc class add dev ifb0 parent 1:1 classid 1:20 hfsc rt rate 400kbit ls rate 200kbit
tc qdisc add dev ifb0 parent 1:20 handle 1201 netem delay 25ms 5ms distribution normal loss 0.1% 30%
I see the 50ms delay but, after two runs of 6000 pings, I see no packet
loss whatsoever. I would have expected about 12 dropped packets:
6570 packets transmitted, 6570 received, 0% packet loss, time 1975920ms
rtt min/avg/max/mdev = 23.983/50.830/75.255/7.101 ms
6536 packets transmitted, 6536 received, 0% packet loss, time 1965211ms
rtt min/avg/max/mdev = 23.298/50.877/74.216/7.064 ms
What have I mangled? Thanks - John
^ permalink raw reply
* netem and hierarchical ingress traffic shaping
From: John A. Sullivan III @ 2011-12-18 5:12 UTC (permalink / raw)
To: netdev
Hello, all. I am having some delightful success building a test WAN
environment using hfsc and netem. We have placed netem on both ingress
and egress for various test environment reasons. We are also using hfsc
on both ingress and egress for traffic shaping.
Since netem appears to be classless, we realized we would need to
replace the SFQ on each leaf with netem which we really didn't want to
do - not only to not lose SFQ but because we didn't want to maintain the
netem parameters on each leaf. So, we activated our ifb1 interface,
placed netem on it and redirected all the egress traffic to ifb1. Taht
worked fine.
However, how do we do this on the ingress? To use hfsc on ingres, we are
already redirecting to ifb0. We can't redirect ifb0 to ifb1. If we
apply multiple filters, one to redirect into ifb0 and the other to ifb1,
only the first match takes effect. So we are living with replacing SFQ
on the ifb0 leaves with netem.
Is there any other way? Thanks - John
In case it is of interest, here is the set of rules we are using:
tc qdisc add dev eth1 root handle 1: hfsc default 20
tc class add dev eth1 parent 1: classid 1:1 hfsc sc rate 1490kbit ul rate 1490kbit
tc class add dev eth1 parent 1:1 classid 1:20 hfsc rt rate 400kbit ls rate 200kbit
tc qdisc add dev eth1 parent 1:20 handle 1201 sfq perturb 10
tc class add dev eth1 parent 1:1 classid 1:10 hfsc rt umax 16kbit dmax 50ms rate 200kbit ls rate 1000kbit
tc qdisc add dev eth1 parent 1:10 handle 1101 sfq perturb 60
tc class add dev eth1 parent 1:1 classid 1:30 hfsc rt umax 1514b dmax 20ms rate 20kbit
tc qdisc add dev eth1 parent 1:30 handle 1301 sfq perturb 60
iptables -t mangle -A POSTROUTING -p 6 --syn --dport 443 -j CONNMARK --set-mark 0x10
iptables -t mangle -A PREROUTING -p 6 --syn --dport 822 -j CONNMARK --set-mark 0x11
iptables -t mangle -A POSTROUTING -o eth1 -p 6 -j CONNMARK --restore-mark
tc filter add dev eth1 parent 1:0 protocol ip prio 10 handle 0x10 fw flowid 1:10
tc filter add dev eth1 parent 1:0 protocol ip prio 10 handle 0x11 fw flowid 1:30
tc qdisc add dev eth1 ingress
modprobe ifb
ifconfig ifb0 up
tc filter add dev eth1 parent ffff: protocol ip prio 50 u32 match u32 0 0 action mirred egress redirect dev ifb0
tc qdisc add dev ifb0 root handle 1: hfsc default 20
tc class add dev ifb0 parent 1: classid 1:1 hfsc sc rate 1490kbit ul rate 1490kbit
tc class add dev ifb0 parent 1:1 classid 1:20 hfsc rt rate 400kbit ls rate 200kbit
tc qdisc add dev ifb0 parent 1:20 handle 1201 netem delay 25ms 5ms distribution normal loss 0.1% 30%
tc class add dev ifb0 parent 1:1 classid 1:10 hfsc rt umax 16kbit dmax 50ms rate 200kbit ls rate 1000kbit
tc qdisc add dev ifb0 parent 1:10 handle 1101 netem delay 25ms 5ms distribution normal loss 0.1% 30%
tc class add dev ifb0 parent 1:1 classid 1:30 hfsc rt umax 1514b dmax 20ms rate 20kbit
tc qdisc add dev ifb0 parent 1:30 handle 1301 netem delay 25ms 5ms distribution normal loss 0.1% 30%
tc filter add dev ifb0 parent 1:0 protocol ip prio 1 handle 6: u32 divisor 1
tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 match ip protocol 6 0xff link 6: offset at 0 mask 0x0f00 shift 6 plus 0 eat
tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 ht 6:0 match tcp src 443 0x00ff flowid 1:10
tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 ht 6:0 match tcp dst 822 0xff00 flowid 1:30
ifconfig ifb1 up
tc qdisc add dev ifb1 root handle 2 netem delay 25ms 5ms distribution normal loss 0.1% 30%
tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 match u32 0 0 action mirred egress redirect dev ifb1
^ permalink raw reply
* Re: [PATCH] net: meth: Add set_rx_mode hook to fix ICMPv6 neighbor discovery
From: David Miller @ 2011-12-18 5:19 UTC (permalink / raw)
To: kumba; +Cc: netdev, linux-mips
In-Reply-To: <4EED6DED.50308@gentoo.org>
From: Joshua Kinard <kumba@gentoo.org>
Date: Sat, 17 Dec 2011 23:37:01 -0500
> MACE Ethernet only ever appears on the SGI O2 systems.
That has no bearing on my feedback, we simply do not put non-portable
code like this into the tree at this point.
Just because this driver has been maintained in an non-portable manner
up to this point, doesn't mean we continue doing that.
^ permalink raw reply
* Darlehen
From: E F C C @ 2011-12-18 7:38 UTC (permalink / raw)
--
Hallo,
Sie suchen einen Business-Darlehen, persönliche Darlehen, Haus,
Auto-Darlehen, Darlehen, Schuldenkonsolidierung Darlehen, unbesicherte
Darlehen, Risikokapital, etc. .. Oder haben Sie schon ein Darlehen von
einer Bank oder ein Finanzinstitut Konfiguration eines oder mehrerer
reasons.You eher ihre Kredit-Lösungen verweigert! Ich bin ein Pastor,
ein privater Kreditgeber, die Kreditvergabe an Unternehmen und
Privatpersonen in einer niedrigen und erschwinglichen Zinssatz von 2%.
Interessiert? Kontakt zur Behandlung des Darlehens zu folgen
Transfer innerhalb von 48 Stunden. KONTAKT: harryfinancialfirm1@gmail.com
Anwendungsdetails
Name:
Geburtstag:
Geschlecht:
Familienstand:
Anschrift:
Lage
Status:
Postleitzahl:
Land:
Telefon:
E-mail:
Staatliche Zweck des Darlehens:
Darlehensbetrag:
Dauer der Ausleihe:
Monatliches Nettoeinkommen.
Zurück zu mir so bald wie möglich mit den oben genannten Informationen
für weitere Informationen.
Hoffnung, von Ihnen zu hören.
Vielen Dank und Gott segne Sie,
Pastor James Harry
^ permalink raw reply
* Re: v6: faster tree-based sysctl implementation
From: Eric W. Biederman @ 2011-12-18 8:05 UTC (permalink / raw)
To: Lucian Adrian Grijincu
Cc: linux-kernel, netdev, Octavian Purdila, David S . Miller,
Alexey Dobriyan, Damien Millescamps, Anca Emanuel,
Benjamin LaHaise
In-Reply-To: <m1obv9rkyp.fsf@fess.ebiederm.org>
I spent some time playing this and managed to get something that works
using proc_dir_entries. And while it is simpler (600 less lines of
code) it takes about 3x the space of just what using ctl_table entries
does.
I managed to prove to myself that the current sysctl infrastructure
relies the union directory existence semantics pretty strongly. Despite
all of Al's work to the contrary when he introduced attached_by and kin
in sysctl head.
One nice thing I managed to do was to shift around the problem a bit
so that only at /proc/sys/net do we to namespace weirdness. Which also
considerably simplifies the problem.
Now that I know that normal unix directory semantics are a lost cause
removing the child entry from ctl_table looks like a very productive
exercise.
Furthermore it feels like the optimal data structure would be a
directory tree that is created on demand as we create entries,
and a second copy of that directory tree that is per network namespace.
That is very similar to the data structure you wound up with.
So in the next little bit I am going to see if I can combine what
you did and what I did and see if I can come up with something that
is obvious in how it works from looking at it's data structures.
Eric
^ permalink raw reply
* Re: [PATCH] 9p: Don't use ATTR_* values from fs.h in userspace facing structs
From: Aneesh Kumar K.V @ 2011-12-18 8:38 UTC (permalink / raw)
To: Al Viro, Sasha Levin
Cc: ericvh, rminnich, lucho, davem, jvrao, v9fs-developer, netdev,
linux-kernel
In-Reply-To: <20111217174725.GW2203@ZenIV.linux.org.uk>
On Sat, 17 Dec 2011 17:47:25 +0000, Al Viro <viro@ZenIV.linux.org.uk> wrote:
> On Sat, Dec 17, 2011 at 05:07:02PM +0200, Sasha Levin wrote:
> > struct p9_iattr_dotl is userspace facing, but the 'valid' field is documented
> > as follows:
> >
> > * @valid: bitfield specifying which fields are valid
> > * same as in struct iattr
> >
> > Which means that the user has to know about kernel internal ATTR_* values.
> >
> > On Fri, 2011-12-16 at 23:30 +0000, Al Viro wrote:
> > > They *are* kernel internal values and 9P is asking for trouble exposing
> > > them. Translation: tomorrow we might reassign those as we bloody wish
> > > and any userland code that happens to rely on their values will break.
> > > At which point we'll handle complaints by pointing and laughing.
> > >
> > > It's a 9P bug; fix it there. Turning random internal constants into a part
> > > of ABI is not going to work.
> >
> > Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
> > ---
> > fs/9p/vfs_inode_dotl.c | 31 ++++++++++++++++++++++++++++++-
> > include/net/9p/9p.h | 18 ++++++++++++++++++
> > 2 files changed, 48 insertions(+), 1 deletions(-)
> >
> > diff --git a/fs/9p/vfs_inode_dotl.c b/fs/9p/vfs_inode_dotl.c
> > index 0b5745e..a948214 100644
> > --- a/fs/9p/vfs_inode_dotl.c
> > +++ b/fs/9p/vfs_inode_dotl.c
> > @@ -523,6 +523,35 @@ v9fs_vfs_getattr_dotl(struct vfsmount *mnt, struct dentry *dentry,
> > return 0;
> > }
> >
> > +int v9fs_vfs_iattr_to_9p_valid(u32 ia_valid)
> > +{
> > + u32 valid = 0, i;
> > + static u32 attr_map[][2] = {
> > + {ATTR_MODE, P9_ATTR_MODE},
> > + {ATTR_UID, P9_ATTR_UID},
> > + {ATTR_SIZE, P9_ATTR_SIZE},
> > + {ATTR_ATIME, P9_ATTR_ATIME},
> > + {ATTR_MTIME, P9_ATTR_MTIME},
> > + {ATTR_CTIME, P9_ATTR_CTIME},
> > + {ATTR_ATIME_SET, P9_ATTR_ATIME_SET},
> > + {ATTR_MTIME_SET, P9_ATTR_MTIME_SET},
> > + {ATTR_FORCE, P9_ATTR_FORCE},
> > + {ATTR_ATTR_FLAG, P9_ATTR_ATTR_FLAG},
> > + {ATTR_KILL_SUID, P9_ATTR_KILL_SUID},
> > + {ATTR_KILL_SGID, P9_ATTR_KILL_SGID},
> > + {ATTR_FILE, P9_ATTR_FILE},
> > + {ATTR_KILL_PRIV, P9_ATTR_KILL_PRIV},
> > + {ATTR_OPEN, P9_ATTR_OPEN},
> > + {ATTR_TIMES_SET, P9_ATTR_TIMES_SET},
> > + };
>
> a) ATTR_GID is lost
> b) passing ATTR_FILE is bloody pointless; look at what it does and
> realize that 9p doesn't as much as look at ia_file.
> c) ATTR_KILL_PRIV is very dubious; what's the legitimate use of that
> puppy in fs code?
>
> Look, that's the problem with exposing this stuff to protocol; you don't
> get clear semantics and are you seriously asking for trouble on kernel
> changes. Suppose tomorrow we get rid of e.g. ATTR_KILL_PRIV; what are you
> guys going to do? Hope that no 9p server has behaviour dependent on that
> flag being set or cleared?
>
> Don't turn the kernel internals into a part of ABI. And blind bulk remapping
> of constants is exactly that...
>
I am testing this locally.
commit 8ebbbcf5185096acccc523fb040e770d7876d4cd
Author: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Date: Sat Dec 17 21:01:08 2011 +0530
fs/9p: iattr_valid flags are kernel internal flags map them to 9p values.
Kernel internal values can change, add protocol values for these constant and
use them.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
diff --git a/fs/9p/vfs_inode_dotl.c b/fs/9p/vfs_inode_dotl.c
index 0b5745e..a81808a 100644
--- a/fs/9p/vfs_inode_dotl.c
+++ b/fs/9p/vfs_inode_dotl.c
@@ -523,6 +523,46 @@ v9fs_vfs_getattr_dotl(struct vfsmount *mnt, struct dentry *dentry,
return 0;
}
+/*
+ * Attribute flags.
+ */
+#define P9_ATTR_MODE (1 << 0)
+#define P9_ATTR_UID (1 << 1)
+#define P9_ATTR_GID (1 << 2)
+#define P9_ATTR_SIZE (1 << 3)
+#define P9_ATTR_ATIME (1 << 4)
+#define P9_ATTR_MTIME (1 << 5)
+#define P9_ATTR_CTIME (1 << 6)
+#define P9_ATTR_ATIME_SET (1 << 7)
+#define P9_ATTR_MTIME_SET (1 << 8)
+
+struct dotl_iattr_map {
+ int iattr_valid;
+ int p9_iattr_valid;
+};
+
+static int v9fs_mapped_iattr_valid(int iattr_valid)
+{
+ int i;
+ int p9_iattr_valid = 0;
+ struct dotl_iattr_map dotl_iattr_map[] = {
+ { ATTR_MODE, P9_ATTR_MODE },
+ { ATTR_UID, P9_ATTR_UID },
+ { ATTR_GID, P9_ATTR_GID },
+ { ATTR_SIZE, P9_ATTR_SIZE },
+ { ATTR_ATIME, P9_ATTR_ATIME },
+ { ATTR_MTIME, P9_ATTR_MTIME },
+ { ATTR_CTIME, P9_ATTR_CTIME },
+ { ATTR_ATIME_SET, P9_ATTR_ATIME_SET },
+ { ATTR_MTIME_SET, P9_ATTR_MTIME_SET },
+ };
+ for (i = 0; i < ARRAY_SIZE(dotl_iattr_map); i++) {
+ if (iattr_valid & dotl_iattr_map[i].iattr_valid)
+ p9_iattr_valid |= dotl_iattr_map[i].p9_iattr_valid;
+ }
+ return p9_iattr_valid;
+}
+
/**
* v9fs_vfs_setattr_dotl - set file metadata
* @dentry: file whose metadata to set
@@ -543,7 +583,7 @@ int v9fs_vfs_setattr_dotl(struct dentry *dentry, struct iattr *iattr)
if (retval)
return retval;
- p9attr.valid = iattr->ia_valid;
+ p9attr.valid = v9fs_mapped_iattr_valid(iattr->ia_valid);
p9attr.mode = iattr->ia_mode;
p9attr.uid = iattr->ia_uid;
p9attr.gid = iattr->ia_gid;
^ permalink raw reply related
* Re: reproducible kernel freeze using r8169 in Linux 3.0
From: Francois Romieu @ 2011-12-18 8:32 UTC (permalink / raw)
To: Matt Ginzton; +Cc: nic_swsd, netdev
In-Reply-To: <63CE35CA-7DD6-41EC-A745-6BA776D8C5E3@ginzton.net>
Matt Ginzton <matt@ginzton.net> :
[...]
> Please let me know if I'm reporting this to the right place, or if there's
> any other helpful info I can provide.
Please grep for a XID line in dmesg and send it so we can figure the
specific revision of your chipset (lspci can not figure it).
If it says something like "blah blah XID 1c4...", you should give current
-rc a try (who shouldn't ?).
--
Ueimor
^ permalink raw reply
* Re: [PATCH] 9p: Don't use ATTR_* values from fs.h in userspace facing structs
From: Aneesh Kumar K.V @ 2011-12-18 8:43 UTC (permalink / raw)
To: Al Viro, Sasha Levin
Cc: ericvh, rminnich, lucho, davem, jvrao, v9fs-developer, netdev,
linux-kernel
In-Reply-To: <87pqfmgtph.fsf@linux.vnet.ibm.com>
On Sun, 18 Dec 2011 14:08:50 +0530, "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:
> On Sat, 17 Dec 2011 17:47:25 +0000, Al Viro <viro@ZenIV.linux.org.uk> wrote:
> > On Sat, Dec 17, 2011 at 05:07:02PM +0200, Sasha Levin wrote:
> > > struct p9_iattr_dotl is userspace facing, but the 'valid' field is documented
> > > as follows:
> > >
> > > * @valid: bitfield specifying which fields are valid
> > > * same as in struct iattr
> > >
> > > Which means that the user has to know about kernel internal ATTR_* values.
> > >
> > > On Fri, 2011-12-16 at 23:30 +0000, Al Viro wrote:
> > > > They *are* kernel internal values and 9P is asking for trouble exposing
> > > > them. Translation: tomorrow we might reassign those as we bloody wish
> > > > and any userland code that happens to rely on their values will break.
> > > > At which point we'll handle complaints by pointing and laughing.
> > > >
> > > > It's a 9P bug; fix it there. Turning random internal constants into a part
> > > > of ABI is not going to work.
> > >
> > > Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
> > > ---
> > > fs/9p/vfs_inode_dotl.c | 31 ++++++++++++++++++++++++++++++-
> > > include/net/9p/9p.h | 18 ++++++++++++++++++
> > > 2 files changed, 48 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/fs/9p/vfs_inode_dotl.c b/fs/9p/vfs_inode_dotl.c
> > > index 0b5745e..a948214 100644
> > > --- a/fs/9p/vfs_inode_dotl.c
> > > +++ b/fs/9p/vfs_inode_dotl.c
> > > @@ -523,6 +523,35 @@ v9fs_vfs_getattr_dotl(struct vfsmount *mnt, struct dentry *dentry,
> > > return 0;
> > > }
> > >
> > > +int v9fs_vfs_iattr_to_9p_valid(u32 ia_valid)
> > > +{
> > > + u32 valid = 0, i;
> > > + static u32 attr_map[][2] = {
> > > + {ATTR_MODE, P9_ATTR_MODE},
> > > + {ATTR_UID, P9_ATTR_UID},
> > > + {ATTR_SIZE, P9_ATTR_SIZE},
> > > + {ATTR_ATIME, P9_ATTR_ATIME},
> > > + {ATTR_MTIME, P9_ATTR_MTIME},
> > > + {ATTR_CTIME, P9_ATTR_CTIME},
> > > + {ATTR_ATIME_SET, P9_ATTR_ATIME_SET},
> > > + {ATTR_MTIME_SET, P9_ATTR_MTIME_SET},
> > > + {ATTR_FORCE, P9_ATTR_FORCE},
> > > + {ATTR_ATTR_FLAG, P9_ATTR_ATTR_FLAG},
> > > + {ATTR_KILL_SUID, P9_ATTR_KILL_SUID},
> > > + {ATTR_KILL_SGID, P9_ATTR_KILL_SGID},
> > > + {ATTR_FILE, P9_ATTR_FILE},
> > > + {ATTR_KILL_PRIV, P9_ATTR_KILL_PRIV},
> > > + {ATTR_OPEN, P9_ATTR_OPEN},
> > > + {ATTR_TIMES_SET, P9_ATTR_TIMES_SET},
> > > + };
> >
> > a) ATTR_GID is lost
> > b) passing ATTR_FILE is bloody pointless; look at what it does and
> > realize that 9p doesn't as much as look at ia_file.
> > c) ATTR_KILL_PRIV is very dubious; what's the legitimate use of that
> > puppy in fs code?
> >
> > Look, that's the problem with exposing this stuff to protocol; you don't
> > get clear semantics and are you seriously asking for trouble on kernel
> > changes. Suppose tomorrow we get rid of e.g. ATTR_KILL_PRIV; what are you
> > guys going to do? Hope that no 9p server has behaviour dependent on that
> > flag being set or cleared?
> >
> > Don't turn the kernel internals into a part of ABI. And blind bulk remapping
> > of constants is exactly that...
> >
>
qemu part if you are interested.
commit 9a45b894ab6d5e4480e721a40e8e8c160344c9fe
Author: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Date: Sat Dec 17 21:02:57 2011 +0530
hw/9pfs: iattr_valid flags are kernel internal flags map them to 9p values.
Kernel internal values can change, add protocol values for these constant and
use them.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
index b3fc3d0..567f6cb 100644
--- a/hw/9pfs/virtio-9p.c
+++ b/hw/9pfs/virtio-9p.c
@@ -1293,17 +1293,18 @@ out_nofid:
complete_pdu(s, pdu, retval);
}
-/* From Linux kernel code */
-#define ATTR_MODE (1 << 0)
-#define ATTR_UID (1 << 1)
-#define ATTR_GID (1 << 2)
-#define ATTR_SIZE (1 << 3)
-#define ATTR_ATIME (1 << 4)
-#define ATTR_MTIME (1 << 5)
-#define ATTR_CTIME (1 << 6)
-#define ATTR_MASK 127
-#define ATTR_ATIME_SET (1 << 7)
-#define ATTR_MTIME_SET (1 << 8)
+/* Attribute flags */
+#define P9_ATTR_MODE (1 << 0)
+#define P9_ATTR_UID (1 << 1)
+#define P9_ATTR_GID (1 << 2)
+#define P9_ATTR_SIZE (1 << 3)
+#define P9_ATTR_ATIME (1 << 4)
+#define P9_ATTR_MTIME (1 << 5)
+#define P9_ATTR_CTIME (1 << 6)
+#define P9_ATTR_ATIME_SET (1 << 7)
+#define P9_ATTR_MTIME_SET (1 << 8)
+
+#define P9_ATTR_MASK 127
static void v9fs_setattr(void *opaque)
{
@@ -1322,16 +1323,16 @@ static void v9fs_setattr(void *opaque)
err = -EINVAL;
goto out_nofid;
}
- if (v9iattr.valid & ATTR_MODE) {
+ if (v9iattr.valid & P9_ATTR_MODE) {
err = v9fs_co_chmod(pdu, &fidp->path, v9iattr.mode);
if (err < 0) {
goto out;
}
}
- if (v9iattr.valid & (ATTR_ATIME | ATTR_MTIME)) {
+ if (v9iattr.valid & (P9_ATTR_ATIME | P9_ATTR_MTIME)) {
struct timespec times[2];
- if (v9iattr.valid & ATTR_ATIME) {
- if (v9iattr.valid & ATTR_ATIME_SET) {
+ if (v9iattr.valid & P9_ATTR_ATIME) {
+ if (v9iattr.valid & P9_ATTR_ATIME_SET) {
times[0].tv_sec = v9iattr.atime_sec;
times[0].tv_nsec = v9iattr.atime_nsec;
} else {
@@ -1340,8 +1341,8 @@ static void v9fs_setattr(void *opaque)
} else {
times[0].tv_nsec = UTIME_OMIT;
}
- if (v9iattr.valid & ATTR_MTIME) {
- if (v9iattr.valid & ATTR_MTIME_SET) {
+ if (v9iattr.valid & P9_ATTR_MTIME) {
+ if (v9iattr.valid & P9_ATTR_MTIME_SET) {
times[1].tv_sec = v9iattr.mtime_sec;
times[1].tv_nsec = v9iattr.mtime_nsec;
} else {
@@ -1359,13 +1360,13 @@ static void v9fs_setattr(void *opaque)
* If the only valid entry in iattr is ctime we can call
* chown(-1,-1) to update the ctime of the file
*/
- if ((v9iattr.valid & (ATTR_UID | ATTR_GID)) ||
- ((v9iattr.valid & ATTR_CTIME)
- && !((v9iattr.valid & ATTR_MASK) & ~ATTR_CTIME))) {
- if (!(v9iattr.valid & ATTR_UID)) {
+ if ((v9iattr.valid & (P9_ATTR_UID | P9_ATTR_GID)) ||
+ ((v9iattr.valid & P9_ATTR_CTIME)
+ && !((v9iattr.valid & P9_ATTR_MASK) & ~P9_ATTR_CTIME))) {
+ if (!(v9iattr.valid & P9_ATTR_UID)) {
v9iattr.uid = -1;
}
- if (!(v9iattr.valid & ATTR_GID)) {
+ if (!(v9iattr.valid & P9_ATTR_GID)) {
v9iattr.gid = -1;
}
err = v9fs_co_chown(pdu, &fidp->path, v9iattr.uid,
@@ -1374,7 +1375,7 @@ static void v9fs_setattr(void *opaque)
goto out;
}
}
- if (v9iattr.valid & (ATTR_SIZE)) {
+ if (v9iattr.valid & (P9_ATTR_SIZE)) {
err = v9fs_co_truncate(pdu, &fidp->path, v9iattr.size);
if (err < 0) {
goto out;
^ permalink raw reply related
* Re: ipv6/addrconf_dad_failure printk() in interrupt context
From: Eric Dumazet @ 2011-12-18 9:15 UTC (permalink / raw)
To: Marek Vasut
Cc: netdev, Wolfgang Denk, David S. Miller, Alexey Kuznetsov,
James Morris, Hideaki YOSHIFUJI, Patrick McHardy
In-Reply-To: <201112180328.00422.marek.vasut@gmail.com>
Le dimanche 18 décembre 2011 à 03:28 +0100, Marek Vasut a écrit :
> Hi,
>
> I just recently hit the following issue. I might actually be wrong with my
> conclusions so bear with me. The events that led to the issue:
>
> 1) Duplicate IPv6 address on the network
> 2) console driver that locks a mutex when printk() is called
This seems buggy : printk() might be called from irq, so muext_lock() is
not allowed.
>
> The problem is the following backtrace:
>
> [ 4.870000] eth0: IPv6 duplicate address XXXX::YYYY:ZZZZ:WWWW:0 detected!
> [ 4.870000] ------------[ cut here ]------------
> [ 4.870000] WARNING: at kernel/mutex.c:198 mutex_lock_nested+0x284/0x2c0()
> [ 4.870000] Modules linked in:
> [ 4.870000] [<c0013ab8>] (unwind_backtrace+0x0/0xf0) from [<c001d934>]
> (warn_slowpath_common+0x4c/0x64)
> [ 4.870000] [<c001d934>] (warn_slowpath_common+0x4c/0x64) from [<c001d968>]
> (warn_slowpath_null+0x1c/0x24)
> [ 4.870000] [<c001d968>] (warn_slowpath_null+0x1c/0x24) from [<c033a4f4>]
> (mutex_lock_nested+0x284/0x2c0)
> [ 4.870000] [<c033a4f4>] (mutex_lock_nested+0x284/0x2c0) from [<c0017d88>]
> (clk_enable+0x20/0x48)
> [ 4.870000] [<c0017d88>] (clk_enable+0x20/0x48) from [<c01dfbf0>]
> (pl011_console_write+0x20/0x74)
> [ 4.870000] [<c01dfbf0>] (pl011_console_write+0x20/0x74) from [<c001da98>]
> (__call_console_drivers+0x7c/0x94)
> [ 4.870000] [<c001da98>] (__call_console_drivers+0x7c/0x94) from [<c001df20>]
> (console_unlock+0xf8/0x244)
> [ 4.870000] [<c001df20>] (console_unlock+0xf8/0x244) from [<c001e308>]
> (vprintk+0x29c/0x484)
> [ 4.870000] [<c001e308>] (vprintk+0x29c/0x484) from [<c03355a8>]
> (printk+0x20/0x30)
> [ 4.870000] [<c03355a8>] (printk+0x20/0x30) from [<c02df600>]
> (addrconf_dad_failure+0x148/0x158)
> [ 4.870000] [<c02df600>] (addrconf_dad_failure+0x148/0x158) from [<c02ebde0>]
> (ndisc_rcv+0xb38/0xdb0)
> [ 4.870000] [<c02ebde0>] (ndisc_rcv+0xb38/0xdb0) from [<c02f1b28>]
> (icmpv6_rcv+0x6ec/0x9c4)
> [ 4.870000] [<c02f1b28>] (icmpv6_rcv+0x6ec/0x9c4) from [<c02da9a4>]
> (ip6_input_finish+0x144/0x4e0)
> [ 4.870000] [<c02da9a4>] (ip6_input_finish+0x144/0x4e0) from [<c02db424>]
> (ip6_mc_input+0xb8/0x154)
> [ 4.870000] [<c02db424>] (ip6_mc_input+0xb8/0x154) from [<c02db12c>]
> (ipv6_rcv+0x300/0x53c)
> [ 4.870000] [<c02db12c>] (ipv6_rcv+0x300/0x53c) from [<c0267b78>]
> (__netif_receive_skb+0x240/0x420)
> [ 4.870000] [<c0267b78>] (__netif_receive_skb+0x240/0x420) from [<c0267de8>]
> (process_backlog+0x90/0x150)
> [ 4.870000] [<c0267de8>] (process_backlog+0x90/0x150) from [<c026a5f8>]
> (net_rx_action+0xc0/0x264)
> [ 4.870000] [<c026a5f8>] (net_rx_action+0xc0/0x264) from [<c0023cfc>]
> (__do_softirq+0xa8/0x214)
> [ 4.870000] [<c0023cfc>] (__do_softirq+0xa8/0x214) from [<c00242c0>]
> (irq_exit+0x8c/0x94)
> [ 4.870000] [<c00242c0>] (irq_exit+0x8c/0x94) from [<c000f6d0>]
> (handle_IRQ+0x34/0x84)
> [ 4.870000] [<c000f6d0>] (handle_IRQ+0x34/0x84) from [<c000e5d8>]
> (__irq_usr+0x38/0x80)
> [ 4.870000] ---[ end trace 32eab6a8dcdca9c0 ]---
>
> So basically what I see here is the following order of events:
>
> Packet received -> IRQ generated -> ipv6 packet received (still in interrupt
> context ... why not in tasklet ... or am I wrong here ?) -> icmpv6 packet
> processing -> addrconf_dad_failure() called -> printk() called in there ->
> mutex_lock() called in printk(), causing the warning.
>
> Can printk() be actually called in interrupt context?
>
Yes, it can be.
> What direction of solving this shall I take?
>
Send this to lkml, since its not a netdev issue, but a kernel one.
> Thanks in advance!
^ permalink raw reply
* Re: bnx2x firmware version 6.x.y
From: Eilon Greenstein @ 2011-12-18 9:21 UTC (permalink / raw)
To: Ben Hutchings
Cc: Dmitry Kravkov, Vladislav Zolotarov, LKML, netdev,
David Woodhouse
In-Reply-To: <1324140746.2825.335.camel@deadeye>
On Sat, 2011-12-17 at 08:52 -0800, Ben Hutchings wrote:
> In general, linux-firmware includes all blobs that any released version
> of a driver may need.
>
> Therefore, I'm about to add the bnx2x firmware versions 6.0.34.0,
> 6.2.5.0 and 6.2.9.0 (taken from kernel versions 2.6.37, 2.6.38 and 3.0
> respectively) into linux-firmware.
Ben - Thanks for doing that.
Acked-by: Eilon Greenstein <eilong@broadcom.com>
>
> The full lists of bnx2x firmware blobs that will be included after this
> is:
>
> bnx2x-e1-4.8.53.0.fw
> bnx2x-e1-5.2.13.0.fw
> bnx2x-e1-5.2.7.0.fw
> bnx2x-e1h-4.8.53.0.fw
> bnx2x-e1h-5.2.13.0.fw
> bnx2x-e1h-5.2.7.0.fw
> bnx2x/bnx2x-e1-6.0.34.0.fw
> bnx2x/bnx2x-e1-6.2.5.0.fw
> bnx2x/bnx2x-e1-6.2.9.0.fw
> bnx2x/bnx2x-e1-7.0.20.0.fw
> bnx2x/bnx2x-e1-7.0.23.0.fw
> bnx2x/bnx2x-e1-7.0.29.0.fw
> bnx2x/bnx2x-e1h-6.0.34.0.fw
> bnx2x/bnx2x-e1h-6.2.5.0.fw
> bnx2x/bnx2x-e1h-6.2.9.0.fw
> bnx2x/bnx2x-e1h-7.0.20.0.fw
> bnx2x/bnx2x-e1h-7.0.23.0.fw
> bnx2x/bnx2x-e1h-7.0.29.0.fw
> bnx2x/bnx2x-e2-6.0.34.0.fw
> bnx2x/bnx2x-e2-6.2.5.0.fw
> bnx2x/bnx2x-e2-6.2.9.0.fw
> bnx2x/bnx2x-e2-7.0.20.0.fw
> bnx2x/bnx2x-e2-7.0.23.0.fw
> bnx2x/bnx2x-e2-7.0.29.0.fw
>
> Ben.
>
^ permalink raw reply
* Re: reproducible kernel freeze using r8169 in Linux 3.0
From: Matt Ginzton @ 2011-12-18 9:40 UTC (permalink / raw)
To: Francois Romieu; +Cc: nic_swsd, netdev
In-Reply-To: <20111218083212.GA28286@electric-eye.fr.zoreil.com>
On Dec 18, 2011, at 12:32 AM, Francois Romieu wrote:
> Please grep for a XID line in dmesg and send it so we can figure the
> specific revision of your chipset (lspci can not figure it).
>
> If it says something like "blah blah XID 1c4...", you should give current
> -rc a try (who shouldn't ?).
Hey, thanks for getting back so fast.
XID 1c4000c0. (And it says "RTL8168c/8111c" in this line, not the 8168B that lspci claimed).
I just found https://lkml.org/lkml/2011/12/1/399. It looks like you've had a handle on this problem since the beginning of December? http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=811fd3010cf512f2e23e6c4c912aad54516dc706 looks promising.
thanks,
Matt
^ permalink raw reply
* Re: ipv6/addrconf_dad_failure printk() in interrupt context
From: Marek Vasut @ 2011-12-18 13:09 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, Wolfgang Denk, David S. Miller, Alexey Kuznetsov,
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, linux
In-Reply-To: <1324199708.3323.71.camel@edumazet-laptop>
> Le dimanche 18 décembre 2011 à 03:28 +0100, Marek Vasut a écrit :
> > Hi,
> >
> > I just recently hit the following issue. I might actually be wrong with
> > my conclusions so bear with me. The events that led to the issue:
> >
> > 1) Duplicate IPv6 address on the network
> > 2) console driver that locks a mutex when printk() is called
>
> This seems buggy : printk() might be called from irq, so muext_lock() is
> not allowed.
I could have guessed so ... mutex_lock() is called in clk_enable() in mxs clock
driver. So that needs to be fixed.
>
> > The problem is the following backtrace:
> >
> > [ 4.870000] eth0: IPv6 duplicate address XXXX::YYYY:ZZZZ:WWWW:0
> > detected! [ 4.870000] ------------[ cut here ]------------
> > [ 4.870000] WARNING: at kernel/mutex.c:198
> > mutex_lock_nested+0x284/0x2c0() [ 4.870000] Modules linked in:
> > [ 4.870000] [<c0013ab8>] (unwind_backtrace+0x0/0xf0) from [<c001d934>]
> > (warn_slowpath_common+0x4c/0x64)
> > [ 4.870000] [<c001d934>] (warn_slowpath_common+0x4c/0x64) from
> > [<c001d968>] (warn_slowpath_null+0x1c/0x24)
> > [ 4.870000] [<c001d968>] (warn_slowpath_null+0x1c/0x24) from
> > [<c033a4f4>] (mutex_lock_nested+0x284/0x2c0)
> > [ 4.870000] [<c033a4f4>] (mutex_lock_nested+0x284/0x2c0) from
> > [<c0017d88>] (clk_enable+0x20/0x48)
> > [ 4.870000] [<c0017d88>] (clk_enable+0x20/0x48) from [<c01dfbf0>]
> > (pl011_console_write+0x20/0x74)
> > [ 4.870000] [<c01dfbf0>] (pl011_console_write+0x20/0x74) from
> > [<c001da98>] (__call_console_drivers+0x7c/0x94)
> > [ 4.870000] [<c001da98>] (__call_console_drivers+0x7c/0x94) from
> > [<c001df20>] (console_unlock+0xf8/0x244)
> > [ 4.870000] [<c001df20>] (console_unlock+0xf8/0x244) from [<c001e308>]
> > (vprintk+0x29c/0x484)
> > [ 4.870000] [<c001e308>] (vprintk+0x29c/0x484) from [<c03355a8>]
> > (printk+0x20/0x30)
> > [ 4.870000] [<c03355a8>] (printk+0x20/0x30) from [<c02df600>]
> > (addrconf_dad_failure+0x148/0x158)
> > [ 4.870000] [<c02df600>] (addrconf_dad_failure+0x148/0x158) from
> > [<c02ebde0>] (ndisc_rcv+0xb38/0xdb0)
> > [ 4.870000] [<c02ebde0>] (ndisc_rcv+0xb38/0xdb0) from [<c02f1b28>]
> > (icmpv6_rcv+0x6ec/0x9c4)
> > [ 4.870000] [<c02f1b28>] (icmpv6_rcv+0x6ec/0x9c4) from [<c02da9a4>]
> > (ip6_input_finish+0x144/0x4e0)
> > [ 4.870000] [<c02da9a4>] (ip6_input_finish+0x144/0x4e0) from
> > [<c02db424>] (ip6_mc_input+0xb8/0x154)
> > [ 4.870000] [<c02db424>] (ip6_mc_input+0xb8/0x154) from [<c02db12c>]
> > (ipv6_rcv+0x300/0x53c)
> > [ 4.870000] [<c02db12c>] (ipv6_rcv+0x300/0x53c) from [<c0267b78>]
> > (__netif_receive_skb+0x240/0x420)
> > [ 4.870000] [<c0267b78>] (__netif_receive_skb+0x240/0x420) from
> > [<c0267de8>] (process_backlog+0x90/0x150)
> > [ 4.870000] [<c0267de8>] (process_backlog+0x90/0x150) from
> > [<c026a5f8>] (net_rx_action+0xc0/0x264)
> > [ 4.870000] [<c026a5f8>] (net_rx_action+0xc0/0x264) from [<c0023cfc>]
> > (__do_softirq+0xa8/0x214)
> > [ 4.870000] [<c0023cfc>] (__do_softirq+0xa8/0x214) from [<c00242c0>]
> > (irq_exit+0x8c/0x94)
> > [ 4.870000] [<c00242c0>] (irq_exit+0x8c/0x94) from [<c000f6d0>]
> > (handle_IRQ+0x34/0x84)
> > [ 4.870000] [<c000f6d0>] (handle_IRQ+0x34/0x84) from [<c000e5d8>]
> > (__irq_usr+0x38/0x80)
> > [ 4.870000] ---[ end trace 32eab6a8dcdca9c0 ]---
> >
> > So basically what I see here is the following order of events:
> >
> > Packet received -> IRQ generated -> ipv6 packet received (still in
> > interrupt context ... why not in tasklet ... or am I wrong here ?) ->
> > icmpv6 packet processing -> addrconf_dad_failure() called -> printk()
> > called in there -> mutex_lock() called in printk(), causing the warning.
> >
> > Can printk() be actually called in interrupt context?
>
> Yes, it can be.
>
> > What direction of solving this shall I take?
>
> Send this to lkml, since its not a netdev issue, but a kernel one.
I already know the direction (where to squash the improper mutex) so I'll poke
into that and send to LKML incl. patch.
Thanks for your reply!
M
^ permalink raw reply
* Re: [PATCH] net: meth: Add set_rx_mode hook to fix ICMPv6 neighbor discovery
From: Sergei Shtylyov @ 2011-12-18 13:26 UTC (permalink / raw)
To: Joshua Kinard; +Cc: netdev, Linux MIPS List
In-Reply-To: <4EED3A3D.9080503@gentoo.org>
Hello.
On 18-12-2011 4:56, Joshua Kinard wrote:
> SGI IP32 (O2)'s ethernet driver (meth) lacks a set_rx_mode function, which
> prevents IPv6 from working completely because any ICMPv6 neighbor
> solicitation requests aren't picked up by the driver. So the machine can
> ping out and connect to other systems, but other systems will have a very
> hard time connecting to the O2.
> Signed-off-by: Joshua Kinard<kumba@gentoo.org>
> ---
Some minor nits below...
> drivers/net/ethernet/sgi/meth.c | 60 +++++++++++++++++++++++++++++++++++-----
> 1 file changed, 53 insertions(+), 7 deletions(-)
> --- a/drivers/net/ethernet/sgi/meth.c 2011-12-17 15:51:44.569166824 -0500
> +++ b/drivers/net/ethernet/sgi/meth.c 2011-12-17 15:51:20.259167050 -0500
[...]
> @@ -57,6 +58,12 @@ static const char *meth_str="SGI O2 Fast
> static int timeout = TX_TIMEOUT;
> module_param(timeout, int, 0);
>
> +/* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
> + * MACE Ethernet uses a 64 element hash table based on the Ethernet CRC.
> + */
> +static int multicast_filter_limit = 32;
> +
> +
On empty oine would be enough...
> /*
> * This structure is private to each device. It is used to pass
> * packets in and out, so there is place for a packet
> @@ -765,15 +775,51 @@ static int meth_ioctl(struct net_device
> }
> }
>
> +static void meth_set_rx_mode(struct net_device *dev)
> +{
> + struct meth_private *priv = netdev_priv(dev);
> + unsigned long flags;
> +
> + netif_stop_queue(dev);
> + spin_lock_irqsave(&priv->meth_lock, flags);
> + priv->mac_ctrl&= ~(METH_PROMISC);
Parens not needed here.
> +
> + if (dev->flags & IFF_PROMISC) {
> + priv->mac_ctrl |= METH_PROMISC;
> + priv->mcast_filter = 0xffffffffffffffffUL;
> + mace->eth.mac_ctrl = priv->mac_ctrl;
> + mace->eth.mcast_filter = priv->mcast_filter;
> + } else if ((netdev_mc_count(dev) > multicast_filter_limit) ||
> + (dev->flags & IFF_ALLMULTI)) {
> + priv->mac_ctrl |= METH_ACCEPT_AMCAST;
> + priv->mcast_filter = 0xffffffffffffffffUL;
> + mace->eth.mac_ctrl = priv->mac_ctrl;
> + mace->eth.mcast_filter = priv->mcast_filter;
This block is over-indented.
> + } else {
> + struct netdev_hw_addr *ha;
> + priv->mac_ctrl |= METH_ACCEPT_MCAST;
> +
> + netdev_for_each_mc_addr(ha, dev)
> + set_bit((ether_crc(ETH_ALEN, ha->addr) >> 26),
> + (volatile long unsigned int *)&priv->mcast_filter);
> +
> + mace->eth.mcast_filter = priv->mcast_filter;
This last statement is common between all branches, so could be moved out
of *if*...
> + }
> +
> + spin_unlock_irqrestore(&priv->meth_lock, flags);
> + netif_wake_queue(dev);
> +}
> +
> static const struct net_device_ops meth_netdev_ops = {
> - .ndo_open = meth_open,
> - .ndo_stop = meth_release,
> - .ndo_start_xmit = meth_tx,
> - .ndo_do_ioctl = meth_ioctl,
> - .ndo_tx_timeout = meth_tx_timeout,
> - .ndo_change_mtu = eth_change_mtu,
> - .ndo_validate_addr = eth_validate_addr,
> + .ndo_open = meth_open,
> + .ndo_stop = meth_release,
> + .ndo_start_xmit = meth_tx,
> + .ndo_do_ioctl = meth_ioctl,
> + .ndo_tx_timeout = meth_tx_timeout,
> + .ndo_change_mtu = eth_change_mtu,
> + .ndo_validate_addr = eth_validate_addr,
> .ndo_set_mac_address = eth_mac_addr,
> + .ndo_set_rx_mode = meth_set_rx_mode,
The intializer values are not aligned now, and they were before the patch.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH] net: meth: Add set_rx_mode hook to fix ICMPv6 neighbor discovery
From: Joshua Kinard @ 2011-12-18 14:35 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: netdev, Linux MIPS List
In-Reply-To: <4EEDEA17.4040006@mvista.com>
On 12/18/2011 08:26, Sergei Shtylyov wrote:
>> @@ -57,6 +58,12 @@ static const char *meth_str="SGI O2 Fast
>> static int timeout = TX_TIMEOUT;
>> module_param(timeout, int, 0);
>>
>> +/* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
>> + * MACE Ethernet uses a 64 element hash table based on the Ethernet CRC.
>> + */
>> +static int multicast_filter_limit = 32;
>> +
>> +
>
> On empty oine would be enough...
>
Fixed, as Dave pointed out. I converted it and the driver name to a macro
anyways.
>> /*
>> * This structure is private to each device. It is used to pass
>> * packets in and out, so there is place for a packet
>> @@ -765,15 +775,51 @@ static int meth_ioctl(struct net_device
>> }
>> }
>>
>> +static void meth_set_rx_mode(struct net_device *dev)
>> +{
>> + struct meth_private *priv = netdev_priv(dev);
>> + unsigned long flags;
>> +
>> + netif_stop_queue(dev);
>> + spin_lock_irqsave(&priv->meth_lock, flags);
>> + priv->mac_ctrl&= ~(METH_PROMISC);
>
> Parens not needed here.
>
Yeah, I am a habitual parenthesis abuser. You should see the RTC driver I
re-wrote :)
>> +
>> + if (dev->flags & IFF_PROMISC) {
>> + priv->mac_ctrl |= METH_PROMISC;
>> + priv->mcast_filter = 0xffffffffffffffffUL;
>> + mace->eth.mac_ctrl = priv->mac_ctrl;
>> + mace->eth.mcast_filter = priv->mcast_filter;
>> + } else if ((netdev_mc_count(dev) > multicast_filter_limit) ||
>> + (dev->flags & IFF_ALLMULTI)) {
>> + priv->mac_ctrl |= METH_ACCEPT_AMCAST;
>> + priv->mcast_filter = 0xffffffffffffffffUL;
>> + mace->eth.mac_ctrl = priv->mac_ctrl;
>> + mace->eth.mcast_filter = priv->mcast_filter;
>
> This block is over-indented.
>
Weird. The editor I was using had the tabs set to an equivalent of 4
spaces, so it lined up for me *originally*, but after the patch was applied,
it was out of alignment, too. I think I got it fixed this time, though.
Not sure what was causing that.
>> + } else {
>> + struct netdev_hw_addr *ha;
>> + priv->mac_ctrl |= METH_ACCEPT_MCAST;
>> +
>> + netdev_for_each_mc_addr(ha, dev)
>> + set_bit((ether_crc(ETH_ALEN, ha->addr) >> 26),
>> + (volatile long unsigned int *)&priv->mcast_filter);
>> +
>> + mace->eth.mcast_filter = priv->mcast_filter;
>
> This last statement is common between all branches, so could be moved out
> of *if*...
>
Done.
>> + }
>> +
>> + spin_unlock_irqrestore(&priv->meth_lock, flags);
>> + netif_wake_queue(dev);
>> +}
>> +
>> static const struct net_device_ops meth_netdev_ops = {
>> - .ndo_open = meth_open,
>> - .ndo_stop = meth_release,
>> - .ndo_start_xmit = meth_tx,
>> - .ndo_do_ioctl = meth_ioctl,
>> - .ndo_tx_timeout = meth_tx_timeout,
>> - .ndo_change_mtu = eth_change_mtu,
>> - .ndo_validate_addr = eth_validate_addr,
>> + .ndo_open = meth_open,
>> + .ndo_stop = meth_release,
>> + .ndo_start_xmit = meth_tx,
>> + .ndo_do_ioctl = meth_ioctl,
>> + .ndo_tx_timeout = meth_tx_timeout,
>> + .ndo_change_mtu = eth_change_mtu,
>> + .ndo_validate_addr = eth_validate_addr,
>> .ndo_set_mac_address = eth_mac_addr,
>> + .ndo_set_rx_mode = meth_set_rx_mode,
>
> The intializer values are not aligned now, and they were before the patch.
Yeah, same problem as above. Not sure how my tabs got mangled. Should be
fixed in the next revision once I test it.
Thanks!
--
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28
"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
^ permalink raw reply
* Re: [PATCH] net: meth: Add set_rx_mode hook to fix ICMPv6 neighbor discovery
From: Joshua Kinard @ 2011-12-18 14:40 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-mips
In-Reply-To: <20111218.001925.2108645748994734084.davem@davemloft.net>
On 12/18/2011 00:19, David Miller wrote:
> From: Joshua Kinard <kumba@gentoo.org>
> Date: Sat, 17 Dec 2011 23:37:01 -0500
>
>> MACE Ethernet only ever appears on the SGI O2 systems.
>
> That has no bearing on my feedback, we simply do not put non-portable
> code like this into the tree at this point.
>
> Just because this driver has been maintained in an non-portable manner
> up to this point, doesn't mean we continue doing that.
Agreed. However, I was simply trying to fix a problem that prevents IPv6
from working, not fix every little thing wrong with the code. While I want
to tackle re-writing the driver to be more in line with existing network
drivers, that's a future project. I'm still new to driver
development/kernel work in general, so I'm learning here.
Thanks for the feedback, though,
--
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28
"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
^ permalink raw reply
* Re: [PATCH] net: meth: Add set_rx_mode hook to fix ICMPv6 neighbor discovery
From: Joshua Kinard @ 2011-12-18 15:13 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-mips
In-Reply-To: <20111217.215630.640392276998191183.davem@davemloft.net>
On 12/17/2011 21:56, David Miller wrote:
>> + netdev_for_each_mc_addr(ha, dev)
>> + set_bit((ether_crc(ETH_ALEN, ha->addr) >> 26),
>> + (volatile long unsigned int *)&priv->mcast_filter);
>
> This makes an assumption not only about the size of the "unsigned long"
> type, but also of the endianness of the architecture this runs on.
>
Can you give me some tips on this one? au1000_eth.c does the same thing,
and I'm not seeing what the endian issue is exactly. Is it the >> 26 part
or the use of ether_crc? I see there's an ether_crc_le, too, and some
drivers also do the >> 26 bit on it as well.
Which is correct? The few drivers I've looked at don't exactly spell out
this part of the code, and are usually doing something different because
most seem to access the multicast filter register in either 8-bits or
32-bits. MACE ethernet seems to be one of the few doing it in full 64-bits.
Thanks,
--
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28
"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
^ permalink raw reply
* [PATCH] Micrel KS8995MA 5-ports 10/100 managed Ethernet switch support added
From: Frederic LAMBERT @ 2011-12-18 17:33 UTC (permalink / raw)
To: netdev; +Cc: Frederic LAMBERT, Gabor Juhos
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Frederic Lambert <frdrc66@gmail.com>
---
drivers/net/phy/Kconfig | 5 +
drivers/net/phy/Makefile | 1 +
drivers/net/phy/spi_ks8995.c | 376 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 382 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/phy/spi_ks8995.c
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index a702443..050f069 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -131,3 +131,8 @@ config MDIO_OCTEON
If in doubt, say Y.
endif # PHYLIB
+
+config MICREL_KS8995MA
+ tristate "Micrel KS8995MA 5-ports 10/100 managed Ethernet switch"
+ depends on SPI
+
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 2333215..e15c83f 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -23,3 +23,4 @@ obj-$(CONFIG_DP83640_PHY) += dp83640.o
obj-$(CONFIG_STE10XP) += ste10Xp.o
obj-$(CONFIG_MICREL_PHY) += micrel.o
obj-$(CONFIG_MDIO_OCTEON) += mdio-octeon.o
+obj-$(CONFIG_MICREL_KS8995MA) += spi_ks8995.o
diff --git a/drivers/net/phy/spi_ks8995.c b/drivers/net/phy/spi_ks8995.c
new file mode 100644
index 0000000..e9ce085
--- /dev/null
+++ b/drivers/net/phy/spi_ks8995.c
@@ -0,0 +1,376 @@
+/*
+ * SPI driver for Micrel/Kendin KS8995M ethernet switch
+ *
+ * Copyright (C) 2008 Gabor Juhos <juhosg at openwrt.org>
+ *
+ * This file was based on: drivers/spi/at25.c
+ * Copyright (C) 2006 David Brownell
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+
+#include <linux/spi/spi.h>
+
+#define DRV_VERSION "0.1.1"
+#define DRV_DESC "Micrel KS8995 Ethernet switch SPI driver"
+
+/* ------------------------------------------------------------------------ */
+
+#define KS8995_REG_ID0 0x00 /* Chip ID0 */
+#define KS8995_REG_ID1 0x01 /* Chip ID1 */
+
+#define KS8995_REG_GC0 0x02 /* Global Control 0 */
+#define KS8995_REG_GC1 0x03 /* Global Control 1 */
+#define KS8995_REG_GC2 0x04 /* Global Control 2 */
+#define KS8995_REG_GC3 0x05 /* Global Control 3 */
+#define KS8995_REG_GC4 0x06 /* Global Control 4 */
+#define KS8995_REG_GC5 0x07 /* Global Control 5 */
+#define KS8995_REG_GC6 0x08 /* Global Control 6 */
+#define KS8995_REG_GC7 0x09 /* Global Control 7 */
+#define KS8995_REG_GC8 0x0a /* Global Control 8 */
+#define KS8995_REG_GC9 0x0b /* Global Control 9 */
+
+#define KS8995_REG_PC(p, r) ((0x10 * p) + r) /* Port Control */
+#define KS8995_REG_PS(p, r) ((0x10 * p) + r + 0xe) /* Port Status */
+
+#define KS8995_REG_TPC0 0x60 /* TOS Priority Control 0 */
+#define KS8995_REG_TPC1 0x61 /* TOS Priority Control 1 */
+#define KS8995_REG_TPC2 0x62 /* TOS Priority Control 2 */
+#define KS8995_REG_TPC3 0x63 /* TOS Priority Control 3 */
+#define KS8995_REG_TPC4 0x64 /* TOS Priority Control 4 */
+#define KS8995_REG_TPC5 0x65 /* TOS Priority Control 5 */
+#define KS8995_REG_TPC6 0x66 /* TOS Priority Control 6 */
+#define KS8995_REG_TPC7 0x67 /* TOS Priority Control 7 */
+
+#define KS8995_REG_MAC0 0x68 /* MAC address 0 */
+#define KS8995_REG_MAC1 0x69 /* MAC address 1 */
+#define KS8995_REG_MAC2 0x6a /* MAC address 2 */
+#define KS8995_REG_MAC3 0x6b /* MAC address 3 */
+#define KS8995_REG_MAC4 0x6c /* MAC address 4 */
+#define KS8995_REG_MAC5 0x6d /* MAC address 5 */
+
+#define KS8995_REG_IAC0 0x6e /* Indirect Access Control 0 */
+#define KS8995_REG_IAC1 0x6f /* Indirect Access Control 0 */
+#define KS8995_REG_IAD7 0x70 /* Indirect Access Data 7 */
+#define KS8995_REG_IAD6 0x71 /* Indirect Access Data 6 */
+#define KS8995_REG_IAD5 0x72 /* Indirect Access Data 5 */
+#define KS8995_REG_IAD4 0x73 /* Indirect Access Data 4 */
+#define KS8995_REG_IAD3 0x74 /* Indirect Access Data 3 */
+#define KS8995_REG_IAD2 0x75 /* Indirect Access Data 2 */
+#define KS8995_REG_IAD1 0x76 /* Indirect Access Data 1 */
+#define KS8995_REG_IAD0 0x77 /* Indirect Access Data 0 */
+
+#define KS8995_REGS_SIZE 0x80
+
+#define ID1_CHIPID_M 0xf
+#define ID1_CHIPID_S 4
+#define ID1_REVISION_M 0x7
+#define ID1_REVISION_S 1
+#define ID1_START_SW 1 /* start the switch */
+
+#define FAMILY_KS8995 0x95
+#define CHIPID_M 0
+
+#define KS8995_CMD_WRITE 0x02U
+#define KS8995_CMD_READ 0x03U
+
+#define KS8995_RESET_DELAY 10 /* usec */
+
+struct ks8995_pdata {
+ /* not yet implemented */
+};
+
+struct ks8995_switch {
+ struct spi_device *spi;
+ struct mutex lock;
+ struct ks8995_pdata *pdata;
+};
+
+static inline u8 get_chip_id(u8 val)
+{
+ return (val >> ID1_CHIPID_S) & ID1_CHIPID_M;
+}
+
+static inline u8 get_chip_rev(u8 val)
+{
+ return (val >> ID1_REVISION_S) & ID1_REVISION_M;
+}
+
+/* ------------------------------------------------------------------------ */
+static int ks8995_read(struct ks8995_switch *ks, char *buf,
+ unsigned offset, size_t count)
+{
+ u8 cmd[2];
+ struct spi_transfer t[2];
+ struct spi_message m;
+ int err;
+
+ spi_message_init(&m);
+
+ memset(&t, 0, sizeof(t));
+
+ t[0].tx_buf = cmd;
+ t[0].len = sizeof(cmd);
+ spi_message_add_tail(&t[0], &m);
+
+ t[1].rx_buf = buf;
+ t[1].len = count;
+ spi_message_add_tail(&t[1], &m);
+
+ cmd[0] = KS8995_CMD_READ;
+ cmd[1] = offset;
+
+ mutex_lock(&ks->lock);
+ err = spi_sync(ks->spi, &m);
+ mutex_unlock(&ks->lock);
+
+ return err ? err : count;
+}
+
+
+static int ks8995_write(struct ks8995_switch *ks, char *buf,
+ unsigned offset, size_t count)
+{
+ u8 cmd[2];
+ struct spi_transfer t[2];
+ struct spi_message m;
+ int err;
+
+ spi_message_init(&m);
+
+ memset(&t, 0, sizeof(t));
+
+ t[0].tx_buf = cmd;
+ t[0].len = sizeof(cmd);
+ spi_message_add_tail(&t[0], &m);
+
+ t[1].tx_buf = buf;
+ t[1].len = count;
+ spi_message_add_tail(&t[1], &m);
+
+ cmd[0] = KS8995_CMD_WRITE;
+ cmd[1] = offset;
+
+ mutex_lock(&ks->lock);
+ err = spi_sync(ks->spi, &m);
+ mutex_unlock(&ks->lock);
+
+ return err ? err : count;
+}
+
+static inline int ks8995_read_reg(struct ks8995_switch *ks, u8 addr, u8 *buf)
+{
+ return (ks8995_read(ks, buf, addr, 1) != 1);
+}
+
+static inline int ks8995_write_reg(struct ks8995_switch *ks, u8 addr, u8 val)
+{
+ char buf = val;
+
+ return (ks8995_write(ks, &buf, addr, 1) != 1);
+}
+
+/* ------------------------------------------------------------------------ */
+
+static int ks8995_stop(struct ks8995_switch *ks)
+{
+ return ks8995_write_reg(ks, KS8995_REG_ID1, 0);
+}
+
+static int ks8995_start(struct ks8995_switch *ks)
+{
+ return ks8995_write_reg(ks, KS8995_REG_ID1, 1);
+}
+
+static int ks8995_reset(struct ks8995_switch *ks)
+{
+ int err;
+
+ err = ks8995_stop(ks);
+ if (err)
+ return err;
+
+ udelay(KS8995_RESET_DELAY);
+
+ return ks8995_start(ks);
+}
+
+/* ------------------------------------------------------------------------ */
+
+static ssize_t ks8995_registers_read(struct file *filp, struct kobject *kobj,
+ struct bin_attribute *bin_attr, char *buf, loff_t off, size_t count)
+{
+ struct device *dev;
+ struct ks8995_switch *ks8995;
+
+ dev = container_of(kobj, struct device, kobj);
+ ks8995 = dev_get_drvdata(dev);
+
+ if (unlikely(off > KS8995_REGS_SIZE))
+ return 0;
+
+ if ((off + count) > KS8995_REGS_SIZE)
+ count = KS8995_REGS_SIZE - off;
+
+ if (unlikely(!count))
+ return count;
+
+ return ks8995_read(ks8995, buf, off, count);
+}
+
+
+static ssize_t ks8995_registers_write(struct file *filp, struct kobject *kobj,
+ struct bin_attribute *bin_attr, char *buf, loff_t off, size_t count)
+{
+ struct device *dev;
+ struct ks8995_switch *ks8995;
+
+ dev = container_of(kobj, struct device, kobj);
+ ks8995 = dev_get_drvdata(dev);
+
+ if (unlikely(off >= KS8995_REGS_SIZE))
+ return -EFBIG;
+
+ if ((off + count) > KS8995_REGS_SIZE)
+ count = KS8995_REGS_SIZE - off;
+
+ if (unlikely(!count))
+ return count;
+
+ return ks8995_write(ks8995, buf, off, count);
+}
+
+
+static struct bin_attribute ks8995_registers_attr = {
+ .attr = {
+ .name = "registers",
+ .mode = S_IRUSR | S_IWUSR,
+ },
+ .size = KS8995_REGS_SIZE,
+ .read = ks8995_registers_read,
+ .write = ks8995_registers_write,
+};
+
+/* ------------------------------------------------------------------------ */
+
+static int __devinit ks8995_probe(struct spi_device *spi)
+{
+ struct ks8995_switch *ks;
+ struct ks8995_pdata *pdata;
+ u8 ids[2];
+ int err;
+
+ /* Chip description */
+ pdata = spi->dev.platform_data;
+
+ ks = kzalloc(sizeof(*ks), GFP_KERNEL);
+ if (!ks) {
+ dev_err(&spi->dev, "no memory for private data\n");
+ return -ENOMEM;
+ }
+
+ mutex_init(&ks->lock);
+ ks->pdata = pdata;
+ ks->spi = spi_dev_get(spi);
+ dev_set_drvdata(&spi->dev, ks);
+
+ spi->mode = SPI_MODE_0;
+ spi->bits_per_word = 8;
+ err = spi_setup(spi);
+ if (err) {
+ dev_err(&spi->dev, "spi_setup failed, err=%d\n", err);
+ goto err_drvdata;
+ }
+
+ err = ks8995_read(ks, ids, KS8995_REG_ID0, sizeof(ids));
+ if (err < 0) {
+ dev_err(&spi->dev, "unable to read id registers, err=%d\n",
+ err);
+ goto err_drvdata;
+ }
+
+ switch (ids[0]) {
+ case FAMILY_KS8995:
+ break;
+ default:
+ dev_err(&spi->dev, "unknown family id:%02x\n", ids[0]);
+ err = -ENODEV;
+ goto err_drvdata;
+ }
+
+ err = ks8995_reset(ks);
+ if (err)
+ goto err_drvdata;
+
+ err = sysfs_create_bin_file(&spi->dev.kobj, &ks8995_registers_attr);
+ if (err) {
+ dev_err(&spi->dev, "unable to create sysfs file, err=%d\n",
+ err);
+ goto err_drvdata;
+ }
+
+ dev_info(&spi->dev, "KS89%02X device found, Chip ID:%01x, "
+ "Revision:%01x\n", ids[0],
+ get_chip_id(ids[1]), get_chip_rev(ids[1]));
+
+ return 0;
+
+err_drvdata:
+ dev_set_drvdata(&spi->dev, NULL);
+ kfree(ks);
+ return err;
+}
+
+static int __devexit ks8995_remove(struct spi_device *spi)
+{
+ struct ks8995_data *ks8995;
+
+ ks8995 = dev_get_drvdata(&spi->dev);
+ sysfs_remove_bin_file(&spi->dev.kobj, &ks8995_registers_attr);
+
+ dev_set_drvdata(&spi->dev, NULL);
+ kfree(ks8995);
+
+ return 0;
+}
+
+/* ------------------------------------------------------------------------ */
+
+static struct spi_driver ks8995_driver = {
+ .driver = {
+ .name = "spi-ks8995",
+ .bus = &spi_bus_type,
+ .owner = THIS_MODULE,
+ },
+ .probe = ks8995_probe,
+ .remove = __devexit_p(ks8995_remove),
+};
+
+static int __init ks8995_init(void)
+{
+ printk(KERN_INFO DRV_DESC " version " DRV_VERSION"\n");
+
+ return spi_register_driver(&ks8995_driver);
+}
+module_init(ks8995_init);
+
+static void __exit ks8995_exit(void)
+{
+ spi_unregister_driver(&ks8995_driver);
+}
+module_exit(ks8995_exit);
+
+MODULE_DESCRIPTION(DRV_DESC);
+MODULE_VERSION(DRV_VERSION);
+MODULE_AUTHOR("Gabor Juhos <juhosg at openwrt.org>");
+MODULE_LICENSE("GPL v2");
+
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH 1/1] tcp: fix spurious undos in CA_Open
From: Neal Cardwell @ 2011-12-18 18:23 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: David Miller, Netdev, nanditad, Yuchung Cheng, therbert
In-Reply-To: <alpine.DEB.2.00.1112141034010.7753@melkinpaasi.cs.helsinki.fi>
On Wed, Dec 14, 2011 at 3:57 AM, Ilpo Järvinen
<ilpo.jarvinen@helsinki.fi> wrote:
> On Mon, 12 Dec 2011, Neal Cardwell wrote:
>
>> On Mon, Dec 12, 2011 at 7:05 AM, Ilpo Järvinen
>> <ilpo.jarvinen@helsinki.fi> wrote:
>> > On Mon, 28 Nov 2011, Neal Cardwell wrote:
>> >
>> >> On Sun, Nov 27, 2011 at 6:58 PM, David Miller <davem@davemloft.net> wrote:
>> >>
>> >> >> Also, one (serious) word of caution! This change, by its extending of
>> >> >> CA_Open state, is somewhat similar to what I made FRTO years ago, and
>> >> >> managed to introduces subtle breaking to the state machine. Please check
>> >> >> that the problem similar to what was fixed by
>> >> >> a1c1f281b84a751fdb5ff919da3b09df7297619f does not reappear (possibly in
>> >> >> some other form causing spurious undos). ...To me it seems that
>> >> >> tcp_packet_delayed might be similarly confused after the given patch.
>> >> >
>> >> > Neil, please look into this so we can have any such issues fixed
>> >> > in time for the next merge window.
>> >>
>> >> Absolutely. I will look into the areas that Ilpo mentioned.
>> >
>> > Unfortunately nothing has happened? So I finally had to come up something
>> > myself. ...Compile tested only.
>>
>> Sorry for the radio silence, but I have been looking at this. So far
>> it's been a time-consuming process, as we've uncovered a number of
>> pre-existing issues in tcp_packet_delayed that seem like quite serious
>> bugs:
>>
>> 1) tcp_packet_delayed implicitly assumes, but does not verify, that
>> the ACK in question (whose ECR field precedes retrans_stamp) covers
>> all retransmitted segments. So if we retransmit segments 1 and 2, and
>> then get an ACK for 1 that has an ECR indicating it was for the
>> original copy of segment 1, then we undo, even in cases where segment
>> 2 really was lost and needed to be retransmitted.
>
> I think this might be an mis-implementation in tcp_try_undo_partial.
Yeah, I'm pretty sure this is a bug. There needs to be some additional
logic, whether in tcp_try_undo_partial or tcp_packet_delayed, or
somewhere else, to fix this bug.
>> 2) tcp_packet_delayed implicitly assumes that if we retransmit a
>> packet that was truly lost then any ACK for the retransmitted instance
>> of that packet will echo the timestamp field in the retransmitted
>> packet. But if the receiver is implementing delayed ACKs and correctly
>> implements timestamps per RFC 1323, then the receiver will be obeying
>> this clause: "Thus, when delayed ACKs are in use, the receiver should
>> reply with the TSval field from the earliest unacknowledged segment."
>> Thus tcp_packet_delayed can cause spurious undos in the following
>> circumstances:
>>
>> - send segment 1 with tsval 10
>> - receiver is doing delayed ACKs and does not ACK 1 but sets TS.Recent to 10
>> - send segment 2 with tsval 20
>> - segment 2 is lost in transit
>> - RTO, retransmit segment 2 with tsval 30
>> - receiver sends delayed ACK for packets 1 and 2 with TS.Recent of 10
>> - sender receives ACK for packet 2 with tsecho of 10, lower than 30,
>> and thinks RTO was spurious
>
> About this I'm actually aware of, I have even some long email postponed
> related to this to discuss in context of 1323bis (as 1323bis seems pretty
> much standstill I'm not in a big hurry :-)). I think 1323 algo is flawed
> anyway and it was fixed/clarified/better in the bis (which doesn't
> address this well enough though).
>
> I discovered this while I setup a network with ACK losses to figure out
> other issue. I discovered that the RTT measurements occassionally took
> "the wrong TS" bloating the RTT estimate. As RTT samples included RTO
> delays, with enough ACK losses the RTO eventually hits the max value.
> ...As a result, not very nice performance was acquired for that such a
> flow.
>
> I think there are two possible solutions:
> 1) Echo latest timestamp for below window packets (I'm not sure if
> there's can of worms w.r.t. security in this approach). A good thing
> in this would be that it would really solve the rexmit ambiguity problem
> which the current approach does not do.
> 2) Ignore packets with DSACK in RTT measurement.
>
> 1323bis is not of much help in this which TS to echo (which is why I
> intented to mention it on tcpm). IIRC, it depended on which takes
> precedence: RFC793 in-window check or the given TS algorithm, which is
> not discussed anywhere.
Interesting. I hope the standards get improved in this area.
>> For better or worse, both of these bugs appear to be inherited from
>> the Eifel Detection Algorithm RFC (RFC 3522).
>
> RFC3522 does not have the issue 1) as it's working after RTO+first ACK
> only. The second issue is valid for it though.
Actually RFC 3522 does have issue 1) because it is also in effect for
fast retransmit / fast recovery; RFC 3522 says "If the Eifel detection
algorithm is used, the following steps MUST be taken by a TCP sender,
but only upon initiation of loss recovery, i.e., when either the
timeout-based retransmit or the fast retransmit is sent."
In addition, RFC 3517 allows senders to send out multiple
retransmissions upon the first ACK that initiates fast recovery:
Section 5., Algorithm Details, says "(5) In order to take advantage of
potential additional available cwnd, proceed to step (C) below. ...
(C) If cwnd - pipe >= 1 SMSS the sender SHOULD transmit one or more
segments." As a consequence, senders can have multiple retransmissions
in flight at the point they get the first ACK during fast recovery, at
which point they run the Eifel detection algorithm.
So I'm pretty sure 1) is an issue both in the RFCs and in Linux.
>> In any case, we've been working on coming up with a solution for these issues.
>>
>> > --
>> > [PATCH 1/1] tcp: fix spurious undos in CA_Open
>> >
>> > There's a landmine in tcp_packet_delayed. In CA_Open the
>> > retrans_stamp is very eagerly cleared which falsely triggers
>> > packet-delayed detection. Therefore this code cannot be used
>> > in CA_Open if the retrans_stamp was already cleared.
>> >
>> > This became issue once DSACK detection was extended to happen
>> > in CA_Open state too (f698204bd0b, tcp: allow undo from
>> > reordered DSACKs). Essentially the whole congestion control
>> > is disabled because the undos now always restore the previous
>> > window. I wonder if this was already in production... ...at
>> > least the Internet didn't melt ;-).
>>
>> I'm pretty sure this commit is unnecessary. It seems like a NOP. Note
>> that tcp_may_undo and tcp_packet_delayed are never called in state
>> TCP_CA_Open. tcp_may_undo is only called from tcp_try_undo_recovery,
>> tcp_try_undo_partial, and tcp_try_undo_loss, and to call any of these
>> functions you must be in either TCP_CA_Loss or TCP_CA_Recovery. Only
>> tcp_try_undo_dsack is called from TCP_CA_Open, but it makes no
>> reference to retrans_stamp.
>
> It seems that I've missed this difference in tcp_try_undo_dsack (well,
> seen it but never thought it that much). I think you're right. Thanks for
> taking a look.
>
> Some WARN_ON to enforce this !CA_Open condition there might not hurt
> though.
Sounds reasonable. I'll think about this as I work on coming up with a
fix for the 1) and 2) bugs discussed above.
neal
^ permalink raw reply
* RE
From: mrs fiona chan @ 2011-12-18 16:01 UTC (permalink / raw)
good day,I have a proposal in tune of $13,99 1,674 for you, reach me on
email(fionachan264@gmail.com)for more info
^ permalink raw reply
* Re: netem and hierarchical ingress traffic shaping
From: Stephen Hemminger @ 2011-12-18 19:55 UTC (permalink / raw)
To: John A. Sullivan III; +Cc: netdev
In-Reply-To: <1324185132.8451.439.camel@denise.theartistscloset.com>
On Sun, 18 Dec 2011 00:12:12 -0500
"John A. Sullivan III" <jsullivan@opensourcedevel.com> wrote:
> Since netem appears to be classless, we realized we would need to
> replace the SFQ on each leaf with netem which we really didn't want to
> do - not only to not lose SFQ but because we didn't want to maintain the
> netem parameters on each leaf. So, we activated our ifb1 interface,
> placed netem on it and redirected all the egress traffic to ifb1. Taht
> worked fine.
Current versions of netem can take one class.
^ 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