* Re: [BUG] bd4265fe36 bridge: Only flood unreg groups... breaks DHCP setup
From: David Miller @ 2011-07-06 1:40 UTC (permalink / raw)
To: herbert; +Cc: mike, netdev
In-Reply-To: <20110705235833.GA5599@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.hengli.com.au>
Date: Wed, 6 Jul 2011 07:58:33 +0800
> 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>
Applied.
^ permalink raw reply
* Re: [PATCH] vmxnet3: fix starving rx ring whenoc_skb kb fails
From: David Miller @ 2011-07-06 1:40 UTC (permalink / raw)
To: sbhatewara; +Cc: bhutchings, pv-drivers, netdev, scottjg
In-Reply-To: <alpine.LRH.2.00.1107051721230.32629@sbhatewara-dev1.eng.vmware.com>
From: Shreyas Bhatewara <sbhatewara@vmware.com>
Date: Tue, 5 Jul 2011 17:34:05 -0700 (PDT)
>
> If the rx ring is completely empty, then the device may never fire an rx
> interrupt. Unfortunately, the rx interrupt is what triggers populating the
> rx ring with fresh buffers, so this will cause networking to lock up.
>
> This patch replenishes the skb in recv descriptor as soon as it is
> peeled off while processing rx completions. If the skb/buffer
> allocation fails, existing one is recycled and the packet in hand is
> dropped. This way none of the RX desc is ever left empty, thus avoiding
> starvation
>
> Signed-off-by: Scott J. Goldman <scottjg@vmware.com>
> Signed-off-by: Shreyas N Bhatewara <sbhatewara@vmware.com>
Applied.
^ permalink raw reply
* Re: [PATCH] usb: usbnet: suspend count gets lost when -EBUSY
From: David Miller @ 2011-07-06 1:40 UTC (permalink / raw)
To: C.Fries, qcf001; +Cc: netdev, stable
In-Reply-To: <CADuEq9BQX2BFBY3pF=CEEymfK4JPwMP7By+JZFdaLqxs+GhtJQ@mail.gmail.com>
From: Chris Fries <qcf001@motorola.com>
Date: Tue, 5 Jul 2011 20:35:05 -0500
> +++ b/drivers/net/usb/usbnet.c
> @@ -1451,6 +1451,7 @@ int usbnet_suspend (struct usb_interface *intf,
> pm_message_t message)
Your email client has mangled your patch, please read
"Documentation/email-clients.txt" on how to fix this.
Once you've fixed it, email the patch to yourself and
verify that you yourself can successfully apply the
patch you receive.
^ permalink raw reply
* Opportunity
From: M.L @ 2011-07-06 1:38 UTC (permalink / raw)
Hello I am contacting you with regards to a business transaction I want us to execute, it is in respect to a dormant account which belongs to my late client.
I believe we may be able to make good of this situation for ourselves. Please indicate your interest and I will give you more information.
Kind regards
M.L.
^ permalink raw reply
* [PATCH] usb: usbnet: suspend count gets lost when -EBUSY
From: Chris Fries @ 2011-07-06 1:35 UTC (permalink / raw)
To: David Miller; +Cc: netdev, stable
When suspend is refused due to pending transmits, the
busy counter gets out of sync, and suspend will stop
working correctly.
Signed-off-by: Chris Fries <C.Fries@motorola.com>
---
drivers/net/usb/usbnet.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index cc95aad..9bcc3e3 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -1451,6 +1451,7 @@ int usbnet_suspend (struct usb_interface *intf,
pm_message_t message)
/* don't autosuspend while transmitting */
if (dev->txq.qlen && (message.event & PM_EVENT_AUTO)) {
spin_unlock_irq(&dev->txq.lock);
+ dev->suspend_count--;
return -EBUSY;
} else {
set_bit(EVENT_DEV_ASLEEP, &dev->flags);
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH net-next-2.6] net: sched: constify tcf_proto and tc_action
From: David Miller @ 2011-07-06 1:33 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <20110705.183234.1710750208514203200.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 05 Jul 2011 18:32:34 -0700 (PDT)
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Tue, 05 Jul 2011 18:36:47 +0200
>
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Applied, thanks Eric.
Actually, I'm reverting:
net/sched/act_ipt.c:294:2: warning: initialization from incompatible pointer type [enabled by default]
net/sched/act_ipt.c:294:2: warning: (near initialization for ‘act_ipt_ops.act’) [enabled by default]
net/sched/act_csum.c:572:2: warning: initialization from incompatible pointer type [enabled by default]
net/sched/act_csum.c:572:2: warning: (near initialization for ‘act_csum_ops.act’) [enabled by default]
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: sched: constify tcf_proto and tc_action
From: David Miller @ 2011-07-06 1:32 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1309883807.2271.30.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 05 Jul 2011 18:36:47 +0200
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2011-07-05
From: David Miller @ 2011-07-06 1:29 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20110705204106.GG7540@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 5 Jul 2011 16:41:07 -0400
> Here is another big batch of changed intended for 3.1. This looks
> bigger than it is, as it also contains a wireless-2.6 pull to resolve
> some build conflicts.
>
> The most noteworth item is yet another rtlwifi-based driver (rtl8192de).
> There is also some HT-phy work for b43, plus the usual contributions
> from the ath9k and iwlwifi crews and a variety of other bits here and
> there.
>
> Please let me know if there are problems!
Pulled, thanks John.
^ permalink raw reply
* Re: [PATCH 0/2] AF_PACKET fanout support
From: David Miller @ 2011-07-06 1:20 UTC (permalink / raw)
To: therbert; +Cc: victor, netdev, willemb
In-Reply-To: <CA+mtBx_MtQGqNT6iungW7eyStpvLEGYsgXQ8=mYq_JR8jw3=DQ@mail.gmail.com>
From: Tom Herbert <therbert@google.com>
Date: Tue, 5 Jul 2011 17:46:36 -0700
> Thanks for these patches! Is it possible you could use an alternative
> term than "fanout"? I think this may be more often associated with a
> transmit operation (e.g. multicast fanout).
I've never heard such terminology myself.
Sorry, the fanout name is staying :-)
> Also, another useful mode of steering would be to steer packets to a
> socket which was recently processed by a thread running on the same
> CPU; somewhat analogous to RFS (cc'ed WIllem Bruijn who is already
> working on this I believe).
This sounds like a good way to overload a local socket and prevent
pushing the work to lesser used sockets on other cpus.
^ permalink raw reply
* Re: usbnet suspend issue
From: David Miller @ 2011-07-06 1:11 UTC (permalink / raw)
To: C.Fries, qcf001; +Cc: netdev, stable
In-Reply-To: <CADuEq9DosCUpw9CnLrgQPXFojeCqEy-BHfZd1_BgvRJdFFQ9Ow@mail.gmail.com>
Patch submitted as binary attachment instead of plain text inline that
we can read and evaluate directly in our mail clients.
Also, if you submit this as a binary attachment, automated patch
management tools, such as patchwork, we use cannot track the patch.
Sorry, this is not the proper way to submit a patch.
Also get rid of the "Change-Id:" in your commit message, it has
no meaning.
^ permalink raw reply
* RE: [RFC] non-preemptible kernel socket for RAMster
From: Dan Magenheimer @ 2011-07-06 1:05 UTC (permalink / raw)
To: Loke, Chetan, netdev; +Cc: Konrad Wilk, linux-mm
In-Reply-To: <D3F292ADF945FB49B35E96C94C2061B91257DCA8@nsmail.netscout.com>
> From: Loke, Chetan [mailto:Chetan.Loke@netscout.com]
> Subject: RE: [RFC] non-preemptible kernel socket for RAMster
>
> > From: Dan Magenheimer [mailto:dan.magenheimer@oracle.com]
>
> > Actually, RAMster is using a much more flexible type of
> > RAM-drive; it is built on top of Transcendent Memory
> > and on top of zcache (and thus on top of cleancache and
> > frontswap). A RAM-drive is fixed size so is not very suitable
> > for the flexibility required for RAMster. For example,
> > suppose you have two machines A and B. At one point in
> > time A is overcommitted and needs to swap and B is relatively
> > idle. Then later, B is overcommitted and needs to swap and
> > A is relatively idle. RAMster can handle this entirely
> > dynamically, a RAM-drive cannot.
>
> Again, iff NBD works with a ram-drive then you really wouldn't need to
> do anything. How often are you going to re-size your remote-SWAP? Plus,
> you can make nbd-server listen on multiple ports - Google(Linux NBD)
> returned: http://www.fi.muni.cz/~kripac/orac-nbd/ . Look at the
> nbd-server code to see if it launches multiple kernel-threads for
> servicing different ports. If not, one can enhance it and scale that way
> too. But nbd-server today can service multiple-ports(that is effectively
> servicing multiple clients). So why not add NBD-filesystem-filters to
> make it point to local/remote swap?
Well, we may be talking past each other, but the RAMster answer to:
> How often are you going to re-size your remote-SWAP?
is "as often as the working set changes on any machine in the
cluster", meaning *constantly*, entirely dynamically! How
about a more specific example: Suppose you have 2 machines,
each with 8GB of memory. 99% of the time each machine is
chugging along just fine and doesn't really need more than 4GB,
and may even use less than 1GB a large part of the time.
But very now and then, one of the machines randomly needs
9GB, 10GB, maybe even 12GB of memory. This would normally
result in swapping. (Most system administrators won't even
have this much information... they'll just know they are
seeing swapping and decide they need to buy more RAM.)
With NBD to a ram-drive, each machine would need to pre-allocate
4GB of RAM for the RAM-drive, leaving only 4GB of RAM for
the "local" RAM. The result will actually be MORE swapping
because a fixed amount of RAM has been pre-reserved for the
other machine's swap. With RAMster, everything is done dynamically,
so all that matters is the maximum of the sum of the RAM
used. You may even be able to *remove* ~2GB of RAM from each
of the systems and still never see any swapping to disk.
> > Thanks. Could you provide a pointer for this? I found
> > the SCST sourceforge page but no obvious references to
> > scst-in-ram-mode. (But also, since it appears to be
> > SCSI-related, I wonder if it also assumes a fixed size
> > target device, RAM or disk or ??)
>
> Yes, it is SCSI. You should be looking for SCST I/O modes. Read some
> docs and then send an email to the scst-mailing-list. If you speak about
> block-IO-performance then FC(in its class of price/performance factor)
> is more than capable of handling any workload. FC is a protocol designed
> for storage. No exotic fabric other than FC is needed.
> Folks who start with ethernet for block-IO, always start with bare
> minimal code and then for squeezing block-IO performance(aka version 2
> of the product), keep hacking repeatedly or go for a link-speed upgrade.
> Start with FC, period.
My point was that block I/O devices (AFAIK) always present a fixed
"size" to the kernel, and if this is also true of scst-in-ram-mode,
the same problem as swap-over-NBD occurs... it's not dynamic.
RAMster does not present a block-I/O storage-like interface;
it's using the Transcendent Memory interface, which is designed
for "slow RAM" of an unknown-and-dynamic size.
I'm not a storage expert either, but I do wonder if "no exotic
fabric other than FC" isn't an oxymoron ;-) FC is certainly
too exotic for me.
Dan
--
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: [PATCH 0/2] AF_PACKET fanout support
From: Tom Herbert @ 2011-07-06 0:46 UTC (permalink / raw)
To: David Miller; +Cc: victor, netdev, Willem Bruijn
In-Reply-To: <20110704.212002.1680758539791986198.davem@davemloft.net>
Dave,
Thanks for these patches! Is it possible you could use an alternative
term than "fanout"? I think this may be more often associated with a
transmit operation (e.g. multicast fanout).
Also, another useful mode of steering would be to steer packets to a
socket which was recently processed by a thread running on the same
CPU; somewhat analogous to RFS (cc'ed WIllem Bruijn who is already
working on this I believe).
Tom
On Mon, Jul 4, 2011 at 9:20 PM, David Miller <davem@davemloft.net> wrote:
>
> This is a fully functional version, I've tested both hash and
> load-balance modes successfully. I plan to commit this to
> net-next-2.6 very soon.
>
> Below is a test program that other people can play with
> if they want. It basically creates 4 threads, and creates
> an AF_PACKET fanout amongst them. Each thread prints out
> it's pid in parentheses every time it receives 10 packets.
> After each thread processes 10,000 packets, it exits.
>
> Try things like "./test eth0 hash", "./test eth0 lb", etc.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> --------------------
> #include <stddef.h>
> #include <stdlib.h>
> #include <stdio.h>
> #include <string.h>
>
> #include <sys/types.h>
> #include <sys/wait.h>
> #include <sys/socket.h>
> #include <sys/ioctl.h>
>
> #include <unistd.h>
>
> #include <linux/if_ether.h>
> #include <linux/if_packet.h>
>
> #include <net/if.h>
>
> static const char *device_name;
> static int fanout_type;
> static int fanout_id;
>
> #ifndef PACKET_FANOUT
> #define PACKET_FANOUT 18
> #define PACKET_FANOUT_HASH 0
> #define PACKET_FANOUT_LB 1
> #endif
>
> static int setup_socket(void)
> {
> int err, fd = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_IP));
> struct sockaddr_ll ll;
> struct ifreq ifr;
> int fanout_arg;
>
> if (fd < 0) {
> perror("socket");
> return EXIT_FAILURE;
> }
>
> memset(&ifr, 0, sizeof(ifr));
> strcpy(ifr.ifr_name, device_name);
> err = ioctl(fd, SIOCGIFINDEX, &ifr);
> if (err < 0) {
> perror("SIOCGIFINDEX");
> return EXIT_FAILURE;
> }
>
> memset(&ll, 0, sizeof(ll));
> ll.sll_family = AF_PACKET;
> ll.sll_ifindex = ifr.ifr_ifindex;
> err = bind(fd, (struct sockaddr *) &ll, sizeof(ll));
> if (err < 0) {
> perror("bind");
> return EXIT_FAILURE;
> }
>
> fanout_arg = (fanout_id | (fanout_type << 16));
> err = setsockopt(fd, SOL_PACKET, PACKET_FANOUT,
> &fanout_arg, sizeof(fanout_arg));
> if (err) {
> perror("setsockopt");
> return EXIT_FAILURE;
> }
>
> return fd;
> }
>
> static void fanout_thread(void)
> {
> int fd = setup_socket();
> int limit = 10000;
>
> if (fd < 0)
> exit(fd);
>
> while (limit-- > 0) {
> char buf[1600];
> int err;
>
> err = read(fd, buf, sizeof(buf));
> if (err < 0) {
> perror("read");
> exit(EXIT_FAILURE);
> }
> if ((limit % 10) == 0)
> fprintf(stdout, "(%d) \n", getpid());
> }
>
> fprintf(stdout, "%d: Received 10000 packets\n", getpid());
>
> close(fd);
> exit(0);
> }
>
> int main(int argc, char **argp)
> {
> int fd, err;
> int i;
>
> if (argc != 3) {
> fprintf(stderr, "Usage: %s INTERFACE {hash|lb}\n", argp[0]);
> return EXIT_FAILURE;
> }
>
> if (!strcmp(argp[2], "hash"))
> fanout_type = PACKET_FANOUT_HASH;
> else if (!strcmp(argp[2], "lb"))
> fanout_type = PACKET_FANOUT_LB;
> else {
> fprintf(stderr, "Unknown fanout type [%s]\n", argp[2]);
> exit(EXIT_FAILURE);
> }
>
> device_name = argp[1];
> fanout_id = getpid() & 0xffff;
>
> for (i = 0; i < 4; i++) {
> pid_t pid = fork();
>
> switch (pid) {
> case 0:
> fanout_thread();
>
> case -1:
> perror("fork");
> exit(EXIT_FAILURE);
> }
> }
>
> for (i = 0; i < 4; i++) {
> int status;
>
> wait(&status);
> }
>
> return 0;
> }
> --
> 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
* Re: [PATCH] vmxnet3: fix starving rx ring whenoc_skb kb fails
From: Shreyas Bhatewara @ 2011-07-06 0:34 UTC (permalink / raw)
To: David Miller
Cc: bhutchings@solarflare.com, pv-drivers@vmware.com,
netdev@vger.kernel.org, scottjg
In-Reply-To: <20110617.120900.550060204741705506.davem@davemloft.net>
If the rx ring is completely empty, then the device may never fire an rx
interrupt. Unfortunately, the rx interrupt is what triggers populating the
rx ring with fresh buffers, so this will cause networking to lock up.
This patch replenishes the skb in recv descriptor as soon as it is
peeled off while processing rx completions. If the skb/buffer
allocation fails, existing one is recycled and the packet in hand is
dropped. This way none of the RX desc is ever left empty, thus avoiding
starvation
Signed-off-by: Scott J. Goldman <scottjg@vmware.com>
Signed-off-by: Shreyas N Bhatewara <sbhatewara@vmware.com>
---
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 2c14736..fabcded 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -573,7 +573,7 @@ vmxnet3_rq_alloc_rx_buf(struct vmxnet3_rx_queue *rq, u32 ring_idx,
struct vmxnet3_cmd_ring *ring = &rq->rx_ring[ring_idx];
u32 val;
- while (num_allocated < num_to_alloc) {
+ while (num_allocated <= num_to_alloc) {
struct vmxnet3_rx_buf_info *rbi;
union Vmxnet3_GenericDesc *gd;
@@ -619,9 +619,15 @@ vmxnet3_rq_alloc_rx_buf(struct vmxnet3_rx_queue *rq, u32 ring_idx,
BUG_ON(rbi->dma_addr == 0);
gd->rxd.addr = cpu_to_le64(rbi->dma_addr);
- gd->dword[2] = cpu_to_le32((ring->gen << VMXNET3_RXD_GEN_SHIFT)
+ gd->dword[2] = cpu_to_le32((!ring->gen << VMXNET3_RXD_GEN_SHIFT)
| val | rbi->len);
+ /* Fill the last buffer but dont mark it ready, or else the
+ * device will think that the queue is full */
+ if (num_allocated == num_to_alloc)
+ break;
+
+ gd->dword[2] |= cpu_to_le32(ring->gen << VMXNET3_RXD_GEN_SHIFT);
num_allocated++;
vmxnet3_cmd_ring_adv_next2fill(ring);
}
@@ -1138,6 +1144,7 @@ vmxnet3_rq_rx_complete(struct vmxnet3_rx_queue *rq,
VMXNET3_REG_RXPROD, VMXNET3_REG_RXPROD2
};
u32 num_rxd = 0;
+ bool skip_page_frags = false;
struct Vmxnet3_RxCompDesc *rcd;
struct vmxnet3_rx_ctx *ctx = &rq->rx_ctx;
#ifdef __BIG_ENDIAN_BITFIELD
@@ -1148,11 +1155,12 @@ vmxnet3_rq_rx_complete(struct vmxnet3_rx_queue *rq,
&rxComp);
while (rcd->gen == rq->comp_ring.gen) {
struct vmxnet3_rx_buf_info *rbi;
- struct sk_buff *skb;
+ struct sk_buff *skb, *new_skb = NULL;
+ struct page *new_page = NULL;
int num_to_alloc;
struct Vmxnet3_RxDesc *rxd;
u32 idx, ring_idx;
-
+ struct vmxnet3_cmd_ring *ring = NULL;
if (num_rxd >= quota) {
/* we may stop even before we see the EOP desc of
* the current pkt
@@ -1163,6 +1171,7 @@ vmxnet3_rq_rx_complete(struct vmxnet3_rx_queue *rq,
BUG_ON(rcd->rqID != rq->qid && rcd->rqID != rq->qid2);
idx = rcd->rxdIdx;
ring_idx = rcd->rqID < adapter->num_rx_queues ? 0 : 1;
+ ring = rq->rx_ring + ring_idx;
vmxnet3_getRxDesc(rxd, &rq->rx_ring[ring_idx].base[idx].rxd,
&rxCmdDesc);
rbi = rq->buf_info[ring_idx] + idx;
@@ -1191,37 +1200,80 @@ vmxnet3_rq_rx_complete(struct vmxnet3_rx_queue *rq,
goto rcd_done;
}
+ skip_page_frags = false;
ctx->skb = rbi->skb;
- rbi->skb = NULL;
+ new_skb = dev_alloc_skb(rbi->len + NET_IP_ALIGN);
+ if (new_skb == NULL) {
+ /* Skb allocation failed, do not handover this
+ * skb to stack. Reuse it. Drop the existing pkt
+ */
+ rq->stats.rx_buf_alloc_failure++;
+ ctx->skb = NULL;
+ rq->stats.drop_total++;
+ skip_page_frags = true;
+ goto rcd_done;
+ }
pci_unmap_single(adapter->pdev, rbi->dma_addr, rbi->len,
PCI_DMA_FROMDEVICE);
skb_put(ctx->skb, rcd->len);
+
+ /* Immediate refill */
+ new_skb->dev = adapter->netdev;
+ skb_reserve(new_skb, NET_IP_ALIGN);
+ rbi->skb = new_skb;
+ rbi->dma_addr = pci_map_single(adapter->pdev,
+ rbi->skb->data, rbi->len,
+ PCI_DMA_FROMDEVICE);
+ rxd->addr = cpu_to_le64(rbi->dma_addr);
+ rxd->len = rbi->len;
+
} else {
- BUG_ON(ctx->skb == NULL);
+ BUG_ON(ctx->skb == NULL && !skip_page_frags);
+
/* non SOP buffer must be type 1 in most cases */
- if (rbi->buf_type == VMXNET3_RX_BUF_PAGE) {
- BUG_ON(rxd->btype != VMXNET3_RXD_BTYPE_BODY);
+ BUG_ON(rbi->buf_type != VMXNET3_RX_BUF_PAGE);
+ BUG_ON(rxd->btype != VMXNET3_RXD_BTYPE_BODY);
- if (rcd->len) {
- pci_unmap_page(adapter->pdev,
- rbi->dma_addr, rbi->len,
- PCI_DMA_FROMDEVICE);
+ /* If an sop buffer was dropped, skip all
+ * following non-sop fragments. They will be reused.
+ */
+ if (skip_page_frags)
+ goto rcd_done;
- vmxnet3_append_frag(ctx->skb, rcd, rbi);
- rbi->page = NULL;
- }
- } else {
- /*
- * The only time a non-SOP buffer is type 0 is
- * when it's EOP and error flag is raised, which
- * has already been handled.
+ new_page = alloc_page(GFP_ATOMIC);
+ if (unlikely(new_page == NULL)) {
+ /* Replacement page frag could not be allocated.
+ * Reuse this page. Drop the pkt and free the
+ * skb which contained this page as a frag. Skip
+ * processing all the following non-sop frags.
*/
- BUG_ON(true);
+ rq->stats.rx_buf_alloc_failure++;
+ dev_kfree_skb(ctx->skb);
+ ctx->skb = NULL;
+ skip_page_frags = true;
+ goto rcd_done;
+ }
+
+ if (rcd->len) {
+ pci_unmap_page(adapter->pdev,
+ rbi->dma_addr, rbi->len,
+ PCI_DMA_FROMDEVICE);
+
+ vmxnet3_append_frag(ctx->skb, rcd, rbi);
}
+
+ /* Immediate refill */
+ rbi->page = new_page;
+ rbi->dma_addr = pci_map_page(adapter->pdev, rbi->page,
+ 0, PAGE_SIZE,
+ PCI_DMA_FROMDEVICE);
+ rxd->addr = cpu_to_le64(rbi->dma_addr);
+ rxd->len = rbi->len;
}
+
skb = ctx->skb;
if (rcd->eop) {
skb->len += skb->data_len;
@@ -1243,26 +1295,27 @@ vmxnet3_rq_rx_complete(struct vmxnet3_rx_queue *rq,
}
rcd_done:
- /* device may skip some rx descs */
- rq->rx_ring[ring_idx].next2comp = idx;
- VMXNET3_INC_RING_IDX_ONLY(rq->rx_ring[ring_idx].next2comp,
- rq->rx_ring[ring_idx].size);
-
- /* refill rx buffers frequently to avoid starving the h/w */
- num_to_alloc = vmxnet3_cmd_ring_desc_avail(rq->rx_ring +
- ring_idx);
- if (unlikely(num_to_alloc > VMXNET3_RX_ALLOC_THRESHOLD(rq,
- ring_idx, adapter))) {
- vmxnet3_rq_alloc_rx_buf(rq, ring_idx, num_to_alloc,
- adapter);
-
- /* if needed, update the register */
- if (unlikely(rq->shared->updateRxProd)) {
- VMXNET3_WRITE_BAR0_REG(adapter,
- rxprod_reg[ring_idx] + rq->qid * 8,
- rq->rx_ring[ring_idx].next2fill);
- rq->uncommitted[ring_idx] = 0;
- }
+ /* device may have skipped some rx descs */
+ ring->next2comp = idx;
+ num_to_alloc = vmxnet3_cmd_ring_desc_avail(ring);
+ ring = rq->rx_ring + ring_idx;
+ while (num_to_alloc) {
+ vmxnet3_getRxDesc(rxd, &ring->base[ring->next2fill].rxd,
+ &rxCmdDesc);
+ BUG_ON(!rxd->addr);
+
+ /* Recv desc is ready to be used by the device */
+ rxd->gen = ring->gen;
+ vmxnet3_cmd_ring_adv_next2fill(ring);
+ num_to_alloc--;
+ }
+
+ /* if needed, update the register */
+ if (unlikely(rq->shared->updateRxProd)) {
+ VMXNET3_WRITE_BAR0_REG(adapter,
+ rxprod_reg[ring_idx] + rq->qid * 8,
+ ring->next2fill);
+ rq->uncommitted[ring_idx] = 0;
}
vmxnet3_comp_ring_adv_next2proc(&rq->comp_ring);
diff --git a/drivers/net/vmxnet3/vmxnet3_int.h b/drivers/net/vmxnet3/vmxnet3_int.h
index 2e37985..a9cb3fa 100644
--- a/drivers/net/vmxnet3/vmxnet3_int.h
+++ b/drivers/net/vmxnet3/vmxnet3_int.h
@@ -69,10 +69,10 @@
/*
* Version numbers
*/
-#define VMXNET3_DRIVER_VERSION_STRING "1.1.9.0-k"
+#define VMXNET3_DRIVER_VERSION_STRING "1.1.14.0-k"
/* a 32-bit int, each byte encode a verion number in VMXNET3_DRIVER_VERSION */
-#define VMXNET3_DRIVER_VERSION_NUM 0x01010900
+#define VMXNET3_DRIVER_VERSION_NUM 0x01010E00
#if defined(CONFIG_PCI_MSI)
/* RSS only makes sense if MSI-X is supported. */
^ permalink raw reply related
* Re: [BUG] bd4265fe36 bridge: Only flood unreg groups... breaks DHCP setup
From: Herbert Xu @ 2011-07-05 23:58 UTC (permalink / raw)
To: Michael Guntsche; +Cc: netdev, davem
In-Reply-To: <20110705204200@it-loops.com>
Michael Guntsche <mike@it-loops.com> wrote:
>
> Looking at the changes between rc5 and rc6 I noticed commit
>
> bd4265fe365c0f3945d: bridge: Only flood unregistered groups to routers
Oops, that was definitely my fault. This patch should fix your
problem.
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>
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) ||
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* RE: [RFC] non-preemptible kernel socket for RAMster
From: Loke, Chetan @ 2011-07-05 22:27 UTC (permalink / raw)
To: Dan Magenheimer, netdev; +Cc: Konrad Wilk, linux-mm
In-Reply-To: <704d094e-7b81-480f-8363-327218d1b0ea@default>
> -----Original Message-----
> From: Dan Magenheimer [mailto:dan.magenheimer@oracle.com]
> Sent: July 05, 2011 3:19 PM
> To: Loke, Chetan; netdev@vger.kernel.org
> Cc: Konrad Wilk; linux-mm
> Subject: RE: [RFC] non-preemptible kernel socket for RAMster
>
> Actually, RAMster is using a much more flexible type of
> RAM-drive; it is built on top of Transcendent Memory
> and on top of zcache (and thus on top of cleancache and
> frontswap). A RAM-drive is fixed size so is not very suitable
> for the flexibility required for RAMster. For example,
> suppose you have two machines A and B. At one point in
> time A is overcommitted and needs to swap and B is relatively
> idle. Then later, B is overcommitted and needs to swap and
> A is relatively idle. RAMster can handle this entirely
> dynamically, a RAM-drive cannot.
Again, iff NBD works with a ram-drive then you really wouldn't need to
do anything. How often are you going to re-size your remote-SWAP? Plus,
you can make nbd-server listen on multiple ports - Google(Linux NBD)
returned: http://www.fi.muni.cz/~kripac/orac-nbd/ . Look at the
nbd-server code to see if it launches multiple kernel-threads for
servicing different ports. If not, one can enhance it and scale that way
too. But nbd-server today can service multiple-ports(that is effectively
servicing multiple clients). So why not add NBD-filesystem-filters to
make it point to local/remote swap?
>
> Thanks. Could you provide a pointer for this? I found
> the SCST sourceforge page but no obvious references to
> scst-in-ram-mode. (But also, since it appears to be
> SCSI-related, I wonder if it also assumes a fixed size
> target device, RAM or disk or ??)
>
Yes, it is SCSI. You should be looking for SCST I/O modes. Read some
docs and then send an email to the scst-mailing-list. If you speak about
block-IO-performance then FC(in its class of price/performance factor)
is more than capable of handling any workload. FC is a protocol designed
for storage. No exotic fabric other than FC is needed.
Folks who start with ethernet for block-IO, always start with bare
minimal code and then for squeezing block-IO performance(aka version 2
of the product), keep hacking repeatedly or go for a link-speed upgrade.
Start with FC, period.
> Dan
Chetan Loke
^ permalink raw reply
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Neil Horman @ 2011-07-05 22:06 UTC (permalink / raw)
To: Eric Dumazet
Cc: Alexey Zaytsev, Michael Büsch, Andrew Morton, netdev,
Gary Zambrano, bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <1309896940.2545.34.camel@edumazet-laptop>
On Tue, Jul 05, 2011 at 10:15:40PM +0200, Eric Dumazet wrote:
> Le mardi 05 juillet 2011 à 22:02 +0200, Eric Dumazet a écrit :
> > Le mardi 05 juillet 2011 à 15:53 -0400, Neil Horman a écrit :
> > > I think this is a goo idea, at least for testing. It seems odd to me that we
> > > have the B44_DMARX_PTR value which indicates (ostensibly) the pointer to the
> > > descriptor to be processed next (the documentation isnt' very verbose on the
> > > subject), along with the EOT bit on a descriptor. It seems like both the
> > > register and the bit are capable of conveying the same (or at least overlapping)
> > > information.
> > >
> > > I think what I'm having the most trouble with is understanding when the hw looks
> > > at the EOT bit in the descriptor. If it completes a DMA and sees the EOT bit
> > > set, does the next DMA occur to the descriptor pointed to by the DMARX_ADDR
> > > register? Of does it stall until such time as the DMARX_PTR register is rotated
> > > around? What if it doesn't see the EOT bit set? Does it just keep going with
> > > the next descriptor?
>
> Since there is no OWN bit (at least not on the online doc I got : it
> says the rx_ring is read only by the NIC), I would say we really need to
> advance DMARX_PTR to signal NIC a new entry is available for following
> incoming frames.
>
> This is the reason rx_pending max value is B44_RX_RING_SIZE - 1, or else
> chip could loop on a circular rx_ring.
>
Agree, although that still leaves open the question of what exactly should get
written into the DMARX_PTR. Is it an index of the descriptor number, or a byte
offset.
Regardless, I think we ned to fix up the looping so as to prevent an EOT reset
jumping outside of our valid ring window. Alexey, theres better ways to do
this, but if in the interim, you could please try this patch, it makes the valid
receive window for b44 cover the entire ring, so as to avoid this problem. It
will at least help support or refute this theory. Note its not exactly the same
as my previous patch. If you set the default ring pending to 512, the math in
the b44_alloc_rx_skb path is wrong, we skip the EOT bit as well as the first
entry in the ring. At 511 it should work out properly.
Thanks
Neil
diff --git a/drivers/net/b44.c b/drivers/net/b44.c
index 3d247f3..b7f5ed1 100644
--- a/drivers/net/b44.c
+++ b/drivers/net/b44.c
@@ -57,7 +57,7 @@
#define B44_MAX_MTU 1500
#define B44_RX_RING_SIZE 512
-#define B44_DEF_RX_RING_PENDING 200
+#define B44_DEF_RX_RING_PENDING 511
#define B44_RX_RING_BYTES (sizeof(struct dma_desc) * \
B44_RX_RING_SIZE)
#define B44_TX_RING_SIZE 512
>
>
>
> --
> 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 related
* Hello
From: Dulce Cupen @ 2011-07-05 19:10 UTC (permalink / raw)
Please be informed that you have
$250,000.00 Lodged in our Western Union to
transfer to you as Compensation.
Please Contact Email: wumt.solodavid.uk@msnzone.cn
^ permalink raw reply
* Hello
From: Dulce Cupen @ 2011-07-05 19:47 UTC (permalink / raw)
Please be informed that you have
$250,000.00 Lodged in our Western Union to
transfer to you as Compensation.
Please Contact Email: wumt.solodavid.uk@msnzone.cn
^ permalink raw reply
* Re: possible bridge regression in "bridge: implement [add/del]_slave ops"?
From: Stephen Hemminger @ 2011-07-05 21:28 UTC (permalink / raw)
To: Alexander Stein; +Cc: David S. Miller, bridge, netdev, linux-kernel
In-Reply-To: <201106301033.23997.alexander.stein@systec-electronic.com>
I just put a fix for the detection of bridge pseudo-device being up
into the current rstp code available at:
git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/rstp.git
^ permalink raw reply
* RE: [PATCH 2/2] packet: Add fanout support.
From: Loke, Chetan @ 2011-07-05 21:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Victor Julien, David Miller, netdev
In-Reply-To: <1309890032.2545.8.camel@edumazet-laptop>
> -----Original Message-----
> From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> Sent: July 05, 2011 2:21 PM
> To: Loke, Chetan
> Cc: Victor Julien; David Miller; netdev@vger.kernel.org
> Subject: RE: [PATCH 2/2] packet: Add fanout support.
>
> Le mardi 05 juillet 2011 à 13:35 -0400, Loke, Chetan a écrit :
>
> > Sure, a lookup is needed(to steer what I call - Hot/Cold flows) and
> > was proposed by me on the oisf mailing list. Always, use the ip_id
> bit
> > then? Another problem that needs to be solved is, what if some
> > decoders are overloaded, then what? How will this scheme work? How
> > will we utilize other CPUs? RPS is needed for sure.
> >
> > If we maintain a i) per port lookup-table ii) 2^20 flows/table and
> > iii) 16 bytes/flow(one can also squeeze it down to 8 bytes) then we
> > will need around 32MB worth memory/port. It's not a huge memory
> > pressure for folks who want to use linux for doing IPS/IDS sort of
> > stuff.
> >
> > User-space decoders end up copying the packet anyways. So fanout can
> > be implemented in user-space to achieve effective CPU utilization.
> > As long as we don't bounce on different CPU-socket we could be ok.
>
> This is the problem we want to address.
>
> Going into user-space to perform the fanout is what you already have
> today, with one socket, one thread doing the fanout to worker threads.
>
> David patch is non adaptative : its a hash on N queue, with a fixed
> hash
> function.
>
> What you want is to add another 'control queue' where new flows are
> directed. Then user application is able to reinject into kernel flow
> director the "This flow should go to queue X" information.
>
I like the term - 'kernel-flow-director'. The problem with rebalancing from user-space is that we will need to have some 'idle' period before we inject flow-redirection event into the kernel. And for bursty workloads this may be problematic. We may have to rebalance often. And then we will have to export the 'rebalance-idle-interval' knob.
And users may have to tune it for their workloads etc.
> Or, let the kernel do a mix of rxhash and loadbalance : Be able to
> select a queue for a new flow without user land control, using a Flow
> hash table.
>
This is exactly what I had proposed. Hash{== lookup of hot/cold flows}+LB{== kernel-flow-director} is what we need.
So something like:
hot_fanout_id = is_flow_active(rx_hash,lookup_table);
if (hot_fanout_id)
/* This flow is Hot */
steer_to(hot_fanout_id);
else {
/* This flow is cold - Get next_rr fanout_id */
fanout_rr_next(...);
...
steer_to(cold_fanout_id);
}
And,
1)hash on <src_ip_addr,dst_ip_addr,src_port,dst_port>
2)store the ip_id from the first fragment in the flow_hash_table for matching subsequent ip_fragments.
One corner case - If the first fragment arrives out-of-order(OOO).
2.1) user has configured - assemble-fragments: In this case it doesn’t matter.
2.2) user has configured - fwd-as-is: Redirect OOO-fragments to the next_rr_fanout_id.
2.2.1)
And so we may have to set a bit in hash_lookup_table for a flow indicating it arrived 'OOO'.
So, is_flow_active will have to lookup twice. First using ip_id as 3rd var in jhash. And second lookup using ports as 3rd var. Worst case there will be two lookups on OOO.
OR
2.2.2) Effectively treat this fragment as 'assemble-fragments' case(?) as in 2.1).
So {hash+LB} together, should take care of the fragmented/non-fragmented flow.
We will have to purge the flow-entry at some point to avoid false routing. Don't know if the control-queue that you mentioned above can be used for purging flows?
Or the control-queue itself can be mmap'd so that user-space can clear 'a' flow-entry?
Chetan Loke
^ permalink raw reply
* pull request: wireless-next-2.6 2011-07-05
From: John W. Linville @ 2011-07-05 20:41 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
Dave,
Here is another big batch of changed intended for 3.1. This looks
bigger than it is, as it also contains a wireless-2.6 pull to resolve
some build conflicts.
The most noteworth item is yet another rtlwifi-based driver (rtl8192de).
There is also some HT-phy work for b43, plus the usual contributions
from the ath9k and iwlwifi crews and a variety of other bits here and
there.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 7d09926d1decb658d4e24f70216b6b0b74168026:
bnx2x: Fix warning message during 57712/8727 initialization (2011-07-05 04:21:40 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git for-davem
Arik Nemtsov (5):
mac80211: fix rx->key NULL dereference during mic failure
mac80211: reestablish mis-configured existing Rx BA sessions
mac80211: dynamic PS - don't enter PS when TX frames are pending
mac80211: propagate information about STA WME support down
wl12xx: AP-mode - use mac80211 indication about STA WME support
Chaoming Li (12):
rtlwifi: rtl8192de: Merge def.h
rtlwifi: rtl8192de: Merge dynamic management routines
rtlwifi: rtl8192de: Merge firmware routines
rtlwifi: rtl8192de: Merge hardware routines
rtlwifi: rtl8192de: Merge led routines
rtlwifi: rtl8192de: Merge phy routines
rtlwifi: rtl8192de: Merge register definitions
rtlwifi: rtl8192de: Merge rf routines
rtlwifi: rtl8192de: Merge main (sw) routines
rtlwifi: rtl8192de: Merge table routines
rtlwifi: rtl8192de: Merge TX and RX routines
rtlwifi: rtl8192de: Modify Kconfig and Makefile routines for new driver
Dan Carpenter (2):
mwifiex: restore handling of NULL parameters
rtlwifi: potential forever loop in rtl92de_hw_init()
Emmanuel Grumbach (1):
iwlagn: Fix a bug introduced by the HUGE command removal
Evgeni Golov (1):
iwlagn: fix *_UCODE_API_MAX output in the firmware field
Geert Uytterhoeven (1):
bcma: main.c needs to include <linux/slab.h>
Hauke Mehrtens (1):
ssb: fix ssb clock rate according to broadcom source
Joe Perches (1):
rt2x00: Fix unspeficied typo
Johannes Berg (10):
iwlagn: fix change_interface for P2P types
iwlagn: use PM ops macro
iwlagn: fix cmd queue unmap
iwlagn: extend host command timeout
iwlagn: fill beacon TX rate properly
iwlagn: don't use CCK rates for P2P interfaces
iwlagn: fix cmd queue unmap
iwlagn: map command buffers BIDI
wireless: unify QoS control field definitions
mac80211: restrict advertised HW scan rates
John W. Linville (6):
Merge branch 'master' of master.kernel.org:/.../padovan/bluetooth-2.6
Merge branch 'wireless-2.6' of git://git.kernel.org/.../iwlwifi/iwlwifi-2.6
Merge branch 'wireless-next-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
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-next-2.6 into for-davem
Jon Mason (3):
iwlegacy: remove unnecessary read of PCI_CAP_ID_EXP
rtlwifi: remove unnecessary read of PCI_CAP_ID_EXP
rtlwifi: use PCI_VENDOR_ID_*
Larry Finger (4):
rtlwifi: rtl8192se: Handle duplicate PCI ID 0x10ec:0x8192 conflict with r8192e_pci
rtl8192cu: Fix missing firmware load
rtlwifi: Fix build problems introduced by merging rtl8192de
rtlwifi: rtl8192de: Fix build errors when using allyes configuration
Mohammed Shafi Shajakhan (4):
ath9k_hw: Add carrier leak correction in desired gain calculation
ath9k_hw: make use of the gain_table_entry macro
ath9k: move few descriptor macros to ath9k.h
ath9k_htc: Add device ID for Sony UWA-BR100
Paul Stewart (1):
mac80211: Drop DS Channel PARAM in directed probe
Rafał Miłecki (10):
b43: HT-PHY: prepare place for HT-PHY tables
b43: HT-PHY: upload PHY values when switching channel
b43: HT-PHY: perform some tables ops on channel switching
b43: HT-PHY: add channel switching tables for 2 GHz band
b43: HT-PHY: implement lacking 0x908 PHY reg op
b43: HT-PHY: replace radio routing magic numbers
b43: HT-PHY: init radio when enabling it
b43: HT-PHY: add init tables
b43: HT-PHY: basic PHY init
b43: HT-PHY: correct 0x2059 radio init
Rajkumar Manoharan (2):
ath9k_hw: Fix false tx hung detection in AR9003 chips
ath9k: Fix locking issue during tx completion
Randy Dunlap (1):
bluetooth: uses crypto interfaces, select CRYPTO
Sergei Shtylyov (2):
ssb: use pci_dev->revision
iwlwifi: use pci_dev->revision, again
Stanislaw Gruszka (1):
iwlagn: fix rmmod crash
drivers/bcma/main.c | 1 +
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 8 +-
drivers/net/wireless/ath/ath9k/ar9003_paprd.c | 38 +-
drivers/net/wireless/ath/ath9k/ar9003_phy.h | 3 +
drivers/net/wireless/ath/ath9k/ath9k.h | 5 +
drivers/net/wireless/ath/ath9k/beacon.c | 8 +
drivers/net/wireless/ath/ath9k/hif_usb.c | 2 +
drivers/net/wireless/ath/ath9k/init.c | 7 -
drivers/net/wireless/ath/ath9k/main.c | 13 +-
drivers/net/wireless/ath/ath9k/xmit.c | 7 +-
drivers/net/wireless/ath/carl9170/rx.c | 2 +-
drivers/net/wireless/b43/Makefile | 1 +
drivers/net/wireless/b43/phy_ht.c | 132 +-
drivers/net/wireless/b43/phy_ht.h | 14 +-
drivers/net/wireless/b43/radio_2059.c | 135 +
drivers/net/wireless/b43/radio_2059.h | 5 +
drivers/net/wireless/b43/tables_phy_ht.c | 750 +++++
drivers/net/wireless/b43/tables_phy_ht.h | 22 +
drivers/net/wireless/iwlegacy/iwl-core.h | 2 +-
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-agn-rxon.c | 2 +
drivers/net/wireless/iwlwifi/iwl-agn-sta.c | 17 +-
drivers/net/wireless/iwlwifi/iwl-agn.c | 26 +-
drivers/net/wireless/iwlwifi/iwl-agn.h | 2 +
drivers/net/wireless/iwlwifi/iwl-core.c | 16 +-
drivers/net/wireless/iwlwifi/iwl-core.h | 7 -
drivers/net/wireless/iwlwifi/iwl-hcmd.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-pci.c | 20 +-
drivers/net/wireless/iwlwifi/iwl-tx.c | 25 +-
drivers/net/wireless/libertas_tf/main.c | 2 +-
drivers/net/wireless/mac80211_hwsim.c | 2 +
drivers/net/wireless/mwifiex/sta_cmd.c | 2 +
drivers/net/wireless/mwifiex/sta_cmdresp.c | 29 +-
drivers/net/wireless/rt2x00/rt2x00queue.h | 2 +-
drivers/net/wireless/rtlwifi/Kconfig | 15 +-
drivers/net/wireless/rtlwifi/Makefile | 1 +
drivers/net/wireless/rtlwifi/pci.c | 23 +-
drivers/net/wireless/rtlwifi/pci.h | 11 -
drivers/net/wireless/rtlwifi/rtl8192ce/reg.h | 2 +
drivers/net/wireless/rtlwifi/rtl8192cu/sw.c | 20 +
drivers/net/wireless/rtlwifi/rtl8192de/Makefile | 14 +
drivers/net/wireless/rtlwifi/rtl8192de/def.h | 269 ++
drivers/net/wireless/rtlwifi/rtl8192de/dm.c | 1355 ++++++++
drivers/net/wireless/rtlwifi/rtl8192de/dm.h | 212 ++
drivers/net/wireless/rtlwifi/rtl8192de/fw.c | 790 +++++
drivers/net/wireless/rtlwifi/rtl8192de/fw.h | 155 +
drivers/net/wireless/rtlwifi/rtl8192de/hw.c | 2326 ++++++++++++++
drivers/net/wireless/rtlwifi/rtl8192de/hw.h | 66 +
drivers/net/wireless/rtlwifi/rtl8192de/led.c | 159 +
drivers/net/wireless/rtlwifi/rtl8192de/led.h | 38 +
drivers/net/wireless/rtlwifi/rtl8192de/phy.c | 3837 +++++++++++++++++++++++
drivers/net/wireless/rtlwifi/rtl8192de/phy.h | 178 ++
drivers/net/wireless/rtlwifi/rtl8192de/reg.h | 1313 ++++++++
drivers/net/wireless/rtlwifi/rtl8192de/rf.c | 628 ++++
drivers/net/wireless/rtlwifi/rtl8192de/rf.h | 44 +
drivers/net/wireless/rtlwifi/rtl8192de/sw.c | 423 +++
drivers/net/wireless/rtlwifi/rtl8192de/sw.h | 37 +
drivers/net/wireless/rtlwifi/rtl8192de/table.c | 1690 ++++++++++
drivers/net/wireless/rtlwifi/rtl8192de/table.h | 57 +
drivers/net/wireless/rtlwifi/rtl8192de/trx.c | 959 ++++++
drivers/net/wireless/rtlwifi/rtl8192de/trx.h | 756 +++++
drivers/net/wireless/rtlwifi/wifi.h | 3 -
drivers/net/wireless/wl12xx/cmd.c | 9 +-
drivers/ssb/main.c | 4 +-
drivers/ssb/scan.c | 3 +-
include/linux/ieee80211.h | 18 +-
include/net/cfg80211.h | 2 +-
include/net/mac80211.h | 2 +
net/bluetooth/Kconfig | 1 +
net/mac80211/agg-rx.c | 6 +-
net/mac80211/cfg.c | 5 +-
net/mac80211/ieee80211_i.h | 6 +-
net/mac80211/mlme.c | 41 +-
net/mac80211/rx.c | 2 +-
net/mac80211/scan.c | 8 +-
net/mac80211/util.c | 21 +-
net/mac80211/wme.c | 3 +-
net/mac80211/wme.h | 5 -
net/mac80211/work.c | 2 +-
net/mac80211/wpa.c | 8 +-
net/wireless/nl80211.c | 3 +-
84 files changed, 16663 insertions(+), 202 deletions(-)
create mode 100644 drivers/net/wireless/b43/tables_phy_ht.c
create mode 100644 drivers/net/wireless/b43/tables_phy_ht.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/Makefile
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/def.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/dm.c
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/dm.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/fw.c
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/fw.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/hw.c
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/hw.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/led.c
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/led.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/phy.c
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/phy.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/reg.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/rf.c
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/rf.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/sw.c
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/sw.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/table.c
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/table.h
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/trx.c
create mode 100644 drivers/net/wireless/rtlwifi/rtl8192de/trx.h
Omnibus patch is available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2011-07-05.patch.bz2
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Eric Dumazet @ 2011-07-05 20:15 UTC (permalink / raw)
To: Neil Horman
Cc: Alexey Zaytsev, Michael Büsch, Andrew Morton, netdev,
Gary Zambrano, bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <1309896147.2545.28.camel@edumazet-laptop>
Le mardi 05 juillet 2011 à 22:02 +0200, Eric Dumazet a écrit :
> Le mardi 05 juillet 2011 à 15:53 -0400, Neil Horman a écrit :
> > I think this is a goo idea, at least for testing. It seems odd to me that we
> > have the B44_DMARX_PTR value which indicates (ostensibly) the pointer to the
> > descriptor to be processed next (the documentation isnt' very verbose on the
> > subject), along with the EOT bit on a descriptor. It seems like both the
> > register and the bit are capable of conveying the same (or at least overlapping)
> > information.
> >
> > I think what I'm having the most trouble with is understanding when the hw looks
> > at the EOT bit in the descriptor. If it completes a DMA and sees the EOT bit
> > set, does the next DMA occur to the descriptor pointed to by the DMARX_ADDR
> > register? Of does it stall until such time as the DMARX_PTR register is rotated
> > around? What if it doesn't see the EOT bit set? Does it just keep going with
> > the next descriptor?
Since there is no OWN bit (at least not on the online doc I got : it
says the rx_ring is read only by the NIC), I would say we really need to
advance DMARX_PTR to signal NIC a new entry is available for following
incoming frames.
This is the reason rx_pending max value is B44_RX_RING_SIZE - 1, or else
chip could loop on a circular rx_ring.
^ permalink raw reply
* Re: libpcap and tc filters
From: Adam Katz @ 2011-07-05 20:07 UTC (permalink / raw)
To: jhs; +Cc: Eric Dumazet, netdev
In-Reply-To: <1309893553.1733.41.camel@mojatatu>
I don't think so. I tried different versions of tcpreplay.
The solution didn't work on 3 different ubuntu 10.04 machines with
2.6.32-32 (actually one of them had 2.6.32-31) but it DID work on a
fedora core 15 virtual machine with a newer kernel as well as a second
virtual machine with on which I installed stock ubuntu 11.04 just for
this test. It has 2.6.38 i think. On the last three machines (the
third ubuntu 10.04 as well as fc15 and ubuntu 11.04 tcpreplay came
straight from the repository).
Just to make myself clear - earlier, I tried the solution on a 10.04
physical box with various versions of tcpreplay, libpcap, and
iproute2. nothing worked.
On Tue, Jul 5, 2011 at 10:19 PM, jamal <hadi@cyberus.ca> wrote:
> On Tue, 2011-07-05 at 19:54 +0300, Adam Katz wrote:
>
>>
>> unless someone suggests a better solution, it seems like i'll be
>> adhering to the first law of engineering - "if it works, don't fix it"
>> and simply replace install fedora core 15 instead of ubuntu.
>
> My feeling is it has nothing to do with distro. Probably
> your tcpreplay?
>
> I am running ubuntu 10.04, but own compiled kernel (3.0-rc4).
> tcpreplay is older than Eric's version:
> --
> tcpreplay version: 3.4.3 (build 2375)
> Copyright 2001-2009 by Aaron Turner <aturner at synfin dot net>
> Cache file supported: 04
> Not compiled with libdnet.
> Compiled against libpcap: 1.0.0
> 64 bit packet counters: enabled
> Verbose printing via tcpdump: enabled
> Packet editing: disabled
> Fragroute engine: disabled
> Injection method: PF_PACKET send()
> ---
>
> cheers,
> jamal
>
>
^ permalink raw reply
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Eric Dumazet @ 2011-07-05 20:02 UTC (permalink / raw)
To: Neil Horman
Cc: Alexey Zaytsev, Michael Büsch, Andrew Morton, netdev,
Gary Zambrano, bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <20110705195353.GG2959@hmsreliant.think-freely.org>
Le mardi 05 juillet 2011 à 15:53 -0400, Neil Horman a écrit :
> I think this is a goo idea, at least for testing. It seems odd to me that we
> have the B44_DMARX_PTR value which indicates (ostensibly) the pointer to the
> descriptor to be processed next (the documentation isnt' very verbose on the
> subject), along with the EOT bit on a descriptor. It seems like both the
> register and the bit are capable of conveying the same (or at least overlapping)
> information.
>
> I think what I'm having the most trouble with is understanding when the hw looks
> at the EOT bit in the descriptor. If it completes a DMA and sees the EOT bit
> set, does the next DMA occur to the descriptor pointed to by the DMARX_ADDR
> register? Of does it stall until such time as the DMARX_PTR register is rotated
> around? What if it doesn't see the EOT bit set? Does it just keep going with
> the next descriptor?
>
> Also, there seems to be some inconsistency in the settnig of the B44_DMARX_PTR
> register. In bnx2_init_hw its set to the value of bp->rx_pending, which is
> defined as being 200. But in b44_rx its advanced by sizeof(struct dma_desc) for
> every iteration. So in b44_init_hw we write the value 200 to it, ostensibly
> indicating a limit of 200 descriptors, but in b44_rx we iteratively write the
> values 0, 8, 16, 24...4*n to the register to indicate which descriptor we're
> indexing? Something really doesn't sit right with me there. In the former case
> we treat the register as holding number of entries, and in the latter we treat
> it as holding a byte offset into an array. Or am I missing something?
>
Yes, definitely this needs some clarification.
More over, when we hit the last entry (currently at slot 511), the EOT
instructs hardware to go back to slot 0, while our real window is
511-200 -> 511 . Slot 0 contains garbage (well, an old value)
Its late here so I dont plan to send a patch before 8/10 hours.
^ permalink raw reply
* Re: coding style question on indentation
From: Joe Perches @ 2011-07-05 20:01 UTC (permalink / raw)
To: Chris Friesen; +Cc: Sathya.Perla, netdev
In-Reply-To: <4E136C0C.8010806@genband.com>
On Tue, 2011-07-05 at 13:54 -0600, Chris Friesen wrote:
> On 07/01/2011 09:23 AM, Joe Perches wrote:
> > I think this better:
> > 1 2 3 4 5 6 7 8
> > 12345678901234567890123456789012345678901234567890123456789012345678901234567890
> > dma_unmap_page(&adapter->pdev->dev, dma_unmap_addr(rx_page_info, bus),
> > adapter->big_page_size, DMA_FROM_DEVICE);
> > maximally fill to 80 cols, then wrap with maximal tabs using spaces
> > if necessary to align args after opening parenthesis.
> > In this case, 2 tabs, 7 spaces.
> I think the most flexible is to use hard tabs to align the continued
> line to the same level of indentation as the parent line, then use
> spaces for "pretty" alignment. That way, it all lines up regardless of
> how many spaces the viewer has set for the equivalent size of hard tabs.
True, but none of the common editing tools do this.
You could produce and publish emacs/vi modes for this
and then teach checkpatch to understand this mode and
not complain about the spacing if it matters that much
to you.
^ 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