drivers/net/3c509.c fails (CONFIG_PM=y) with: drivers/built-in.o:(.data+0x7dcc): undefined reference to `el3_resume' drivers/built-in.o:(.data+0x7e08): undefined reference to `el3_resume' It seems that this function does not exist in the source file. --- ~Randy Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA http://linuxplumbersconf.org/ --

Currently, the receive processing reads ->byte_cnt twice (once to update interface statistics and once to properly size the data area of the received skb), but since receive descriptors live in uncached memory, caching this value in a local variable saves one uncached access, and increases routing performance a tiny little bit more. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> --- drivers/net/mv643xx_eth.c | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-) diff...

Get rid of the skb pointer array that we currently use for transmit reclaim, and replace it with an skb queue, to which skbuffs are appended when they are passed to the xmit function, and removed from the front and freed when we do transmit queue reclaim and hit a descriptor with the 'owned by device' bit clear and 'last descriptor' bit set. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> --- drivers/net/mv643xx_eth.c | 39 ++++++++++----------------------------- 1 files changed, 1...

By moving DMA unmapping during transmit reclaim back under the netif tx lock, we avoid the situation where we read the DMA address and buffer length from the descriptor under the lock and then not do anything with that data after dropping the lock on platforms where the DMA unmapping routines are all NOPs (which is the case on all ARM platforms that mv643xx_eth is used on at least). This saves two uncached reads, which makes a small but measurable performance difference in routing benchmarks. Si...

drivers/net/bonding throws a large number of warnings when compiling a kernel with sparse. These two patches remove the easiest offenders to try and cut down the number and see what is important. -- Ben (ben@fluff.org, http://www.fluff.org/) 'a smiley only costs 4 bytes' --

Hi All, Sendfile() over UDP socket are currently limited to ~ 64KBytes file (max cork.length). Indeed, if you run sendfile() with a file size > 64KBytes over UDP socket, system call will stop and return ~64KBytes without sending anything on the network. This patch is pushing ongoing frames when frames buffer is full, to prevent overflow. Signed-off-by: Johann Baudy <johann.baudy@gmail.com> net/ipv4/udp.c | 15 +++++++++++++++ 1 files changed, 15 insertions(+), 0 deletions(-) diff ...

Need a little bit more information here. How close is this hardware to e1000? Is this driver really from Intel, as the contact information implies? Is there documentation on the hardware anywhere? --

Good point, that would be better in some circumstances. We're already looking up the route to the real server anyways and I think the route entry also contains the source IP that a packet to that host would Ok, just from the replies in that thread, it sounds like you have to rethink many assumptions and cases which might be dangerous with that patch. Or have these worries been resolved? Then it would be a nice Hm, that happens in ip_vs_in(), which then calls the connection's transmit function...

Thanks for the info! Right, I even said myself in the previous reply that ip_vs_postrouting() stops further processing in the POSTROUTING chain, so it never reaches netfilter NAT code. I still think an in-IPVS SNAT would be nice anyways... don't know if I'll find the time to hack on it soon, though. Julius -- Julius Volz - Corporate Operations - SysOps Google Switzerland GmbH - Identification No.: CH-020.4.028.116-1 --

sounds OK by me. You should get an opinion from people who I assume the function is there o to speed up LVS (useful but not required for LVS-NAT) o to push the layer 2 packet for LVS-DR out on the wire. This packet has the MAC address of the RIP, but dst_addr=VIP, so can't be sent through routing. Joe -- Joseph Mack NA3T EME(B,D), FM05lw North Carolina jmack (at) wm7d (dot) net - azimuthal equidistant map generator at http://www.wm7d.net/azproj.shtml Homepage [ message continues ]

nice - i think kmemcheck is starting to build up a healthy list of references :-) Ingo --

It's too big for vger as one patch. There's a lot of code that can be whittled down, but this driver has been delayed for months already waiting for that to be finished. Would you prefer a gzipped One Big Patch? -- Chris --

On Thu, 21 Aug 2008 15:58:49 +0400 [...] Alexey, Can you please try this patch? diff --git a/drivers/net/atlx/atl1.c b/drivers/net/atlx/atl1.c index e23ce77..e00a986 100644 --- a/drivers/net/atlx/atl1.c +++ b/drivers/net/atlx/atl1.c @@ -2642,6 +2642,7 @@ static void atl1_down(struct atl1_adapter *adapter) { struct net_device *netdev = adapter->netdev; + netif_stop_queue(netdev); del_timer_sync(&adapter->watchdog_timer); del_timer_sync(&adapter->phy_config_timer)...

From: Jay Cliburn <jacliburn@bellsouth.net> If the cable is unplugged, netif_carrier_off() will be (or should be) invoked by the driver, and that cancels the watchdog timer. This is all from memory since I'm travelling and don't have the time to check this directly. You should investigate this yourself instead of asking me if you want a truly definitive answer :) --

So... the NIC doesn't work after resume, even after your patch is applied? --

applied --

Patch looks good -- ACK -- but I cannot apply since I do not have include/linux/xilinx_devices.h --

If it's only for this initial check I still think my earlier proposal should be enough: http://marc.info/?l=linux-netdev&m=122113717013988&w=2 Anyway, the main problem here was a high cpu load despite stopped queue. Are you sure this peek, which is almost full dequeue, can really help for this? BTW, since after current fix there were no later complains I guess it's just about full netif_stop or non-mq device. Cheers, Jarek P. --

On Sat, Sep 13, 2008 at 11:16 PM, Herbert Xu <herbert@gondor.apana.org.au> What if we were to push the check for netif_tx_queue_stopped further down into the qdisc layer so that the basic qdiscs such as pfifo_fast did their own peek and in the event that a queue is stopped it just returned NULL and set a flag bit? Basically this would mimic how we are currently handling throttled queues (TCQ_F_THROTTLED). Then in turn each parent could do a check on skb == NULL and set the same flag, or they...

Why would you want to do that? Just because people have abused requeue in the psat doesn't mean that we need to support such abuses for perpetuity. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --

I don't know enough about the arch to be able to ACK or NAK... pass this through the appropriate arch maintainer tree please? --

Hi Lennert, When I published this patch, I had access to an i.MX31ADS board, and getting Linux to work on this board was just a necessity to get my job done. I did this by copying the parts I needed working (the serial console and ethernet driver) from the Freescale tree. Now, I am no longer working on this, so I can not test any modification. And I do not even know why people at Freescale did what they did. All I can tell you is that an i.MX31ADS board works when using this patch. Regards...

Changes look good, but do not apply to the 'retina' branch. Also, the virt_to_bus/virt_to_phys stuff should be replaced with DMA mapping API usage. --

applied --

Testing feedback? Lennert ack? --