Hello. I hope this is not a known problem. We have servers running recent (2.6.36, 2.6.37-rc) hand compiled vanilla kernels. We are using those servers to run KVM & LXC. Those servers are DELL poweredge M605 in a M1000e enclosure ; the network cards are 2X BCM5708S, driver bnx2, connected to Power Connect M6220. Multiples vlans are used, each vlan is connected to a virtual bridge on the host. This setup has been running fine for months. We just added BCM57711 10G cards (bnx2x ...

Hi Shawn, Since you introduce this new kernel command line parameter in patch #3 of this series, why not just make it right in the first place? This should make both Since you now remove mach/hardware.h for ARCH_MXC, does this build for all This breaks kernels for multiple archs (e.g. i.MX28 and i.MX25). Please use run-time detection of CPU type, and do the MII/RMII etc. configuration [snip] baruch -- ~. .~ Tk Open ...

Bosch C_CAN controller is a full-CAN implementation which is compliant to CAN protocol version 2.0 part A and B. Bosch C_CAN user manual can be obtained from: http://www.semiconductors.bosch.de/pdf/Users_Manual_C_CAN.pdf This patch adds the support for this controller. The following are the design choices made while writing the controller driver: 1. Interface Register set IF1 has be used only in the current design. 2. Out of the 32 Message objects available, 16 are kept aside for RX ...

[...] However, the option to omit the second operand is a GNU extension. Ben. -- Ben Hutchings, Senior Software Engineer, Solarflare Communications Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. --

Hi, After a series of discussions [1], Eric provided "tcp: bind() fix when many ports are bound" patch. ([2]) Anyhow, due to this problem ([3]) it was reverted. Where there any follow ups on this patch? I have spent some time looking at inet_csk_get_port with the only conclusion that it's scary :D. Should I work around patch "tcp: bind() fix when many ports are bound", and try to fix problem [3], or is that a dead end? thanks, Daniel. [1] ...

From: "Michael Chan" <mchan@broadcom.com> Applied. --

From: "Michael Chan" <mchan@broadcom.com> Applied. --

From: Francois-Xavier Le Bail <fx.lebail@orange.fr> Applied, thanks. --

I meant #define FIB_RES_PREFSRC(res) __FIB_RES_PREFSRC(res, __fib_res_prefsrc(&res)) --

Ternary operator is standard C idiom, used in networking stuff, for example in FIB_RES_PREFSRC() ;) This could be properly done using another macro in include/net/ip_fib.h to centralize this ternary op in one point : #define __FIB_RES_PREFSRC(res, default) ((res).fi->fib_prefsrc ? : default) #define FIB_RES_PREFSRC(res) __FIB_RES_PREFSRC(res, default, __fib_res_prefsrc(&res)) --

Dont mix TCP and UDP, they are not the same. Problem with TCP is you can have TIME_WAIT sockets, disallowing a port to be reused. Not with UDP. The connect() [without a previous bind()], or a sendto() [without a previous bind()] problem is more an API problem. When kernel autobinds an UDP socket [to get a local IP/port], there is a problem on the selection of the local address : It must be ANY_ADDR (0.0.0.0) While for TCP, the IP address wont change for the whole session. Problem is : ...

Here is the POC patch I am currently testing, with a probability to "early drop" a packet of one percent per ms (HZ=1000 here), only if packet stayed at least 4 ms on queue. Of course, this only apply where SFQ is used, with known SFQ limits :) The term "early drop" is a lie. RED really early mark/drop a packet at enqueue() time, while I do it at dequeue() time [since I need to compute the delay]. But effect is the same on sent packets. This might use a bit more memory, but no more than ...

Not at all, I had to install an AQM here at work, I chose SFQ because Yes I did, but after some reading, I think there is an issue with BLUE, regarding number of cache misses and complexity because of Bloom filter (and double hashing) For workloads with many flows, all bits are marked very fast. I'd like to try kind of a SFQRED implementation, ie : classify flows, then instead of using plain pfifo queues (currently done in SFQ), use N pseudo RED queues. RED is a bit complex because it ...

Hi there! Well, that looks strange. On my own side I've just put workaround (manually binding to all ports in sequence :) and moved production code to FreeBSD as it has better scalable network stack. I can see the potential problem with that bind() problem on highly loaded DNS servers/resolvers which establish tons of outgoing UDP connections. In some cases that connections could fail and as not receiving the answer it is normal condition for DNS this will go totally unnoticed. I ...

That is true, operations department went kind of crazy when they started to add/move customers to our new Nehalem Xeon 5550 systems. I have stopped them now ;-) The use of an SFQ per customer, actually also solves the buffer bloat This is very interesting stuff! :-) Have you looked at the SFB (Stochastic Fair Blue) implementation by Juliusz Chroboczek? http://www.pps.jussieu.fr/~jch/software/sfb/ Cheers, Jesper ...

I'm not sure why this unsetting is needed in case it was set by a Did you give up those stats per tc class? You only show the leaf classes here, but you could first loop per num_tc (as virtual parent classes). So in dump_class_stats you should be able to distinguish class 'level' by cl and do the second loop if necessary. To show the class hierarchy you change tcm_parent in dump_class for 'leaf' classes (like eg in sch_htb/htb_dump_class). --

Hey there, I can't really say whether it's genetlink or netlink to blame, but I noticed that a request with nlmsg_flags = NLM_F_CREATE | NLM_F_EXCL to a genl-registered component can return -EOPNOTSUPP because it does not have a dumpit function defined in struct genl_ops. Make sense? Not at first sight at least. include/linux/netlink.h has this nice anecdote: /* Modifiers to GET request */ #define NLM_F_ROOT 0x100 #define NLM_F_MATCH 0x200 #define NLM_F_ATOMIC ...

This implements a mqprio queueing discipline that by default creates a pfifo_fast qdisc per tx queue and provides the needed configuration interface. Using the mqprio qdisc the number of tcs currently in use along with the range of queues alloted to each class can be configured. By default skbs are mapped to traffic classes using the skb priority. This mapping is configurable. Configurable parameters, struct tc_mclass_qopt { __u8 num_tc; __u8 prio_tc_map[16]; ...

OK I'm convinced I'll keep everything contained in mclass. Building this mechanism into the qdisc seems to be adding extra complexity that is most likely not needed as you noted. Although I suspect the "additional parameter" would be something along the lines of a queue index and offset? right? Otherwise how would a mq like qdisc know which queues it owns. Thanks, John. --

I did give up... but got it working with your hint in v5 thanks. John. --

This patch provides a mechanism for lower layer devices to steer traffic using skb->priority to tx queues. This allows for hardware based QOS schemes to use the default qdisc without incurring the penalties related to global state and the qdisc lock. While reliably receiving skbs on the correct tx ring to avoid head of line blocking resulting from shuffling in the LLD. Finally, all the goodness from txq caching and xps/rps can still be leveraged. Many drivers and hardware exist with the ...

(Thanks for the explanation)^2. I left my code now with the only warning from sparse: warning: Using plain integer as NULL pointer That means, I got all __iomem references fixed. Is this '0' instead of 'NULL' a big problem? I got plenty of those. Kurt --

This patch adds the driver that creates a platform:softing device from a pcmcia_device Note: the Kconfig indicates a dependency on the softing.ko driver, but this is purely to make configuration intuitive. This driver will work independent, but no CAN network devices appear until softing.ko is loaded too. Signed-off-by: Kurt Van Dijck <kurt.van.dijck@eia.be> --- drivers/net/can/softing/Kconfig | 13 ++ drivers/net/can/softing/Makefile | 1 + ...

Because the hardware does not yet support these in this mode. Reviewed-by: Benjamin Li <benli@broadcom.com> Signed-off-by: Michael Chan <mchan@broadcom.com> --- drivers/net/cnic.c | 8 ++------ 1 files changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/net/cnic.c b/drivers/net/cnic.c index 4a9c628..41957fa 100644 --- a/drivers/net/cnic.c +++ b/drivers/net/cnic.c @@ -4826,12 +4826,8 @@ static void cnic_get_bnx2x_iscsi_info(struct cnic_dev *dev) val = CNIC_RD(dev, addr); ...

There's ioread() and get_unaligned(). Do we have a combination of this? Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions | Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917-5555 | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |

From 91e84e6b6ca416e8200f04b60383c398f9b93bd2 Mon Sep 17 00:00:00 2001 From: Oliver Neukum <oliver@neukum.org> Date: Tue, 4 Jan 2011 17:11:29 +0100 Subject: [PATCH] r8169: support control of advertising This allows "ethtool advertise" to control the speed and duplex features the device offers the switch. Signed-off-by: Oliver Neukum <oneukum@suse.de> --- drivers/net/r8169.c | 41 +++++++++++++++++++++++++++++++---------- 1 files changed, 31 insertions(+), 10 deletions(-) diff --git ...

Adapted from version 8.019.00 of Realtek's r8168 driver and amended per Hayes Wang's correction : - OCPDR_GPHY_REG_SHIFT must be 16, not 12 - the reg should be at bit 16 ~ 22, whence OCPDR_REG_MASK Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Cc: Hayes <hayeswang@realtek.com> --- drivers/net/r8169.c | 83 +++++++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 81 insertions(+), 2 deletions(-) diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c index ...

Current mdio_{read/write} needs device specific information to work correctly with newer chipsets. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Cc: Hayes <hayeswang@realtek.com> --- drivers/net/r8169.c | 307 ++++++++++++++++++++++++++------------------------- 1 files changed, 157 insertions(+), 150 deletions(-) diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c index 33c3fbf..b5ced5e 100644 --- a/drivers/net/r8169.c +++ b/drivers/net/r8169.c @@ -502,9 +502,9 @@ struct ...

Adapted from version 8.019.00 of Realtek's r8168 driver. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Cc: Hayes <hayeswang@realtek.com> --- drivers/net/r8169.c | 93 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 93 insertions(+), 0 deletions(-) diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c index 0ec47f4..a73dd28 100644 --- a/drivers/net/r8169.c +++ b/drivers/net/r8169.c @@ -278,6 +278,18 @@ enum rtl8168_8101_registers { }; enum ...

Adapted from version 8.019.00 of Realtek's r8168 driver Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Cc: Hayes <hayeswang@realtek.com> --- drivers/net/r8169.c | 145 +++++++++++++++++++++++++++++++++++++++++++++++--- 1 files changed, 136 insertions(+), 9 deletions(-) diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c index a468ee9..27a7c20 100644 --- a/drivers/net/r8169.c +++ b/drivers/net/r8169.c @@ -121,7 +121,8 @@ enum mac_version { RTL_GIGA_MAC_VER_24 = 0x18, // ...

hayeswang <hayeswang@realtek.com> : Ok. Any comment about the patch below ? I wish it was more expressive, especially the "mutex" magic. diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c index 27a7c20..d2c850d 100644 --- a/drivers/net/r8169.c +++ b/drivers/net/r8169.c @@ -615,6 +615,58 @@ static void ocp_write(struct rtl8169_private *tp, u8 mask, u16 reg, u32 data) } } +#define OCP_REG_1 0x009c +#define OCP_REG_2 0x0014 + +static void ocp_lock_write(struct rtl8169_private ...

Thanks for your guess, Eric. Unfortunately, that didn't change anything. According to the documentation at http://lartc.org/howto/lartc.kernel.html that parameter is to prevent _responses_ leaving through a different interface that the original packet came in on. So, I wouldn't expect it to have any impact on _routed packets_. In my original e-mail, I forgot to mention something I noticed while debugging: If i put the bridge into promiscuous mode, then suddenly the packets ...

Read fec mac address from ocotp and save it into fec_platform_data mac field for fec driver to use. Signed-off-by: Shawn Guo <shawn.guo@freescale.com> --- Changes for v2: - It's not necessary to remove "const" for fec_platform_data from platform-fec.c and devices-common.h, so add it back. - Hard-coding Freescale OUI (00:04:9f) instead of just the first two two octets. - Correct the return of mx28evk_fec_get_mac() and check it with caller arch/arm/mach-mxs/mach-mx28evk.c | ...

FEC_MMFR_OP_WRITE should be used than FEC_MMFR_OP_READ in a mdio write operation. It's probably a typo introduced by commit: e6b043d512fa8d9a3801bf5d72bfa3b8fc3b3cc8 netdev/fec.c: add phylib supporting to enable carrier detection (v2) Signed-off-by: Shawn Guo <shawn.guo@freescale.com> --- drivers/net/fec.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/fec.c b/drivers/net/fec.c index cce32d4..52e9ca8 100644 --- a/drivers/net/fec.c +++ ...

Hi Baruch, Sorry for rushing to send the patch set out. All these updates should happen on patch #3 than #5. This is a serious problem, I do not find a good way to detect cpu type. Neither adding a new platform data field nor using __machine_arch_type to enumerate all mx28 based machine (though there is only one currently) seems to be good for me. I will try to manipulate some mx28 unique register to identify mx28 from other i.mx variants. Hopefully, it will work. Thanks for the ...

This is a very initial pm support and basically does nothing. With this pm support entry, drivers can start testing their own pm functions. Signed-off-by: Shawn Guo <shawn.guo@freescale.com> --- Changes for v2: - Let build of pm.c depend on CONFIG_PM - Remove the blank line above device_initcall in pm.c arch/arm/mach-mxs/Makefile | 2 ++ arch/arm/mach-mxs/pm.c | 43 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 45 insertions(+), 0 deletions(-) create mode ...

The "index" becomes legacy since fep->pdev->id starts working to identify the instance. Moreover, the call of fec_enet_init(ndev, 0) always passes 0 to fep->index. This makes the following code in fec_get_mac buggy. /* Adjust MAC if using default MAC address */ if (iap == fec_mac_default) dev->dev_addr[ETH_ALEN-1] = fec_mac_default[ETH_ALEN-1] + fep->index; It may be the time to remove "index" and use fep->pdev->id instead. Signed-off-by: Shawn Guo <shawn.guo@freescale.com> --- ...

The following commit made a fix to use fec_enet_open/fec_enet_close over fec_enet_init/fec_stop for suspend/resume, because fec_enet_init does not allow to have a working network interface at resume. e3fe8558c7fc182972c3d947d88744482111f304 net/fec: fix pm to survive to suspend/resume This fix works for i.mx/mxc fec controller, but fails on mx28 fec which gets a different interrupt logic design. On i.mx fec, interrupt can be triggered even bit ETHER_EN of ECR register is not set. But on ...

I am playing with Quick Fair Queue (QFQ) from FreeBSD. The authors started with Linux first and sent me their version, it needs some work first. http://info.iet.unipi.it/~luigi/qfq/ http://www.google.com/search?client=ubuntu&channel=fs&q=QFQ+rizzo&ie=utf-8... --

I still don't see the value in doing this RX/TX queue pairing (unless you're considering the possibility of explicitly binding sockets to queue pairs). XPS should be sufficient mechanism to get affinity on sending side. Also, don't know how the queue paring model will be maintained when using priority queues on transmit-- transmit is likely to be asymmetric to receive side. The ability to seamlessly decouple The device hash should already be available in sk_rxhash, so maybe that could be used ...

I think Joe may object the use of "? :" -- Regards, Changli Gao(xiaosuo@gmail.com) --