* Re: [PATCH 9/9] batman-adv: Use packing of 2 for all headers before an ethernet header
From: David Miller @ 2012-11-21 20:31 UTC (permalink / raw)
To: sven
Cc: ordex, netdev, b.a.t.m.a.n, lindner_marek, kevin.curtis,
linux-driver, ron.mercer, jitendra.kalsaria, rmody, andy, fubar
In-Reply-To: <8108710.8oNxxR0rRd@sven-laptop.home.narfation.org>
From: Sven Eckelmann <sven@narfation.org>
Date: Wed, 21 Nov 2012 19:20:21 +0100
> Agree. But we should get this message also to the other guys
>
> $ git grep pragma -- drivers/net
Good point, I've pulled your tree, thanks!
^ permalink raw reply
* [PATCH] 8139cp: set ring address after enabling C+ mode
From: David Woodhouse @ 2012-11-21 20:27 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Jason Wang, David S. Miller, netdev
In-Reply-To: <50AD1972.5080403@pobox.com>
[-- Attachment #1: Type: text/plain, Size: 3796 bytes --]
This fixes (for me) a regression introduced by commit b01af457 ("8139cp:
set ring address before enabling receiver"). That commit configured the
descriptor ring addresses earlier in the initialisation sequence, in
order to avoid the possibility of triggering stray DMA before the
correct address had been set up.
Unfortunately, it seems that the hardware will scribble garbage into the
TxRingAddr registers when we enable "plus mode" Tx in the CpCmd
register. Observed on a Traverse Geos router board.
To deal with this, while not reintroducing the problem which led to the
original commit, we augment cp_start_hw() to write to the CpCmd register
*first*, then set the descriptor ring addresses, and then finally to
enable Rx and Tx in the original 8139 Cmd register. The datasheet
actually indicates that we should enable Tx/Rx in the Cmd register
*before* configuring the descriptor addresses, but that would appear to
re-introduce the problem that the offending commit b01af457 was trying
to solve. And this variant appears to work fine on real hardware.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Cc: stable@kernel.org [3.5+]
---
How about this? I'm still somewhat confused about when it actually
*does* start doing DMA, given what the datasheet says.
diff --git a/drivers/net/ethernet/realtek/8139cp.c b/drivers/net/ethernet/realtek/8139cp.c
index 1c81825..5166d94 100644
--- a/drivers/net/ethernet/realtek/8139cp.c
+++ b/drivers/net/ethernet/realtek/8139cp.c
@@ -957,7 +957,35 @@ static void cp_reset_hw (struct cp_private *cp)
static inline void cp_start_hw (struct cp_private *cp)
{
+ dma_addr_t ring_dma;
+
cpw16(CpCmd, cp->cpcmd);
+
+ /*
+ * These (at least TxRingAddr) need to be configured after the
+ * corresponding bits in CpCmd are enabled. Datasheet v1.6 §6.33
+ * (C+ Command Register) recommends that these and more be configured
+ * *after* the [RT]xEnable bits in CpCmd are set. And on some hardware
+ * it's been observed that the TxRingAddr is actually reset to garbage
+ * when C+ mode Tx is enabled in CpCmd.
+ */
+ cpw32_f(HiTxRingAddr, 0);
+ cpw32_f(HiTxRingAddr + 4, 0);
+
+ ring_dma = cp->ring_dma;
+ cpw32_f(RxRingAddr, ring_dma & 0xffffffff);
+ cpw32_f(RxRingAddr + 4, (ring_dma >> 16) >> 16);
+
+ ring_dma += sizeof(struct cp_desc) * CP_RX_RING_SIZE;
+ cpw32_f(TxRingAddr, ring_dma & 0xffffffff);
+ cpw32_f(TxRingAddr + 4, (ring_dma >> 16) >> 16);
+
+ /*
+ * Strictly speaking, the datasheet says this should be enabled
+ * *before* setting the descriptor addresses. But what, then, would
+ * prevent it from doing DMA to random unconfigured addresses?
+ * This variant appears to work fine.
+ */
cpw8(Cmd, RxOn | TxOn);
}
@@ -969,7 +997,6 @@ static void cp_enable_irq(struct cp_private *cp)
static void cp_init_hw (struct cp_private *cp)
{
struct net_device *dev = cp->dev;
- dma_addr_t ring_dma;
cp_reset_hw(cp);
@@ -979,17 +1006,6 @@ static void cp_init_hw (struct cp_private *cp)
cpw32_f (MAC0 + 0, le32_to_cpu (*(__le32 *) (dev->dev_addr + 0)));
cpw32_f (MAC0 + 4, le32_to_cpu (*(__le32 *) (dev->dev_addr + 4)));
- cpw32_f(HiTxRingAddr, 0);
- cpw32_f(HiTxRingAddr + 4, 0);
-
- ring_dma = cp->ring_dma;
- cpw32_f(RxRingAddr, ring_dma & 0xffffffff);
- cpw32_f(RxRingAddr + 4, (ring_dma >> 16) >> 16);
-
- ring_dma += sizeof(struct cp_desc) * CP_RX_RING_SIZE;
- cpw32_f(TxRingAddr, ring_dma & 0xffffffff);
- cpw32_f(TxRingAddr + 4, (ring_dma >> 16) >> 16);
-
cp_start_hw(cp);
cpw8(TxThresh, 0x06); /* XXX convert magic num to a constant */
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply related
* Re: 8139cp: set ring address before enabling receiver
From: Ben Hutchings @ 2012-11-21 20:18 UTC (permalink / raw)
To: David Woodhouse; +Cc: Jeff Garzik, Jason Wang, David S. Miller, netdev
In-Reply-To: <1353527481.26346.150.camel@shinybook.infradead.org>
On Wed, 2012-11-21 at 19:51 +0000, David Woodhouse wrote:
> On Wed, 2012-11-21 at 13:12 -0500, Jeff Garzik wrote:
> >
> > What sticks out at me from the commit message?
> >
> > It was not tested on the famously quirky 8139 hardware at all.
> >
> > While I have not looked at the 8139C+ data sheet in a while, sometimes
> > the hardware _did_ have a strange init order.
> >
> > As this works in a simulator but fails on real hardware, it seems like
> > an obvious regression caused by an untested [on read hardware] patch.
>
> The data sheet (v1.6, from http://realtek.info/pdf/rtl8139cp.pdf ) says
> in §6.33 (C+ Command Register):
> "Enable C+ mode functions in C+CR register first,
> => Enable transmit/receive in Command register (offset 37h),
> => Configure other related registers (ex. Descriptor start address,
> TCR, RCR, ...)."
>
> I understand the concern expressed in the offending commit message about
> DMA happening to invalid addresses, and I'll look at the data sheet
> harder to see when the DMA actually starts happening. But it definitely
> seems that our current code isn't doing what the data sheet says.
>
> I wonder if I can find one of these lying around and stick it in a
> machine with an IOMMU...
You might be able to avoid disaster by doing:
1. Set MAC filter to drop everything
2. Enable RX DMA
3. Set RX DMA ring address
4. Set MAC filter according to current flags & multicast list
I'm assuming, knowing nothing about this particular hardware, that the
MAC filter register(s) will accept writes before RX DMA is enabled.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 1/1] asix: use ramdom hw addr if the one read is not valid
From: Sergei Shtylyov @ 2012-11-21 20:16 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1353493362-30418-1-git-send-email-plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
Hello.
On 11/21/2012 01:22 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
> Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> ---
> drivers/net/usb/asix_devices.c | 24 +++++++++++++++++++++---
> 1 file changed, 21 insertions(+), 3 deletions(-)
> diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
> index 33ab824..7ebec5b 100644
> --- a/drivers/net/usb/asix_devices.c
> +++ b/drivers/net/usb/asix_devices.c
> @@ -225,7 +225,13 @@ static int ax88172_bind(struct usbnet *dev, struct usb_interface *intf)
> ret);
> goto out;
> }
> - memcpy(dev->net->dev_addr, buf, ETH_ALEN);
> +
> + if (is_valid_ether_addr(buf)) {
> + memcpy(dev->net->dev_addr, buf, ETH_ALEN);
> + } else {
> + netdev_info(dev->net, "invalid hw address, using random\n");
> + eth_hw_addr_random(dev->net);
> + }
>
> /* Initialize MII structure */
> dev->mii.dev = dev->net;
> @@ -423,7 +429,13 @@ static int ax88772_bind(struct usbnet *dev, struct usb_interface *intf)
> netdev_dbg(dev->net, "Failed to read MAC address: %d\n", ret);
> return ret;
> }
> - memcpy(dev->net->dev_addr, buf, ETH_ALEN);
> +
> + if (is_valid_ether_addr(buf)) {
> + memcpy(dev->net->dev_addr, buf, ETH_ALEN);
> + } else {
> + netdev_info(dev->net, "invalid hw address, using random\n");
> + eth_hw_addr_random(dev->net);
> + }
>
> /* Initialize MII structure */
> dev->mii.dev = dev->net;
> @@ -777,7 +789,13 @@ static int ax88178_bind(struct usbnet *dev, struct usb_interface *intf)
> netdev_dbg(dev->net, "Failed to read MAC address: %d\n", ret);
> return ret;
> }
> - memcpy(dev->net->dev_addr, buf, ETH_ALEN);
> +
> + if (is_valid_ether_addr(buf)) {
> + memcpy(dev->net->dev_addr, buf, ETH_ALEN);
> + } else {
> + netdev_info(dev->net, "invalid hw address, using random\n");
> + eth_hw_addr_random(dev->net);
> + }
>
> /* Initialize MII structure */
> dev->mii.dev = dev->net;
Repeated thrice, this asks to be put into subroutine...
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: 8139cp: set ring address before enabling receiver
From: David Woodhouse @ 2012-11-21 19:51 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Jason Wang, David S. Miller, netdev
In-Reply-To: <50AD1972.5080403@pobox.com>
[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]
On Wed, 2012-11-21 at 13:12 -0500, Jeff Garzik wrote:
>
> What sticks out at me from the commit message?
>
> It was not tested on the famously quirky 8139 hardware at all.
>
> While I have not looked at the 8139C+ data sheet in a while, sometimes
> the hardware _did_ have a strange init order.
>
> As this works in a simulator but fails on real hardware, it seems like
> an obvious regression caused by an untested [on read hardware] patch.
The data sheet (v1.6, from http://realtek.info/pdf/rtl8139cp.pdf ) says
in §6.33 (C+ Command Register):
"Enable C+ mode functions in C+CR register first,
=> Enable transmit/receive in Command register (offset 37h),
=> Configure other related registers (ex. Descriptor start address,
TCR, RCR, ...)."
I understand the concern expressed in the offending commit message about
DMA happening to invalid addresses, and I'll look at the data sheet
harder to see when the DMA actually starts happening. But it definitely
seems that our current code isn't doing what the data sheet says.
I wonder if I can find one of these lying around and stick it in a
machine with an IOMMU...
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply
* Re: Packet Corruption with Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) Interface
From: Martin Tessun @ 2012-11-21 19:34 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1353518049.2590.41.camel@edumazet-glaptop>
Am 21.11.2012 18:14, schrieb Eric Dumazet:
> On Wed, 2012-11-21 at 15:54 +0100, Martin Tessun wrote:
[snip bug description]
>
> Is it only happening for IPv6 traffic, or is it also buggy for IPv4 ?
>
> If you disable tso , does the bug disappear ?
>
>
>
It also happens with IPv4 (usually not so fast as with IPv6):
SCP from client:
$ scp -4 server:/export/no_backup/burn/openSUSE-12.2-DVD-x86_64.iso .
openSUSE-12.2-DVD-x86_64.iso
4% 184MB 9.3MB/s 07:37 ETA
Corrupted MAC on input.
Disconnecting: Packet corrupt
openSUSE-12.2-DVD-x86_64.iso
4% 193MB 9.2MB/s 07:40 ETA
lost connection
SCP initiated from the server:
$ scp -4 openSUSE-12.2-DVD-x86_64.iso uhura:/tmp
openSUSE-12.2-DVD-x86_64.iso
3% 149MB 8.8MB/s 08:10 ETA
Received disconnect from 10.100.14.100: 2: Packet corrupt
lost connection
With TSO disabled:
$ sudo ethtool -K eth0 tso off
$ sudo ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: off
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: off
SCP (IPv4) initiated from client:
$ scp -4 server:/export/no_backup/burn/openSUSE-12.2-DVD-x86_64.iso .
openSUSE-12.2-DVD-x86_64.iso
2% 93MB 10.4MB/s 06:59 ETA
Corrupted MAC on input.
Disconnecting: Packet corrupt
lost connection
SCP (IPv4) initated from server:
$ scp -4 openSUSE-12.2-DVD-x86_64.iso uhura:/tmp
openSUSE-12.2-DVD-x86_64.iso
4% 179MB 9.2MB/s 07:46 ETA
Received disconnect from 10.100.14.100: 2: Packet corrupt
lost connection
Regards,
Martin
^ permalink raw reply
* Re: [PATCH 1/1 v2] net: add micrel KSZ8873MLL switch support
From: Joe Perches @ 2012-11-21 19:03 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD; +Cc: linux-arm-kernel, netdev
In-Reply-To: <1353512287-24048-1-git-send-email-plagnioj@jcrosoft.com>
On Wed, 2012-11-21 at 16:38 +0100, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> this will allow to detect the link between the switch and the soc
[]
> diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
[]
> @@ -127,6 +127,39 @@ static int ks8051_config_init(struct phy_device *phydev)
[]
> +int ksz8873mll_read_status(struct phy_device *phydev)
> +{
[]
> + regval = phy_read(phydev, KSZ8873MLL_GLOBAL_CONTROL_4);
> +
> + if (regval & KSZ8873MLL_GLOBAL_CONTROL_4_DUPLEX)
> + phydev->duplex = DUPLEX_HALF;
> + else
> + phydev->duplex = DUPLEX_FULL;
This doesn't check for phy_read errors.
Shouldn't it?
^ permalink raw reply
* Re: [PATCH net-next 09/17] net: Allow userns root control of the core of the network stack.
From: Ben Hutchings @ 2012-11-21 18:29 UTC (permalink / raw)
To: Eric W. Biederman
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Linux Containers, David Miller
In-Reply-To: <87lie13q18.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
On Fri, 2012-11-16 at 18:46 -0800, Eric W. Biederman wrote:
> Ben Hutchings <bhutchings-s/n/eUQHGBpZroRs9YW3xA@public.gmane.org> writes:
>
> > On Fri, 2012-11-16 at 06:32 -0800, Eric W. Biederman wrote:
> >> Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> writes:
> >>
> >> > On 11/16/2012 05:03 PM, Eric W. Biederman wrote:
> >> >> + if (!capable(CAP_NET_ADMIN))
> >> >> + return -EPERM;
> >> >> +
> >> >> return netdev_store(dev, attr, buf, len, change_tx_queue_len);
> >> >
> >> > You mean ns_capable here?
> >>
> >> No. There I meant capable.
> >>
> >> I deliberately call capable here because I don't understand what
> >> the tx_queue_len well enough to be certain it is safe to relax
> >> that check to be just ns_capable.
> >>
> >> My get feel is that allowing an unprivileged user to be able to
> >> arbitrarily change the tx_queue_len on a networking device would be a
> >> nice way to allow queuing as many network packets as you would like with
> >> kernel memory and DOSing the machine.
> >>
> >> So since with a quick read of the code I could not convince myself it
> >> was safe to allow unprivilged users to change tx_queue_len I left it
> >> protected by capable. While at the same time I relaxed the check in
> >> netdev_store to be ns_capable.
> >
> > Tor the same reason you had better be very selective about which ethtool
> > commands are allowed based on per-user_ns CAP_NET_ADMIN. Consider for a
> > start:
> >
> > ETHTOOL_SEEPROM => brick the NIC
> > ETHTOOL_FLASHDEV => brick the NIC; own the system if it's not using an IOMMU
>
> These are prevented by not having access to real hardware by default. A
> physical network interface must be moved into a network namespace for
> you to have access to it.
Yes, I realise that. The question is whether you would expect anything
in a container to be able to do those things, even with a physical net
device assigned to it.
Actually we have the same issue without considering containers - should
CAP_NET_ADMIN really give you low-level control over hardware just
because it's networking hardware? I think some of these ethtool
operations, and access to non-standard MDIO registers, should perhaps
require an additional capability (CAP_SYS_ADMIN or CAP_SYS_RAWIO?).
> There are a handful of software network devices that are generally safe
> macvlan, veth, tun, ipip tunnels, etc. Using those network devices is
> very interesting and about as performant as you can get while still
> being safe.
>
> A buffer overflow in an ethtool command looks as likely to me as being
> able to own the system by reflashing the NIC.
Sure, if you can find one. But on many NICs the firmware can perform
more or less arbitrary DMA *by design* (one reason for using IOMMUs),
and the ability to update the firmware is not a bug to be fixed!
> Access to a real physical NIC is an act of trust. Given the general
> linux policy that drivers are merged when they mostly work I don't
> currently know of any trust models between "I trust you with full access
> to this device" and "I don't trust you with direct access to this
> device" that I would feel confident giving to an untrusted user.
At the moment it's 'I trust you with full access to *all* network
devices' (init ns CAP_NET_ADMIN), 'I trust you with some reconfiguration
of these network devices' (other ns CAP_NET_ADMIN) and 'I don't trust
you...'
You're expanding what other-ns-CAP_NET_ADMIN means, to 'I trust you with
full access to these network devices'.
> Which is a convoluted way of saying "ip link set eth0 netns bob" is the
> moral equivalent of "chown bob.bob /dev/eth0; chmod u+rwx /dev/eth0"
[...]
And it's previously been decided that ownership of a block device still
should *not* mean full control over it (see responses to CVE-2011-4127).
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: Re: [PATCH 9/9] batman-adv: Use packing of 2 for all headers before an ethernet header
From: Sven Eckelmann @ 2012-11-21 18:20 UTC (permalink / raw)
To: David Miller
Cc: ordex, netdev, b.a.t.m.a.n, lindner_marek, kevin.curtis,
linux-driver, ron.mercer, jitendra.kalsaria, rmody, andy, fubar
In-Reply-To: <20121121.125759.322762083309845086.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1961 bytes --]
On Wednesday 21 November 2012 12:57:59 David Miller wrote:
> From: Antonio Quartulli <ordex@autistici.org>
> Date: Wed, 21 Nov 2012 13:11:59 +0100
>
> > +#pragma pack(2)
>
> ...
>
> > -} __packed;
>
> The __packed attribute is an abstraction of the actual syntax
> the compiler uses, if it is supported at all.
>
> Therefore, you can't just unconditionally use the #pragma, and
> you would need to use some kind of similar compiler abstraction
> for it.
>
> But to be honest this is really ugly and for very little, if any,
> gain.
Agree. But we should get this message also to the other guys
$ git grep pragma -- drivers/net
drivers/net/bonding/bond_3ad.h:#pragma pack(1)
drivers/net/bonding/bond_3ad.h:#pragma pack()
drivers/net/bonding/bond_3ad.h:#pragma pack(8)
drivers/net/bonding/bond_3ad.h:#pragma pack()
drivers/net/bonding/bond_alb.c:#pragma pack(1)
drivers/net/bonding/bond_alb.c:#pragma pack()
drivers/net/ethernet/brocade/bna/bfa_defs.h:#pragma pack(1)
drivers/net/ethernet/brocade/bna/bfa_defs.h:#pragma pack()
drivers/net/ethernet/brocade/bna/bfa_defs_cna.h:#pragma pack(1)
drivers/net/ethernet/brocade/bna/bfa_defs_cna.h:#pragma pack()
drivers/net/ethernet/brocade/bna/bfa_defs_mfg_comm.h:#pragma pack(1)
drivers/net/ethernet/brocade/bna/bfa_defs_mfg_comm.h:#pragma pack()
drivers/net/ethernet/brocade/bna/bfi.h:#pragma pack(1)
drivers/net/ethernet/brocade/bna/bfi.h:#pragma pack()
drivers/net/ethernet/brocade/bna/bfi_cna.h:#pragma pack(1)
drivers/net/ethernet/brocade/bna/bfi_cna.h:#pragma pack()
drivers/net/ethernet/brocade/bna/bfi_enet.h:#pragma pack(1)
drivers/net/ethernet/brocade/bna/bfi_enet.h:#pragma pack()
drivers/net/ethernet/brocade/bna/cna.h:#pragma pack(1)
drivers/net/ethernet/brocade/bna/cna.h:#pragma pack()
drivers/net/ethernet/qlogic/qla3xxx.h:#pragma pack(1)
drivers/net/ethernet/qlogic/qla3xxx.h:#pragma pack()
drivers/net/wan/farsync.c:#pragma pack(1)
drivers/net/wan/farsync.c:#pragma pack()
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] brcmsmac: Add __printf verification to logging prototypes
From: Joe Perches @ 2012-11-21 18:17 UTC (permalink / raw)
To: linux-kernel
Cc: Brett Rudley, Roland Vossen, Arend van Spriel,
Franky (Zhenhui) Lin, Kan Yan, John W. Linville, linux-wireless,
brcm80211-dev-list, netdev
Adding __printf helps spot format and argument mismatches.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/wireless/brcm80211/brcmsmac/debug.h | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/debug.h b/drivers/net/wireless/brcm80211/brcmsmac/debug.h
index c0d2cf7..f77066b 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/debug.h
+++ b/drivers/net/wireless/brcm80211/brcmsmac/debug.h
@@ -8,17 +8,23 @@
#include "main.h"
#include "mac80211_if.h"
+__printf(2, 3)
void __brcms_info(struct device *dev, const char *fmt, ...);
+__printf(2, 3)
void __brcms_warn(struct device *dev, const char *fmt, ...);
+__printf(2, 3)
void __brcms_err(struct device *dev, const char *fmt, ...);
+__printf(2, 3)
void __brcms_crit(struct device *dev, const char *fmt, ...);
#if defined(CONFIG_BRCMDBG) || defined(CONFIG_BRCM_TRACING)
+__printf(4, 5)
void __brcms_dbg(struct device *dev, u32 level, const char *func,
const char *fmt, ...);
#else
-static inline void __brcms_dbg(struct device *dev, u32 level,
- const char *func, const char *fmt, ...)
+static inline __printf(4, 5)
+void __brcms_dbg(struct device *dev, u32 level, const char *func,
+ const char *fmt, ...)
{
}
#endif
--
1.7.8.112.g3fd21
^ permalink raw reply related
* Re: 8139cp: set ring address before enabling receiver
From: Jeff Garzik @ 2012-11-21 18:12 UTC (permalink / raw)
To: David Woodhouse; +Cc: Jason Wang, David S. Miller, netdev
In-Reply-To: <1353517042.26346.130.camel@shinybook.infradead.org>
On 11/21/2012 11:57 AM, David Woodhouse wrote:
> On Sat, 2012-06-02 at 23:50 +0000, Linux Kernel Mailing List wrote:
>> Gitweb: http://git.kernel.org/linus/;a=commit;h=b01af4579ec41f48e9b9c774e70bd6474ad210db
>> Commit: b01af4579ec41f48e9b9c774e70bd6474ad210db
>> Parent: 20e2a86485967c385d7c7befc1646e4d1d39362e
>> Author: Jason Wang <jasowang@redhat.com>
>> AuthorDate: Thu May 31 18:19:39 2012 +0000
>> Committer: David S. Miller <davem@davemloft.net>
>> CommitDate: Fri Jun 1 14:22:11 2012 -0400
>>
>> 8139cp: set ring address before enabling receiver
>>
>> Currently, we enable the receiver before setting the ring address which could
>> lead the card DMA into unexpected areas. Solving this by set the ring address
>> before enabling the receiver.
>>
>> btw. I find and test this in qemu as I didn't have a 8139cp card in hand. please
>> review it carefully.
What sticks out at me from the commit message?
It was not tested on the famously quirky 8139 hardware at all.
While I have not looked at the 8139C+ data sheet in a while, sometimes
the hardware _did_ have a strange init order.
As this works in a simulator but fails on real hardware, it seems like
an obvious regression caused by an untested [on read hardware] patch.
Jeff
^ permalink raw reply
* Re: [PATCH 9/9] batman-adv: Use packing of 2 for all headers before an ethernet header
From: David Miller @ 2012-11-21 17:57 UTC (permalink / raw)
To: ordex; +Cc: netdev, b.a.t.m.a.n, sven, lindner_marek
In-Reply-To: <1353499919-28596-10-git-send-email-ordex@autistici.org>
From: Antonio Quartulli <ordex@autistici.org>
Date: Wed, 21 Nov 2012 13:11:59 +0100
> +#pragma pack(2)
...
> -} __packed;
The __packed attribute is an abstraction of the actual syntax
the compiler uses, if it is supported at all.
Therefore, you can't just unconditionally use the #pragma, and
you would need to use some kind of similar compiler abstraction
for it.
But to be honest this is really ugly and for very little, if any,
gain.
^ permalink raw reply
* Re: [PATCH RFC 3/5] printk: modify printk interface for syslog_namespace
From: Serge E. Hallyn @ 2012-11-21 17:49 UTC (permalink / raw)
To: Rui Xiang
Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Eric W. Biederman, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <50A9EAF0.4000902-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
I notice that you haven't made any changes to the struct cont. I
suspect this means that to-be-continued msgs from one ns can be
erroneously mixed with another ns.
You said you don't mind putting the syslogns into the userns. If
there's no reason not to do that, then we should do so as it will
remove a bunch of code (plus the use of a new CLONE flag) from your
patch, and the new syslog(NEW_NS) command from mine.
Now IMO the ideal place for syslog_ns would be in the devices ns,
but that does not yet exist, and may never. The bonus to that would
be that the consoles sort of belong there. I avoid this by not
having consoles in child syslog namespaces. You put the console in
the ns. I haven't looked closely enough to see if what you do is
ok (will do so soon).
WOuld you mind looking through my patch to see if it suffices for
your needs? Where it does not, patches would be greatly appreciated
if simple enough.
Note I'm not at all wedded to my patchset. I'm happy to go with
something else entirely. My set was just a proof of concept.
thanks,
-serge
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2012-11-21 17:36 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) inet6_csk_update_pmtu() must return NULL or non-NULL, so translate
ERR_PTR to NULL, as needed. Fix from Eric Dumazet.
2) Fix copy&paste error in IRDA sir_dev ->set_speed method invocation,
it was testing the NULL'ness of a different method to guard the call.
Fix from Alexander Shiyan.
3) Fix build regression of xilinx driver, from Jeff Mahoney.
4) Make XEN netfront (like XEN netback) handle compound pages
in SKBs properly. From Ian Campbell.
5) Fix inverted logic of team_dev_queue_xmit() return value checks,
from Jiri Pirko and Dan Carpenter.
6) dma_poll_create() no longer allows a NULL device argument, breaking
both ixp4xx drivers. Fix from Xi Wang.
7) ne2000 driver doesn't hook up the parent device properly, breaking
udev matching. Fix from Alan Cox.
8) Locking and memory leak fixes in Near Field Communications layer.
From Thierry Escande, Szymon Janc, and Waldemar Rymarkiewicz.
9) sis900 resume regression, sis900_set_mode() is being called with
the iomem pointer instead of the expected device private. Fix
from Francois Romieu.
10) Fix IBSS regression caused by uninitializing the ibss-internals
before performing an emptyness check, from Simon WUnderlich.
11) Fix SNIFFER mode regression in iwlwifi driver, from Johannes Berg.
12) Fix task wedges in mwifiex_cmd_timeout_func(), from Bing Zhao.
13) Add back wireless sysfs directory, too much stuff depends upon it
being there. (actually I'd say it never should have been removed
to begin with) From Johannes Berg.
14) Fix hang introduced by suspend/resume changes in ath9k. Fix from
Sujith Manoharan.
Please pull, thanks a lot!
The following changes since commit 3587b1b097d70c2eb9fee95ea7995d13c05f66e5:
fanotify: fix FAN_Q_OVERFLOW case of fanotify_read() (2012-11-18 09:30:00 -1000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net master
for you to fetch changes up to 403f43c937d24832b18524f65415c0bbba6b5064:
team: bcast: convert return value of team_dev_queue_xmit() to bool correctly (2012-11-21 11:55:07 -0500)
----------------------------------------------------------------
Alan Cox (1):
ne2000: add the right platform device
Albert Pool (1):
rtlwifi: rtl8192cu: Add new USB ID
Alexander Shiyan (1):
irda: sir_dev: Fix copy/paste typo
Bing Zhao (2):
mwifiex: fix system hang issue in cmd timeout error case
mwifiex: report error to MMC core if we cannot suspend
Emmanuel Grumbach (1):
iwlwifi: don't WARN when a non empty queue is disabled
Eric Dumazet (1):
ipv6: fix inet6_csk_update_pmtu() return value
Francois Romieu (1):
sis900: fix sis900_set_mode call parameters.
Ian Campbell (1):
xen/netfront: handle compound page fragments on transmit
Jeff Mahoney (1):
net: fix build failure in xilinx
Jiri Pirko (1):
team: bcast: convert return value of team_dev_queue_xmit() to bool correctly
Johannes Berg (2):
iwlwifi: fix monitor mode FCS flag
wireless: add back sysfs directory
John W. Linville (4):
Merge branch 'for-john' of git://git.kernel.org/.../jberg/mac80211
Merge branch 'for-john' of git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
Merge tag 'nfc-fixes-3.7-1' of git://git.kernel.org/.../sameo/nfc-3.0
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem
Sarveshwar Bandi (1):
bonding: Bonding driver does not consider the gso_max_size/gso_max_segs setting of slave devices.
Simon Wunderlich (1):
mac80211: deinitialize ibss-internals after emptiness check
Srinivas Kandagatla (1):
of/net/mdio-gpio: Fix pdev->id issue when using devicetrees.
Sujith Manoharan (1):
ath9k_hw: Fix regression in device reset
Szymon Janc (2):
NFC: pn533: Fix missing lock while operating on commands list
NFC: pn533: Fix use after free
Thierry Escande (2):
NFC: Fix nfc_llcp_local chained list insertion
NFC: Fix pn533 target mode memory leak
Waldemar Rymarkiewicz (1):
NFC: pn533: Fix mem leak in pn533_in_dep_link_up
Xi Wang (2):
ixp4xx_eth: avoid calling dma_pool_create() with NULL dev
ixp4xx_hss: avoid calling dma_pool_create() with NULL dev
Documentation/devicetree/bindings/net/mdio-gpio.txt | 9 +++++-
drivers/net/bonding/bond_main.c | 7 +++++
drivers/net/ethernet/8390/ne.c | 1 +
drivers/net/ethernet/sis/sis900.c | 2 +-
drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 2 ++
drivers/net/ethernet/xscale/ixp4xx_eth.c | 8 +++--
drivers/net/irda/sir_dev.c | 2 +-
drivers/net/phy/mdio-gpio.c | 11 ++++---
drivers/net/team/team_mode_broadcast.c | 6 ++--
drivers/net/wan/ixp4xx_hss.c | 8 +++--
drivers/net/wireless/ath/ath9k/hw.c | 2 +-
drivers/net/wireless/iwlwifi/dvm/mac80211.c | 14 +++++++++
drivers/net/wireless/iwlwifi/pcie/tx.c | 8 -----
drivers/net/wireless/mwifiex/cmdevt.c | 11 +++++--
drivers/net/wireless/mwifiex/sdio.c | 11 ++++---
drivers/net/wireless/rtlwifi/rtl8192cu/sw.c | 1 +
drivers/net/xen-netfront.c | 98 +++++++++++++++++++++++++++++++++++++++++++++-------------
drivers/nfc/pn533.c | 25 ++++++++-------
net/core/net-sysfs.c | 20 ++++++++++++
net/ipv6/inet6_connection_sock.c | 3 +-
net/mac80211/ibss.c | 8 ++---
net/nfc/llcp/llcp.c | 2 +-
22 files changed, 188 insertions(+), 71 deletions(-)
^ permalink raw reply
* Re: net, bluetooth: object debug warning in bt_host_release()
From: Gustavo Padovan @ 2012-11-21 17:27 UTC (permalink / raw)
To: Sasha Levin
Cc: marcel-kz+m5ild9QBg9hUCZPvPmw, Johan Hedberg, David S. Miller,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Dave Jones
In-Reply-To: <50A272E7.9080103-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 5691 bytes --]
* Sasha Levin <sasha.levin-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> [2012-11-13 11:18:47 -0500]:
> Hi all,
>
> While fuzzing with trinity on a KVM tools (lkvm) guest running latest -next kernel I've
> stumbled on the following:
>
> [ 1434.201149] ------------[ cut here ]------------
> [ 1434.204998] WARNING: at lib/debugobjects.c:261 debug_print_object+0x8e/0xb0()
> [ 1434.208324] ODEBUG: free active (active state 0) object type: work_struct hint: hci_power_on+0x0/0x90
> [ 1434.210386] Pid: 8564, comm: trinity-child25 Tainted: G W 3.7.0-rc5-next-20121112-sasha-00018-g2f4ce0e #127
> [ 1434.210760] Call Trace:
> [ 1434.210760] [<ffffffff819f3d6e>] ? debug_print_object+0x8e/0xb0
> [ 1434.210760] [<ffffffff8110b887>] warn_slowpath_common+0x87/0xb0
> [ 1434.210760] [<ffffffff8110b911>] warn_slowpath_fmt+0x41/0x50
> [ 1434.210760] [<ffffffff819f3d6e>] debug_print_object+0x8e/0xb0
> [ 1434.210760] [<ffffffff8376b750>] ? hci_dev_open+0x310/0x310
> [ 1434.210760] [<ffffffff83bf94e5>] ? _raw_spin_unlock_irqrestore+0x55/0xa0
> [ 1434.210760] [<ffffffff819f3ee5>] __debug_check_no_obj_freed+0xa5/0x230
> [ 1434.210760] [<ffffffff83785db0>] ? bt_host_release+0x10/0x20
> [ 1434.210760] [<ffffffff819f4d15>] debug_check_no_obj_freed+0x15/0x20
> [ 1434.210760] [<ffffffff8125eee7>] kfree+0x227/0x330
> [ 1434.210760] [<ffffffff83785db0>] bt_host_release+0x10/0x20
> [ 1434.210760] [<ffffffff81e539e5>] device_release+0x65/0xc0
> [ 1434.210760] [<ffffffff819d3975>] kobject_cleanup+0x145/0x190
> [ 1434.210760] [<ffffffff819d39cd>] kobject_release+0xd/0x10
> [ 1434.210760] [<ffffffff819d33cc>] kobject_put+0x4c/0x60
> [ 1434.210760] [<ffffffff81e548b2>] put_device+0x12/0x20
> [ 1434.210760] [<ffffffff8376a334>] hci_free_dev+0x24/0x30
> [ 1434.210760] [<ffffffff82fd8fe1>] vhci_release+0x31/0x60
> [ 1434.210760] [<ffffffff8127be12>] __fput+0x122/0x250
> [ 1434.210760] [<ffffffff811cab0d>] ? rcu_user_exit+0x9d/0xd0
> [ 1434.210760] [<ffffffff8127bf49>] ____fput+0x9/0x10
> [ 1434.210760] [<ffffffff81133402>] task_work_run+0xb2/0xf0
> [ 1434.210760] [<ffffffff8106cfa7>] do_notify_resume+0x77/0xa0
> [ 1434.210760] [<ffffffff83bfb0ea>] int_signal+0x12/0x17
> [ 1434.210760] ---[ end trace a6d57fefbc8a8cc7 ]---
>
> Not that the guest doesn't emulate anything that looks like a bluetooth device or
> has bluetooth capabilities.
You have a virtual bluetooth device (vhci). That is why you get a bluetooth
crash. I think the following patch will fix this issue.
Gustavo
---
Author: Gustavo Padovan <gustavo.padovan-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
Date: Wed Nov 21 00:50:21 2012 -0200
Bluetooth: cancel power_on work when unregistering the device
We need to cancel the hci_power_on work in order to avoid it run when we
try to free the hdev.
[ 1434.201149] ------------[ cut here ]------------
[ 1434.204998] WARNING: at lib/debugobjects.c:261 debug_print_object+0x8e/0xb0()
[ 1434.208324] ODEBUG: free active (active state 0) object type: work_struct hint:
_power_on+0x0/0x90
[ 1434.210386] Pid: 8564, comm: trinity-child25 Tainted: G W 3.7.0-rc5-n
20121112-sasha-00018-g2f4ce0e #127
[ 1434.210760] Call Trace:
[ 1434.210760] [<ffffffff819f3d6e>] ? debug_print_object+0x8e/0xb0
[ 1434.210760] [<ffffffff8110b887>] warn_slowpath_common+0x87/0xb0
[ 1434.210760] [<ffffffff8110b911>] warn_slowpath_fmt+0x41/0x50
[ 1434.210760] [<ffffffff819f3d6e>] debug_print_object+0x8e/0xb0
[ 1434.210760] [<ffffffff8376b750>] ? hci_dev_open+0x310/0x310
[ 1434.210760] [<ffffffff83bf94e5>] ? _raw_spin_unlock_irqrestore+0x55/0xa0
[ 1434.210760] [<ffffffff819f3ee5>] __debug_check_no_obj_freed+0xa5/0x230
[ 1434.210760] [<ffffffff83785db0>] ? bt_host_release+0x10/0x20
[ 1434.210760] [<ffffffff819f4d15>] debug_check_no_obj_freed+0x15/0x20
[ 1434.210760] [<ffffffff8125eee7>] kfree+0x227/0x330
[ 1434.210760] [<ffffffff83785db0>] bt_host_release+0x10/0x20
[ 1434.210760] [<ffffffff81e539e5>] device_release+0x65/0xc0
[ 1434.210760] [<ffffffff819d3975>] kobject_cleanup+0x145/0x190
[ 1434.210760] [<ffffffff819d39cd>] kobject_release+0xd/0x10
[ 1434.210760] [<ffffffff819d33cc>] kobject_put+0x4c/0x60
[ 1434.210760] [<ffffffff81e548b2>] put_device+0x12/0x20
[ 1434.210760] [<ffffffff8376a334>] hci_free_dev+0x24/0x30
[ 1434.210760] [<ffffffff82fd8fe1>] vhci_release+0x31/0x60
[ 1434.210760] [<ffffffff8127be12>] __fput+0x122/0x250
[ 1434.210760] [<ffffffff811cab0d>] ? rcu_user_exit+0x9d/0xd0
[ 1434.210760] [<ffffffff8127bf49>] ____fput+0x9/0x10
[ 1434.210760] [<ffffffff81133402>] task_work_run+0xb2/0xf0
[ 1434.210760] [<ffffffff8106cfa7>] do_notify_resume+0x77/0xa0
[ 1434.210760] [<ffffffff83bfb0ea>] int_signal+0x12/0x17
[ 1434.210760] ---[ end trace a6d57fefbc8a8cc7 ]---
Reported-by: Sasha Levin <sasha.levin-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 81f4bac..69eb644 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1854,6 +1854,8 @@ void hci_unregister_dev(struct hci_dev *hdev)
for (i = 0; i < NUM_REASSEMBLY; i++)
kfree_skb(hdev->reassembly[i]);
+ cancel_work_sync(&hdev->power_on);
+
if (!test_bit(HCI_INIT, &hdev->flags) &&
!test_bit(HCI_SETUP, &hdev->dev_flags)) {
hci_dev_lock(hdev);
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: 3.6 routing cache regression, multicast loopback broken
From: David Miller @ 2012-11-21 17:25 UTC (permalink / raw)
To: ja; +Cc: mbizon, netdev
In-Reply-To: <alpine.LFD.2.00.1211210055040.1751@ja.ssi.bg>
From: Julian Anastasov <ja@ssi.bg>
Date: Wed, 21 Nov 2012 02:35:34 +0200 (EET)
> [PATCH net-next] ipv4: do not cache looped multicasts
>
> We have two cases for outgoing multicasts
> depending on the membership: with or without RTCF_LOCAL.
> Currently, we use caching only if route to 224/4 is used.
> As we can not cache for both cases, optimize the caching
> for senders only, do not cache routes with RTCF_LOCAL
> flag set.
>
> Signed-off-by: Julian Anastasov <ja@ssi.bg>
The sad part is that you warned me about this issue nearly
2 years ago Julian, sorry :-/
^ permalink raw reply
* Re: Packet Corruption with Atheros Communications Inc. AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0) Interface
From: Eric Dumazet @ 2012-11-21 17:14 UTC (permalink / raw)
To: Martin Tessun; +Cc: netdev
In-Reply-To: <50ACEB1D.2020303@gmx.de>
On Wed, 2012-11-21 at 15:54 +0100, Martin Tessun wrote:
> Hi @all,
>
> unfortunately I don't have the old postings any more, so I start a new
> thread.
>
> Following situation:
>
> I have a Server (NFS) and a Client with the Atheros network card. If I
> transfer big files, the md5sum of these files differ.
> If I try to scp the file I get "MAC corrupted on inpu".
>
> Everything works fine, if running on any other OS (or with other NICs
> than the Atheros one).
>
> So here is the data:
>
> lspci:
> 02:00.0 Ethernet controller: Atheros Communications Inc.
> AR8121/AR8113/AR8114 Gigabit or Fast Ethernet (rev b0)
> Subsystem: ASUSTeK Computer Inc. Device 831c
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR+ FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0, Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 44
> Region 0: Memory at fbec0000 (64-bit, non-prefetchable) [size=256K]
> Region 2: I/O ports at dc00 [size=128]
> Capabilities: [40] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot+,D3cold+)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [48] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Address: 00000000fee0f00c Data: 4181
> Capabilities: [58] Express (v1) Endpoint, MSI 00
> DevCap: MaxPayload 4096 bytes, PhantFunc 0, Latency L0s
> <4us, L1 unlimited
> ExtTag- AttnBtn+ AttnInd+ PwrInd+ RBE- FLReset-
> DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
> Unsupported-
> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
> MaxPayload 128 bytes, MaxReadReq 512 bytes
> DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+
> AuxPwr+ TransPend-
> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s,
> Latency L0 unlimited, L1 unlimited
> ClockPM- Surprise- LLActRep- BwNot-
> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain-
> CommClk+
> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
> DLActive- BWMgmt- ABWMgmt-
> Capabilities: [100 v1] Advanced Error Reporting
> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt+
> UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
> UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt-
> UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
> NonFatalErr-
> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
> NonFatalErr-
> AERCap: First Error Pointer: 14, GenCap+ CGenEn-
> ChkCap+ ChkEn-
> Capabilities: [180 v1] Device Serial Number ff-76-f8-79-00-26-18-ff
> Kernel driver in use: ATL1E
>
>
> $ ethtool -k eth0
> Offload parameters for eth0:
> rx-checksumming: off
> tx-checksumming: on
> scatter-gather: on
> tcp-segmentation-offload: on
> udp-fragmentation-offload: off
> generic-segmentation-offload: on
> generic-receive-offload: on
> large-receive-offload: off
> rx-vlan-offload: on
> tx-vlan-offload: on
> ntuple-filters: off
> receive-hashing: off
>
>
> SCP initiated on client:
> $ scp server:/export/no_backup/burn/openSUSE-12.2-DVD-x86_64.iso .
> openSUSE-12.2-DVD-x86_64.iso
>
> 1% 88MB
> 9.8MB/s 07:26 ETA
> Corrupted MAC on input.
> Disconnecting: Packet corrupt
> lost connection
>
> SCP initiated on server:
> $ scp /export/no_backup/burn/openSUSE-12.2-DVD-x86_64.iso client:/tmp
> Enter passphrase for key '/home/chewie/tessun/.ssh/id_rsa':
> openSUSE-12.2-DVD-x86_64.iso
>
> 5% 229MB
> 7.0MB/s 10:00 ETA
> Received disconnect from 2a01:198:366:100::fba5: 2: Packet corrupt
> lost connection
>
>
> ifconfig-output (Client):
> RX packets:773481 errors:0 dropped:7620 overruns:0 frame:0
> TX packets:589594 errors:0 dropped:0 overruns:0 carrier:1
> collisions:0 Sendewarteschlangenlänge:1000
> RX bytes:596932088 (569.2 Mb) TX bytes:90583584 (86.3 Mb)
> Interrupt:44
>
> ifconfig-Output (Server):
> RX packets:11579837 errors:0 dropped:0 overruns:0 frame:0
> TX packets:19734057 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:2717120721 (2591.2 Mb) TX bytes:22047372376
> (21026.0 Mb)
> Interrupt:42 Base address:0xc000
>
>
> As said: Other NICs than the Atheros work fine.
>
> If you need additional Infos (tcpdumps, etc.) please let me know.
>
> Regards,
> Martin
Is it only happening for IPv6 traffic, or is it also buggy for IPv4 ?
If you disable tso , does the bug disappear ?
^ permalink raw reply
* Re: [PATCH 2/2] smsc95xx: support PHY wakeup source
From: David Miller @ 2012-11-21 17:07 UTC (permalink / raw)
To: steve.glendinning; +Cc: netdev
In-Reply-To: <1353504577-5719-2-git-send-email-steve.glendinning@shawell.net>
From: Steve Glendinning <steve.glendinning@shawell.net>
Date: Wed, 21 Nov 2012 13:29:37 +0000
> +{
> + struct mii_if_info *mii = &dev->mii;
> +
> + /* first, a dummy read, needed to latch some MII phys */
> + int ret = smsc95xx_mdio_read_nopm(dev->net, mii->phy_id, MII_BMSR);
Please keep the local variable declarations together at the beginning
of the basic block, don't intermix empty lines and comments as you
are doing here.
^ permalink raw reply
* Re: [PATCH 1/2] smsc95xx: detect chip revision specific features
From: David Miller @ 2012-11-21 17:06 UTC (permalink / raw)
To: steve.glendinning; +Cc: netdev
In-Reply-To: <1353504577-5719-1-git-send-email-steve.glendinning@shawell.net>
From: Steve Glendinning <steve.glendinning@shawell.net>
Date: Wed, 21 Nov 2012 13:29:36 +0000
> + if ((val == ID_REV_CHIP_ID_9500A_) || (val == ID_REV_CHIP_ID_9530_) ||
> + (val == ID_REV_CHIP_ID_89530_) || (val == ID_REV_CHIP_ID_9730_))
> + pdata->features = FEATURE_8_WAKEUP_FILTERS
> + | FEATURE_PHY_NLP_CROSSOVER | FEATURE_AUTOSUSPEND;
Please style this properly.
if ((val == ID_REV_CHIP_ID_9500A_) || (val == ID_REV_CHIP_ID_9530_) ||
(val == ID_REV_CHIP_ID_89530_) || (val == ID_REV_CHIP_ID_9730_))
pdata->features = (FEATURE_8_WAKEUP_FILTERS |
FEATURE_PHY_NLP_CROSSOVER |
FEATURE_AUTOSUSPEND);
^ permalink raw reply
* Re: [PATCH] pkt_sched: QFQ Plus: fair-queueing service at DRR cost
From: David Miller @ 2012-11-21 17:04 UTC (permalink / raw)
To: paolo.valente; +Cc: jhs, shemminger, linux-kernel, netdev, rizzo, fchecconi
In-Reply-To: <50ACA2AA.1020206@unimore.it>
From: Paolo Valente <paolo.valente@unimore.it>
Date: Wed, 21 Nov 2012 10:45:14 +0100
> Got it. Actually, if the first qfq_peek_skb returns NULL, then the
> example version that you are proposing apparently may behave in a
> different way than the original one: in your proposal the scheduler
> tries to switch to a new aggregate and may return a non-NULL value,
> whereas the original version would immediately return NULL. I guess
> that this slightly different behavior is fine as well, and I am
> preparing a new patch that integrates these changes.
Thanks.
^ permalink raw reply
* Re: [net-next 06/10] ixgbe: eliminate Smatch warnings in ixgbe_debugfs.c
From: David Miller @ 2012-11-21 17:04 UTC (permalink / raw)
To: dan.carpenter; +Cc: jeffrey.t.kirsher, joshua.a.hay, netdev, gospo, sassmann
In-Reply-To: <20121121110409.GG6186@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Wed, 21 Nov 2012 14:04:09 +0300
> On Wed, Nov 21, 2012 at 02:47:32AM -0800, Jeff Kirsher wrote:
>> + len = simple_write_to_buffer(ixgbe_dbg_reg_ops_buf,
>> + sizeof(ixgbe_dbg_reg_ops_buf)-1,
>> + ppos,
>> + buffer,
>> + count);
>> + if (len < 0)
>> + return -EFAULT;
>
> Any negative return is bad.
>
> if (len)
> return len;
...
>> @@ -187,15 +196,15 @@ static ssize_t ixgbe_dbg_netdev_ops_write(struct file *filp,
...
>> + if (len < 0)
>> + return -EFAULT;
>
> Same.
Agreed.
^ permalink raw reply
* Re: 8139cp: set ring address before enabling receiver
From: David Woodhouse @ 2012-11-21 16:57 UTC (permalink / raw)
To: Jason Wang; +Cc: David S. Miller, netdev, Jeff Garzik
In-Reply-To: <20120602235020.2C0A57C006C@ra.kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2601 bytes --]
On Sat, 2012-06-02 at 23:50 +0000, Linux Kernel Mailing List wrote:
> Gitweb: http://git.kernel.org/linus/;a=commit;h=b01af4579ec41f48e9b9c774e70bd6474ad210db
> Commit: b01af4579ec41f48e9b9c774e70bd6474ad210db
> Parent: 20e2a86485967c385d7c7befc1646e4d1d39362e
> Author: Jason Wang <jasowang@redhat.com>
> AuthorDate: Thu May 31 18:19:39 2012 +0000
> Committer: David S. Miller <davem@davemloft.net>
> CommitDate: Fri Jun 1 14:22:11 2012 -0400
>
> 8139cp: set ring address before enabling receiver
>
> Currently, we enable the receiver before setting the ring address which could
> lead the card DMA into unexpected areas. Solving this by set the ring address
> before enabling the receiver.
>
> btw. I find and test this in qemu as I didn't have a 8139cp card in hand. please
> review it carefully.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
This commit appears to break Ethernet on my Traverse Geos router. With
OpenWRT and 3.6.6 I get:
[ 124.068359] NETDEV WATCHDOG: eth1 (8139cp): transmit queue 0 timed out
...
[ 124.260614] 8139cp 0000:00:0b.0: eth1: Transmit timeout, status c 2b 1 80ac
If I add code to *read* the *RingAddr registers, at the later point in
cp_init_hw() that they *used* to be set, I get the following:
[ 1126.909193] HiTxRingAddr 0000000000000000 (should be 0)
[ 1126.913880] RxRingAddr 000000000f1e5000 (sb f1e5000)
[ 1126.919018] TxRingAddr 000000000f344400 (sb f1e5400)
Adding further debugging indicates that it's being changed in
cp_start_hw(), at the line which writes the CpCmd register. These two
outputs are from the surrounding lines...
[ 1331.650579] at line 960 TxRingAddr 000000000f3c6400 (sb f3c6400)
[ 1331.656820] at line 962 TxRingAddr 000000000f3e4400 (sb f3c6400)
The devices are:
00:0a.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ [10ec:8139] (rev 20)
00:0b.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ [10ec:8139] (rev 20)
The other one (eth0) isn't connected, which is why I only see the errors
from eth1.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply
* Re: [patch net] team: bcast: convert return value of team_dev_queue_xmit() to bool correctly
From: David Miller @ 2012-11-21 16:55 UTC (permalink / raw)
To: jiri; +Cc: netdev, dan.carpenter
In-Reply-To: <20121121125328.GA6812@minipsycho.orion>
From: Jiri Pirko <jiri@resnulli.us>
Date: Wed, 21 Nov 2012 13:53:28 +0100
>
> I forgot to mention this bug was introduced by:
> team: add broadcast mode (5fc889911a99043a97da1daa0d010ad72cbc3042)
>
> Wed, Nov 21, 2012 at 01:34:45PM CET, jiri@resnulli.us wrote:
>>The thing is that team_dev_queue_xmit() returns NET_XMIT_* or -E*.
>>bc_trasmit() should return true in case all went well. So use ! to get
>>correct retval from team_dev_queue_xmit() result.
>>This bug caused iface statistics to be badly computed.
>>
>>Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
>>Signed-off-by: Jiri Pirko <jiri@resnulli.us>
I incorporated the reference to the bug introducing commit and
applied this patch, thanks.
^ permalink raw reply
* Re: [PATCH net-2.6] bonding: Bonding driver does not consider the gso_max_size/gso_max_segs setting of slave devices.
From: David Miller @ 2012-11-21 16:51 UTC (permalink / raw)
To: eric.dumazet; +Cc: sarveshwar.bandi, netdev
In-Reply-To: <1353509706.2590.33.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 21 Nov 2012 06:55:06 -0800
> On Wed, 2012-11-21 at 20:05 +0530, sarveshwar.bandi@emulex.com wrote:
>> From: Sarveshwar Bandi <sarveshwar.bandi@emulex.com>
>>
>> Patch sets the lowest gso_max_size and gso_max_segs values of the slave devices during enslave and detach.
>>
>> Signed-off-by: Sarveshwar Bandi <sarveshwar.bandi@emulex.com>
...
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH V3] xen/netfront: handle compound page fragments on transmit
From: David Miller @ 2012-11-21 16:49 UTC (permalink / raw)
To: konrad
Cc: ian.campbell, netdev, xen-devel, edumazet, annie.li, linux,
stefan.bader
In-Reply-To: <20121121151625.GA13127@konrad-lan.dumpdata.com>
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
Date: Wed, 21 Nov 2012 10:16:27 -0500
> On Wed, Nov 21, 2012 at 12:02:16PM +0000, Ian Campbell wrote:
>> An SKB paged fragment can consist of a compound page with order > 0.
>> However the netchannel protocol deals only in PAGE_SIZE frames.
>>
>> Handle this in xennet_make_frags by iterating over the frames which
>> make up the page.
>>
>> This is the netfront equivalent to 6a8ed462f16b for netback.
>>
>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> Cc: netdev@vger.kernel.org
>> Cc: xen-devel@lists.xen.org
>> Cc: Eric Dumazet <edumazet@google.com>
>> Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>
>
> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>
> David, would you like me to send it to Linus via my tree or are you
> OK sending him a git pull with this patch (and hopefully some other
> ones?)
I'll merge this to Linus via my net tree, thanks.
^ 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