* Re: [PATCH net-next v2 1/7] r8169: adjust some registers
From: Francois Romieu @ 2011-07-07 8:50 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, linux-kernel
In-Reply-To: <1309939088-31994-1-git-send-email-hayeswang@realtek.com>
Hayes Wang <hayeswang@realtek.com> :
[...]
I have acked and pushed the whole serie against davem's -next branch
(aec27311c23a8ce8eaf490762249d3ed74be83b6) as :
git://git.kernel.org/pub/scm/linux/kernel/git/romieu/netdev-2.6.git davem-next.r8169
I have done three changes which do imho not deserve a separate patch:
- renamed rtl_eri_write_w0w1 to rtl_w1w0i_eri as there already is a
rtl_w1w0_phy. Parameters have been permuted (idem for callers).
- fixed spurious static<space><space> and excess comment line length.
I am giving it a pair of hours testing.
--
Ueimor
^ permalink raw reply
* Re: [PATCH 01/14] mm: Serialize access to min_free_kbytes
From: Mel Gorman @ 2011-07-07 9:17 UTC (permalink / raw)
To: Andrew Morton
Cc: Linux-MM, Linux-Netdev, LKML, David Miller, Neil Brown,
Peter Zijlstra
In-Reply-To: <20110706164447.d571051a.akpm@linux-foundation.org>
On Wed, Jul 06, 2011 at 04:44:47PM -0700, Andrew Morton wrote:
> On Mon, 20 Jun 2011 14:12:07 +0100
> Mel Gorman <mgorman@suse.de> wrote:
>
> > There is a race between the min_free_kbytes sysctl, memory hotplug
> > and transparent hugepage support enablement. Memory hotplug uses a
> > zonelists_mutex to avoid a race when building zonelists. Reuse it to
> > serialise watermark updates.
>
> This patch appears to be a standalone fix, unrelated to the overall
> patch series?
>
Yes. In the original series this would have been a more serious problem
as min_free_kbytes was potentially adjusted more frequently.
> How does one trigger the race and what happens when it hits, btw?
One could trigger the trace by having multiple processes on different
CPUs write to min_free_kbytes. One could add memory hotplug events
to that for extra fun but it is unnecessary to trigger the race.
The consequences are that the value for min_free_kbytes and the zone
watermarks get out of sync. Whether the zone watermarks will be too
high or too low would depend on the timing. For the most part, the
consequence will simply be that the min free level for some zones will
be wrong. A more serious consequence is that totalreserve_pages could
get out of sync and strict no memory overcommit could fail a mmap when
it should have succeeded for the value of min_free_kbytes or suspend
fail because it did not preallocate enough pages.
It's not exactly earth shattering.
--
Mel Gorman
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Eric Dumazet @ 2011-07-07 9:20 UTC (permalink / raw)
To: Alexey Zaytsev
Cc: Michael Büsch, Neil Horman, Andrew Morton, netdev,
Gary Zambrano, bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <CAB9v_DF1-q31Y57CUzinXOfGtNejoCAEJVc7u2ECWNLDj97ZPQ@mail.gmail.com>
Le jeudi 07 juillet 2011 à 11:45 +0400, Alexey Zaytsev a écrit :
> On Thu, Jul 7, 2011 at 10:48, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > Le jeudi 07 juillet 2011 à 10:32 +0400, Alexey Zaytsev a écrit :
> >> Sorry, been busy for the last couple days. Any patches I should test?
> >
> > Please try :
> >
>
> Thanks. Seems to fail to initialize, getting this in dmesg:
>
> [ 103.421577] b44 0000:02:0e.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> [ 103.440139] ssb: Core 0 found: Fast Ethernet (cc 0x806, rev 0x07,
> vendor 0x4243)
> [ 103.440159] ssb: Core 1 found: V90 (cc 0x807, rev 0x03, vendor 0x4243)
> [ 103.440177] ssb: Core 2 found: PCI (cc 0x804, rev 0x0A, vendor 0x4243)
> [ 103.481128] ssb: Sonics Silicon Backplane found on PCI device 0000:02:0e.0
> [ 103.481532] b44: b44.c:v2.0
> [ 103.502185] b44 ssb1:0: eth0: Broadcom 44xx/47xx 10/100BaseT
> Ethernet 00:17:a4:dd:4e:93
> [ 109.405071] b44 ssb1:0: eth0: powering down PHY
> [ 112.816456] b44 ssb1:0: eth0: Link is up at 100 Mbps, full duplex
> [ 112.816470] b44 ssb1:0: eth0: Flow control is off for TX and off for RX
> [ 112.952073] b44 ssb1:0: eth0: powering down PHY
> [ 113.816148] b44 ssb1:0: eth0: Link is down
> [ 114.953717] b44 ssb1:0: eth0: powering down PHY
> [ 117.816246] b44 ssb1:0: eth0: Link is up at 100 Mbps, full duplex
> [ 117.816260] b44 ssb1:0: eth0: Flow control is off for TX and off for RX
> [ 117.963238] b44 ssb1:0: eth0: powering down PHY
> [ 118.816128] b44 ssb1:0: eth0: Link is down
> [ 119.962817] b44 ssb1:0: eth0: powering down PHY
Maybe this is the b44_init_hw() change :
bw32(bp, B44_DMARX_PTR, 0);
So please change this part
Updated patch :
diff --git a/drivers/net/b44.c b/drivers/net/b44.c
index 6c4ef96..555a8ce 100644
--- a/drivers/net/b44.c
+++ b/drivers/net/b44.c
@@ -688,8 +688,8 @@ static int b44_alloc_rx_skb(struct b44 *bp, int src_idx, u32 dest_idx_unmasked)
ctrl |= DESC_CTRL_EOT;
dp = &bp->rx_ring[dest_idx];
- dp->ctrl = cpu_to_le32(ctrl);
dp->addr = cpu_to_le32((u32) mapping + bp->dma_offset);
+ dp->ctrl = cpu_to_le32(ctrl);
if (bp->flags & B44_FLAG_RX_RING_HACK)
b44_sync_dma_desc_for_device(bp->sdev, bp->rx_ring_dma,
@@ -725,13 +725,15 @@ static void b44_recycle_rx(struct b44 *bp, int src_idx, u32 dest_idx_unmasked)
DMA_BIDIRECTIONAL);
ctrl = src_desc->ctrl;
+ src_desc->ctrl = (ctrl & cpu_to_le32(DESC_CTRL_EOT));
if (dest_idx == (B44_RX_RING_SIZE - 1))
ctrl |= cpu_to_le32(DESC_CTRL_EOT);
else
ctrl &= cpu_to_le32(~DESC_CTRL_EOT);
- dest_desc->ctrl = ctrl;
dest_desc->addr = src_desc->addr;
+ dest_desc->ctrl = ctrl;
+ src_desc->addr = 0;
src_map->skb = NULL;
@@ -1118,6 +1120,7 @@ static void b44_init_rings(struct b44 *bp)
if (b44_alloc_rx_skb(bp, -1, i) < 0)
break;
}
+ bp->rx_prod = i;
}
/*
@@ -1406,7 +1409,6 @@ static void b44_init_hw(struct b44 *bp, int reset_kind)
bw32(bp, B44_DMARX_ADDR, bp->rx_ring_dma + bp->dma_offset);
bw32(bp, B44_DMARX_PTR, bp->rx_pending);
- bp->rx_prod = bp->rx_pending;
bw32(bp, B44_MIB_CTRL, MIB_CTRL_CLR_ON_READ);
}
^ permalink raw reply related
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Alexey Zaytsev @ 2011-07-07 9:34 UTC (permalink / raw)
To: Eric Dumazet
Cc: Michael Büsch, Neil Horman, Andrew Morton, netdev,
Gary Zambrano, bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <1310030439.2127.4.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Thu, Jul 7, 2011 at 13:20, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 07 juillet 2011 à 11:45 +0400, Alexey Zaytsev a écrit :
>> On Thu, Jul 7, 2011 at 10:48, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> > Le jeudi 07 juillet 2011 à 10:32 +0400, Alexey Zaytsev a écrit :
>> >> Sorry, been busy for the last couple days. Any patches I should test?
>> >
>> > Please try :
>> >
>>
>> Thanks. Seems to fail to initialize, getting this in dmesg:
>>
>> [ 103.421577] b44 0000:02:0e.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
>> [ 103.440139] ssb: Core 0 found: Fast Ethernet (cc 0x806, rev 0x07,
>> vendor 0x4243)
>> [ 103.440159] ssb: Core 1 found: V90 (cc 0x807, rev 0x03, vendor 0x4243)
>> [ 103.440177] ssb: Core 2 found: PCI (cc 0x804, rev 0x0A, vendor 0x4243)
>> [ 103.481128] ssb: Sonics Silicon Backplane found on PCI device 0000:02:0e.0
>> [ 103.481532] b44: b44.c:v2.0
>> [ 103.502185] b44 ssb1:0: eth0: Broadcom 44xx/47xx 10/100BaseT
>> Ethernet 00:17:a4:dd:4e:93
>> [ 109.405071] b44 ssb1:0: eth0: powering down PHY
>> [ 112.816456] b44 ssb1:0: eth0: Link is up at 100 Mbps, full duplex
>> [ 112.816470] b44 ssb1:0: eth0: Flow control is off for TX and off for RX
>> [ 112.952073] b44 ssb1:0: eth0: powering down PHY
>> [ 113.816148] b44 ssb1:0: eth0: Link is down
>> [ 114.953717] b44 ssb1:0: eth0: powering down PHY
>> [ 117.816246] b44 ssb1:0: eth0: Link is up at 100 Mbps, full duplex
>> [ 117.816260] b44 ssb1:0: eth0: Flow control is off for TX and off for RX
>> [ 117.963238] b44 ssb1:0: eth0: powering down PHY
>> [ 118.816128] b44 ssb1:0: eth0: Link is down
>> [ 119.962817] b44 ssb1:0: eth0: powering down PHY
>
> Maybe this is the b44_init_hw() change :
>
> bw32(bp, B44_DMARX_PTR, 0);
>
> So please change this part
>
> Updated patch :
Initializes fine now, but the transfer would stall every few seconds.
^ permalink raw reply
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Alexey Zaytsev @ 2011-07-07 9:37 UTC (permalink / raw)
To: Eric Dumazet
Cc: Michael Büsch, Neil Horman, Andrew Morton, netdev,
Gary Zambrano, bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <CAB9v_DEYbPztDMr9m0B6A-a-q1gvECzX8g=B31xUp+D1_d5fZA@mail.gmail.com>
On Thu, Jul 7, 2011 at 13:34, Alexey Zaytsev <alexey.zaytsev@gmail.com> wrote:
> On Thu, Jul 7, 2011 at 13:20, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> Le jeudi 07 juillet 2011 à 11:45 +0400, Alexey Zaytsev a écrit :
>>> On Thu, Jul 7, 2011 at 10:48, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>> > Le jeudi 07 juillet 2011 à 10:32 +0400, Alexey Zaytsev a écrit :
>>> >> Sorry, been busy for the last couple days. Any patches I should test?
>>> >
>>> > Please try :
>>> >
>>>
>>> Thanks. Seems to fail to initialize, getting this in dmesg:
>>>
>>> [ 103.421577] b44 0000:02:0e.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
>>> [ 103.440139] ssb: Core 0 found: Fast Ethernet (cc 0x806, rev 0x07,
>>> vendor 0x4243)
>>> [ 103.440159] ssb: Core 1 found: V90 (cc 0x807, rev 0x03, vendor 0x4243)
>>> [ 103.440177] ssb: Core 2 found: PCI (cc 0x804, rev 0x0A, vendor 0x4243)
>>> [ 103.481128] ssb: Sonics Silicon Backplane found on PCI device 0000:02:0e.0
>>> [ 103.481532] b44: b44.c:v2.0
>>> [ 103.502185] b44 ssb1:0: eth0: Broadcom 44xx/47xx 10/100BaseT
>>> Ethernet 00:17:a4:dd:4e:93
>>> [ 109.405071] b44 ssb1:0: eth0: powering down PHY
>>> [ 112.816456] b44 ssb1:0: eth0: Link is up at 100 Mbps, full duplex
>>> [ 112.816470] b44 ssb1:0: eth0: Flow control is off for TX and off for RX
>>> [ 112.952073] b44 ssb1:0: eth0: powering down PHY
>>> [ 113.816148] b44 ssb1:0: eth0: Link is down
>>> [ 114.953717] b44 ssb1:0: eth0: powering down PHY
>>> [ 117.816246] b44 ssb1:0: eth0: Link is up at 100 Mbps, full duplex
>>> [ 117.816260] b44 ssb1:0: eth0: Flow control is off for TX and off for RX
>>> [ 117.963238] b44 ssb1:0: eth0: powering down PHY
>>> [ 118.816128] b44 ssb1:0: eth0: Link is down
>>> [ 119.962817] b44 ssb1:0: eth0: powering down PHY
>>
>> Maybe this is the b44_init_hw() change :
>>
>> bw32(bp, B44_DMARX_PTR, 0);
>>
>> So please change this part
>>
>> Updated patch :
>
> Initializes fine now, but the transfer would stall every few seconds.
>
Err, wait a sec, patches the wrong version.
^ permalink raw reply
* [PATCH] rose: Delete commented out references to ancient firewalling code.
From: David Miller @ 2011-07-07 9:42 UTC (permalink / raw)
To: netdev
These intefaces haven't existed since 2.2.x
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/rose/rose_link.c | 7 -------
net/rose/rose_route.c | 5 -----
2 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/net/rose/rose_link.c b/net/rose/rose_link.c
index fa5f564..7a02bd1 100644
--- a/net/rose/rose_link.c
+++ b/net/rose/rose_link.c
@@ -266,13 +266,6 @@ void rose_transmit_link(struct sk_buff *skb, struct rose_neigh *neigh)
{
unsigned char *dptr;
-#if 0
- if (call_fw_firewall(PF_ROSE, skb->dev, skb->data, NULL, &skb) != FW_ACCEPT) {
- kfree_skb(skb);
- return;
- }
-#endif
-
if (neigh->loopback) {
rose_loopback_queue(skb, neigh);
return;
diff --git a/net/rose/rose_route.c b/net/rose/rose_route.c
index 479cae5..d389de1 100644
--- a/net/rose/rose_route.c
+++ b/net/rose/rose_route.c
@@ -864,11 +864,6 @@ int rose_route_frame(struct sk_buff *skb, ax25_cb *ax25)
int res = 0;
char buf[11];
-#if 0
- if (call_in_firewall(PF_ROSE, skb->dev, skb->data, NULL, &skb) != FW_ACCEPT)
- return res;
-#endif
-
if (skb->len < ROSE_MIN_LEN)
return res;
frametype = skb->data[2];
--
1.7.6
^ permalink raw reply related
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Alexey Zaytsev @ 2011-07-07 9:43 UTC (permalink / raw)
To: Eric Dumazet
Cc: Michael Büsch, Neil Horman, Andrew Morton, netdev,
Gary Zambrano, bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <CAB9v_DEfe6XnavbDB8Jj9XmSXt4MSs6sVUD4F1C8w8wsdqJjPA@mail.gmail.com>
On Thu, Jul 7, 2011 at 13:37, Alexey Zaytsev <alexey.zaytsev@gmail.com> wrote:
> On Thu, Jul 7, 2011 at 13:34, Alexey Zaytsev <alexey.zaytsev@gmail.com> wrote:
>> On Thu, Jul 7, 2011 at 13:20, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>> Le jeudi 07 juillet 2011 à 11:45 +0400, Alexey Zaytsev a écrit :
>>>> On Thu, Jul 7, 2011 at 10:48, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>>> > Le jeudi 07 juillet 2011 à 10:32 +0400, Alexey Zaytsev a écrit :
>>>> >> Sorry, been busy for the last couple days. Any patches I should test?
>>>> >
>>>> > Please try :
>>>> >
>>>>
>>>> Thanks. Seems to fail to initialize, getting this in dmesg:
>>>>
>>>> [ 103.421577] b44 0000:02:0e.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
>>>> [ 103.440139] ssb: Core 0 found: Fast Ethernet (cc 0x806, rev 0x07,
>>>> vendor 0x4243)
>>>> [ 103.440159] ssb: Core 1 found: V90 (cc 0x807, rev 0x03, vendor 0x4243)
>>>> [ 103.440177] ssb: Core 2 found: PCI (cc 0x804, rev 0x0A, vendor 0x4243)
>>>> [ 103.481128] ssb: Sonics Silicon Backplane found on PCI device 0000:02:0e.0
>>>> [ 103.481532] b44: b44.c:v2.0
>>>> [ 103.502185] b44 ssb1:0: eth0: Broadcom 44xx/47xx 10/100BaseT
>>>> Ethernet 00:17:a4:dd:4e:93
>>>> [ 109.405071] b44 ssb1:0: eth0: powering down PHY
>>>> [ 112.816456] b44 ssb1:0: eth0: Link is up at 100 Mbps, full duplex
>>>> [ 112.816470] b44 ssb1:0: eth0: Flow control is off for TX and off for RX
>>>> [ 112.952073] b44 ssb1:0: eth0: powering down PHY
>>>> [ 113.816148] b44 ssb1:0: eth0: Link is down
>>>> [ 114.953717] b44 ssb1:0: eth0: powering down PHY
>>>> [ 117.816246] b44 ssb1:0: eth0: Link is up at 100 Mbps, full duplex
>>>> [ 117.816260] b44 ssb1:0: eth0: Flow control is off for TX and off for RX
>>>> [ 117.963238] b44 ssb1:0: eth0: powering down PHY
>>>> [ 118.816128] b44 ssb1:0: eth0: Link is down
>>>> [ 119.962817] b44 ssb1:0: eth0: powering down PHY
>>>
>>> Maybe this is the b44_init_hw() change :
>>>
>>> bw32(bp, B44_DMARX_PTR, 0);
>>>
>>> So please change this part
>>>
>>> Updated patch :
>>
>> Initializes fine now, but the transfer would stall every few seconds.
>>
> Err, wait a sec, patches the wrong version.
>
Ok, I've wrongly fixed this part in the clean b44.c, and got stalls.
Then fixed the patched one after applying the stash, and still got the
stalls.
^ permalink raw reply
* [heads-up] bridge in kernel 3.0~ and dhcp from kvm guest on tap device
From: Michael Tokarev @ 2011-07-07 9:44 UTC (permalink / raw)
To: netdev, KVM list
The combination in $subject apparently stopped working --
I'm running 3.0-rc6 kernel on host where it doesn't work.
The setup is -- a bridge, br0, to which host eth0 and guest
tap devices are connected.
When KVM guest boots, it tries to send DHCP requests to
its ethernet device (it does not matter which device it
uses - be it virtio or e1000 or rtl8139, all work the
same). These requests appears (can be seen) on the tap
device, but they never propagate to bridge.
Example of a packet as seen on the tap device from a
windows7 guest:
# tcpdump -npvi tap-kvm port bootpc
tcpdump: WARNING: tap-kvm: no IPv4 address assigned
tcpdump: listening on tap-kvm, link-type EN10MB (Ethernet), capture size 65535 bytes
13:38:21.435032 IP (tos 0x0, ttl 128, id 109, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 52:54:00:12:34:56, length 300, xid 0xdc8f28b1, secs 7168, Flags [Broadcast]
Client-Ethernet-Address 52:54:00:12:34:56
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 7: ether 52:54:00:12:34:56
Hostname Option 12, length 7: "mjt-006"
Vendor-Class Option 60, length 8: "MSFT 5.0"
Parameter-Request Option 55, length 12:
Subnet-Mask, Domain-Name, Default-Gateway, Domain-Name-Server
Netbios-Name-Server, Netbios-Node, Netbios-Scope, Router-Discovery
Static-Route, Classless-Static-Route, Classless-Static-Route-Microsoft, Vendor-Option
Exactly the same thing happens with 4 different DHCP
clients: it's ipxe boot rom (network booting of a KVM
guest), win7 built-in DHCP client, udhcpc and dhcp3.
All other traffic - so far anyway - works correcty.
Right now I don't have time to debug the issue, will try
to bisect later. But if anyone have pointers or thoughts,
please shot away ;)
Thanks!
/mjt
^ permalink raw reply
* Re: [PATCH 00/14] Swap-over-NBD without deadlocking v5
From: Mel Gorman @ 2011-07-07 9:47 UTC (permalink / raw)
To: Andrew Morton
Cc: Linux-MM, Linux-Netdev, LKML, David Miller, Neil Brown,
Peter Zijlstra
In-Reply-To: <20110706165146.be7ab61b.akpm@linux-foundation.org>
On Wed, Jul 06, 2011 at 04:51:46PM -0700, Andrew Morton wrote:
> On Mon, 20 Jun 2011 14:12:06 +0100
> Mel Gorman <mgorman@suse.de> wrote:
>
> > Swapping over NBD is something that is technically possible but not
> > often advised. While there are number of guides on the internet
> > on how to configure it and nbd-client supports a -swap switch to
> > "prevent deadlocks", the fact of the matter is a machine using NBD
> > for swap can be locked up within minutes if swap is used intensively.
> >
> > The problem is that network block devices do not use mempools like
> > normal block devices do. As the host cannot control where they receive
> > packets from, they cannot reliably work out in advance how much memory
> > they might need.
> >
> > Some years ago, Peter Ziljstra developed a series of patches that
> > supported swap over an NFS that some distributions are carrying in
> > their kernels. This patch series borrows very heavily from Peter's work
> > to support swapping over NBD (the relatively straight-forward case)
> > and uses throttling instead of dynamically resized memory reserves
> > so the series is not too unwieldy for review.
>
> I have to say, I look over these patches and my mind wants to turn to
> things like puppies. And ice cream.
>
People do love puppies and ice cream!
> There's quite some complexity added here in areas which are already
> reliably unreliable and afaik swap-over-NBD is not a thing which a lot
> of people want to do. I can see that swap-over-NFS would be useful to
> some people, and the fact that distros are carrying swap-over-NFS
> patches has weight.
>
> Do these patches lead on to swap-over-NFS? If so, how much more
> additional complexity are we buying into for that?
Swap-over-NFS is the primary motivation. As you say, distributions are
carrying this and have been for some time. Based on my asking about the
background, the primary user is clusters of blades that are diskless
or have extremely limited storage with no possibility of expansion (be
it due to physical dimensions or maintenance overhead). They require
an amount of infrequently used swap for their workloads. They are
connected to some sort of SAN that may or may not be running Linux
but that exports NFS so they want to stick a swapfile on it.
Swap-over-NBD is the simplier case that can be used if the SAN
is running Linux. Almost all of the compexity required to support
swap-over-NBD is reused for swap-over-NFS (obviously the NBD-specific
bits are not reused).
Additional complexity is required for swap-over-NFS but affects the
core kernel far less than this series. I do not have a series prepared
but from what's in a distro kernel, supporting NFS requires extending
address_space_operations for swapfile activation/deactivation with
some minor helpers and the bulk of the remaining complexity within
NFS itself.
--
Mel Gorman
SUSE Labs
^ permalink raw reply
* Re: [heads-up] bridge in kernel 3.0~ and dhcp from kvm guest on tap device
From: David Miller @ 2011-07-07 9:49 UTC (permalink / raw)
To: mjt; +Cc: netdev, kvm
In-Reply-To: <4E158019.9040604@msgid.tls.msk.ru>
From: Michael Tokarev <mjt@tls.msk.ru>
Date: Thu, 07 Jul 2011 13:44:57 +0400
> The combination in $subject apparently stopped working --
> I'm running 3.0-rc6 kernel on host where it doesn't work.
Already fixed in net-2.6:
>From 44661462ee1ee3c922754fc1f246867f0d01e7ea Mon Sep 17 00:00:00 2001
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 5 Jul 2011 13:58:33 +0000
Subject: [PATCH 24/30] bridge: Always flood broadcast packets
As is_multicast_ether_addr returns true on broadcast packets as
well, we need to explicitly exclude broadcast packets so that
they're always flooded. This wasn't an issue before as broadcast
packets were considered to be an unregistered multicast group,
which were always flooded. However, as we now only flood such
packets to router ports, this is no longer acceptable.
Reported-by: Michael Guntsche <mike@it-loops.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/bridge/br_device.c | 4 +++-
net/bridge/br_input.c | 6 ++++--
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
index c188c80..32b8f9f 100644
--- a/net/bridge/br_device.c
+++ b/net/bridge/br_device.c
@@ -49,7 +49,9 @@ netdev_tx_t br_dev_xmit(struct sk_buff *skb, struct net_device *dev)
skb_pull(skb, ETH_HLEN);
rcu_read_lock();
- if (is_multicast_ether_addr(dest)) {
+ if (is_broadcast_ether_addr(dest))
+ br_flood_deliver(br, skb);
+ else if (is_multicast_ether_addr(dest)) {
if (unlikely(netpoll_tx_running(dev))) {
br_flood_deliver(br, skb);
goto out;
diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index f3ac1e8..f06ee39 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_input.c
@@ -60,7 +60,7 @@ int br_handle_frame_finish(struct sk_buff *skb)
br = p->br;
br_fdb_update(br, p, eth_hdr(skb)->h_source);
- if (is_multicast_ether_addr(dest) &&
+ if (!is_broadcast_ether_addr(dest) && is_multicast_ether_addr(dest) &&
br_multicast_rcv(br, p, skb))
goto drop;
@@ -77,7 +77,9 @@ int br_handle_frame_finish(struct sk_buff *skb)
dst = NULL;
- if (is_multicast_ether_addr(dest)) {
+ if (is_broadcast_ether_addr(dest))
+ skb2 = skb;
+ else if (is_multicast_ether_addr(dest)) {
mdst = br_mdb_get(br, skb);
if (mdst || BR_INPUT_SKB_CB_MROUTERS_ONLY(skb)) {
if ((mdst && mdst->mglist) ||
--
1.7.6
^ permalink raw reply related
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Eric Dumazet @ 2011-07-07 9:52 UTC (permalink / raw)
To: Alexey Zaytsev
Cc: Michael Büsch, Neil Horman, Andrew Morton, netdev,
Gary Zambrano, bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <CAB9v_DFcdEFRdW-qmjr2TWwM3jtru=R+89LpaPKJ8XG_iXT3UQ@mail.gmail.com>
Le jeudi 07 juillet 2011 à 13:43 +0400, Alexey Zaytsev a écrit :
> Ok, I've wrongly fixed this part in the clean b44.c, and got stalls.
> Then fixed the patched one after applying the stash, and still got the
> stalls.
So, filling NULL to 'should not be used slots' definitely removes the
memory corruption, but also stalls the NIC.
Driver model is completely wrong. Without full hardware specs, this will
be hard to guess appropriate fixes.
^ permalink raw reply
* Re: [heads-up] bridge in kernel 3.0~ and dhcp from kvm guest on tap device
From: lists+linux-netdev @ 2011-07-07 9:55 UTC (permalink / raw)
To: David Miller; +Cc: netdev, kvm
In-Reply-To: <20110707.024906.763895385840201032.davem@davemloft.net>
07.07.2011 13:49, David Miller wrote:
> From: Michael Tokarev <mjt@tls.msk.ru>
> Date: Thu, 07 Jul 2011 13:44:57 +0400
>
>> The combination in $subject apparently stopped working --
>> I'm running 3.0-rc6 kernel on host where it doesn't work.
>
> Already fixed in net-2.6:
>
> From 44661462ee1ee3c922754fc1f246867f0d01e7ea Mon Sep 17 00:00:00 2001
> From: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Tue, 5 Jul 2011 13:58:33 +0000
> Subject: [PATCH 24/30] bridge: Always flood broadcast packets
Thank you very much for the quick response! I was preparing
myself for another painful bisection session for tonight
already.. ;)
I just verified - this patch fixes this issue (I rebuilt and
re-loaded the module) -- hopefully the fix will be in 3.0
kernel ;)
Thanks!
/mjt
^ permalink raw reply
* [PATCHv3] sctp: Enforce retransmission limit during shutdown
From: Thomas Graf @ 2011-07-07 10:28 UTC (permalink / raw)
To: Vladislav Yasevich
Cc: netdev, davem, Wei Yongjun, Sridhar Samudrala, linux-sctp
In-Reply-To: <4E148C16.8090505@hp.com>
When initiating a graceful shutdown while having data chunks
on the retransmission queue with a peer which is in zero
window mode the shutdown is never completed because the
retransmission error count is reset periodically by the
following two rules:
- Do not timeout association while doing zero window probe.
- Reset overall error count when a heartbeat request has
been acknowledged.
The graceful shutdown will wait for all outstanding TSN to
be acknowledged before sending the SHUTDOWN request. This
never happens due to the peer's zero window not acknowledging
the continuously retransmitted data chunks. Although the
error counter is incremented for each failed retransmission,
the receiving of the SACK announcing the zero window clears
the error count again immediately. Also heartbeat requests
continue to be sent periodically. The peer acknowledges these
requests causing the error counter to be reset as well.
This patch changes behaviour to only reset the overall error
counter for the above rules while not in shutdown. After
reaching the maximum number of retransmission attempts, the
T5 shutdown guard timer is scheduled to give the receiver
some additional time to recover. The timer is stopped as soon
as the receiver acknowledges any data.
The issue can be easily reproduced by establishing a sctp
association over the loopback device, constantly queueing
data at the sender while not reading any at the receiver.
Wait for the window to reach zero, then initiate a shutdown
by killing both processes simultaneously. The association
will never be freed and the chunks on the retransmission
queue will be retransmitted indefinitely.
Signed-off-by: Thomas Graf <tgraf@infradead.org>
diff --git a/include/net/sctp/command.h b/include/net/sctp/command.h
index dd6847e..6506458 100644
--- a/include/net/sctp/command.h
+++ b/include/net/sctp/command.h
@@ -63,6 +63,7 @@ typedef enum {
SCTP_CMD_ECN_ECNE, /* Do delayed ECNE processing. */
SCTP_CMD_ECN_CWR, /* Do delayed CWR processing. */
SCTP_CMD_TIMER_START, /* Start a timer. */
+ SCTP_CMD_TIMER_START_ONCE, /* Start a timer once */
SCTP_CMD_TIMER_RESTART, /* Restart a timer. */
SCTP_CMD_TIMER_STOP, /* Stop a timer. */
SCTP_CMD_INIT_CHOOSE_TRANSPORT, /* Choose transport for an INIT. */
diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
index 1c88c89..d036821 100644
--- a/net/sctp/outqueue.c
+++ b/net/sctp/outqueue.c
@@ -1582,6 +1582,8 @@ static void sctp_check_transmitted(struct sctp_outq *q,
#endif /* SCTP_DEBUG */
if (transport) {
if (bytes_acked) {
+ struct sctp_association *asoc = transport->asoc;
+
/* We may have counted DATA that was migrated
* to this transport due to DEL-IP operation.
* Subtract those bytes, since the were never
@@ -1600,6 +1602,17 @@ static void sctp_check_transmitted(struct sctp_outq *q,
transport->error_count = 0;
transport->asoc->overall_error_count = 0;
+ /*
+ * While in SHUTDOWN PENDING, we may have started
+ * the T5 shutdown guard timer after reaching the
+ * retransmission limit. Stop that timer as soon
+ * as the receiver acknowledged any data.
+ */
+ if (asoc->state == SCTP_STATE_SHUTDOWN_PENDING &&
+ del_timer(&asoc->timers
+ [SCTP_EVENT_TIMEOUT_T5_SHUTDOWN_GUARD]))
+ sctp_association_put(asoc);
+
/* Mark the destination transport address as
* active if it is not so marked.
*/
@@ -1629,10 +1642,15 @@ static void sctp_check_transmitted(struct sctp_outq *q,
* A sender is doing zero window probing when the
* receiver's advertised window is zero, and there is
* only one data chunk in flight to the receiver.
+ *
+ * Allow the association to timeout while in SHUTDOWN
+ * PENDING or SHUTDOWN RECEIVED in case the receiver
+ * stays in zero window mode forever.
*/
if (!q->asoc->peer.rwnd &&
!list_empty(&tlist) &&
- (sack_ctsn+2 == q->asoc->next_tsn)) {
+ (sack_ctsn+2 == q->asoc->next_tsn) &&
+ q->asoc->state < SCTP_STATE_SHUTDOWN_PENDING) {
SCTP_DEBUG_PRINTK("%s: SACK received for zero "
"window probe: %u\n",
__func__, sack_ctsn);
diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
index 534c2e5..6e0f882 100644
--- a/net/sctp/sm_sideeffect.c
+++ b/net/sctp/sm_sideeffect.c
@@ -670,10 +670,19 @@ static void sctp_cmd_transport_on(sctp_cmd_seq_t *cmds,
/* 8.3 Upon the receipt of the HEARTBEAT ACK, the sender of the
* HEARTBEAT should clear the error counter of the destination
* transport address to which the HEARTBEAT was sent.
- * The association's overall error count is also cleared.
*/
t->error_count = 0;
- t->asoc->overall_error_count = 0;
+
+ /*
+ * Although RFC4960 specifies that the overall error count must
+ * be cleared when a HEARTBEAT ACK is received, we make an
+ * exception while in SHUTDOWN PENDING. If the peer keeps its
+ * window shut forever, we may never be able to transmit our
+ * outstanding data and rely on the retransmission limit be reached
+ * to shutdown the association.
+ */
+ if (t->asoc->state != SCTP_STATE_SHUTDOWN_PENDING)
+ t->asoc->overall_error_count = 0;
/* Clear the hb_sent flag to signal that we had a good
* acknowledgement.
@@ -1437,6 +1446,13 @@ static int sctp_cmd_interpreter(sctp_event_t event_type,
sctp_cmd_setup_t2(commands, asoc, cmd->obj.ptr);
break;
+ case SCTP_CMD_TIMER_START_ONCE:
+ timer = &asoc->timers[cmd->obj.to];
+
+ if (timer_pending(timer))
+ break;
+ /* fall through */
+
case SCTP_CMD_TIMER_START:
timer = &asoc->timers[cmd->obj.to];
timeout = asoc->timeouts[cmd->obj.to];
diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
index a297283..2461171 100644
--- a/net/sctp/sm_statefuns.c
+++ b/net/sctp/sm_statefuns.c
@@ -5154,7 +5154,7 @@ sctp_disposition_t sctp_sf_do_9_2_start_shutdown(
* The sender of the SHUTDOWN MAY also start an overall guard timer
* 'T5-shutdown-guard' to bound the overall time for shutdown sequence.
*/
- sctp_add_cmd_sf(commands, SCTP_CMD_TIMER_START,
+ sctp_add_cmd_sf(commands, SCTP_CMD_TIMER_RESTART,
SCTP_TO(SCTP_EVENT_TIMEOUT_T5_SHUTDOWN_GUARD));
if (asoc->autoclose)
@@ -5299,14 +5299,28 @@ sctp_disposition_t sctp_sf_do_6_3_3_rtx(const struct sctp_endpoint *ep,
SCTP_INC_STATS(SCTP_MIB_T3_RTX_EXPIREDS);
if (asoc->overall_error_count >= asoc->max_retrans) {
- sctp_add_cmd_sf(commands, SCTP_CMD_SET_SK_ERR,
- SCTP_ERROR(ETIMEDOUT));
- /* CMD_ASSOC_FAILED calls CMD_DELETE_TCB. */
- sctp_add_cmd_sf(commands, SCTP_CMD_ASSOC_FAILED,
- SCTP_PERR(SCTP_ERROR_NO_ERROR));
- SCTP_INC_STATS(SCTP_MIB_ABORTEDS);
- SCTP_DEC_STATS(SCTP_MIB_CURRESTAB);
- return SCTP_DISPOSITION_DELETE_TCB;
+ if (asoc->state == SCTP_STATE_SHUTDOWN_PENDING) {
+ /*
+ * We are here likely because the receiver had its rwnd
+ * closed for a while and we have not been able to
+ * transmit the locally queued data within the maximum
+ * retransmission attempts limit. Start the T5
+ * shutdown guard timer to give the receiver one last
+ * chance and some additional time to recover before
+ * aborting.
+ */
+ sctp_add_cmd_sf(commands, SCTP_CMD_TIMER_START_ONCE,
+ SCTP_TO(SCTP_EVENT_TIMEOUT_T5_SHUTDOWN_GUARD));
+ } else {
+ sctp_add_cmd_sf(commands, SCTP_CMD_SET_SK_ERR,
+ SCTP_ERROR(ETIMEDOUT));
+ /* CMD_ASSOC_FAILED calls CMD_DELETE_TCB. */
+ sctp_add_cmd_sf(commands, SCTP_CMD_ASSOC_FAILED,
+ SCTP_PERR(SCTP_ERROR_NO_ERROR));
+ SCTP_INC_STATS(SCTP_MIB_ABORTEDS);
+ SCTP_DEC_STATS(SCTP_MIB_CURRESTAB);
+ return SCTP_DISPOSITION_DELETE_TCB;
+ }
}
/* E1) For the destination address for which the timer
diff --git a/net/sctp/sm_statetable.c b/net/sctp/sm_statetable.c
index 0338dc6..7c211a7 100644
--- a/net/sctp/sm_statetable.c
+++ b/net/sctp/sm_statetable.c
@@ -827,7 +827,7 @@ static const sctp_sm_table_entry_t other_event_table[SCTP_NUM_OTHER_TYPES][SCTP_
/* SCTP_STATE_ESTABLISHED */ \
TYPE_SCTP_FUNC(sctp_sf_timer_ignore), \
/* SCTP_STATE_SHUTDOWN_PENDING */ \
- TYPE_SCTP_FUNC(sctp_sf_timer_ignore), \
+ TYPE_SCTP_FUNC(sctp_sf_t5_timer_expire), \
/* SCTP_STATE_SHUTDOWN_SENT */ \
TYPE_SCTP_FUNC(sctp_sf_t5_timer_expire), \
/* SCTP_STATE_SHUTDOWN_RECEIVED */ \
^ permalink raw reply related
* Re: [PATCH V8 2/4 net-next] skbuff: skb supports zero-copy buffers
From: David Miller @ 2011-07-07 11:01 UTC (permalink / raw)
To: mashirle; +Cc: mst, netdev, kvm, linux-kernel
In-Reply-To: <1309990932.10209.19.camel@localhost.localdomain>
From: Shirley Ma <mashirle@us.ibm.com>
Date: Wed, 06 Jul 2011 15:22:12 -0700
> + while (head) {
> + put_page(head);
> + head = (struct page *)head->private;
> + }
Looks like you might be referencing the page after it's
release here. I think you need something like:
while (head) {
struct page *next = (struct page *)head->private;
put_page(head);
head = next;
}
^ permalink raw reply
* Re: [PATCH V8 0/4 net-next] macvtap/vhost TX zero-copy support
From: David Miller @ 2011-07-07 11:08 UTC (permalink / raw)
To: mashirle; +Cc: mst, netdev, kvm, linux-kernel
In-Reply-To: <1309990525.10209.12.camel@localhost.localdomain>
From: Shirley Ma <mashirle@us.ibm.com>
Date: Wed, 06 Jul 2011 15:15:25 -0700
> This patchset add supports for TX zero-copy between guest and host
> kernel through vhost. It significantly reduces CPU utilization on the
> local host on which the guest is located (It reduced about 50% CPU usage
> for single stream test on the host, while 4K message size BW has
> increased about 50%). The patchset is based on previous submission and
> comments from the community regarding when/how to handle guest kernel
> buffers to be released. This is the simplest approach I can think of
> after comparing with several other solutions.
>
> This patchset has integrated V3 review comments from community:
I'm personally fine with this patch set. Unless there are others
who object, please fix the use-after-free bug I reported, respin
the patch set, and I'll apply it.
Thanks.
^ permalink raw reply
* Re: [PATCH] net/fec: gasket needs to be enabled for some i.mx
From: David Miller @ 2011-07-07 11:12 UTC (permalink / raw)
To: shawn.guo
Cc: netdev, s.hauer, troy.kisky, u.kleine-koenig, linux-arm-kernel,
LW
In-Reply-To: <1309515082-7386-1-git-send-email-shawn.guo@linaro.org>
From: Shawn Guo <shawn.guo@linaro.org>
Date: Fri, 1 Jul 2011 18:11:22 +0800
> On the recent i.mx (mx25/50/53), there is a gasket inside fec
> controller which needs to be enabled no matter phy works in MII
> or RMII mode.
>
> The current code enables the gasket only when phy interface is RMII.
> It's broken when the driver works with a MII phy. The patch uses
> platform_device_id to distinguish the SoCs that have the gasket and
> enables it on these SoCs for both MII and RMII mode.
>
> Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH v2] Disable router anycast address for /127 prefixes
From: David Miller @ 2011-07-07 11:15 UTC (permalink / raw)
To: bjorn; +Cc: netdev, shemminger, herbert, brian.haley
In-Reply-To: <1309943053-21437-1-git-send-email-bjorn@mork.no>
From: Bjørn Mork <bjorn@mork.no>
Date: Wed, 6 Jul 2011 11:04:13 +0200
> RFC 6164 requires that routers MUST disable Subnet-Router anycast
> for the prefix when /127 prefixes are used.
>
> No need for matching code in addrconf_leave_anycast() as it
> will silently ignore any attempt to leave an unknown anycast
> address.
>
> Signed-off-by: Bjørn Mork <bjorn@mork.no>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* [PATCH] lib/checksum.c: optimize do_csum a bit
From: Ian Abbott @ 2011-07-07 11:18 UTC (permalink / raw)
To: netdev; +Cc: Ian Abbott, David S. Miller, Arnd Bergmann, linux-kernel
Reduce the number of variables modified by the loop in do_csum() by 1,
which seems like a good idea. On Nios II (a RISC CPU with 3-operand
instruction set) it reduces the loop from 7 to 6 instructions, including
the conditional branch.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
---
lib/checksum.c | 13 +++++--------
1 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/lib/checksum.c b/lib/checksum.c
index 0975087..8df2f91 100644
--- a/lib/checksum.c
+++ b/lib/checksum.c
@@ -49,7 +49,7 @@ static inline unsigned short from32to16(unsigned int x)
static unsigned int do_csum(const unsigned char *buff, int len)
{
- int odd, count;
+ int odd;
unsigned int result = 0;
if (len <= 0)
@@ -64,25 +64,22 @@ static unsigned int do_csum(const unsigned char *buff, int len)
len--;
buff++;
}
- count = len >> 1; /* nr of 16-bit words.. */
- if (count) {
+ if (len >= 2) {
if (2 & (unsigned long) buff) {
result += *(unsigned short *) buff;
- count--;
len -= 2;
buff += 2;
}
- count >>= 1; /* nr of 32-bit words.. */
- if (count) {
+ if (len >= 4) {
+ const unsigned char *end = buff + ((unsigned)len & ~3);
unsigned int carry = 0;
do {
unsigned int w = *(unsigned int *) buff;
- count--;
buff += 4;
result += carry;
result += w;
carry = (w > result);
- } while (count);
+ } while (buff < end);
result += carry;
result = (result & 0xffff) + (result >> 16);
}
--
1.7.6
^ permalink raw reply related
* RE: bnx2: FTQ dump on heavy workload(bnx2-2.0.23b + kernel 2.6.32.36)
From: MaoXiaoyun @ 2011-07-07 11:21 UTC (permalink / raw)
To: mchan, netdev; +Cc: davidch
In-Reply-To: <C27F8246C663564A84BB7AB343977242667C64FA19@IRVEXCHCCR01.corp.ad.broadcom.com>
Hi:
I've added more register to dump.
Hope this helps. Thanks.
---[ end trace cdb56f702ac69a53 ]---
bnx2: <--- start FTQ dump on peth0 --->
bnx2: peth0: BNX2_RV2P_PFTQ_CTL 10000
bnx2: peth0: BNX2_RV2P_TFTQ_CTL 20000
bnx2: peth0: BNX2_RV2P_MFTQ_CTL 4000
bnx2: peth0: BNX2_TBDR_FTQ_CTL 1004002
bnx2: peth0: BNX2_TDMA_FTQ_CTL 4010002
bnx2: peth0: BNX2_TXP_FTQ_CTL 4010002
bnx2: peth0: BNX2_TPAT_FTQ_CTL 10002
bnx2: peth0: BNX2_RXP_CFTQ_CTL 8000
bnx2: peth0: BNX2_RXP_FTQ_CTL 100000
bnx2: peth0: BNX2_COM_COMXQ_FTQ_CTL 10000
bnx2: peth0: BNX2_COM_COMTQ_FTQ_CTL 20000
bnx2: peth0: BNX2_COM_COMQ_FTQ_CTL 10000
bnx2: peth0: BNX2_CP_CPQ_FTQ_CTL 4000
bnx2: peth0: TXP mode b84c state 80005000 evt_mask 500 pc 8000758 pc 8000758 instr 8fa90030
bnx2: peth0: TPAT mode b84c state 80001000 evt_mask 500 pc 8000a4c pc 8000a5c instr 10400016
bnx2: peth0: RXP mode b84c state 80001000 evt_mask 500 pc 8004c20 pc 8004c10 instr 32050003
bnx2: peth0: COM mode b8cc state 80000000 evt_mask 500 pc 8000a98 pc 8000a94 instr 8821
bnx2: peth0: CP mode b8cc state 80004000 evt_mask 500 pc 8000ca8 pc 8000920 instr 8f890014
bnx2: <--- end FTQ dump on peth0 --->
bnx2: <--- start extra FTQ dump on peth0 --->
bnx2: peth0: BNX2_TBDR_STATUS 42
bnx2: peth0: BNX2_TBDR_CONFIG 4000040
bnx2: peth0: BNX2_TBDR_DEBUG_VECT_PEEK 70007
bnx2: peth0: BNX2_TBDR_CKSUM_ERROR_STATUS 0
bnx2: peth0: BNX2_TBDR_TBDRQ 0
bnx2: peth0: BNX2_TDMA_STATUS 420000
bnx2: peth0: BNX2_TDMA_CONFIG 310088c
bnx2: peth0: BNX2_TDMA_PAYLOAD_PROD 9480
bnx2: peth0: BNX2_TDMA_DMAD_STATUS 0
bnx2: peth0: BNX2_TDMA_DR_INTF_FSM 0
bnx2: peth0: BNX2_TDMA_DR_INTF_STATUS 0
bnx2: peth0: BNX2_TDMA_TDMAQ 0
bnx2: peth0: BNX2_TXP_CPU_MODE b84c
bnx2: peth0: BNX2_TXP_CPU_STATE 80005000
bnx2: peth0: BNX2_TXP_CPU_EVENT_MASK 500
bnx2: peth0: BNX2_TXP_SCRATCH a00002a
bnx2: peth0: BNX2_TXP_CPU_REG_FILE 8007f6c
bnx2: peth0: BNX2_TXP_TXPQ 0
bnx2: peth0: BNX2_TPAT_CPU_MODE b84c
bnx2: peth0: BNX2_TPAT_CPU_STATE 80001000
bnx2: peth0: BNX2_TPAT_CPU_EVENT_MASK 500
bnx2: peth0: BNX2_TPAT_CPU_PROGRAM_COUNTER 8000a54
bnx2: peth0: BNX2_TPAT_TPATQ 0
bnx2: peth0: BNX2_TPAT_SCRATCH0
bnx2: <--- end extra FTQ dump on peth0 --->
bnx2: peth0 DEBUG: intr_sem[0]
bnx2: peth0 DEBUG: intr_sem[0] PCI_CMD[20100406]
bnx2: peth0 DEBUG: PCI_PM[19002008] PCI_MISC_CFG[92000088]
bnx2: peth0 DEBUG: EMAC_TX_STATUS[00000008] EMAC_RX_STATUS[00000000]
bnx2: peth0 RPM_MGMT_PKT_CTRL[40000088]
bnx2: peth0 DEBUG: MCP_STATE_P0[0007e10e] MCP_STATE_P1[0003e00e]
bnx2: peth0 DEBUG: HC_STATS_INTERRUPT_STATUS[01ff0000]
bnx2: peth0 DEBUG: PBA[00000000]
BNX2_PCICFG_INT_ACK_CMD[0401f8d4]
bnx2: peth0: prevent chip reset during tx timeout
last status idx 34554
hw_tx_cons 60308, txr->hw_tx_conds 60308 txr->tx_prod 60429 txr->tx_cons 60301
hw_rx_cons 19366, txr->hw_rx_conds 19366
sblk->status_attn_bits 1
sblk->status_attn_bits_ack 1
bnx2_tx_avail 127
sblk->status_tx_quick_consumer_index0 60308
sblk->status_tx_quick_consumer_index1 0
sblk->status_tx_quick_consumer_index2 0
sblk->status_tx_quick_consumer_index3 0
sblk->status_rx_quick_consumer_index0 19366
sblk->status_rx_quick_consumer_index1 0
sblk->status_rx_quick_consumer_index2 0
sblk->status_rx_quick_consumer_index3 0
sblk->status_rx_quick_consumer_index4 0
sblk->status_rx_quick_consumer_index5 0
sblk->status_rx_quick_consumer_index6 0
sblk->status_rx_quick_consumer_index7 0
sblk->status_rx_quick_consumer_index8 0
sblk->status_rx_quick_consumer_index9 0
sblk->status_rx_quick_consumer_index10 0
sblk->status_rx_quick_consumer_index11 0
sblk->status_rx_quick_consumer_index12 0
sblk->status_rx_quick_consumer_index13 0
sblk->status_rx_quick_consumer_index14 0
sblk->status_rx_quick_consumer_index15 0
sblk->status_completion_producer_index 0
sblk->status_cmd_consumer_index 0
sblk->status_idx 34554
sblk->status_unused 0
sblk->status_blk_num 0
> From: mchan@broadcom.com
> To: tinnycloud@hotmail.com; netdev@vger.kernel.org
> CC: davidch@broadcom.com
> Date: Mon, 4 Jul 2011 10:04:25 -0700
> Subject: Re: bnx2: FTQ dump on heavy workload(bnx2-2.0.23b + kernel 2.6.32.36)
>
> MaoXiaoyun wrote:
>
> > Could it be caused by the similar timeout as
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-
> > 2.6.git;a=commit;h=c441b8d2cb2194b05550a558d6d95d8944e56a84.
>
> Based on the register dump below, it is not caused by the MSI-X issue.
>
> >
> > Maybe timeout still happens in my test scenerino.
> >
> > Well, from the patch, BNX2_MISC_ECO_HW_CTL is defined 0x000008cc. But I
> > cannot find
> > the defines in programmer reference Guide.(NetXtremeII-PG203-R.pdf).
> > Could some help
> > to point out for me or is the doc is out of date.
>
> I will request the document to be updated to describe that register. We
> are increasing the register read and write timeout value to workaround
> the problem of the MSI-X table being updated while there is a pending
> MSI-X. Without the patch, the write to unmask the MSI-X table entry can
> be dropped by the chip.
>
> >
> > Also, is there a way to comfirm whether the timeout really happen?
> > (which regisiter
> > shall I read?) Or is there a bigger timeout I can set?
>
> Again, the register dump shows that it is not caused by this issue. I'll
> send you some additional debug patch to try to debug the problem.
>
> Thanks.
> >
> > thanks.
> >
> > ----------------------------------------
> > > From: tinnycloud@hotmail.com
> > > To: netdev@vger.kernel.org
> > > Subject: bnx2: FTQ dump on heavy workload(bnx2-2.0.23b + kernel
> > 2.6.32.36)
> > > Date: Mon, 4 Jul 2011 15:40:01 +0800
> > >
> > >
> > > Hi:
> > >
> > > I met bnx2 FTQ dump over and over again during my testing on Xen live
> > migration which generate
> > > heavy network workload.
> > >
> > > I have two physcial machine, both have xen 4.0.1 installed, and
> > kernel 2.6.32.36, bnx2 2.0.23b.
> > > I start 15 Virtual Machines totoally, and doing migration between the
> > host over and over again,
> > > about 16hours, the network will not work, and sometimes, it can reset
> > successfully, sometimes, it
> > > cause kernel crash.
> > >
> > > I've tried debug some, add code in the driver. below is the code when
> > FTQ happened.
> > > It looks like the NIC is stop transmit the packets, and cause
> > timeout.
> > >
> > > BTW, cpu max_cstate=1 in my grub.
> > >
> > > Thanks.
> > >
> > > --------------
> > > static void
> > > bnx2_tx_timeout(struct net_device *dev)
> > > {
> > > struct bnx2 *bp = netdev_priv(dev);
> > > struct bnx2_napi *bnapi = &bp->bnx2_napi[0];
> > > struct bnx2_tx_ring_info *txr = &bnapi->tx_ring;
> > > struct bnx2_rx_ring_info *rxr = &bnapi->rx_ring;
> > > int i ;
> > > bnx2_dump_ftq(bp);
> > > bnx2_dump_state(bp);
> > > if (stop_on_tx_timeout) {
> > > printk(KERN_WARNING PFX
> > > "%s: prevent chip reset during tx timeout\n",
> > > bp->dev->name);
> > > smp_rmb();
> > > printk("last status idx %d \n", bnapi->last_status_idx);
> > > printk("hw_tx_cons %d, txr->hw_tx_conds %d txr->tx_prod %d txr-
> > >tx_cons %d\n",
> > > bnx2_get_hw_tx_cons(bnapi), txr->hw_tx_cons, txr->tx_prod, txr-
> > >tx_cons);
> > > printk("hw_rx_cons %d, txr->hw_rx_conds %d\n",
> > bnx2_get_hw_rx_cons(bnapi), rxr->rx_cons);
> > > printk("sblk->status_attn_bits %d\n",bnapi->status_blk.msi-
> > >status_attn_bits);
> > > printk("sblk->status_attn_bits_ack %d\n",bnapi->status_blk.msi-
> > >status_attn_bits_ack);
> > > printk("bnx2_tx_avail %d \n",(bnx2_tx_avail(bp, txr)));
> > > printk("sblk->status_tx_quick_consumer_index0 %d\n",bnapi-
> > >status_blk.msi->status_tx_quick_consumer_index0);
> > > printk("sblk->status_tx_quick_consumer_index1 %d\n",bnapi-
> > >status_blk.msi->status_tx_quick_consumer_index1);
> > > printk("sblk->status_tx_quick_consumer_index2 %d\n",bnapi-
> > >status_blk.msi->status_tx_quick_consumer_index2);
> > > printk("sblk->status_tx_quick_consumer_index3 %d\n",bnapi-
> > >status_blk.msi->status_tx_quick_consumer_index3);
> > > printk("sblk->status_rx_quick_consumer_index0 %d\n",bnapi-
> > >status_blk.msi->status_rx_quick_consumer_index0);
> > > printk("sblk->status_rx_quick_consumer_index1 %d\n",bnapi-
> > >status_blk.msi->status_rx_quick_consumer_index1);
> > > printk("sblk->status_rx_quick_consumer_index2 %d\n",bnapi-
> > >status_blk.msi->status_rx_quick_consumer_index2);
> > > printk("sblk->status_rx_quick_consumer_index3 %d\n",bnapi-
> > >status_blk.msi->status_rx_quick_consumer_index3);
> > > printk("sblk->status_rx_quick_consumer_index4 %d\n",bnapi-
> > >status_blk.msi->status_rx_quick_consumer_index4);
> > > printk("sblk->status_rx_quick_consumer_index5 %d\n",bnapi-
> > >status_blk.msi->status_rx_quick_consumer_index5);
> > > printk("sblk->status_rx_quick_consumer_index6 %d\n",bnapi-
> > >status_blk.msi->status_rx_quick_consumer_index6);
> > > printk("sblk->status_rx_quick_consumer_index7 %d\n",bnapi-
> > >status_blk.msi->status_rx_quick_consumer_index7);
> > > printk("sblk->status_rx_quick_consumer_index8 %d\n",bnapi-
> > >status_blk.msi->status_rx_quick_consumer_index8);
> > > printk("sblk->status_rx_quick_consumer_index9 %d\n",bnapi-
> > >status_blk.msi->status_rx_quick_consumer_index9);
> > > printk("sblk->status_rx_quick_consumer_index10 %d\n",bnapi-
> > >status_blk.msi->status_rx_quick_consumer_index10);
> > > printk("sblk->status_rx_quick_consumer_index11 %d\n",bnapi-
> > >status_blk.msi->status_rx_quick_consumer_index11);
> > > printk("sblk->status_rx_quick_consumer_index12 %d\n",bnapi-
> > >status_blk.msi->status_rx_quick_consumer_index12);
> > > printk("sblk->status_rx_quick_consumer_index13 %d\n",bnapi-
> > >status_blk.msi->status_rx_quick_consumer_index13);
> > > printk("sblk->status_rx_quick_consumer_index14 %d\n",bnapi-
> > >status_blk.msi->status_rx_quick_consumer_index14);
> > > printk("sblk->status_rx_quick_consumer_index15 %d\n",bnapi-
> > >status_blk.msi->status_rx_quick_consumer_index15);
> > > printk("sblk->status_completion_producer_index %d\n",bnapi-
> > >status_blk.msi->status_completion_producer_index);
> > > printk("sblk->status_cmd_consumer_index %d\n",bnapi->status_blk.msi-
> > >status_cmd_consumer_index);
> > > printk("sblk->status_idx %d\n",bnapi->status_blk.msi->status_idx);
> > > printk("sblk->status_unused %d\n",bnapi->status_blk.msi-
> > >status_unused);
> > > printk("sblk->status_blk_num %d\n",bnapi->status_blk.msi-
> > >status_blk_num);
> > > is_timedout = 1;
> > > for (i = 0; i < bp->irq_nvecs; i++) {
> > > bnapi = &bp->bnx2_napi[i];
> > > bnx2_tx_int(bp, bnapi, 0);
> > > }
> > > return;
> > > }
> > > -----------------
> > >
> > > -------------FTQ log in /var/log/message
> > > ------------[ cut here ]------------
> > > WARNING: at net/sched/sch_generic.c:261 dev_watchdog+0x105/0x16a()
> > > Hardware name: Tecal RH2285
> > > Modules linked in: iptable_filter ip_tables nfs fscache nfs_acl
> > auth_rpcgss bridge stp llc autofs4 ipmi_devintf ipmi_si ipmi_msghandler
> > lockd sunrpc ipv6 xenfs dm_multipath fuse xen_netback xen_blkback
> > blktap blkback_pagemap loop nbd video output sbs sbshc parport_pc lp
> > parport snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq
> > snd_seq_device snd_pcm_oss snd_mixer_oss bnx2 serio_raw snd_pcm
> > snd_timer snd soundcore snd_page_alloc i2c_i801 iTCO_wdt
> > iTCO_vendor_support i2c_core pata_acpi ata_generic pcspkr ata_piix
> > shpchp mptsas mptscsih mptbase [last unloaded: freq_table]
> > > Pid: 0, comm: swapper Not tainted 2.6.32.36xen #1
> > > Call Trace:
> > > <IRQ> [<ffffffff813ba154>] ? dev_watchdog+0x105/0x16a
> > > [<ffffffff81056666>] warn_slowpath_common+0x7c/0x94
> > > [<ffffffff81056738>] warn_slowpath_fmt+0xa4/0xa6
> > > [<ffffffff81080bfa>] ? clockevents_program_event+0x78/0x81
> > > [<ffffffff81081fce>] ? tick_program_event+0x2a/0x2c
> > > [<ffffffff813b951d>] ? __netif_tx_lock+0x1b/0x24
> > > [<ffffffff813b95a8>] ? netif_tx_lock+0x46/0x6e
> > > [<ffffffff813a3ed1>] ? netdev_drivername+0x48/0x4f
> > > [<ffffffff813ba154>] dev_watchdog+0x105/0x16a
> > > [<ffffffff81063d98>] run_timer_softirq+0x156/0x1f8
> > > [<ffffffff813ba04f>] ? dev_watchdog+0x0/0x16a
> > > [<ffffffff8105d6f0>] __do_softirq+0xd7/0x19e
> > > [<ffffffff81013eac>] call_softirq+0x1c/0x30
> > > [<ffffffff8101564b>] do_softirq+0x46/0x87
> > > [<ffffffff8105d575>] irq_exit+0x3b/0x7a
> > > [<ffffffff8128dcfe>] xen_evtchn_do_upcall+0x38/0x46
> > > [<ffffffff81013efe>] xen_do_hypervisor_callback+0x1e/0x30
> > > <EOI> [<ffffffff8103f642>] ? pick_next_task_idle+0x18/0x22
> > > [<ffffffff810093aa>] ? hypercall_page+0x3aa/0x1000
> > > [<ffffffff810093aa>] ? hypercall_page+0x3aa/0x1000
> > > [<ffffffff8100f1bb>] ? xen_safe_halt+0x10/0x1a
> > > [<ffffffff81019e14>] ? default_idle+0x39/0x56
> > > [<ffffffff81011cd0>] ? cpu_idle+0x5d/0x8c
> > > [<ffffffff8143375d>] ? cpu_bringup_and_idle+0x13/0x15
> > > ---[ end trace 867bb8f6cd959b03 ]---
> > > bnx2: <--- start FTQ dump on peth0 --->
> > > bnx2: peth0: BNX2_RV2P_PFTQ_CTL 10000
> > > bnx2: peth0: BNX2_RV2P_TFTQ_CTL 20000
> > > bnx2: peth0: BNX2_RV2P_MFTQ_CTL 4000
> > > bnx2: peth0: BNX2_TBDR_FTQ_CTL 1004002
> > > bnx2: peth0: BNX2_TDMA_FTQ_CTL 4010002
> > > bnx2: peth0: BNX2_TXP_FTQ_CTL 2410002
> > > bnx2: peth0: BNX2_TPAT_FTQ_CTL 10002
> > > bnx2: peth0: BNX2_RXP_CFTQ_CTL 8000
> > > bnx2: peth0: BNX2_RXP_FTQ_CTL 100000
> > > bnx2: peth0: BNX2_COM_COMXQ_FTQ_CTL 10000
> > > bnx2: peth0: BNX2_COM_COMTQ_FTQ_CTL 20000
> > > bnx2: peth0: BNX2_COM_COMQ_FTQ_CTL 10000
> > > bnx2: peth0: BNX2_CP_CPQ_FTQ_CTL 4000
> > > bnx2: peth0: TXP mode b84c state 80005000 evt_mask 500 pc 8000d60 pc
> > 8000d60 instr 8f860000
> > > bnx2: peth0: TPAT mode b84c state 80009000 evt_mask 500 pc 8000a5c pc
> > 8000a5c instr 10400016
> > > bnx2: peth0: RXP mode b84c state 80001000 evt_mask 500 pc 8004c14 pc
> > 8004c14 instr 10e00088
> > > bnx2: peth0: COM mode b8cc state 80000000 evt_mask 500 pc 8000b28 pc
> > 8000a9c instr 8c530000
> > > bnx2: peth0: CP mode b8cc state 80000000 evt_mask 500 pc 8000c50 pc
> > 8000c58 instr 8ca50020
> > > bnx2: <--- end FTQ dump on peth0 --->
> > > bnx2: peth0 DEBUG: intr_sem[0]
> > > bnx2: peth0 DEBUG: intr_sem[0] PCI_CMD[20100406]
> > > bnx2: peth0 DEBUG: PCI_PM[19002008] PCI_MISC_CFG[92000088]
> > > bnx2: peth0 DEBUG: EMAC_TX_STATUS[00000008] EMAC_RX_STATUS[00000000]
> > > bnx2: peth0 RPM_MGMT_PKT_CTRL[40000088]
> > > bnx2: peth0 DEBUG: MCP_STATE_P0[0007e10e] MCP_STATE_P1[0003e00e]
> > > bnx2: peth0 DEBUG: HC_STATS_INTERRUPT_STATUS[01ff0000]
> > > bnx2: peth0 DEBUG: PBA[00000000]
> > > BNX2_PCICFG_INT_ACK_CMD[00013ce1]
> > > bnx2: peth0: prevent chip reset during tx timeout
> > > last status idx 2426
> > > hw_tx_cons 32474, txr->hw_tx_conds 32474 txr->tx_prod 32641 txr-
> > >tx_cons 32474
> > > hw_rx_cons 19665, txr->hw_rx_conds 19665
> > > sblk->status_attn_bits 1
> > > sblk->status_attn_bits_ack 1
> > > bnx2_tx_avail 88
> > > sblk->status_tx_quick_consumer_index0 32474
> > > sblk->status_tx_quick_consumer_index1 0
> > > sblk->status_tx_quick_consumer_index2 0
> > > sblk->status_tx_quick_consumer_index3 0
> > > sblk->status_rx_quick_consumer_index0 19665
> > > sblk->status_rx_quick_consumer_index1 0
> > > sblk->status_rx_quick_consumer_index2 0
> > > sblk->status_rx_quick_consumer_index3 0
> > > sblk->status_rx_quick_consumer_index4 0
> > > sblk->status_rx_quick_consumer_index5 0
> > > sblk->status_rx_quick_consumer_index6 0
> > > sblk->status_rx_quick_consumer_index7 0
> > > sblk->status_rx_quick_consumer_index8 0
> > > sblk->status_rx_quick_consumer_index9 0
> > > sblk->status_rx_quick_consumer_index10 0
> > > sblk->status_rx_quick_consumer_index11 0
> > > sblk->status_rx_quick_consumer_index12 0
> > > sblk->status_rx_quick_consumer_index13 0
> > > sblk->status_rx_quick_consumer_index14 0
> > > sblk->status_rx_quick_consumer_index15 0
> > > sblk->status_completion_producer_index 0
> > > sblk->status_cmd_consumer_index 0
> > > sblk->status_idx 2426
> > > sblk->status_unused 0
> > > sblk->status_blk_num 0
> > > hw_cons 32474 sw_cons 32474 ffff8801d27f85c0 bnapi
> > > return hw_cons 32474 sw_cons 32474 ffff8801d27f85c0 bnapi
> > > hw_cons 3628 sw_cons 3625 ffff8801d27f8bc0 bnapi
> > > return hw_cons 3628 sw_cons 3625 ffff8801d27f8bc0 bnapi
> > > hw_cons 62094 sw_cons 62090 ffff8801d27f91c0 bnapi
> > > return hw_cons 62094 sw_cons 62090 ffff8801d27f91c0 bnapi
> > > hw_cons 3184 sw_cons 3173 ffff8801d27f97c0 bnapi
> > > return hw_cons 3184 sw_cons 3173 ffff8801d27f97c0 bnapi
> > > hw_cons 0 sw_cons 0 ffff8801d27f9dc0 bnapi
> > > return hw_cons 0 sw_cons 0 ffff8801d27f9dc0 bnapi
> >
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] gianfar v2: code cleanups
From: Sebastian Pöhn @ 2011-07-07 11:22 UTC (permalink / raw)
To: Linux Netdev; +Cc: Sebastian Pöhn
This patch:
# improves readability of some gianfar nfc code
> Your email client has corrupted this patch, breaking up long
> lines, etc.
Sorry for that!
Signed-off-by: Sebastian Poehn <sebastian.poehn@belden.com>
---
drivers/net/gianfar.h | 1 +
drivers/net/gianfar_ethtool.c | 52 ++++++++++++++++++++++-------------------
2 files changed, 29 insertions(+), 24 deletions(-)
diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
index 76f14d0..27499c6 100644
--- a/drivers/net/gianfar.h
+++ b/drivers/net/gianfar.h
@@ -409,6 +409,7 @@ extern const char gfar_driver_version[];
#define RQFCR_HASHTBL_2 0x00060000
#define RQFCR_HASHTBL_3 0x00080000
#define RQFCR_HASH 0x00010000
+#define RQFCR_QUEUE 0x0000FC00
#define RQFCR_CLE 0x00000200
#define RQFCR_RJE 0x00000100
#define RQFCR_AND 0x00000080
diff --git a/drivers/net/gianfar_ethtool.c b/drivers/net/gianfar_ethtool.c
index 2ecdc9a..203369c 100644
--- a/drivers/net/gianfar_ethtool.c
+++ b/drivers/net/gianfar_ethtool.c
@@ -40,6 +40,7 @@
#include <linux/mii.h>
#include <linux/phy.h>
#include <linux/sort.h>
+#include <linux/if_vlan.h>
#include "gianfar.h"
@@ -883,7 +884,7 @@ static void gfar_set_attribute(u32 value, u32 mask, u32 flag,
struct filer_table *tab)
{
switch (flag) {
- /* 3bit */
+ /* 3bit */
case RQFCR_PID_PRI:
if (!(value | mask))
return;
@@ -1051,17 +1052,17 @@ static int gfar_convert_to_filer(struct ethtool_rx_flow_spec *rule,
vlan_mask = RQFPR_VLN;
/* Separate the fields */
- id = rule->h_ext.vlan_tci & 0xFFF;
- id_mask = rule->m_ext.vlan_tci & 0xFFF;
- cfi = (rule->h_ext.vlan_tci >> 12) & 1;
- cfi_mask = (rule->m_ext.vlan_tci >> 12) & 1;
- prio = (rule->h_ext.vlan_tci >> 13) & 0x7;
- prio_mask = (rule->m_ext.vlan_tci >> 13) & 0x7;
-
- if (cfi == 1 && cfi_mask == 1) {
+ id = rule->h_ext.vlan_tci & VLAN_VID_MASK;
+ id_mask = rule->m_ext.vlan_tci & VLAN_VID_MASK;
+ cfi = rule->h_ext.vlan_tci & VLAN_CFI_MASK;
+ cfi_mask = rule->m_ext.vlan_tci & VLAN_CFI_MASK;
+ prio = (rule->h_ext.vlan_tci & VLAN_PRIO_MASK) >> VLAN_PRIO_SHIFT;
+ prio_mask = (rule->m_ext.vlan_tci & VLAN_PRIO_MASK) >> VLAN_PRIO_SHIFT;
+
+ if (cfi == VLAN_TAG_PRESENT && cfi_mask == VLAN_TAG_PRESENT) {
vlan |= RQFPR_CFI;
vlan_mask |= RQFPR_CFI;
- } else if (cfi == 0 && cfi_mask == 1) {
+ } else if (cfi != VLAN_TAG_PRESENT && cfi_mask == VLAN_TAG_PRESENT) {
vlan_mask |= RQFPR_CFI;
}
}
@@ -1262,21 +1263,21 @@ static void gfar_cluster_filer(struct filer_table *tab)
}
}
-/* Swaps the 0xFF80 masked bits of a1<>a2 and b1<>b2 */
-static void gfar_swap_ff80_bits(struct gfar_filer_entry *a1,
+/* Swaps the masked bits of a1<>a2 and b1<>b2 */
+static void gfar_swap_bits(struct gfar_filer_entry *a1,
struct gfar_filer_entry *a2, struct gfar_filer_entry *b1,
- struct gfar_filer_entry *b2)
+ struct gfar_filer_entry *b2, u32 mask)
{
u32 temp[4];
- temp[0] = a1->ctrl & 0xFF80;
- temp[1] = a2->ctrl & 0xFF80;
- temp[2] = b1->ctrl & 0xFF80;
- temp[3] = b2->ctrl & 0xFF80;
+ temp[0] = a1->ctrl & mask;
+ temp[1] = a2->ctrl & mask;
+ temp[2] = b1->ctrl & mask;
+ temp[3] = b2->ctrl & mask;
- a1->ctrl &= ~0xFF80;
- a2->ctrl &= ~0xFF80;
- b1->ctrl &= ~0xFF80;
- b2->ctrl &= ~0xFF80;
+ a1->ctrl &= ~mask;
+ a2->ctrl &= ~mask;
+ b1->ctrl &= ~mask;
+ b2->ctrl &= ~mask;
a1->ctrl |= temp[1];
a2->ctrl |= temp[0];
@@ -1305,7 +1306,7 @@ static u32 gfar_generate_mask_table(struct gfar_mask_entry *mask_table,
mask_table[and_index - 1].end = i - 1;
and_index++;
}
- /* cluster starts will be separated because they should
+ /* cluster starts and ends will be separated because they should
* hold their position */
if (tab->fe[i].ctrl & RQFCR_CLE)
block_index++;
@@ -1356,10 +1357,13 @@ static void gfar_sort_mask_table(struct gfar_mask_entry *mask_table,
new_first = mask_table[start].start + 1;
new_last = mask_table[i - 1].end;
- gfar_swap_ff80_bits(&temp_table->fe[new_first],
+ gfar_swap_bits(&temp_table->fe[new_first],
&temp_table->fe[old_first],
&temp_table->fe[new_last],
- &temp_table->fe[old_last]);
+ &temp_table->fe[old_last],
+ RQFCR_QUEUE | RQFCR_CLE |
+ RQFCR_RJE | RQFCR_AND
+ );
start = i;
size = 0;
^ permalink raw reply related
* Re: [PATCH] lib/checksum.c: optimize do_csum a bit
From: David Miller @ 2011-07-07 11:29 UTC (permalink / raw)
To: abbotti; +Cc: netdev, arnd, linux-kernel
In-Reply-To: <1310037529-30854-1-git-send-email-abbotti@mev.co.uk>
From: Ian Abbott <abbotti@mev.co.uk>
Date: Thu, 7 Jul 2011 12:18:49 +0100
> Reduce the number of variables modified by the loop in do_csum() by 1,
> which seems like a good idea. On Nios II (a RISC CPU with 3-operand
> instruction set) it reduces the loop from 7 to 6 instructions, including
> the conditional branch.
>
> Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
I think you'll overshoot past the end of the buffer when there are
trailing bytes to handle.
The whole reason we need the count variable is to handle those
kinds of cases.
^ permalink raw reply
* Re: [PATCH] gianfar v2: code cleanups
From: David Miller @ 2011-07-07 11:30 UTC (permalink / raw)
To: sebastian.belden; +Cc: netdev, sebastian.poehn
In-Reply-To: <1310037749.3410.5.camel@DENEC1DT0191>
From: "Sebastian Pöhn" <sebastian.belden@googlemail.com>
Date: Thu, 07 Jul 2011 13:22:29 +0200
> This patch:
> # improves readability of some gianfar nfc code
>
>> Your email client has corrupted this patch, breaking up long
>> lines, etc.
> Sorry for that!
>
> Signed-off-by: Sebastian Poehn <sebastian.poehn@belden.com>
Applied, thanks.
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2011-07-07 11:32 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) iwl_tx_queue_reset() doesn't clear out the right number of slots,
fix from Emmanuel Grumbach.
2) DMA buffer leak in iwlagn, fix from Johannes Berg.
3) iwlwifi command buffers need to be DMA mapped as "bidirectional" as
the chip can write back to them sometimes, fix from Johannes Berg.
4) Fix OOPS in mac80211 on MIC failure, from Arik Nemtsov.
5) Fix lost power up during resume in ath9k, from Rajkumar Manoharan.
6) Memory leak in ath5k, fix from Bob Copeland.
7) 6pack/mkiss need to use BH locking, fix from Arnd Bergmann.
8) Get rid of artificial ipv6 routing table size limits, this is
hitting real people now.
9) Don't send ICMP errors on local socket created MTU events. Fix
from Steffen Klassert.
10) Fix mailbox execution crash in qlge, from Jitendra Kalsaria.
11) Fix mixup between "spin_lock_irqsave()" flags and flags
passed to request_irq in bna driver, fix from Shyam Iyer.
12) vlan_features not set properly in 8139too, from Shan Wei.
13) Fix DMA unmap length in natsemi, from FUJITA Tomonori.
14) Use more POSIX'ly correct when wrong address family is used
during ipv4 bind(). From Marcus Meissner.
15) Fix MAC address setting in greth driver, from Kristoffer Glembo.
16) Regression fix, have to always flood broadcasts on bridge. Fix
from Herbert Xu.
17) Global memory limits of TCP/UDP/SCTP are miscalculated when lots
of hugepages are reserved. Fix from Eric Dumazet.
18) SCTP_SENDER_DRY_EVENT are not always sent when they should be, fix
from Wei Yongjun.
Please pull, thanks a lot!
The following changes since commit 4dd1b49c6d215dc41ce50c80b4868388b93f31a3:
Merge branch 'gpio/merge' of git://git.secretlab.ca/git/linux-2.6 (2011-07-06 18:36:53 -0700)
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
Arik Nemtsov (1):
mac80211: fix rx->key NULL dereference during mic failure
Arnd Bergmann (1):
6pack,mkiss: fix lock inconsistency
David S. Miller (3):
Merge branch 'for-davem' of git://git.kernel.org/.../linville/wireless-2.6
ipv6: Don't change dst->flags using assignments.
ipv6: Don't put artificial limit on routing table size.
Emmanuel Grumbach (1):
iwlagn: Fix a bug introduced by the HUGE command removal
Eric Dumazet (1):
net: refine {udp|tcp|sctp}_mem limits
Eugene A. Shatokhin (1):
ath5k: fix memory leak when fewer than N_PD_CURVES are in use
Evgeni Golov (1):
iwlagn: fix *_UCODE_API_MAX output in the firmware field
FUJITA Tomonori (1):
natsemi: silence dma-debug warnings
Herbert Xu (1):
bridge: Always flood broadcast packets
Jitendra Kalsaria (3):
qlge:Fix crash caused by mailbox execution on wedged chip.
qlge: Fix printk priority so chip fatal errors are always reported.
qlge:Version change to v1.00.00.29
Johannes Berg (3):
iwlagn: fix change_interface for P2P types
iwlagn: fix cmd queue unmap
iwlagn: map command buffers BIDI
John W. Linville (3):
Merge branch 'wireless-2.6' of git://git.kernel.org/.../iwlwifi/iwlwifi-2.6
iwlagn: use PCI_DMA_* for pci_* operations
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6 into for-davem
Kristoffer Glembo (1):
greth: greth_set_mac_add would corrupt the MAC address.
Marcus Meissner (1):
net: bind() fix error return on wrong address family
Rajkumar Manoharan (1):
ath9k: Fix suspend/resume when no interface is UP
Shan Wei (2):
net: 8139too: Initial necessary vlan_features to support vlan
net: vlan: enable soft features regardless of underlying device
Shreyas Bhatewara (2):
vmxnet3: fix starving rx ring whenoc_skb kb fails
vmxnet3: round down # of queues to power of two
Shyam Iyer (1):
Fix call trace when interrupts are disabled while sleeping function kzalloc is called
Steffen Klassert (3):
xfrm: Remove family arg from xfrm_bundle_ok
ipv4: Don't use ufo handling on later transformed packets
xfrm4: Don't call icmp_send on local error
Wei Yongjun (1):
sctp: fix missing send up SCTP_SENDER_DRY_EVENT when subscribe it
Yoshihiro Shimoda (2):
net: sh_eth: fix cannot work half-duplex mode
net: sh_eth: fix the parameter for the ETHER of SH7757
drivers/net/8139too.c | 1 +
drivers/net/bna/bnad.c | 7 +-
drivers/net/greth.c | 7 +-
drivers/net/hamradio/6pack.c | 4 +-
drivers/net/hamradio/mkiss.c | 4 +-
drivers/net/natsemi.c | 3 +-
drivers/net/qlge/qlge.h | 3 +-
drivers/net/qlge/qlge_main.c | 42 ++++++----
drivers/net/sh_eth.c | 6 +-
drivers/net/vmxnet3/vmxnet3_drv.c | 138 ++++++++++++++++++++++---------
drivers/net/vmxnet3/vmxnet3_int.h | 5 +-
drivers/net/wireless/ath/ath5k/eeprom.c | 8 +-
drivers/net/wireless/ath/ath9k/pci.c | 6 ++
drivers/net/wireless/iwlwifi/iwl-1000.c | 5 +-
drivers/net/wireless/iwlwifi/iwl-2000.c | 7 +-
drivers/net/wireless/iwlwifi/iwl-5000.c | 5 +-
drivers/net/wireless/iwlwifi/iwl-6000.c | 9 +-
drivers/net/wireless/iwlwifi/iwl-core.c | 3 +-
drivers/net/wireless/iwlwifi/iwl-tx.c | 25 ++----
include/net/cfg80211.h | 2 +-
include/net/dst.h | 1 +
net/8021q/vlan_dev.c | 5 +
net/bridge/br_device.c | 4 +-
net/bridge/br_input.c | 6 +-
net/core/dst.c | 6 +-
net/ipv4/af_inet.c | 4 +-
net/ipv4/ip_output.c | 2 +-
net/ipv4/tcp.c | 10 +--
net/ipv4/udp.c | 10 +--
net/ipv4/xfrm4_output.c | 7 ++-
net/ipv6/af_inet6.c | 2 +-
net/ipv6/route.c | 25 ++----
net/mac80211/wpa.c | 8 ++-
net/sctp/protocol.c | 11 +--
net/sctp/socket.c | 23 +++++
net/wireless/nl80211.c | 3 +-
net/xfrm/xfrm_policy.c | 6 +-
37 files changed, 257 insertions(+), 166 deletions(-)
^ permalink raw reply
* Re: [PATCH] lib/checksum.c: optimize do_csum a bit
From: Ian Abbott @ 2011-07-07 11:32 UTC (permalink / raw)
To: David Miller
Cc: Ian Abbott, netdev@vger.kernel.org, arnd@arndb.de,
linux-kernel@vger.kernel.org
In-Reply-To: <20110707.042925.1609726410655229616.davem@davemloft.net>
On 07/07/11 12:29, David Miller wrote:
> From: Ian Abbott <abbotti@mev.co.uk>
> Date: Thu, 7 Jul 2011 12:18:49 +0100
>
>> Reduce the number of variables modified by the loop in do_csum() by 1,
>> which seems like a good idea. On Nios II (a RISC CPU with 3-operand
>> instruction set) it reduces the loop from 7 to 6 instructions, including
>> the conditional branch.
>>
>> Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
>
> I think you'll overshoot past the end of the buffer when there are
> trailing bytes to handle.
>
> The whole reason we need the count variable is to handle those
> kinds of cases.
I don't think it does. That's what the & ~3 was for.
--
-=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=-
-=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
^ permalink raw reply
* Re: [PATCH] lib/checksum.c: optimize do_csum a bit
From: David Miller @ 2011-07-07 11:36 UTC (permalink / raw)
To: abbotti; +Cc: ian.abbott, netdev, arnd, linux-kernel
In-Reply-To: <4E15995D.6040405@mev.co.uk>
From: Ian Abbott <abbotti@mev.co.uk>
Date: Thu, 7 Jul 2011 12:32:45 +0100
> On 07/07/11 12:29, David Miller wrote:
>> From: Ian Abbott <abbotti@mev.co.uk>
>> Date: Thu, 7 Jul 2011 12:18:49 +0100
>>
>>> Reduce the number of variables modified by the loop in do_csum() by 1,
>>> which seems like a good idea. On Nios II (a RISC CPU with 3-operand
>>> instruction set) it reduces the loop from 7 to 6 instructions, including
>>> the conditional branch.
>>>
>>> Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
>>
>> I think you'll overshoot past the end of the buffer when there are
>> trailing bytes to handle.
>>
>> The whole reason we need the count variable is to handle those
>> kinds of cases.
>
> I don't think it does. That's what the & ~3 was for.
Aha, yes that indeed makes it work.
^ 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