* [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: [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
* 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 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 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
* [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: [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
* 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: 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: [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
* [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: [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
* [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: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
* 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: 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: [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: [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] gianfar v2: code cleanups
From: David Miller @ 2011-07-07 7:48 UTC (permalink / raw)
To: sebastian.belden; +Cc: netdev, joe, sebastian.poehn
In-Reply-To: <1309764900.3123.7.camel@DENEC1DT0191>
From: "Sebastian Pöhn" <sebastian.belden@googlemail.com>
Date: Mon, 04 Jul 2011 09:35:00 +0200
> This patch:
> # improves readability of some gianfar nfc code
>
> Signed-off-by: Sebastian Poehn <sebastian.poehn@belden.com>
Your email client has corrupted this patch, breaking up long
lines, etc.
Please read "Documentation/email-clients.txt" in the kernel
tree, and after following it's advice send a test email with
the patch to yourself. Verify that the patch you receive
in the email can be applied properly.
Only once you've passed this test should you attempt to resend
your patch here.
Thanks.
^ permalink raw reply
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Alexey Zaytsev @ 2011-07-07 7:45 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: <1310021286.2481.36.camel@edumazet-laptop>
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
^ permalink raw reply
* Re: [PATCH 0/4] skge: driver update
From: David Miller @ 2011-07-07 7:30 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20110707050003.998140428@vyatta.com>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 06 Jul 2011 22:00:04 -0700
> Add one pci id, and cleanup table.
> Make support for really old hardware optional.
All applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH net-next] net: doc: fix compile warning of no format arguments in ifenslave.c
From: David Miller @ 2011-07-07 7:28 UTC (permalink / raw)
To: shanwei; +Cc: rdunlap, netdev, linux-doc
In-Reply-To: <4E155A7F.6050008@cn.fujitsu.com>
From: Shan Wei <shanwei@cn.fujitsu.com>
Date: Thu, 07 Jul 2011 15:04:31 +0800
> Fix following warning in ifenslave.c with gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4).
...
> Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
Applied.
^ permalink raw reply
* [help] macb driver modification for direct mac-to-mac connection without phy -- Thanks
From: Xu Bingcan @ 2011-07-07 7:27 UTC (permalink / raw)
To: netdev; +Cc: Bingcan Xu
Hi, Guys
I am appreciate that anyone can give me some hint...
My Case Description:
I'm working with an Atmel ARM9 board (macb driver), that doesn't have
a PHY. The MAC is connected to a switch via MII. That MII link is
hard-wired to be 100M full-duplex.
I have a real, working MDIO bus.What I don't have is a PHY.I don't
want an emulated MDIO bus such as phy_fixed.
I found a mail thread about "Question about PHY-less board and
"fixed_phy"" in the linux netdev but no solution provided.
http://www.spinics.net/lists/netdev/msg143651.html
/* Not really PHY in our situation. Use a fake phy like fixed_phy
except a really MDIO to switch
* The switch IP175C uses the PHY addr 0-6 16 18 29 30 31. For more
detail information refer to IP175Cx-DS-R17-20081121.pdf.
* For simplity, the fake PHY use addr = FAKE_PHY_ADDR(19)
*/
I try to modify mdiobus_scan() so that it just allocate space and does
not register device for PHYADDR 19
at macb_mii_probe().. I replace the first found phy to my hardcode one
FAKE_PHY_ADDR(19)...
then I modify the macb_mdio_read() macb_mdio_write() to use my stub
function when addr == FAKE_PHY_ADDR.
But the traffic are lost when startup.
Thanks
Brs,
- Xu Bingcan
^ permalink raw reply
* Re: [Bugme-new] [Bug 38032] New: default values of /proc/sys/net/ipv4/udp_mem does not consider huge page allocation
From: David Miller @ 2011-07-07 7:27 UTC (permalink / raw)
To: eric.dumazet; +Cc: starlight, akpm, linux-mm, netdev, bugme-daemon, aquini
In-Reply-To: <1310013490.2481.35.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 07 Jul 2011 06:38:10 +0200
> [PATCH] net: refine {udp|tcp|sctp}_mem limits
>
> Current tcp/udp/sctp global memory limits are not taking into account
> hugepages allocations, and allow 50% of ram to be used by buffers of a
> single protocol [ not counting space used by sockets / inodes ...]
>
> Lets use nr_free_buffer_pages() and allow a default of 1/8 of kernel ram
> per protocol, and a minimum of 128 pages.
> Heavy duty machines sysadmins probably need to tweak limits anyway.
>
>
> References: https://bugzilla.stlinux.com/show_bug.cgi?id=38032
> Reported-by: starlight <starlight@binnacle.cx>
> Suggested-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
--
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 net-next] net: fix warning of versioncheck
From: David Miller @ 2011-07-07 7:26 UTC (permalink / raw)
To: shanwei; +Cc: netdev, eilong, sjur.brandeland
In-Reply-To: <4E152325.4050202@cn.fujitsu.com>
From: Shan Wei <shanwei@cn.fujitsu.com>
Date: Thu, 07 Jul 2011 11:08:21 +0800
>
> net-next-2.6/drivers/net/bnx2x/bnx2x_sp.c: 19 linux/version.h not needed.
> net-next-2.6/drivers/net/caif/caif_hsi.c: 9 linux/version.h not needed.
>
> Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
Applied.
^ 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