* [PATCH RESEND net-next v3 1/2] bonding: fail_over_mac should only affect AB mode at enslave and removal processing
From: Ding Tianhong @ 2014-01-25 5:00 UTC (permalink / raw)
To: Jay Vosburgh, Veaceslav Falico, David S. Miller, Netdev,
Andy Gospodarek
According to bonding.txt, the fail_over_ma should only affect active-backup mode,
but I found that the fail_over_mac could be set to active or follow in all
modes, this will cause new slave could not be set to bond's MAC address at
enslave processing and restore its own MAC address at removal processing.
The correct way to fix the problem is that we should not add restrictions when
setting options, just need to modify the bond enslave and removal processing
to check the mode in addition to fail_over_mac when setting a slave's MAC during
enslavement. The change active slave processing already only calls the fail_over_mac
function when in active-backup mode.
Thanks for Jay's suggestion.
The patch also modify the pr_warning() to pr_warn().
Cc: Jay Vosburgh <fubar@us.ibm.com>
Cc: Veaceslav Falico <vfalico@redhat.com>
Cc: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
---
drivers/net/bonding/bond_main.c | 22 +++++++++++++++-------
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 2ca949f..4409aa8 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1270,9 +1270,13 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
if (slave_ops->ndo_set_mac_address == NULL) {
if (!bond_has_slaves(bond)) {
- pr_warning("%s: Warning: The first slave device specified does not support setting the MAC address. Setting fail_over_mac to active.",
- bond_dev->name);
- bond->params.fail_over_mac = BOND_FOM_ACTIVE;
+ pr_warn("%s: Warning: The first slave device specified does not support setting the MAC address.\n",
+ bond_dev->name);
+ if (bond->params.mode == BOND_MODE_ACTIVEBACKUP) {
+ bond->params.fail_over_mac = BOND_FOM_ACTIVE;
+ pr_warn("%s: Setting fail_over_mac to active for active-backup mode.\n",
+ bond_dev->name);
+ }
} else if (bond->params.fail_over_mac != BOND_FOM_ACTIVE) {
pr_err("%s: Error: The slave device specified does not support setting the MAC address, but fail_over_mac is not set to active.\n",
bond_dev->name);
@@ -1315,7 +1319,8 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
*/
memcpy(new_slave->perm_hwaddr, slave_dev->dev_addr, ETH_ALEN);
- if (!bond->params.fail_over_mac) {
+ if (!bond->params.fail_over_mac ||
+ bond->params.mode != BOND_MODE_ACTIVEBACKUP) {
/*
* Set slave to master's mac address. The application already
* set the master's mac address to that of the first slave
@@ -1579,7 +1584,8 @@ err_close:
dev_close(slave_dev);
err_restore_mac:
- if (!bond->params.fail_over_mac) {
+ if (!bond->params.fail_over_mac ||
+ bond->params.mode != BOND_MODE_ACTIVEBACKUP) {
/* XXX TODO - fom follow mode needs to change master's
* MAC if this slave's MAC is in use by the bond, or at
* least print a warning.
@@ -1672,7 +1678,8 @@ static int __bond_release_one(struct net_device *bond_dev,
bond->current_arp_slave = NULL;
- if (!all && !bond->params.fail_over_mac) {
+ if (!all && (!bond->params.fail_over_mac ||
+ bond->params.mode != BOND_MODE_ACTIVEBACKUP)) {
if (ether_addr_equal_64bits(bond_dev->dev_addr, slave->perm_hwaddr) &&
bond_has_slaves(bond))
pr_warn("%s: Warning: the permanent HWaddr of %s - %pM - is still in use by %s. Set the HWaddr of %s to a different address to avoid conflicts.\n",
@@ -1769,7 +1776,8 @@ static int __bond_release_one(struct net_device *bond_dev,
/* close slave before restoring its mac address */
dev_close(slave_dev);
- if (bond->params.fail_over_mac != BOND_FOM_ACTIVE) {
+ if (bond->params.fail_over_mac != BOND_FOM_ACTIVE ||
+ bond->params.mode != BOND_MODE_ACTIVEBACKUP) {
/* restore original ("permanent") mac address */
memcpy(addr.sa_data, slave->perm_hwaddr, ETH_ALEN);
addr.sa_family = slave_dev->type;
--
1.8.0
^ permalink raw reply related
* [PATCH RESEND net-next] bonding: don't permit slaves to change their mtu independently
From: Ding Tianhong @ 2014-01-25 4:55 UTC (permalink / raw)
To: Jay Vosburgh, Veaceslav Falico, Andy Gospodarek, David S. Miller,
Netdev
I have come to a conclusion by testing all modes for mtu changing:
1). If the slaves support changing mtu and no need to restart the device,
just like virtual nic, the master will not lost any packages for all
mode.
2). If the slaves support changing mtu and need to restart the device,
just like Intel 82599, the AB, 802.3, ALB and TLB mode may lost
packages, but other modes could work well.
The reason is that when the slave's mtu has been changed, the slave's hw will
restart, if the slave is current active slave, the master may set the
slave to backup state and reselect a new slave, after the reselect processing,
the master could work again, but if in load-balance mode, the master could
select another active slave to send and recv packages.
So the best way to fix the problem is don't permit slave to change their
mtu independently.
Cc: Jay Vosburgh <fubar@us.ibm.com>
Cc: Veaceslav Falico <vfalico@redhat.com>
Cc: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
---
drivers/net/bonding/bond_main.c | 18 +++++-------------
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 2ca949f..e127031c 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -2808,20 +2808,12 @@ static int bond_slave_netdev_event(unsigned long event,
* ... Or is it this?
*/
break;
- case NETDEV_CHANGEMTU:
- /*
- * TODO: Should slaves be allowed to
- * independently alter their MTU? For
- * an active-backup bond, slaves need
- * not be the same type of device, so
- * MTUs may vary. For other modes,
- * slaves arguably should have the
- * same MTUs. To do this, we'd need to
- * take over the slave's change_mtu
- * function for the duration of their
- * servitude.
+ case NETDEV_PRECHANGEMTU:
+ /* The master and slaves should have the
+ * same mtu, so don't permit slaves to
+ * change their mtu independently.
*/
- break;
+ return NOTIFY_BAD;
case NETDEV_CHANGENAME:
/* we don't care if we don't have primary set */
if (!USES_PRIMARY(bond->params.mode) ||
--
1.8.0
^ permalink raw reply related
* Re: [PATCH net-next v3 0/2] bonding: Fix some issues for fail_over_mac
From: Ding Tianhong @ 2014-01-25 4:56 UTC (permalink / raw)
To: David Miller; +Cc: fubar, vfalico, netdev, andy
In-Reply-To: <20140124.180427.1942816445484474722.davem@davemloft.net>
On 2014/1/25 10:04, David Miller wrote:
> From: Ding Tianhong <dingtianhong@huawei.com>
> Date: Fri, 24 Jan 2014 12:27:28 +0800
>
>> So set the fail_over_mac to none if the mode is not active-backup and
>> slight optimization for bond_set_mac_address().
>
> This is no longer how your series fixes the problem, please fix this
> text and resubmit.
>
>
OK, sorry for that.
^ permalink raw reply
* Re: [PATCH net-next v3 0/2] bonding: Fix some issues for fail_over_mac
From: David Miller @ 2014-01-25 2:04 UTC (permalink / raw)
To: dingtianhong; +Cc: fubar, vfalico, netdev, andy
In-Reply-To: <52E1EBB0.6040505@huawei.com>
From: Ding Tianhong <dingtianhong@huawei.com>
Date: Fri, 24 Jan 2014 12:27:28 +0800
> So set the fail_over_mac to none if the mode is not active-backup and
> slight optimization for bond_set_mac_address().
This is no longer how your series fixes the problem, please fix this
text and resubmit.
^ permalink raw reply
* Re: [PATCH v5] can: add Renesas R-Car CAN driver
From: Sergei Shtylyov @ 2014-01-25 1:34 UTC (permalink / raw)
To: Marc Kleine-Budde, netdev, wg, linux-can; +Cc: linux-sh, vksavl
In-Reply-To: <52DCE9E4.7010209@pengutronix.de>
Hello.
On 01/20/2014 12:18 PM, Marc Kleine-Budde wrote:
>> Add support for the CAN controller found in Renesas R-Car SoCs.
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>> ---
>> The patch is against the 'linux-can-next.git' repo.
[...]
>> Index: linux-can-next/drivers/net/can/rcar_can.c
>> ===================================================================
>> --- /dev/null
>> +++ linux-can-next/drivers/net/can/rcar_can.c
>> @@ -0,0 +1,857 @@
[...]
>> +/* Mailbox registers structure */
>> +struct rcar_can_mbox_regs {
>> + u32 id; /* IDE and RTR bits, SID and EID */
>> + u8 stub; /* Not used */
>> + u8 dlc; /* Data Length Code - bits [0..3] */
>> + u8 data[8]; /* Data Bytes */
>> + u8 tsh; /* Time Stamp Higher Byte */
>> + u8 tsl; /* Time Stamp Lower Byte */
>> +} __packed;
> If you have contact to the hardware designer please blame him for
Unfortunately, we don't.
> placing the data register unaligned into the register space. :)
It's not even the only one or worst example of questionable register
design in this module IMO.
[...]
>> +static void rcar_can_tx_done(struct net_device *ndev)
>> +{
>> + struct rcar_can_priv *priv = netdev_priv(ndev);
>> + struct net_device_stats *stats = &ndev->stats;
>> + int i;
>> +
>> + spin_lock(&priv->skb_lock);
>> + for (i = 0; i < priv->frames_queued; i++)
>> + can_get_echo_skb(ndev, i);
>> + stats->tx_bytes += priv->bytes_queued;
>> + stats->tx_packets += priv->frames_queued;
>> + priv->bytes_queued = 0;
>> + priv->frames_queued = 0;
>> + spin_unlock(&priv->skb_lock);
> This looks broken. What happens if you send 2 CAN frames in a row, the
> first one is send, a TX complete interrupt is issued and you handle it
> here? You assume, that all CAN frames have been sent.
TX interrupt will be issued only when TX FIFO gets empty (all 2 frames
have been transmitted in this case). Please see the comment to the
RCAR_CAN_MIER1_TXFIT bit.
>> +static irqreturn_t rcar_can_interrupt(int irq, void *dev_id)
>> +{
>> + struct net_device *ndev = (struct net_device *)dev_id;
> the cast is not needed
Removed.
[...]
>> +static void rcar_can_set_bittiming(struct net_device *dev)
>> +{
>> + struct rcar_can_priv *priv = netdev_priv(dev);
>> + struct can_bittiming *bt = &priv->can.bittiming;
>> + u32 bcr;
>> + u8 clkr;
>> +
>> + /* Don't overwrite CLKR with 32-bit BCR access */
>> + /* CLKR has 8-bit access */
> Can you explain the register layout here? Why do you access BCR with 32
> bits when the register is defined as 3x8 bit? Can't you make it a
> standard 32 bit register?
1. According to documentation BCR is the 24-bit register.
Actually we can consider some 32-bit register that combines BCR and
CLKR but according to documentation there are two separate registers.
2. BCR has 8- ,16-, and 32-bit access (according to documentation).
3. This is the algorithm that the documentation suggests.
4. We had a driver version with byte access but 32-bit access seems shorter.
>> +static void rcar_can_start(struct net_device *ndev)
>> +{
>> + struct rcar_can_priv *priv = netdev_priv(ndev);
>> + u16 ctlr, str;
>> +
>> + /* Set controller to known mode:
>> + * - FIFO mailbox mode
>> + * - accept all messages
>> + * - overrun mode
>> + * CAN is in sleep mode after MCU hardware or software reset.
>> + */
>> + ctlr = readw(&priv->regs->ctlr);
>> + ctlr &= ~RCAR_CAN_CTLR_SLPM;
>> + writew(ctlr, &priv->regs->ctlr);
>> + /* Go to reset mode */
>> + ctlr |= RCAR_CAN_CTLR_CANM_FORCE_RESET;
>> + writew(ctlr, &priv->regs->ctlr);
>> + do {
>> + str = readw(&priv->regs->str);
>> + } while (!(str & RCAR_CAN_STR_RSTST));
> Please add a timeout for this loop and the loop below.
Added a counter, converted the loop to *for*.
>> +static int rcar_can_open(struct net_device *ndev)
>> +{
>> + struct rcar_can_priv *priv = netdev_priv(ndev);
>> + int err;
>> +
>> + clk_prepare_enable(priv->clk);
> clk_prepare_enable can fail
Added check.
>> + err = open_candev(ndev);
>> + if (err) {
>> + netdev_err(ndev, "open_candev() failed %d\n", err);
>> + goto out;
> please adjust the jump label, you have to disable the clock.
Fixed.
[...]
>> +static void rcar_can_stop(struct net_device *ndev)
>> +{
>> + struct rcar_can_priv *priv = netdev_priv(ndev);
>> + u16 ctlr, str;
>> +
>> + /* Go to (force) reset mode */
>> + ctlr = readw(&priv->regs->ctlr);
>> + ctlr |= RCAR_CAN_CTLR_CANM_FORCE_RESET;
>> + writew(ctlr, &priv->regs->ctlr);
>> + do {
>> + str = readw(&priv->regs->str);
>> + } while (!(str & RCAR_CAN_STR_RSTST));
> please add a timeout to the loop
Added a counter and converted to *for*.
[...]
>> +static netdev_tx_t rcar_can_start_xmit(struct sk_buff *skb,
>> + struct net_device *ndev)
>> +{
>> + struct rcar_can_priv *priv = netdev_priv(ndev);
>> + struct can_frame *cf = (struct can_frame *)skb->data;
>> + u32 data, i;
>> + unsigned long flags;
>> + u8 tfcr;
>> +
>> + if (can_dropped_invalid_skb(ndev, skb))
>> + return NETDEV_TX_OK;
>> + tfcr = readb(&priv->regs->tfcr);
>> + if ((tfcr & RCAR_CAN_TFCR_TFUST) >> RCAR_CAN_TFCR_TFUST_SHIFT > 2)
>> + netif_stop_queue(ndev);
> Can you explain what's checked here?
if (<Number of unsent massages in Transmit FIFO> > 2)
FIFO depth = 4.
Added a comment. Changed to >= 3.
>> +
>> + if (cf->can_id & CAN_EFF_FLAG) {
>> + /* Extended frame format */
>> + data = (cf->can_id & CAN_EFF_MASK) | RCAR_CAN_IDE;
>> + } else {
>> + /* Standard frame format */
>> + data = (cf->can_id & CAN_SFF_MASK) << RCAR_CAN_SID_SHIFT;
>> + }
>> + if (cf->can_id & CAN_RTR_FLAG) {
>> + /* Remote transmission request */
>> + data |= RCAR_CAN_RTR;
>> + }
> You can move the comments into the line of if and else and remove the {
> & } as there is only one line after if and else.
Done.
>> + writel(data, &priv->regs->mb[RCAR_CAN_TX_FIFO_MBX].id);
>> +
>> + writeb(cf->can_dlc, &priv->regs->mb[RCAR_CAN_TX_FIFO_MBX].dlc);
>> +
>> + for (i = 0; i < cf->can_dlc; i++)
>> + writeb(cf->data[i],
>> + &priv->regs->mb[RCAR_CAN_TX_FIFO_MBX].data[i]);
>> +
>> + spin_lock_irqsave(&priv->skb_lock, flags);
>> + can_put_echo_skb(skb, ndev, priv->frames_queued++);
>> + priv->bytes_queued += cf->can_dlc;
> How does the frames_queued and bytes_queued mechanism work?
Explained above, we get TX interrupt only after all queued packets are sent.
>> + spin_unlock_irqrestore(&priv->skb_lock, flags);
>> + /* Start Tx: write 0xFF to the TFPCR register to increment
>> + * the CPU-side pointer for the transmit FIFO to the next
>> + * mailbox location
>> + */
>> + writeb(0xFF, &priv->regs->tfpcr);
> please use lowercase for hex.
Done here ind in comment above.
>> +
>> + return NETDEV_TX_OK;
> I'm missing flow control here. You have to stop the queue if there isn't
> any room in the tx fifo.
You've seen it above.
[...]
>> +static int rcar_can_rx_poll(struct napi_struct *napi, int quota)
>> +{
>> + struct rcar_can_priv *priv = container_of(napi,
>> + struct rcar_can_priv, napi);
>> + int num_pkts = 0;
>> +
>> + while (num_pkts < quota) {
>> + u8 i, rfcr, nframes, isr;
>> +
>> + isr = readb(&priv->regs->isr);
>> + /* Clear interrupt bit */
>> + if (isr & RCAR_CAN_ISR_RXFF)
>> + writeb(isr & ~RCAR_CAN_ISR_RXFF, &priv->regs->isr);
>> + rfcr = readb(&priv->regs->rfcr);
>> + if (rfcr & RCAR_CAN_RFCR_RFEST)
>> + break;
>> + nframes = (rfcr & RCAR_CAN_RFCR_RFUST) >>
>> + RCAR_CAN_RFCR_RFUST_SHIFT;
>> + for (i = 0; i < nframes; i++) {
>> + rcar_can_rx_pkt(priv);
>> + /* Write 0xFF to the RFPCR register to increment
>> + * the CPU-side pointer for the receive FIFO
>> + * to the next mailbox location
>> + */
>> + writeb(0xFF, &priv->regs->rfpcr);
>> + ++num_pkts;
>> + }
> The for loop inside the while loop makes no sense if you increment
> num_pkts. You are not allowed to receive more than quota CAN frames.
Removed the *for* loop. Stupid me. :-)
>> +static int rcar_can_get_berr_counter(const struct net_device *dev,
>> + struct can_berr_counter *bec)
>> +{
>> + struct rcar_can_priv *priv = netdev_priv(dev);
>> +
>> + clk_prepare_enable(priv->clk);
> clk_prepare_enable can fail
Fixed.
[...]
>> +static int rcar_can_resume(struct device *dev)
>> +{
>> + struct net_device *ndev = dev_get_drvdata(dev);
>> + struct rcar_can_priv *priv = netdev_priv(ndev);
>> + u16 ctlr;
>> +
>> + clk_enable(priv->clk);
Added error check.
[...]
>> Index: linux-can-next/include/linux/can/platform/rcar_can.h
>> ===================================================================
>> --- /dev/null
>> +++ linux-can-next/include/linux/can/platform/rcar_can.h
>> @@ -0,0 +1,15 @@
>> +#ifndef _CAN_PLATFORM_RCAR_CAN_H_
>> +#define _CAN_PLATFORM_RCAR_CAN_H_
>> +
>> +#include <linux/types.h>
>> +
>> +/* Clock Select Register settings */
>> +#define CLKR_CLKEXT 3 /* Externally input clock */
>> +#define CLKR_CLKP2 1 /* Peripheral clock (clkp2) */
>> +#define CLKR_CLKP1 0 /* Peripheral clock (clkp1) */
> Please make it an enum
Done.
WBR, Sergei
^ permalink raw reply
* Re: r8169 won't transmit with 3.12
From: Craig Small @ 2014-01-25 0:59 UTC (permalink / raw)
To: Francois Romieu; +Cc: Realtek linux nic maintainers, netdev
In-Reply-To: <20140124002525.GA29384@electric-eye.fr.zoreil.com>
On Fri, Jan 24, 2014 at 01:25:25AM +0100, Francois Romieu wrote:
> > [ 0.000000] DMI: Gigabyte Technology Co., Ltd. To be filled by O.E.M./970A-D3P, BIOS F3 05/24/2013
> (8168evl on a fairly recent motherboard, bios could be upgraded)
Done!
[ 0.000000] DMI: Gigabyte Technology Co., Ltd. To be filled by
O.E.M./970A-D3P, BIOS F5 08/06/2013
> Did you enable the iommu in the setup ? If not, please give it a try.
That caused some excitement...
I got a page of AMD-Vi Event logged IO_PAGE_FAULT device 02:00.0 domain
0016 messages.
And then it sat at "waiting for /dev to be fully populated"
The keyboard seemed dead at that point. I'm not sure of the exact
message and if it is important I can make it die again.
I had to turn that off to get anywhere. Then we were back where we
started.
[ 97.797982] WARNING: CPU: 4 PID: 0 at /build/linux-xS3nxO/linux-3.12.6/net/sched/sch_generic.c:264 dev_watchdog+0x226/0x230()
[ 97.797989] NETDEV WATCHDOG: eth6 (r8169): transmit queue 0 timed out
I've also at times rebuilt the r8169 module to add more printk lines.
I can tell you that each packet makes it to rtl8169_start_xmit and
returns NETDEV_TX_OK because the number of printk lines for my enter
and exit equal the number of tx dropped packets.
What you are seeing though is from the stock Debian kernel module. If
you have a test module code you want me to run, let me know.
- Craig
--
Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au
Debian GNU/Linux http://www.debian.org/ csmall at : debian.org
GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5
^ permalink raw reply
* Re: [PATCH] net/cxgb4: Fix referencing freed adapter
From: David Miller @ 2014-01-25 0:00 UTC (permalink / raw)
To: shangw; +Cc: netdev
In-Reply-To: <1390554723-15285-1-git-send-email-shangw@linux.vnet.ibm.com>
From: Gavin Shan <shangw@linux.vnet.ibm.com>
Date: Fri, 24 Jan 2014 17:12:03 +0800
> The adapter is freed before we check its flags. It was caused
> by commit 144be3d ("net/cxgb4: Avoid disabling PCI device for
> towice"). The problem was reported by Intel's "0-day" tool.
>
> The patch fixes it to avoid reverting commit 144be3d.
>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net v2] ipv6: reallocate addrconf router for ipv6 address when lo device up
From: David Miller @ 2014-01-25 0:00 UTC (permalink / raw)
To: gaofeng; +Cc: netdev, sd, hannes, chenweilong
In-Reply-To: <1390552151-20735-1-git-send-email-gaofeng@cn.fujitsu.com>
From: Gao feng <gaofeng@cn.fujitsu.com>
Date: Fri, 24 Jan 2014 16:29:11 +0800
> commit 25fb6ca4ed9cad72f14f61629b68dc03c0d9713f
> "net IPv6 : Fix broken IPv6 routing table after loopback down-up"
> allocates addrconf router for ipv6 address when lo device up.
> but commit a881ae1f625c599b460cc8f8a7fcb1c438f699ad
> "ipv6:don't call addrconf_dst_alloc again when enable lo" breaks
> this behavior.
>
> Since the addrconf router is moved to the garbage list when
> lo device down, we should release this router and rellocate
> a new one for ipv6 address when lo device up.
>
> This patch solves bug 67951 on bugzilla
> https://bugzilla.kernel.org/show_bug.cgi?id=67951
>
> change from v1:
> use ip6_rt_put to repleace ip6_del_rt, thanks Hannes!
> change code style, suggested by Sergei.
>
> CC: Sabrina Dubroca <sd@queasysnail.net>
> CC: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Reported-by: Weilong Chen <chenweilong@huawei.com>
> Signed-off-by: Weilong Chen <chenweilong@huawei.com>
> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
Applied and queued up for -stable, thanks!
^ permalink raw reply
* Re: critic on documentation of the network stack
From: Stephen Hemminger @ 2014-01-24 23:58 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: netdev
In-Reply-To: <20140124032324.GO7269@order.stressinduktion.org>
On Fri, 24 Jan 2014 04:23:24 +0100
Hannes Frederic Sowa <hannes@stressinduktion.org> wrote:
> Hello!
>
> After net-next is closed I wanted to put the following link here:
>
> <http://linux.slashdot.org/comments.pl?sid=4356053&cid=45184693>
The problem I have is more that there are more incorrect sources of documentation
and differing opinions on the Internet. Maybe the problem is users, maybe the
problem is lack of SEO, or developers not being paid to write documentation, or
old web sites not being updated. For example, this commenter obviously never
found http://www.lartc.org/
^ permalink raw reply
* Re: [PATCH stable 3.7+] fib_frontend: fix possible NULL pointer dereference
From: David Miller @ 2014-01-24 23:52 UTC (permalink / raw)
To: socketcan; +Cc: eric.dumazet, netdev
In-Reply-To: <52E0DEA6.3060803@hartkopp.net>
From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Thu, 23 Jan 2014 10:19:34 +0100
> The two commits 0115e8e30d (net: remove delay at device dismantle) and
> 748e2d9396a (net: reinstate rtnl in call_netdevice_notifiers()) silently
> removed a NULL pointer check for in_dev since Linux 3.7.
>
> This patch re-introduces this check as it causes crashing the kernel when
> setting small mtu values on non-ip capable netdevices.
>
> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: Force ACK each received tcp segment under no condition
From: Vincent Li @ 2014-01-24 23:47 UTC (permalink / raw)
To: Vincent Li, netdev@vger.kernel.org
In-Reply-To: <20140124232547.GS7269@order.stressinduktion.org>
I tried 'TCP_QUICKACK' with libhttpd.c in thttpd, seems no effect,
that is why I want to go to the extreme route to make it in kernel to
do that always, there is really no good reason for this, I just want
to test the effect of ACK each segment under no condition in my
personal lab for some effect i am looking for.
Vincent
On Fri, Jan 24, 2014 at 3:25 PM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> On Fri, Jan 24, 2014 at 03:18:19PM -0800, Vincent Li wrote:
>> I know this sounds really silly, but I would like to do such test to
>> meet my curiosity. is that all I need to do?
>
> Isn't quick ack mode what you're looking for (bcefe17cffd "tcp:
> introduce a per-route knob for quick ack"), also settable per setsockopt
> TCP_QUICKACK?
>
> Greetings,
>
> Hannes
>
^ permalink raw reply
* Re: critic on documentation of the network stack
From: Richard Weinberger @ 2014-01-24 23:44 UTC (permalink / raw)
To: netdev@vger.kernel.org
In-Reply-To: <20140124032324.GO7269@order.stressinduktion.org>
On Fri, Jan 24, 2014 at 4:23 AM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> Hello!
>
> After net-next is closed I wanted to put the following link here:
>
> <http://linux.slashdot.org/comments.pl?sid=4356053&cid=45184693>
>
> I don't want to start a flamefest or come too close to someone but I
> fear some of the critic is reasonable. Maybe we can do better (I have
> to admit, I also hate writing documentation, e.g. have not yet send the
> IP_PMTUDISC_INTERFACE man-page patches).
>
> I try to start with some constructive discussion:
>
> There are some great features in the network stack that some people miss
> because of lack documentation. One possible solution is documentation
> directly in the kernel, but mostly this is just written as a reference
> and the real wonderful stuff is only achieved by putting lots of those
> features correclty together.
>
> Maybe this is the second or third time this was proposed but I'll try
> again: Would it make sense to just start slow and setup a wiki where we
> just throw in the various snippets we use for testing while developing
> patches, maybe with a bit of background information? This may well attract
> interested people outside of netdev@ which could start helping cleaning
> up the wiki or add more useful documentation on their own. We could
> check from time to time what could be fed back into Documentation/? The
> reason why I would definitely help to improve the wiki is because I
> am sure I can learn from other setups and testing methodologies, too,
> and definitely still have not yet seen everything what is possible with
> the linux network stack.
I fully agree with you. Kernel features without userspace docs suck.
I'm not sure whether a wiki is a good idea but at least the manpages
be kept in sync.
The tcp socket option TCP_CONGESTION is such a case.
Kernel implemenation was added by:
commit 5f8ef48d240963093451bcf83df89f1a1364f51d
Author: Stephen Hemminger <shemminger@osdl.org>
Date: Thu Jun 23 20:37:36 2005 -0700
[TCP]: Allow choosing TCP congestion control via sockopt.
Allow using setsockopt to set TCP congestion control to use on a per
socket basis.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Linux manpages tell about the feature since:
commit d6d58656220f3ee24990e88dd9f37967a46fb290
Author: Michael Kerrisk <mtk.manpages@gmail.com>
Date: Fri Nov 21 12:29:37 2008 -0500
tcp.7: Document /proc file tcp_allowed_congestion_control (new in
Linux 2.4.20)
Text taken from Documentation/networking/ip-sysctl.txt
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
and finally:
commit bf561a0fbcfed101aea2d523fe5cd50e90273786
Author: Michael Kerrisk <mtk.manpages@gmail.com>
Date: Thu Jan 23 05:11:10 2014 +0100
tcp.7: Document TCP_CONGESTION
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
A hardcore net/ hacker may know all nice features but joey random
network programer
just reads the manpages...
--
Thanks,
//richard
^ permalink raw reply
* Re: Force ACK each received tcp segment under no condition
From: Hannes Frederic Sowa @ 2014-01-24 23:25 UTC (permalink / raw)
To: Vincent Li; +Cc: netdev@vger.kernel.org
In-Reply-To: <CAK3+h2wd5gEp9oDMZpte-Ed2M3eGSzdkuMJuvk24p=9JcjAzAg@mail.gmail.com>
On Fri, Jan 24, 2014 at 03:18:19PM -0800, Vincent Li wrote:
> I know this sounds really silly, but I would like to do such test to
> meet my curiosity. is that all I need to do?
Isn't quick ack mode what you're looking for (bcefe17cffd "tcp:
introduce a per-route knob for quick ack"), also settable per setsockopt
TCP_QUICKACK?
Greetings,
Hannes
^ permalink raw reply
* Force ACK each received tcp segment under no condition
From: Vincent Li @ 2014-01-24 23:18 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hi
I know this sounds really silly, but I would like to do such test to
meet my curiosity. is that all I need to do?
static void __tcp_ack_snd_check(struct sock *sk, int ofo_possible)
{
struct tcp_sock *tp = tcp_sk(sk);
/* More than one full frame received... */
if (((tp->rcv_nxt - tp->rcv_wup) > inet_csk(sk)->icsk_ack.rcv_mss
/* ... and right edge of window advances far enough.
* (tcp_recvmsg() will send ACK otherwise). Or...
*/
&& __tcp_select_window(sk) >= tp->rcv_wnd) ||
/* We ACK each frame or... */
tcp_in_quickack_mode(sk) ||
/* We have out of order data. */
(ofo_possible && skb_peek(&tp->out_of_order_queue))) {
/* Then ack it now */
tcp_send_ack(sk);
} else {
/* Else, send delayed ack. */
//tcp_send_delayed_ack(sk);
tcp_send_ack(sk);
}
}
^ permalink raw reply
* Re: [PATCH 4/4 v3] ipv4: mark nexthop as dead when it's subnet becomes unreachable
From: Julian Anastasov @ 2014-01-24 21:49 UTC (permalink / raw)
To: Sergey Popovich; +Cc: netdev
In-Reply-To: <1521507.ObZglEaf1D@tuxracer>
Hello,
On Fri, 24 Jan 2014, Sergey Popovich wrote:
> -int fib_sync_down_dev(struct net_device *dev, int force)
> +static inline bool fib_sync_down_gw(struct fib_nh *nh,
> + struct in_ifaddr *ifr)
> +{
> + if (!ifr)
> + return true;
> +
> + if (nh->nh_flags & RTNH_F_ONLINK)
> + return false;
> +
> + if (!inet_ifa_match(nh->nh_gw, ifr))
> + return false;
> +
You need to walk subnets here, not IPs, so
for_primary_ifa() instead of for_ifa() will save some
cycles. But for me such change still looks expensive
and does not fix the root of the problem:
- You fix the problem from IP address point of view.
The actual problem is that subnet is removed, i.e.
it is the route removal that is making GWs unreachable.
I can ip route delete some link route and cause GWs
to become unreachable.
- not sure that walking the ifa_list is a fast operation
- sadly, the NHs can not survive the secondary address
promotion as done in __inet_del_ifa().
You can have additional optimization in
fib_del_ifaddr() while calling fib_sync_down_dev():
do nothing if secondary address is deleted because its
subnet (primary address) should be present. For example:
if (fib_sync_down_addr(dev_net(dev), ifa->ifa_local) |
(!(ifa->ifa_flags & IFA_F_SECONDARY) &&
fib_sync_down_dev(dev, ifa, 0)))
> + for_ifa(ifr->ifa_dev) {
Below ifa == ifr check will not be needed when
for_primary_ifa() is used or when fib_sync_down_dev() is
called only for primary IPs. We can see some ifr in the
list only if it is secondary IP deleted during the promotion
process. Without promotion, the primary/secondary ifa is
unlinked before the NETDEV_DOWN notification and we do
not see it here.
> + if (unlikely(ifa == ifr))
> + continue;
> + if (inet_ifa_match(nh->nh_gw, ifa))
> + return false;
> + } endfor_ifa(ifr->ifa_dev);
> +
> + return true;
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [patch 1/3] qeth: bridgeport support - basic control
From: Paul Gortmaker @ 2014-01-24 21:23 UTC (permalink / raw)
To: frank.blaschka
Cc: David Miller, netdev, linux-s390, Eugene Crosser, Ursula Braun
In-Reply-To: <20140114145509.287096531@de.ibm.com>
On Tue, Jan 14, 2014 at 9:54 AM, <frank.blaschka@de.ibm.com> wrote:
> From: Eugene Crosser <Eugene.Crosser@ru.ibm.com>
>
> Introduce functions to assign roles and check state of bridgeport-capable
> HiperSocket devices, and sysfs attributes providing access to these
> functions from userspace. Introduce udev events emitted when the state
> of a bridgeport device changes.
>
> Signed-off-by: Eugene Crosser <eugene.crosser@ru.ibm.com>
> Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
> Reviewed-by: Ursula Braun <ursula.braun@de.ibm.com>
Hi Eugene,
This commit breaks the linux-next builds of s390 allmodconfig:
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[b4d72c08b358fc5b259fad0f4971112d949efd1c] qeth: bridgeport support -
basic control
running ./x
scripts/kconfig/conf --allmodconfig Kconfig
#
# configuration written to .config
#
ERROR: "qeth_wq" [drivers/s390/net/qeth_l2.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
b4d72c08b358fc5b259fad0f4971112d949efd1c is the first bad commit
commit b4d72c08b358fc5b259fad0f4971112d949efd1c
Author: Eugene Crosser <Eugene.Crosser@ru.ibm.com>
Date: Tue Jan 14 15:54:11 2014 +0100
qeth: bridgeport support - basic control
Introduce functions to assign roles and check state of bridgeport-capable
HiperSocket devices, and sysfs attributes providing access to these
functions from userspace. Introduce udev events emitted when the state
of a bridgeport device changes.
Signed-off-by: Eugene Crosser <eugene.crosser@ru.ibm.com>
Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com>
Reviewed-by: Ursula Braun <ursula.braun@de.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
:040000 040000 1eb4205806a03dbc3de37af46e9447168b0d0e2a
0ba638a94d92c41d732bedc54c8108775f689cf3 M Documentation
:040000 040000 9a9eb7da725785bfe40c77cdee4c181c90f74ef3
f7e69854a168599f2f191675b449783292b0a4a1 M drivers
bisect run success
http://kisskb.ellerman.id.au/kisskb/buildresult/10509367/
Paul.
--
> ---
> Documentation/s390/qeth.txt | 21 +++
> drivers/s390/net/Makefile | 2 +-
> drivers/s390/net/qeth_core.h | 25 +++
> drivers/s390/net/qeth_core_main.c | 14 +-
> drivers/s390/net/qeth_core_mpc.c | 1 +
> drivers/s390/net/qeth_core_mpc.h | 84 +++++++++
> drivers/s390/net/qeth_l2.h | 15 ++
> drivers/s390/net/qeth_l2_main.c | 364 ++++++++++++++++++++++++++++++++++++++
> drivers/s390/net/qeth_l2_sys.c | 161 +++++++++++++++++
> 9 files changed, 685 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/s390/qeth.txt
> create mode 100644 drivers/s390/net/qeth_l2.h
> create mode 100644 drivers/s390/net/qeth_l2_sys.c
>
>
^ permalink raw reply
* Re: pull request: wireless-next 2014-01-24
From: David Miller @ 2014-01-24 21:04 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20140124193933.GL4309@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Fri, 24 Jan 2014 14:39:33 -0500
> Please pull these fixes for the 3.14 stream!
Pulled, thanks John.
^ permalink raw reply
* Re: IPV6 routing problem
From: Cong Wang @ 2014-01-24 20:05 UTC (permalink / raw)
To: Sharat Masetty; +Cc: Emmanuel Thierry, netdev
In-Reply-To: <CAJzFV34vJTCV+-rwH+TE1oB0qiUw1PuqgAWpm8U1Xe_xAv-_BA@mail.gmail.com>
On Fri, Jan 24, 2014 at 10:50 AM, Sharat Masetty <sharat04@gmail.com> wrote:
> A general question, Can you suggest a good reference documentation to
> understand the Linux kernel IPV6 routing and neighboring subsystem
> better? The O Reilly book does not have much about IPV6.
Rami Rosen is writing a book on Linux networking which covers IPv6
as well. You can also search on Internet for his slides on IPv6 too.
^ permalink raw reply
* pull request: wireless-next 2014-01-24
From: John W. Linville @ 2014-01-24 19:39 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 7249 bytes --]
Dave,
Please pull these fixes for the 3.14 stream!
For the iwlwifi fix, Emmanuel says:
"A critical bug has been reported on all NICs supported by iwldvm.
iwlwifi would simply panic upon interface up This patch fixes this. The
offending code is by me and is present in wireless-next.git and hence in
net-next.git."
Along with that...
Andreas Fenkart corrects a WoWLAN problem with mwifiex.
Roman Dubtsov adds a device ID to rt2800usb.
Sujith Manoharan re-enables a mistakenly commented-out line of code in
ath9k, and also fixes and interrupt mitigation issue for that driver.
ZHAO Gang fixes an incorrect assignment (reverse/wrong API call) in b43.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit f55aa836fb7a90b62cb2c533b899e331cdffcf0c:
rtnetlink: remove IFLA_BOND_SLAVE definition (2014-01-24 00:36:48 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next.git for-davem
for you to fetch changes up to 5746cc2a6923b4e4726d9be8aa155461829be360:
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem (2014-01-24 13:25:15 -0500)
----------------------------------------------------------------
Andreas Fenkart (1):
mwifiex: fix wakeup on magic packet
Emmanuel Grumbach (1):
iwlwifi: pcie: don't panic on host commands in iwldvm
John W. Linville (2):
Merge branch 'for-john' of git://git.kernel.org/.../iwlwifi/iwlwifi-next
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-next into for-davem
Roman Dubtsov (1):
rt2x00: rt2800usb: mark D-Link DWA-137 as supported
Sujith Manoharan (2):
ath9k: Fix code mistake
ath9k: Fix RX interrupt mitigation
ZHAO Gang (1):
b43: fix the wrong assignment of status.freq in b43_rx()
drivers/net/wireless/ath/ath9k/hw.c | 12 ++++++++++--
drivers/net/wireless/ath/ath9k/hw.h | 2 ++
drivers/net/wireless/ath/ath9k/main.c | 2 +-
drivers/net/wireless/b43/xmit.c | 4 ++--
drivers/net/wireless/iwlwifi/pcie/tx.c | 4 +++-
drivers/net/wireless/mwifiex/cfg80211.c | 2 +-
drivers/net/wireless/rt2x00/rt2800usb.c | 1 +
7 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index ce41658a6003..fbf43c05713f 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -358,6 +358,14 @@ static void ath9k_hw_init_config(struct ath_hw *ah)
ah->config.rx_intr_mitigation = true;
+ if (AR_SREV_9300_20_OR_LATER(ah)) {
+ ah->config.rimt_last = 500;
+ ah->config.rimt_first = 2000;
+ } else {
+ ah->config.rimt_last = 250;
+ ah->config.rimt_first = 700;
+ }
+
/*
* We need this for PCI devices only (Cardbus, PCI, miniPCI)
* _and_ if on non-uniprocessor systems (Multiprocessor/HT).
@@ -1876,8 +1884,8 @@ int ath9k_hw_reset(struct ath_hw *ah, struct ath9k_channel *chan,
REG_WRITE(ah, AR_OBS, 8);
if (ah->config.rx_intr_mitigation) {
- REG_RMW_FIELD(ah, AR_RIMT, AR_RIMT_LAST, 500);
- REG_RMW_FIELD(ah, AR_RIMT, AR_RIMT_FIRST, 2000);
+ REG_RMW_FIELD(ah, AR_RIMT, AR_RIMT_LAST, ah->config.rimt_last);
+ REG_RMW_FIELD(ah, AR_RIMT, AR_RIMT_FIRST, ah->config.rimt_first);
}
if (ah->config.tx_intr_mitigation) {
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index e766399bdcda..0acd4b5a4892 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -310,6 +310,8 @@ struct ath9k_ops_config {
u8 max_txtrig_level;
u16 ani_poll_interval; /* ANI poll interval in ms */
u16 hw_hang_checks;
+ u16 rimt_first;
+ u16 rimt_last;
/* Platform specific config */
u32 aspm_l1_fix;
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 73a36551a5ed..5924f72dd493 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -524,7 +524,7 @@ void ath9k_tasklet(unsigned long data)
* successfully after a GTT interrupt, the GTT counter
* gets reset to zero here.
*/
- /* sc->gtt_cnt = 0; */
+ sc->gtt_cnt = 0;
ath_tx_edma_tasklet(sc);
} else {
diff --git a/drivers/net/wireless/b43/xmit.c b/drivers/net/wireless/b43/xmit.c
index 4ae63f4ddfb2..50e5ddb12fb3 100644
--- a/drivers/net/wireless/b43/xmit.c
+++ b/drivers/net/wireless/b43/xmit.c
@@ -821,10 +821,10 @@ void b43_rx(struct b43_wldev *dev, struct sk_buff *skb, const void *_rxhdr)
* channel number in b43. */
if (chanstat & B43_RX_CHAN_5GHZ) {
status.band = IEEE80211_BAND_5GHZ;
- status.freq = b43_freq_to_channel_5ghz(chanid);
+ status.freq = b43_channel_to_freq_5ghz(chanid);
} else {
status.band = IEEE80211_BAND_2GHZ;
- status.freq = b43_freq_to_channel_2ghz(chanid);
+ status.freq = b43_channel_to_freq_2ghz(chanid);
}
break;
default:
diff --git a/drivers/net/wireless/iwlwifi/pcie/tx.c b/drivers/net/wireless/iwlwifi/pcie/tx.c
index 3b14fa8abfc7..3d549008b3e2 100644
--- a/drivers/net/wireless/iwlwifi/pcie/tx.c
+++ b/drivers/net/wireless/iwlwifi/pcie/tx.c
@@ -289,13 +289,15 @@ static void iwl_pcie_txq_inval_byte_cnt_tbl(struct iwl_trans *trans,
*/
void iwl_pcie_txq_inc_wr_ptr(struct iwl_trans *trans, struct iwl_txq *txq)
{
+ struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans);
u32 reg = 0;
int txq_id = txq->q.id;
if (txq->need_update == 0)
return;
- if (trans->cfg->base_params->shadow_reg_enable) {
+ if (trans->cfg->base_params->shadow_reg_enable ||
+ txq_id == trans_pcie->cmd_queue) {
/* shadow register enabled */
iwl_write32(trans, HBUS_TARG_WRPTR,
txq->q.write_ptr | (txq_id << 8));
diff --git a/drivers/net/wireless/mwifiex/cfg80211.c b/drivers/net/wireless/mwifiex/cfg80211.c
index f37b403e83d0..8bfc07cd330e 100644
--- a/drivers/net/wireless/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/mwifiex/cfg80211.c
@@ -2449,7 +2449,7 @@ static int mwifiex_cfg80211_suspend(struct wiphy *wiphy,
ETH_ALEN);
mef_entry->filter[filt_num].byte_seq[MWIFIEX_MEF_MAX_BYTESEQ] =
ETH_ALEN;
- mef_entry->filter[filt_num].offset = 14;
+ mef_entry->filter[filt_num].offset = 28;
mef_entry->filter[filt_num].filt_type = TYPE_EQ;
if (filt_num)
mef_entry->filter[filt_num].filt_action = TYPE_OR;
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index 5c5c4906c6b6..caddc1b427a9 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -989,6 +989,7 @@ static struct usb_device_id rt2800usb_device_table[] = {
{ USB_DEVICE(0x07d1, 0x3c15) },
{ USB_DEVICE(0x07d1, 0x3c16) },
{ USB_DEVICE(0x07d1, 0x3c17) },
+ { USB_DEVICE(0x2001, 0x3317) },
{ USB_DEVICE(0x2001, 0x3c1b) },
/* Draytek */
{ USB_DEVICE(0x07fa, 0x7712) },
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply related
* Re: IPV6 routing problem
From: Sharat Masetty @ 2014-01-24 18:50 UTC (permalink / raw)
To: Emmanuel Thierry, Sharat Masetty, netdev
In-Reply-To: <20140124135932.GR7269@order.stressinduktion.org>
Thank you Emmanuel and Hannes, I went through the thread and the
suggested fix and it definitely makes sense. I will apply the fix and
test it out.
A general question, Can you suggest a good reference documentation to
understand the Linux kernel IPV6 routing and neighboring subsystem
better? The O Reilly book does not have much about IPV6.
Thanks
Sharat
On Fri, Jan 24, 2014 at 6:59 AM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> On Fri, Jan 24, 2014 at 10:36:54AM +0100, Emmanuel Thierry wrote:
>> Hello,
>>
>> Le 23 janv. 2014 à 08:15, Sharat Masetty a écrit :
>>
>> > Unfortunately toggling this config setting CONFIG_IPV6_ROUTER_PREF did
>> > not help, I see the same problem in both cases.
>> > The kernel version I am using is 3.10.0.
>> >
>> > Thanks for confirming that this is a non issue on 3.13 kernel version.
>> > Would you happen to know which patch would have potentially fixed this
>> > issue?
>>
>> Your problem looks like the following one :
>> http://marc.info/?l=linux-netdev&m=137280268407054&w=2
>>
>> Which has been fixed in 3.10.4, and 3.11+
>
> Yes, that could very well be the case. We resolve the gateway while
> inserting the route (if not on-link), and it may not be available
> because of missing probes or no traffic went to it, yet. Thanks for
> looking after this, Emmanuel.
>
> I really recommend using the stable kernels btw. instead of the vanialla
> point zero releases.
>
> Thanks,
>
> Hannes
>
^ permalink raw reply
* Re: [PATCH net-next] bonding: Use do_div to divide 64 bit numbers
From: Zoltan Kiss @ 2014-01-24 18:27 UTC (permalink / raw)
To: Nikolay Aleksandrov, Jay Vosburgh, Veaceslav Falico,
Andy Gospodarek, netdev, linux-kernel
In-Reply-To: <52E18720.4060008@redhat.com>
On 23/01/14 21:18, Nikolay Aleksandrov wrote:
>> Hi Zoltan,
>> Thanks for fixing this, a few comments though:
>> bond->params.miimon can be 0 here that's why there's a check afterwards,
>> also please separate the local variable definitions from the body with a
>> new line.
>> The same applies for downdelay.
>>
>> Nik
> In fact since we don't need the u64 and newval->value is limited to
> INT_MAX, can't we simply cast it to (int) and avoid the do_div entirely ?
Yep, that's even better, thanks for fixing it!
Zoli
^ permalink raw reply
* Re: [README] bug fixes only...
From: Eric Dumazet @ 2014-01-24 17:28 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: David Miller, netdev
In-Reply-To: <52E29650.7010606@hartkopp.net>
On Fri, 2014-01-24 at 17:35 +0100, Oliver Hartkopp wrote:
> Do you plan this fix after the net-next merge?
>
> http://patchwork.ozlabs.org/patch/313483/
>
Oliver, this is a bug fix.
David said "I want to see zero feature and/or cleanup patches submitted
at this time."
Is a bug fix a "zero feature and/or cleanup patches" ?
Answer is obviously no, so relax, read
Documentation/networking/netdev-FAQ.txt again,
and please avoid top posting.
Thanks
^ permalink raw reply
* Re: [PATCH v6] xen/grant-table: Avoid m2p_override during mapping
From: Zoltan Kiss @ 2014-01-24 17:20 UTC (permalink / raw)
To: Matt Wilson
Cc: ian.campbell, wei.liu2, xen-devel, netdev, linux-kernel,
jonathan.davies, Anthony Liguori, Matt Wilson
In-Reply-To: <20140124054828.GA18522@u109add4315675089e695.ant.amazon.com>
On 24/01/14 05:48, Matt Wilson wrote:
> On Thu, Jan 23, 2014 at 09:23:44PM +0000, Zoltan Kiss wrote:
> Apologies for coming in late on this thread. I'm quite behind on
> xen-devel mail that isn't CC: to me.
>
> It seems to have been forgotten that Anthony and I proposed a similar
> change last November.
>
> https://lkml.kernel.org/r/1384307336-5328-1-git-send-email-anthony@codemonkey.ws
>
> Or am I misunderstanding the change?
I didn't know about this patch, but yes, both of them do basically the
same. One subtle difference that you store the old mfn in page->private,
while my patch keeps the original behaviour, and store it in
page->index. page->private is used instead to store the new mfn we got
from Xen, however I haven't checked where do we use that.
Your approach might be better, we also talked with David that we should
stop using page->index, as e.g. with the netback grant mapping patches I
spent a lot of time to figure out a packet drop issue, which eventually
boiled down to the fact that index is in union with pfmemalloc, and if
you don't set mapping, the local IP stack will think it is a pfmemalloc
page. (see the comment in my second patch, xenvif_fill_frags)
However I think that should be a separate patch, I tried to keep the
original behaviour as much as possible, and focus just on avoiding
m2p_override when possible.
Regards,
Zoli
^ permalink raw reply
* Re: [PATCH 2/5] arm64: dts: APM X-Gene SoC Ethernet device tree nodes
From: Mark Salter @ 2014-01-24 17:01 UTC (permalink / raw)
To: Iyappan Subramanian
Cc: devicetree, jcm, gregkh, patches, linux-kernel, netdev,
Keyur Chudgar, davem, linux-arm-kernel, Ravi Patel
In-Reply-To: <1387597376-29303-3-git-send-email-isubramanian@apm.com>
On Fri, 2013-12-20 at 19:42 -0800, Iyappan Subramanian wrote:
> Device tree files for APM X-Gene SoC Ethernet.
>
> Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
> Signed-off-by: Ravi Patel <rapatel@apm.com>
> Signed-off-by: Keyur Chudgar <kchudgar@apm.com>
> ---
> arch/arm64/boot/dts/apm-mustang.dts | 8 ++++++++
> arch/arm64/boot/dts/apm-storm.dtsi | 19 +++++++++++++++++++
> 2 files changed, 27 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/apm-mustang.dts b/arch/arm64/boot/dts/apm-mustang.dts
> index 1247ca1..ccb2771 100644
> --- a/arch/arm64/boot/dts/apm-mustang.dts
> +++ b/arch/arm64/boot/dts/apm-mustang.dts
> @@ -17,6 +17,10 @@
> model = "APM X-Gene Mustang board";
> compatible = "apm,mustang", "apm,xgene-storm";
>
> + aliases {
> + ethernet0 = &menet;
> + };
> +
> chosen { };
>
> memory {
> @@ -24,3 +28,7 @@
> reg = < 0x1 0x00000000 0x0 0x80000000 >; /* Updated by bootloader */
> };
> };
> +
> +&menet {
> + status = "ok";
> +};
> diff --git a/arch/arm64/boot/dts/apm-storm.dtsi b/arch/arm64/boot/dts/apm-storm.dtsi
> index f64f946..9c7b8cd 100644
> --- a/arch/arm64/boot/dts/apm-storm.dtsi
> +++ b/arch/arm64/boot/dts/apm-storm.dtsi
> @@ -204,5 +204,24 @@
> #clock-cells = <1>;
> clocks = <&qmlclk 0>;
> };
> +
> + menet: ethernet@17020000 {
> + compatible = "apm,xgene-enet";
> + status = "disabled";
> + reg = <0x0 0x17020000 0x0 0x30>,
> + <0x0 0x17020000 0x0 0x10000>,
> + <0x0 0x17020000 0x0 0x20>;
> + slave-name = "RGMII";
> + interrupts = <0x0 0x38 0x4>,
> + <0x0 0x39 0x4>,
> + <0x0 0x3a 0x4>;
> + #clock-cells = <1>;
> + clocks = <ð8clk 0>;
> + local-mac-address = <0x0 0x11 0x3a 0x8a 0x5a 0x78>;
Shouldn't this be a byte string?:
local-mac-address = [ 00 11 3a 8a 5a 78 ];
> + max-frame-size = <0x233a>;
> + devid = <8>;
> + phyid = <3>;
> + phy-mode = "rgmii";
> + };
> };
> };
^ permalink raw reply
* Re: [README] bug fixes only...
From: Oliver Hartkopp @ 2014-01-24 16:35 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20140123.162408.681541949851852312.davem@davemloft.net>
Do you plan this fix after the net-next merge?
http://patchwork.ozlabs.org/patch/313483/
Regards,
Oliver
On 24.01.2014 01:24, David Miller wrote:
>
> I want to see zero feature and/or cleanup patches submitted at this
> time.
>
> net-next is now frozen and I'm going to let it sit for a day before
> I try to merge it to Linus.
>
> Thanks for your understanding.
> --
> 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
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