* Re: [PATCH 00/12] Gigaset driver patches for 2.6.32
From: Tilman Schmidt @ 2009-09-09 22:32 UTC (permalink / raw)
To: Daniel Walker
Cc: i4ldeveloper-JX7+OpRa80SjiSfgN6Y1Ib39b6g2fGNp,
netdev-u79uwXL29TY76Z2rM5mHXA, Hansjoerg Lipp,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, linux-kernel-u79uwXL29TY76Z2rM5mHXA
Daniel Walker wrote 07.09.09 16:30:
> Yeah, it looks like the whole file needs a checkpatch clean up.. Sounds
like your not willing to do that?
It's not a question of willingness. You may notice I did a lot of cleanup work already. But it's very time consuming work, and there has been more important work to attend to first.
> Usually if a checkpatch cleanup comes
first prior to all your other changes , it doesn't usually cloud the
rest of the changes..
Sure. But that would mean postponing the merging of bugfixes until someone finds the time to do a complete checkpatch cleanup of the affected code. I don't think that's a sensible approach.
Thanks,
Tilman
^ permalink raw reply
* Re: TCP kernel tables overflowing after sustained 1000 new connections per second
From: David Miller @ 2009-09-10 0:08 UTC (permalink / raw)
To: paulsheer; +Cc: linux-kernel, roque, netdev
In-Reply-To: <c67e3dc60909091146j4aeaf422v4e0543eff87c7f9a@mail.gmail.com>
From: Paul Sheer <paulsheer@gmail.com>
Date: Wed, 9 Sep 2009 20:46:07 +0200
Can you please send networking reports and questions at least
CC:'d to netdev@vger.kernel.org, which is where the networking
developers are subscribed? I've added it to the CC:
> I am developing a high-performance application, and testing against Apache.
> It makes 1000 new connections to Apache per second.
>
> After 16 seconds the test grinds to a halt. A Linux kernel problem. There are
> several hurdles to overcome when trying to sustain such through-put. Some
> are configuration issues, others I believe are real problems with the kernel
> internals. I'll discuss these all below.
>
> Configuration:
>
> These are the relavent kernel configuration parameters:
>
> /proc/sys/net/ipv4/tcp_tw_recycle
> /proc/sys/net/ipv4/tcp_tw_reuse
> /proc/sys/net/ipv4/tcp_max_tw_buckets
> /proc/sys/net/ipv4/ip_local_port_range
> /proc/sys/net/ipv4/tcp_timestamps
> /proc/sys/net/ipv4/tcp_fin_timeout
> /proc/sys/net/ipv4/tcp_orphan_retries
> /proc/sys/net/ipv4/tcp_rfc1337
> /proc/sys/net/ipv4/tcp_max_orphans
> /proc/sys/net/ipv4/tcp_max_syn_backlog
> /proc/sys/net/ipv4/tcp_mem
>
> On a gigabit local LAN I can set the timeouts very low to encourage
> port reuse. A well known configuration issue with all OS's - just search
> for MyOS+TIMED_WAIT on google. No problems here.
>
>
> The second problem is the ip_conntrack module.
>
> If you don't know that your distribution has enabled this module
> by default, it not easy to work out that it has internal tables
> that max out at 16384. So this explains why my system
> stops accepting connections after exactly 16 seconds.
> If you stop the application, give it a few minutes, try again,
> then you can do another 16 seconds of flat out load for it
> grinds to a halt again. Doing an rm on the module ko and
> rebooting fixed *this* problem.
>
> The third problem seems to be connected to /proc/net/tcp6
>
> look at the output of the script
>
> while true ; do echo "`date`: `cat /proc/net/tcp6 | wc -l` vs `cat
> /proc/net/tcp | wc -l`" ; sleep 1 ; done
>
> while I run my load test:
>
>
> Wed Sep 9 20:39:26 SAST 2009: 5 vs 20
> Wed Sep 9 20:39:27 SAST 2009: 5 vs 20
> Wed Sep 9 20:39:28 SAST 2009: 5 vs 20
> Wed Sep 9 20:39:29 SAST 2009: 5 vs 20
> Wed Sep 9 20:39:31 SAST 2009: 1233 vs 20
> Wed Sep 9 20:39:32 SAST 2009: 2640 vs 21
> Wed Sep 9 20:39:33 SAST 2009: 4190 vs 20
> Wed Sep 9 20:39:34 SAST 2009: 5813 vs 20
> Wed Sep 9 20:39:35 SAST 2009: 7527 vs 20
> Wed Sep 9 20:39:37 SAST 2009: 9568 vs 44
> Wed Sep 9 20:39:38 SAST 2009: 11819 vs 21
> Wed Sep 9 20:39:40 SAST 2009: 14510 vs 21
> Wed Sep 9 20:39:42 SAST 2009: 16971 vs 20
> Wed Sep 9 20:39:44 SAST 2009: 16971 vs 20
> Wed Sep 9 20:39:46 SAST 2009: 17013 vs 20
> Wed Sep 9 20:39:48 SAST 2009: 17013 vs 20
> Wed Sep 9 20:39:50 SAST 2009: 17013 vs 20
>
> So it is clear "something" is filling up in tcp_ipv6.c
>
> any ideas Pedro?
> anyone?
>
> Many thanks.
>
> -paul
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* pull request: wireless-next-2.6 2009-09-09
From: John W. Linville @ 2009-09-10 0:10 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev
Dave,
One last batch of wireless bits for the 2.6.32 merge window... :-)
This includes a number of ath9k updates related especially to bluetooth
coexistance, as well as a number of b43 changes related to support of SDIO
and the associated SSB over SDIO bus support.
Please let me know if there are problems!
Thanks,
John
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6/
---
The following changes since commit 6ec1c69a8f6492fd25722f4762721921da074c12:
David S. Miller (1):
net_sched: add classful multiqueue dummy scheduler
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git master
Albert Herranz (1):
ssb: Implement SDIO host bus support
Christian Lamparter (1):
ar9170: implement frequency calibration for one-stage/openfw
Holger Schurig (1):
cfg80211: allow scanning on specified frequencies when using wext-compatibility
Ivo van Doorn (1):
rt2x00: Hardcode TX ack timeout and consume time
Joe Perches (1):
MAINTAINERS: Add Atheros Linux wireless drivers home page
Joerg Albert (3):
ar9170: added phy register initialisation from eeprom values
ath,ar9170: move CTL_ defines into regd.h
ath,ar9170: implemented conformance test limit calc. for tx power
Luis R. Rodriguez (5):
ath9k: propagate ieee80211_alloc_hw() failure
ath9k: propagate errors on ath_init_device() and request_irq()
ath9k: claim irq for ath9k, not ath for pci
wireless: update cfg80211 kconfig entry
wireless: mark prism54 as deprecated and mark for removal
Michael Buesch (10):
b43: Use a threaded IRQ handler
b43: Remove TX spinlock
b43: Remove DMA/PIO queue locks
b43: Remove PIO RX workqueue
b43: remove SHM spinlock
ssb: Fail ssb modinit, if attach of the buses failed.
b43: PCMCIA is not experimental anymore
b43: Really disable QoS, if requested
b43: Fix sparse warning in hw-tkip code
b44/b43/b43legacy: Fix switch warnings introduced by SSB-SDIO
Sujith (2):
ath9k: Fix RX Filter handling for BAR
ath9k: Fix channelFlags for 2GHZ
Vasanthakumar Thiagarajan (6):
ath9k: Disable ASPM when btcoex is active
ath9k: Remove unnecessary casting to u8 in pci_read_config_byte() call
ath9k: Store subsystem id in struct hw_version
ath9k: Enable btcoex based on the subsystem id of the device
ath9k: Get rid of the modparam btcoex_enable
ath9k: Initialize the priority gpio for BT coex 3-wire
Documentation/feature-removal-schedule.txt | 29 ++
MAINTAINERS | 2 +
drivers/net/b44.c | 10 +-
drivers/net/wireless/Kconfig | 57 +--
drivers/net/wireless/ath/ar9170/phy.c | 420 +++++++++++++++++++-
drivers/net/wireless/ath/ath9k/ahb.c | 10 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 2 +-
drivers/net/wireless/ath/ath9k/btcoex.c | 23 +
drivers/net/wireless/ath/ath9k/btcoex.h | 2 +
drivers/net/wireless/ath/ath9k/hw.c | 30 +-
drivers/net/wireless/ath/ath9k/hw.h | 10 +
drivers/net/wireless/ath/ath9k/mac.h | 1 +
drivers/net/wireless/ath/ath9k/main.c | 12 +-
drivers/net/wireless/ath/ath9k/pci.c | 22 +-
drivers/net/wireless/ath/ath9k/recv.c | 3 +
drivers/net/wireless/ath/ath9k/reg.h | 1 -
drivers/net/wireless/ath/regd.h | 6 +
drivers/net/wireless/ath/regd_common.h | 6 -
drivers/net/wireless/b43/Kconfig | 4 +-
drivers/net/wireless/b43/b43.h | 30 +-
drivers/net/wireless/b43/debugfs.c | 67 +---
drivers/net/wireless/b43/debugfs.h | 3 +-
drivers/net/wireless/b43/dma.c | 31 +--
drivers/net/wireless/b43/dma.h | 3 -
drivers/net/wireless/b43/main.c | 460 +++++++++++-----------
drivers/net/wireless/b43/main.h | 4 -
drivers/net/wireless/b43/phy_common.c | 1 -
drivers/net/wireless/b43/phy_common.h | 3 +-
drivers/net/wireless/b43/phy_g.c | 7 -
drivers/net/wireless/b43/phy_g.h | 3 +-
drivers/net/wireless/b43/pio.c | 71 +---
drivers/net/wireless/b43/pio.h | 6 -
drivers/net/wireless/b43/sysfs.c | 3 -
drivers/net/wireless/b43/xmit.c | 10 +-
drivers/net/wireless/b43legacy/main.c | 8 +-
drivers/net/wireless/rt2x00/rt2400pci.c | 5 +-
drivers/net/wireless/rt2x00/rt2500pci.c | 5 +-
drivers/net/wireless/rt2x00/rt2500usb.c | 4 -
drivers/net/wireless/rt2x00/rt2800usb.c | 3 +-
drivers/net/wireless/rt2x00/rt2x00.h | 3 -
drivers/net/wireless/rt2x00/rt2x00config.c | 11 -
drivers/net/wireless/rt2x00/rt61pci.c | 2 +-
drivers/net/wireless/rt2x00/rt73usb.c | 2 +-
drivers/ssb/Kconfig | 14 +
drivers/ssb/Makefile | 1 +
drivers/ssb/main.c | 64 +++-
drivers/ssb/scan.c | 11 +
drivers/ssb/sdio.c | 610 ++++++++++++++++++++++++++++
drivers/ssb/ssb_private.h | 40 ++
include/linux/ssb/ssb.h | 25 +-
net/wireless/Kconfig | 11 +-
net/wireless/scan.c | 41 ++-
52 files changed, 1673 insertions(+), 539 deletions(-)
create mode 100644 drivers/ssb/sdio.c
Omnibus patch is available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2009-09-09.patch.bz2
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH] [NIU] VLAN does not work with niu driver
From: David Miller @ 2009-09-10 0:15 UTC (permalink / raw)
To: Joyce.Yu; +Cc: netdev
In-Reply-To: <4AA819D8.1020306@Sun.COM>
From: Joyce Yu <Joyce.Yu@sun.com>
Date: Wed, 09 Sep 2009 14:10:48 -0700
> drivers/net/niu.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Can I get a more verbose commit message than this?
> @@ -2700,7 +2700,7 @@ struct fcram_hash_ipv6 {
> #define RCR_PKT_TYPE_UDP 0x2
> #define RCR_PKT_TYPE_SCTP 0x3
>
> -#define NIU_RXPULL_MAX ETH_HLEN
> +#define NIU_RXPULL_MAX 64
>
See, that's why I want a detailed commit message, because if you
described things more clearly I'd understand why you choose the value
'64' as opposed to, say, the size of a VLAN header which to me would
be a more appropriate value to use here.
You just seem to be reverting a change I made a while back, and it
just so happens to fix your problem. But '64' is too large a value
to use here and it will impact performance.
You did check to see if there were any performance regressions
resulting from your change, right?
^ permalink raw reply
* Re: [PATCH] [NIU] VLAN does not work with niu driver
From: David Miller @ 2009-09-10 0:16 UTC (permalink / raw)
To: shemminger; +Cc: Joyce.Yu, netdev
In-Reply-To: <20090909143514.0bd1e7ba@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 9 Sep 2009 14:35:14 -0700
> Shouldn't the vlan driver being doing pskb_may_pull()
> or pskb_pull() instead?
I thought about it, and my answer is 'probably not'.
Just like for eth_type_trans(), it's pretty reasonable to
expect the link level header to be linearized already.
^ permalink raw reply
* Re: TCP kernel tables overflowing after sustained 1000 new connections per second
From: Brian Haley @ 2009-09-10 0:26 UTC (permalink / raw)
To: paulsheer; +Cc: David Miller, linux-kernel, roque, netdev
In-Reply-To: <20090909.170824.141343404.davem@davemloft.net>
>> The third problem seems to be connected to /proc/net/tcp6
>>
>> look at the output of the script
>>
>> while true ; do echo "`date`: `cat /proc/net/tcp6 | wc -l` vs `cat
>> /proc/net/tcp | wc -l`" ; sleep 1 ; done
>>
>> while I run my load test:
>>
>>
>> Wed Sep 9 20:39:26 SAST 2009: 5 vs 20
>> Wed Sep 9 20:39:27 SAST 2009: 5 vs 20
>> Wed Sep 9 20:39:28 SAST 2009: 5 vs 20
>> Wed Sep 9 20:39:29 SAST 2009: 5 vs 20
>> Wed Sep 9 20:39:31 SAST 2009: 1233 vs 20
>> Wed Sep 9 20:39:32 SAST 2009: 2640 vs 21
>> Wed Sep 9 20:39:33 SAST 2009: 4190 vs 20
>> Wed Sep 9 20:39:34 SAST 2009: 5813 vs 20
>> Wed Sep 9 20:39:35 SAST 2009: 7527 vs 20
>> Wed Sep 9 20:39:37 SAST 2009: 9568 vs 44
>> Wed Sep 9 20:39:38 SAST 2009: 11819 vs 21
>> Wed Sep 9 20:39:40 SAST 2009: 14510 vs 21
>> Wed Sep 9 20:39:42 SAST 2009: 16971 vs 20
>> Wed Sep 9 20:39:44 SAST 2009: 16971 vs 20
>> Wed Sep 9 20:39:46 SAST 2009: 17013 vs 20
>> Wed Sep 9 20:39:48 SAST 2009: 17013 vs 20
>> Wed Sep 9 20:39:50 SAST 2009: 17013 vs 20
>>
>> So it is clear "something" is filling up in tcp_ipv6.c
By default, apache is going to open an IPv6 socket, so every connection,
even IPv4, will use an IPv6 socket with a mapped address:
# netstat -anp | grep apache
tcp6 0 0 :::80 :::* LISTEN 27795/apache2
tcp6 0 0 ::ffff:10.0.0.1:80 ::ffff:10.0.0.2:35271 ESTABLISHED27813/apache2
I'm guessing that 17013 is your 16384 plus a few in time-wait, right?
There's a way to change it to be IPv4-only in the conf file from what I remember.
-Brian
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-09-09
From: David Miller @ 2009-09-10 0:36 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20090910001025.GA19645@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 9 Sep 2009 20:10:25 -0400
> One last batch of wireless bits for the 2.6.32 merge window... :-)
>
> This includes a number of ath9k updates related especially to bluetooth
> coexistance, as well as a number of b43 changes related to support of SDIO
> and the associated SSB over SDIO bus support.
Pulled, thanks John!
^ permalink raw reply
* Re: [PATCH] ipv6: Add IFA_F_DADFAILED flag
From: Brian Haley @ 2009-09-10 0:41 UTC (permalink / raw)
To: Jens Rosenboom; +Cc: david Miller, netdev@vger.kernel.org, YOSHIFUJI Hideaki
In-Reply-To: <1252424623.5827.14.camel@fnki-nb00130>
Jens Rosenboom wrote:
> On Tue, 2009-09-08 at 11:18 -0400, Brian Haley wrote:
>> Jens Rosenboom wrote:
>>>> --- a/net/ipv6/addrconf.c
>>>> +++ b/net/ipv6/addrconf.c
>>>> @@ -1376,7 +1376,7 @@ static void addrconf_dad_stop(struct inet6_ifaddr *ifp)
>>>> if (ifp->flags&IFA_F_PERMANENT) {
>>>> spin_lock_bh(&ifp->lock);
>>>> addrconf_del_timer(ifp);
>>>> - ifp->flags |= IFA_F_TENTATIVE;
>>>> + ifp->flags |= IFA_F_DADFAILED;
>>> I think you still have to set IFA_F_TENTATIVE here, too, otherwise
>>> ipv6_dev_get_saddr() will use this address.
>> The tentative bit is still set from when this address was added back
>> in ipv6_add_addr() from what I can tell, re-setting it here is actually
>> unnecessary. At least /sbin/ip was still showing it set during my
>> testing.
>
> There is the possibility of a race when the dad_timer expires at the
> same time the NA triggering DAD failure is received. There isn't a big
> chance to see that during real world testing, though.
Ok, how does this look? I changed it to set the tentative flag as it did
before, plus clear the dad_failed flag if the device got restarted,
triggering DAD to happen again for any tentative address, that was an
oversight on my part.
I'd still like to know if using this last ifa_flag is going to be an issue,
I actually finished a similar patch that uses a new IFA_ADDRFLAGS structure
to pass in/out this additional info.
-Brian
diff --git a/include/linux/if_addr.h b/include/linux/if_addr.h
index a60c821..fd97404 100644
--- a/include/linux/if_addr.h
+++ b/include/linux/if_addr.h
@@ -41,6 +41,7 @@ enum
#define IFA_F_NODAD 0x02
#define IFA_F_OPTIMISTIC 0x04
+#define IFA_F_DADFAILED 0x08
#define IFA_F_HOMEADDRESS 0x10
#define IFA_F_DEPRECATED 0x20
#define IFA_F_TENTATIVE 0x40
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 43b3c9f..c9b3690 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1371,12 +1371,14 @@ struct inet6_ifaddr *ipv6_get_ifaddr(struct net *net, const struct in6_addr *add
/* Gets referenced address, destroys ifaddr */
-static void addrconf_dad_stop(struct inet6_ifaddr *ifp)
+static void addrconf_dad_stop(struct inet6_ifaddr *ifp, int dad_failed)
{
if (ifp->flags&IFA_F_PERMANENT) {
spin_lock_bh(&ifp->lock);
addrconf_del_timer(ifp);
ifp->flags |= IFA_F_TENTATIVE;
+ if (dad_failed)
+ ifp->flags |= IFA_F_DADFAILED;
spin_unlock_bh(&ifp->lock);
in6_ifa_put(ifp);
#ifdef CONFIG_IPV6_PRIVACY
@@ -1422,7 +1424,7 @@ void addrconf_dad_failure(struct inet6_ifaddr *ifp)
}
}
- addrconf_dad_stop(ifp);
+ addrconf_dad_stop(ifp, 1);
}
/* Join to solicited addr multicast group. */
@@ -2778,7 +2780,7 @@ static void addrconf_dad_start(struct inet6_ifaddr *ifp, u32 flags)
idev->cnf.accept_dad < 1 ||
!(ifp->flags&IFA_F_TENTATIVE) ||
ifp->flags & IFA_F_NODAD) {
- ifp->flags &= ~(IFA_F_TENTATIVE|IFA_F_OPTIMISTIC);
+ ifp->flags &= ~(IFA_F_TENTATIVE|IFA_F_OPTIMISTIC|IFA_F_DADFAILED);
spin_unlock_bh(&ifp->lock);
read_unlock_bh(&idev->lock);
@@ -2795,7 +2797,7 @@ static void addrconf_dad_start(struct inet6_ifaddr *ifp, u32 flags)
* - otherwise, kill it.
*/
in6_ifa_hold(ifp);
- addrconf_dad_stop(ifp);
+ addrconf_dad_stop(ifp, 0);
return;
}
@@ -2829,7 +2831,7 @@ static void addrconf_dad_timer(unsigned long data)
* DAD was successful
*/
- ifp->flags &= ~(IFA_F_TENTATIVE|IFA_F_OPTIMISTIC);
+ ifp->flags &= ~(IFA_F_TENTATIVE|IFA_F_OPTIMISTIC|IFA_F_DADFAILED);
spin_unlock_bh(&ifp->lock);
read_unlock_bh(&idev->lock);
^ permalink raw reply related
* Re: [PATCH] [NIU] VLAN does not work with niu driver
From: Matheos Worku @ 2009-09-10 1:01 UTC (permalink / raw)
To: David Miller; +Cc: Joyce.Yu, netdev
In-Reply-To: <20090909.171517.34998160.davem@davemloft.net>
David Miller wrote:
> From: Joyce Yu <Joyce.Yu@sun.com>
> Date: Wed, 09 Sep 2009 14:10:48 -0700
>
>> drivers/net/niu.h | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> Can I get a more verbose commit message than this?
>
>> @@ -2700,7 +2700,7 @@ struct fcram_hash_ipv6 {
>> #define RCR_PKT_TYPE_UDP 0x2
>> #define RCR_PKT_TYPE_SCTP 0x3
>>
>> -#define NIU_RXPULL_MAX ETH_HLEN
>> +#define NIU_RXPULL_MAX 64
>>
>
> See, that's why I want a detailed commit message, because if you
> described things more clearly I'd understand why you choose the value
> '64' as opposed to, say, the size of a VLAN header which to me would
> be a more appropriate value to use here.
Dave,
The frame type in NIU HW is embedded in a HW header, so it is
possible to check the HW header and decide whether to pull up ETH_HLEN
or VLAN header size of bytes. However, considering the amount of work
required to get and examine the HW header (including endianess issues),
we thought pulling up 64 bytes by default (as used in cassini.c) would
be efficient.
Regards,
Matheos
>
> You just seem to be reverting a change I made a while back, and it
> just so happens to fix your problem. But '64' is too large a value
> to use here and it will impact performance.
>
> You did check to see if there were any performance regressions
> resulting from your change, right?
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] [NIU] VLAN does not work with niu driver
From: David Miller @ 2009-09-10 1:10 UTC (permalink / raw)
To: Matheos.Worku; +Cc: Joyce.Yu, netdev
In-Reply-To: <4AA84FE3.6030407@sun.com>
From: Matheos Worku <Matheos.Worku@Sun.COM>
Date: Wed, 09 Sep 2009 18:01:23 -0700
> The frame type in NIU HW is embedded in a HW header, so it is possible
> to check the HW header and decide whether to pull up ETH_HLEN or VLAN
> header size of bytes. However, considering the amount of work required
> to get and examine the HW header (including endianess issues), we
> thought pulling up 64 bytes by default (as used in cassini.c) would be
> efficient.
Well, it was 64 in early versions of the driver, and I decreased it
down to ETH_HLEN.
The less the better since for forwarding applications anything past
the IPV4 header pulled is going to be a waste of CPU cache lines and
thus negatively effect forwarding rates.
That's why I asked if this change was performance regression tested,
because I know it's going to slow down forwarding rates for small
packets.
^ permalink raw reply
* Re: net_sched: fix estimator lock selection for mq child qdiscs
From: David Miller @ 2009-09-10 1:11 UTC (permalink / raw)
To: kaber; +Cc: netdev
In-Reply-To: <4AA7D0C5.9080601@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Wed, 09 Sep 2009 17:59:01 +0200
> net_sched: fix estimator lock selection for mq child qdiscs
>
> When new child qdiscs are attached to the mq qdisc, they are actually
> attached as root qdiscs to the device queues. The lock selection for
> new estimators incorrectly picks the root lock of the existing and
> to be replaced qdisc, which results in a use-after-free once the old
> qdisc has been destroyed.
>
> Mark mq qdisc instances with a new flag and treat qdiscs attached to
> mq as children similar to regular root qdiscs.
>
> Additionally prevent estimators from being attached to the mq qdisc
> itself since it only updates its byte and packet counters during dumps.
>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH NEXT 2/2] netxen: fix tx descriptor structure
From: David Miller @ 2009-09-10 1:13 UTC (permalink / raw)
To: dhananjay; +Cc: netdev, amit
In-Reply-To: <1252526963-25621-2-git-send-email-dhananjay@netxen.com>
From: Dhananjay Phadke <dhananjay@netxen.com>
Date: Wed, 9 Sep 2009 13:09:23 -0700
> From: Amit Kumar Salecha <amit@qlogic.com>
>
> Fix the offset of vlan_TCI field in cmd_desc_type0.
>
> Signed-off-by: Amit Kumar Salecha <amit@qlogic.com>
> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Also applied, thanks.
^ permalink raw reply
* Re: [PATCH] [NIU] VLAN does not work with niu driver
From: Matheos Worku @ 2009-09-10 1:19 UTC (permalink / raw)
To: David Miller; +Cc: Joyce.Yu, netdev
In-Reply-To: <20090909.181033.25374239.davem@davemloft.net>
David Miller wrote:
> From: Matheos Worku <Matheos.Worku@Sun.COM>
> Date: Wed, 09 Sep 2009 18:01:23 -0700
>
>> The frame type in NIU HW is embedded in a HW header, so it is possible
>> to check the HW header and decide whether to pull up ETH_HLEN or VLAN
>> header size of bytes. However, considering the amount of work required
>> to get and examine the HW header (including endianess issues), we
>> thought pulling up 64 bytes by default (as used in cassini.c) would be
>> efficient.
>
> Well, it was 64 in early versions of the driver, and I decreased it
> down to ETH_HLEN.
>
> The less the better since for forwarding applications anything past
> the IPV4 header pulled is going to be a waste of CPU cache lines and
> thus negatively effect forwarding rates.
>
> That's why I asked if this change was performance regression tested,
> because I know it's going to slow down forwarding rates for small
> packets.
Dave,
We did throughput testing (netperf) and didn't notice any performance
degradation. We haven't done forwarding testing however.
We can work on a version which implements HW header checking and do
pullup accordingly.
Regards,
Matheos
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] [NIU] VLAN does not work with niu driver
From: David Miller @ 2009-09-10 1:44 UTC (permalink / raw)
To: Matheos.Worku; +Cc: Joyce.Yu, netdev
In-Reply-To: <4AA85404.5020300@sun.com>
From: Matheos Worku <Matheos.Worku@Sun.COM>
Date: Wed, 09 Sep 2009 18:19:00 -0700
> We can work on a version which implements HW header checking and do
> pullup accordingly.
I think using a constant based on the vlan header size would be
sufficient to fix this.
^ permalink raw reply
* Re: [PATCH] [NIU] VLAN does not work with niu driver
From: Matheos Worku @ 2009-09-10 1:48 UTC (permalink / raw)
To: David Miller; +Cc: Joyce.Yu, netdev
In-Reply-To: <20090909.184410.64382338.davem@davemloft.net>
David Miller wrote:
> From: Matheos Worku <Matheos.Worku@Sun.COM>
> Date: Wed, 09 Sep 2009 18:19:00 -0700
>
>> We can work on a version which implements HW header checking and do
>> pullup accordingly.
>
> I think using a constant based on the vlan header size would be
> sufficient to fix this.
We will have a patch based on vlan header size.
Regards
Matheos
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] dm9000: Use resource_size instead of private macro
From: David Miller @ 2009-09-10 1:55 UTC (permalink / raw)
To: tklauser; +Cc: netdev
In-Reply-To: <1252494464-4633-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Wed, 9 Sep 2009 13:07:43 +0200
> The macro res_size in drivers/net/dm9000.c is a copy of resource_size in
> linux/ioport.h. Remove the function and use resource_size instead.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* Re: [PATCH] dm9000: Remove unnecessary memset of netdev private data
From: David Miller @ 2009-09-10 1:55 UTC (permalink / raw)
To: tklauser; +Cc: netdev
In-Reply-To: <1252494464-4633-2-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Wed, 9 Sep 2009 13:07:44 +0200
> The memory for the private data is allocated using kzalloc in
> alloc_etherdev (or alloc_netdev_mq respectively) so there is no need to
> set it to 0 again.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Applied.
^ permalink raw reply
* [PATCH 1/3] phy/marvell: Make non-aneg speed/duplex forcing work for 88E1111 PHYs
From: Anton Vorontsov @ 2009-09-10 2:01 UTC (permalink / raw)
To: David Miller
Cc: Andy Fleming, Timur Tabi, Li Yang, Kumar Gala, netdev,
linuxppc-dev
According to specs, when auto-negotiation is disabled, Marvell PHYs need
a software reset after changing speed/duplex forcing bits. Otherwise,
the modified bits have no effect.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/phy/marvell.c | 21 ++++++++++++++++++++-
1 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index dd6f54d..6f69b9b 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -155,8 +155,27 @@ static int marvell_config_aneg(struct phy_device *phydev)
return err;
err = genphy_config_aneg(phydev);
+ if (err < 0)
+ return err;
- return err;
+ if (phydev->autoneg != AUTONEG_ENABLE) {
+ int bmcr;
+
+ /*
+ * A write to speed/duplex bits (that is performed by
+ * genphy_config_aneg() call above) must be followed by
+ * a software reset. Otherwise, the write has no effect.
+ */
+ bmcr = phy_read(phydev, MII_BMCR);
+ if (bmcr < 0)
+ return bmcr;
+
+ err = phy_write(phydev, MII_BMCR, bmcr | BMCR_RESET);
+ if (err < 0)
+ return err;
+ }
+
+ return 0;
}
static int m88e1121_config_aneg(struct phy_device *phydev)
--
1.6.3.3
^ permalink raw reply related
* [PATCH 2/3] ucc_geth: Rearrange some code to avoid forward declarations
From: Anton Vorontsov @ 2009-09-10 2:01 UTC (permalink / raw)
To: David Miller
Cc: Andy Fleming, Timur Tabi, Li Yang, Kumar Gala, netdev,
linuxppc-dev
We'll need ugeth_disable() and ugeth_enable() calls earlier in the
file, so rearrange some code to avoid forward declarations.
The patch doesn't contain any functional changes.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/ucc_geth.c | 300 ++++++++++++++++++++++++------------------------
1 files changed, 149 insertions(+), 151 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 33ed69e..2a2c973 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1411,6 +1411,155 @@ static int adjust_enet_interface(struct ucc_geth_private *ugeth)
return 0;
}
+static int ugeth_graceful_stop_tx(struct ucc_geth_private *ugeth)
+{
+ struct ucc_fast_private *uccf;
+ u32 cecr_subblock;
+ u32 temp;
+ int i = 10;
+
+ uccf = ugeth->uccf;
+
+ /* Mask GRACEFUL STOP TX interrupt bit and clear it */
+ clrbits32(uccf->p_uccm, UCC_GETH_UCCE_GRA);
+ out_be32(uccf->p_ucce, UCC_GETH_UCCE_GRA); /* clear by writing 1 */
+
+ /* Issue host command */
+ cecr_subblock =
+ ucc_fast_get_qe_cr_subblock(ugeth->ug_info->uf_info.ucc_num);
+ qe_issue_cmd(QE_GRACEFUL_STOP_TX, cecr_subblock,
+ QE_CR_PROTOCOL_ETHERNET, 0);
+
+ /* Wait for command to complete */
+ do {
+ msleep(10);
+ temp = in_be32(uccf->p_ucce);
+ } while (!(temp & UCC_GETH_UCCE_GRA) && --i);
+
+ uccf->stopped_tx = 1;
+
+ return 0;
+}
+
+static int ugeth_graceful_stop_rx(struct ucc_geth_private *ugeth)
+{
+ struct ucc_fast_private *uccf;
+ u32 cecr_subblock;
+ u8 temp;
+ int i = 10;
+
+ uccf = ugeth->uccf;
+
+ /* Clear acknowledge bit */
+ temp = in_8(&ugeth->p_rx_glbl_pram->rxgstpack);
+ temp &= ~GRACEFUL_STOP_ACKNOWLEDGE_RX;
+ out_8(&ugeth->p_rx_glbl_pram->rxgstpack, temp);
+
+ /* Keep issuing command and checking acknowledge bit until
+ it is asserted, according to spec */
+ do {
+ /* Issue host command */
+ cecr_subblock =
+ ucc_fast_get_qe_cr_subblock(ugeth->ug_info->uf_info.
+ ucc_num);
+ qe_issue_cmd(QE_GRACEFUL_STOP_RX, cecr_subblock,
+ QE_CR_PROTOCOL_ETHERNET, 0);
+ msleep(10);
+ temp = in_8(&ugeth->p_rx_glbl_pram->rxgstpack);
+ } while (!(temp & GRACEFUL_STOP_ACKNOWLEDGE_RX) && --i);
+
+ uccf->stopped_rx = 1;
+
+ return 0;
+}
+
+static int ugeth_restart_tx(struct ucc_geth_private *ugeth)
+{
+ struct ucc_fast_private *uccf;
+ u32 cecr_subblock;
+
+ uccf = ugeth->uccf;
+
+ cecr_subblock =
+ ucc_fast_get_qe_cr_subblock(ugeth->ug_info->uf_info.ucc_num);
+ qe_issue_cmd(QE_RESTART_TX, cecr_subblock, QE_CR_PROTOCOL_ETHERNET, 0);
+ uccf->stopped_tx = 0;
+
+ return 0;
+}
+
+static int ugeth_restart_rx(struct ucc_geth_private *ugeth)
+{
+ struct ucc_fast_private *uccf;
+ u32 cecr_subblock;
+
+ uccf = ugeth->uccf;
+
+ cecr_subblock =
+ ucc_fast_get_qe_cr_subblock(ugeth->ug_info->uf_info.ucc_num);
+ qe_issue_cmd(QE_RESTART_RX, cecr_subblock, QE_CR_PROTOCOL_ETHERNET,
+ 0);
+ uccf->stopped_rx = 0;
+
+ return 0;
+}
+
+static int ugeth_enable(struct ucc_geth_private *ugeth, enum comm_dir mode)
+{
+ struct ucc_fast_private *uccf;
+ int enabled_tx, enabled_rx;
+
+ uccf = ugeth->uccf;
+
+ /* check if the UCC number is in range. */
+ if (ugeth->ug_info->uf_info.ucc_num >= UCC_MAX_NUM) {
+ if (netif_msg_probe(ugeth))
+ ugeth_err("%s: ucc_num out of range.", __func__);
+ return -EINVAL;
+ }
+
+ enabled_tx = uccf->enabled_tx;
+ enabled_rx = uccf->enabled_rx;
+
+ /* Get Tx and Rx going again, in case this channel was actively
+ disabled. */
+ if ((mode & COMM_DIR_TX) && (!enabled_tx) && uccf->stopped_tx)
+ ugeth_restart_tx(ugeth);
+ if ((mode & COMM_DIR_RX) && (!enabled_rx) && uccf->stopped_rx)
+ ugeth_restart_rx(ugeth);
+
+ ucc_fast_enable(uccf, mode); /* OK to do even if not disabled */
+
+ return 0;
+
+}
+
+static int ugeth_disable(struct ucc_geth_private *ugeth, enum comm_dir mode)
+{
+ struct ucc_fast_private *uccf;
+
+ uccf = ugeth->uccf;
+
+ /* check if the UCC number is in range. */
+ if (ugeth->ug_info->uf_info.ucc_num >= UCC_MAX_NUM) {
+ if (netif_msg_probe(ugeth))
+ ugeth_err("%s: ucc_num out of range.", __func__);
+ return -EINVAL;
+ }
+
+ /* Stop any transmissions */
+ if ((mode & COMM_DIR_TX) && uccf->enabled_tx && !uccf->stopped_tx)
+ ugeth_graceful_stop_tx(ugeth);
+
+ /* Stop any receptions */
+ if ((mode & COMM_DIR_RX) && uccf->enabled_rx && !uccf->stopped_rx)
+ ugeth_graceful_stop_rx(ugeth);
+
+ ucc_fast_disable(ugeth->uccf, mode); /* OK to do even if not enabled */
+
+ return 0;
+}
+
/* Called every time the controller might need to be made
* aware of new link state. The PHY code conveys this
* information through variables in the ugeth structure, and this
@@ -1586,157 +1735,6 @@ static int init_phy(struct net_device *dev)
return 0;
}
-
-
-static int ugeth_graceful_stop_tx(struct ucc_geth_private *ugeth)
-{
- struct ucc_fast_private *uccf;
- u32 cecr_subblock;
- u32 temp;
- int i = 10;
-
- uccf = ugeth->uccf;
-
- /* Mask GRACEFUL STOP TX interrupt bit and clear it */
- clrbits32(uccf->p_uccm, UCC_GETH_UCCE_GRA);
- out_be32(uccf->p_ucce, UCC_GETH_UCCE_GRA); /* clear by writing 1 */
-
- /* Issue host command */
- cecr_subblock =
- ucc_fast_get_qe_cr_subblock(ugeth->ug_info->uf_info.ucc_num);
- qe_issue_cmd(QE_GRACEFUL_STOP_TX, cecr_subblock,
- QE_CR_PROTOCOL_ETHERNET, 0);
-
- /* Wait for command to complete */
- do {
- msleep(10);
- temp = in_be32(uccf->p_ucce);
- } while (!(temp & UCC_GETH_UCCE_GRA) && --i);
-
- uccf->stopped_tx = 1;
-
- return 0;
-}
-
-static int ugeth_graceful_stop_rx(struct ucc_geth_private * ugeth)
-{
- struct ucc_fast_private *uccf;
- u32 cecr_subblock;
- u8 temp;
- int i = 10;
-
- uccf = ugeth->uccf;
-
- /* Clear acknowledge bit */
- temp = in_8(&ugeth->p_rx_glbl_pram->rxgstpack);
- temp &= ~GRACEFUL_STOP_ACKNOWLEDGE_RX;
- out_8(&ugeth->p_rx_glbl_pram->rxgstpack, temp);
-
- /* Keep issuing command and checking acknowledge bit until
- it is asserted, according to spec */
- do {
- /* Issue host command */
- cecr_subblock =
- ucc_fast_get_qe_cr_subblock(ugeth->ug_info->uf_info.
- ucc_num);
- qe_issue_cmd(QE_GRACEFUL_STOP_RX, cecr_subblock,
- QE_CR_PROTOCOL_ETHERNET, 0);
- msleep(10);
- temp = in_8(&ugeth->p_rx_glbl_pram->rxgstpack);
- } while (!(temp & GRACEFUL_STOP_ACKNOWLEDGE_RX) && --i);
-
- uccf->stopped_rx = 1;
-
- return 0;
-}
-
-static int ugeth_restart_tx(struct ucc_geth_private *ugeth)
-{
- struct ucc_fast_private *uccf;
- u32 cecr_subblock;
-
- uccf = ugeth->uccf;
-
- cecr_subblock =
- ucc_fast_get_qe_cr_subblock(ugeth->ug_info->uf_info.ucc_num);
- qe_issue_cmd(QE_RESTART_TX, cecr_subblock, QE_CR_PROTOCOL_ETHERNET, 0);
- uccf->stopped_tx = 0;
-
- return 0;
-}
-
-static int ugeth_restart_rx(struct ucc_geth_private *ugeth)
-{
- struct ucc_fast_private *uccf;
- u32 cecr_subblock;
-
- uccf = ugeth->uccf;
-
- cecr_subblock =
- ucc_fast_get_qe_cr_subblock(ugeth->ug_info->uf_info.ucc_num);
- qe_issue_cmd(QE_RESTART_RX, cecr_subblock, QE_CR_PROTOCOL_ETHERNET,
- 0);
- uccf->stopped_rx = 0;
-
- return 0;
-}
-
-static int ugeth_enable(struct ucc_geth_private *ugeth, enum comm_dir mode)
-{
- struct ucc_fast_private *uccf;
- int enabled_tx, enabled_rx;
-
- uccf = ugeth->uccf;
-
- /* check if the UCC number is in range. */
- if (ugeth->ug_info->uf_info.ucc_num >= UCC_MAX_NUM) {
- if (netif_msg_probe(ugeth))
- ugeth_err("%s: ucc_num out of range.", __func__);
- return -EINVAL;
- }
-
- enabled_tx = uccf->enabled_tx;
- enabled_rx = uccf->enabled_rx;
-
- /* Get Tx and Rx going again, in case this channel was actively
- disabled. */
- if ((mode & COMM_DIR_TX) && (!enabled_tx) && uccf->stopped_tx)
- ugeth_restart_tx(ugeth);
- if ((mode & COMM_DIR_RX) && (!enabled_rx) && uccf->stopped_rx)
- ugeth_restart_rx(ugeth);
-
- ucc_fast_enable(uccf, mode); /* OK to do even if not disabled */
-
- return 0;
-
-}
-
-static int ugeth_disable(struct ucc_geth_private * ugeth, enum comm_dir mode)
-{
- struct ucc_fast_private *uccf;
-
- uccf = ugeth->uccf;
-
- /* check if the UCC number is in range. */
- if (ugeth->ug_info->uf_info.ucc_num >= UCC_MAX_NUM) {
- if (netif_msg_probe(ugeth))
- ugeth_err("%s: ucc_num out of range.", __func__);
- return -EINVAL;
- }
-
- /* Stop any transmissions */
- if ((mode & COMM_DIR_TX) && uccf->enabled_tx && !uccf->stopped_tx)
- ugeth_graceful_stop_tx(ugeth);
-
- /* Stop any receptions */
- if ((mode & COMM_DIR_RX) && uccf->enabled_rx && !uccf->stopped_rx)
- ugeth_graceful_stop_rx(ugeth);
-
- ucc_fast_disable(ugeth->uccf, mode); /* OK to do even if not enabled */
-
- return 0;
-}
-
static void ugeth_dump_regs(struct ucc_geth_private *ugeth)
{
#ifdef DEBUG
--
1.6.3.3
^ permalink raw reply related
* [PATCH 3/3] ucc_geth: Fix hangs after switching from full to half duplex
From: Anton Vorontsov @ 2009-09-10 2:01 UTC (permalink / raw)
To: David Miller
Cc: Andy Fleming, Timur Tabi, Li Yang, Kumar Gala, netdev,
linuxppc-dev
MPC8360 QE UCC ethernet controllers hang when changing link duplex
under a load (a bit of NFS activity is enough).
PHY: mdio@e0102120:00 - Link is Up - 1000/Full
sh-3.00# ethtool -s eth0 speed 100 duplex half autoneg off
PHY: mdio@e0102120:00 - Link is Down
PHY: mdio@e0102120:00 - Link is Up - 100/Half
NETDEV WATCHDOG: eth0 (ucc_geth): transmit queue 0 timed out
------------[ cut here ]------------
Badness at c01fcbd0 [verbose debug info unavailable]
NIP: c01fcbd0 LR: c01fcbd0 CTR: c0194e44
...
The cure is to disable the controller before changing speed/duplex
and enable it afterwards.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/ucc_geth.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 2a2c973..9ad9015 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1631,9 +1631,13 @@ static void adjust_link(struct net_device *dev)
ugeth->oldspeed = phydev->speed;
}
+ ugeth_disable(ugeth, COMM_DIR_RX_AND_TX);
+
out_be32(&ug_regs->maccfg2, tempval);
out_be32(&uf_regs->upsmr, upsmr);
+ ugeth_enable(ugeth, COMM_DIR_RX_AND_TX);
+
if (!ugeth->oldlink) {
new_state = 1;
ugeth->oldlink = 1;
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH 00/12] Gigaset driver patches for 2.6.32
From: Daniel Walker @ 2009-09-10 3:47 UTC (permalink / raw)
To: Tilman Schmidt; +Cc: davem, linux-kernel, netdev, i4ldeveloper, Hansjoerg Lipp
In-Reply-To: <20090909223205.E9D632269516@fifo99.com>
On Thu, 2009-09-10 at 00:32 +0200, Tilman Schmidt wrote:
> Daniel Walker wrote 07.09.09 16:30:
> > Yeah, it looks like the whole file needs a checkpatch clean up..
> Sounds
> like your not willing to do that?
>
> It's not a question of willingness. You may notice I did a lot of
> cleanup work already. But it's very time consuming work, and there has
> been more important work to attend to first.
>
> > Usually if a checkpatch cleanup comes
> first prior to all your other changes , it doesn't usually cloud the
> rest of the changes..
>
> Sure. But that would mean postponing the merging of bugfixes until
> someone finds the time to do a complete checkpatch cleanup of the
> affected code. I don't think that's a sensible approach.
You shouldn't be adding any new checkpatch errors, but you currently
are .. Just clean up the individual patches w/o the entire gigaset
driver, that should be do-able (it's even a basic submission
requirement). The other issue is that your adding new files which aren't
clean, those can certainly be cleaned up.
Daniel
^ permalink raw reply
* Re: [PATCH 00/12] Gigaset driver patches for 2.6.32
From: David Miller @ 2009-09-10 3:51 UTC (permalink / raw)
To: dwalker; +Cc: tilman, linux-kernel, netdev, i4ldeveloper, hjlipp
In-Reply-To: <1252554477.30578.167.camel@desktop>
From: Daniel Walker <dwalker@fifo99.com>
Date: Wed, 09 Sep 2009 20:47:57 -0700
> On Thu, 2009-09-10 at 00:32 +0200, Tilman Schmidt wrote:
>> Daniel Walker wrote 07.09.09 16:30:
>> > Yeah, it looks like the whole file needs a checkpatch clean up..
>> Sounds
>> like your not willing to do that?
>>
>> It's not a question of willingness. You may notice I did a lot of
>> cleanup work already. But it's very time consuming work, and there has
>> been more important work to attend to first.
>>
>> > Usually if a checkpatch cleanup comes
>> first prior to all your other changes , it doesn't usually cloud the
>> rest of the changes..
>>
>> Sure. But that would mean postponing the merging of bugfixes until
>> someone finds the time to do a complete checkpatch cleanup of the
>> affected code. I don't think that's a sensible approach.
>
> You shouldn't be adding any new checkpatch errors, but you currently
> are .. Just clean up the individual patches w/o the entire gigaset
> driver, that should be do-able (it's even a basic submission
> requirement). The other issue is that your adding new files which aren't
> clean, those can certainly be cleaned up.
Right, this is a very reasonable request.
^ permalink raw reply
* Re: [iproute2] tc action mirred question
From: Xiaofei Wu @ 2009-09-10 6:06 UTC (permalink / raw)
To: hadi; +Cc: linux netdev
In-Reply-To: <1252534266.4119.5.camel@dogo.mojatatu.com>
>> After run 'tcpdump -i wlan1 -e', I can not capture any packets.
>Could it be related to the wireless driver?
Maybe. I will check it.
>Here's something i tried on my laptop
....
>
I tried your example.
-on window1 'ping 127.0.0.2'
....
2616 packets transmitted, 0 received, 100% packet loss
-on window2 'tcpdump -n -i eth0 -e' , i see
....
10:15:06.314420 00:23:cd:af:d0:74 > 00:23:cd:af:ec:da, ethertype IPv4 (0x0800), length 98: 127.0.0.2 > 127.0.0.2: ICMP echo request, id 17419, seq 234, length 64
....
-on window3 'tcpdump -i lo -e'
....
10:15:37.332527 00:23:cd:af:d0:74 (oui Unknown) > 00:23:cd:af:ec:da (oui Unknown), ethertype IPv4 (0x0800), length 98: 127.0.0.2 > 127.0.0.2: ICMP echo request, id 17419, seq 265, length 64
....
It seems that I modify the dst MAC, src MAC of the packets, then transmit to 'lo' and mirror the packects to 'eth0'. (On 'lo', '2616 packets transmitted, 0 received, 100% packet loss' .) How to let 'lo' receive the packets?
But I want to only modify the dst MAC, src MAC of the mirroring packets, transmit them to next hop. (not modify the dst,src MAC of the packets to 'lo'). What should I do?
When I change 'lo' to 'eth1' (or wlan1 ...), node A will have two paths (A-B-C, A-D-C) to transmit the "same"(IP header, data) packets to node C simultaneously.
regards,
wu
^ permalink raw reply
* Re: r8169 ethernet hangs after a pm-suspend (and resume)
From: Alex Bennee @ 2009-09-10 6:49 UTC (permalink / raw)
To: Francois Romieu; +Cc: lkml, netdev
In-Reply-To: <20090909092822.GA18355@electric-eye.fr.zoreil.com>
2009/9/9 Francois Romieu <romieu@fr.zoreil.com>:
> Alex Bennee <kernel-hacker@bennee.com> :
> [...]
>> I've just recently gotten suspend working on my system. Unfortunately
>> after the resume event I loose access to the network.
>> As far as the system is concerned the network is configured properly
>> but every attempt to ping local nodes fails with "Host not reachable".
>
> Can the problem be described as "gigabit link setting does not survive
> suspend/resume" ?
Further experimentation shows the failure is intermittent. The
following dmesg shows a successful resume with working 'net:
[ 475.800017] ACPI: Waking up from system sleep state S3
[ 475.800726] HDA Intel 0000:00:1b.0: restoring config space at
offset 0x1 (was 0x100006, writing 0x100002)
[ 475.800747] pcieport-driver 0000:00:1c.0: restoring config space at
offset 0xf (was 0x60100, writing 0x6010a)
[ 475.800762] pcieport-driver 0000:00:1c.0: restoring config space at
offset 0x1 (was 0x100107, writing 0x100507)
[ 475.800799] pci 0000:00:1d.0: restoring config space at offset 0x1
(was 0x2800005, writing 0x2800001)
[ 475.800819] pci 0000:00:1d.1: restoring config space at offset 0x1
(was 0x2800005, writing 0x2800001)
[ 475.800840] pci 0000:00:1d.2: restoring config space at offset 0x1
(was 0x2800005, writing 0x2800001)
[ 475.800861] pci 0000:00:1d.3: restoring config space at offset 0x1
(was 0x2800005, writing 0x2800001)
[ 475.800889] pci 0000:00:1d.7: restoring config space at offset 0x1
(was 0x2900006, writing 0x2900002)
[ 475.800967] PIIX_IDE 0000:00:1f.1: restoring config space at offset
0x1 (was 0x2880005, writing 0x2800005)
[ 475.801050] r8169 0000:02:00.0: restoring config space at offset
0x3 (was 0x4, writing 0x8)
[ 475.801056] r8169 0000:02:00.0: restoring config space at offset
0x1 (was 0x100007, writing 0x100407)
[ 475.803466] i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 475.803470] i915 0000:00:02.0: setting latency timer to 64
[ 475.864097] [drm] DAC-6: set mode 1440x900 2a
[ 475.936922] [drm] TMDS-8: set mode 1680x1050 2b
[ 476.108887] HDA Intel 0000:00:1b.0: PCI INT A -> GSI 19 (level,
low) -> IRQ 19
[ 476.108892] HDA Intel 0000:00:1b.0: setting latency timer to 64
[ 476.548200] pci 0000:00:1d.7: PME# disabled
[ 476.548207] pci 0000:00:1e.0: setting latency timer to 64
[ 476.548216] PIIX_IDE 0000:00:1f.1: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[ 476.548223] PIIX_IDE 0000:00:1f.1: setting latency timer to 64
[ 476.548235] ata_piix 0000:00:1f.2: PCI INT B -> GSI 17 (level, low) -> IRQ 17
[ 476.548248] ata_piix 0000:00:1f.2: setting latency timer to 64
[ 476.548352] r8169 0000:02:00.0: PME# disabled
[ 476.564404] r8169: eth0: link up
And now compare with a return from suspend that failed:
[12397.816024] ACPI: Waking up from system sleep state S3
[12397.816693] agpgart-intel 0000:00:00.0: restoring config space at
offset 0x1 (was 0x30900006, writing 0x20900006)
[12397.816737] HDA Intel 0000:00:1b.0: restoring config space at
offset 0x1 (was 0x100006, writing 0x100002)
[12397.816757] pcieport-driver 0000:00:1c.0: restoring config space at
offset 0xf (was 0x60100, writing 0x6010a)
[12397.816768] pcieport-driver 0000:00:1c.0: restoring config space at
offset 0x7 (was 0x2000e0e0, writing 0xe0e0)
[12397.816776] pcieport-driver 0000:00:1c.0: restoring config space at
offset 0x1 (was 0x100107, writing 0x100507)
[12397.816813] uhci_hcd 0000:00:1d.0: restoring config space at offset
0x1 (was 0x2800005, writing 0x2800001)
[12397.816835] uhci_hcd 0000:00:1d.1: restoring config space at offset
0x1 (was 0x2800005, writing 0x2800001)
[12397.816856] uhci_hcd 0000:00:1d.2: restoring config space at offset
0x1 (was 0x2800005, writing 0x2800001)
[12397.816877] uhci_hcd 0000:00:1d.3: restoring config space at offset
0x1 (was 0x2800005, writing 0x2800001)
[12397.816906] pci 0000:00:1d.7: restoring config space at offset 0x1
(was 0x2900006, writing 0x2900002)
[12397.816929] pci 0000:00:1e.0: restoring config space at offset 0x7
(was 0x2280d0d0, writing 0xa280d0d0)
[12397.816987] PIIX_IDE 0000:00:1f.1: restoring config space at offset
0x1 (was 0x2880005, writing 0x2800005)
[12397.832040] r8169 0000:02:00.0: restoring config space at offset
0xf (was 0xffffffff, writing 0x10a)
[12397.832045] r8169 0000:02:00.0: restoring config space at offset
0xe (was 0xffffffff, writing 0x0)
[12397.832050] r8169 0000:02:00.0: restoring config space at offset
0xd (was 0xffffffff, writing 0x40)
[12397.832055] r8169 0000:02:00.0: restoring config space at offset
0xc (was 0xffffffff, writing 0xdffc0000)
[12397.832061] r8169 0000:02:00.0: restoring config space at offset
0xb (was 0xffffffff, writing 0x81aa1043)
[12397.832066] r8169 0000:02:00.0: restoring config space at offset
0xa (was 0xffffffff, writing 0x0)
[12397.832071] r8169 0000:02:00.0: restoring config space at offset
0x9 (was 0xffffffff, writing 0x0)
[12397.832076] r8169 0000:02:00.0: restoring config space at offset
0x8 (was 0xffffffff, writing 0xdeff000c)
[12397.832081] r8169 0000:02:00.0: restoring config space at offset
0x7 (was 0xffffffff, writing 0x0)
[12397.832086] r8169 0000:02:00.0: restoring config space at offset
0x6 (was 0xffffffff, writing 0xdffff004)
[12397.832091] r8169 0000:02:00.0: restoring config space at offset
0x5 (was 0xffffffff, writing 0x0)
[12397.832096] r8169 0000:02:00.0: restoring config space at offset
0x4 (was 0xffffffff, writing 0xe801)
[12397.832101] r8169 0000:02:00.0: restoring config space at offset
0x3 (was 0xffffffff, writing 0x8)
[12397.832106] r8169 0000:02:00.0: restoring config space at offset
0x2 (was 0xffffffff, writing 0x2000002)
[12397.832111] r8169 0000:02:00.0: restoring config space at offset
0x1 (was 0xffffffff, writing 0x100407)
[12397.832117] r8169 0000:02:00.0: restoring config space at offset
0x0 (was 0xffffffff, writing 0x816810ec)
[12397.834527] i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[12397.834531] i915 0000:00:02.0: setting latency timer to 64
[12397.895209] [drm] DAC-6: set mode 1440x900 2a
[12397.968038] [drm] TMDS-8: set mode 1680x1050 2b
[12398.140006] HDA Intel 0000:00:1b.0: PCI INT A -> GSI 19 (level,
low) -> IRQ 19
[12398.140011] HDA Intel 0000:00:1b.0: setting latency timer to 64
[12398.580194] uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
[12398.580200] uhci_hcd 0000:00:1d.0: setting latency timer to 64
[12398.580224] usb usb2: root hub lost power or was reset
[12398.580250] uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
[12398.580255] uhci_hcd 0000:00:1d.1: setting latency timer to 64
[12398.580273] usb usb3: root hub lost power or was reset
[12398.580291] uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
[12398.580296] uhci_hcd 0000:00:1d.2: setting latency timer to 64
[12398.580314] usb usb4: root hub lost power or was reset
[12398.580332] uhci_hcd 0000:00:1d.3: PCI INT D -> GSI 19 (level, low) -> IRQ 19
[12398.580337] uhci_hcd 0000:00:1d.3: setting latency timer to 64
[12398.580355] usb usb5: root hub lost power or was reset
[12398.580374] pci 0000:00:1d.7: PME# disabled
[12398.580380] pci 0000:00:1e.0: setting latency timer to 64
[12398.580387] PIIX_IDE 0000:00:1f.1: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[12398.580394] PIIX_IDE 0000:00:1f.1: setting latency timer to 64
[12398.580403] ata_piix 0000:00:1f.2: PCI INT B -> GSI 17 (level, low) -> IRQ 17
[12398.580407] ata_piix 0000:00:1f.2: setting latency timer to 64
[12398.580512] r8169 0000:02:00.0: PME# disabled
[12398.660050] firewire_core: skipped bus generations, destroying all nodes
[12398.664833] hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
[12398.665625] hda: skipping word 93 validity check
[12398.665627] hda: UDMA/66 mode selected
[12398.687404] sd 0:0:0:0: [sda] Starting disk
[12399.419164] r8169: eth0: link up
which has an oops further on:
[12434.816100] ------------[ cut here ]------------
[12434.816111] WARNING: at net/sched/sch_generic.c:246
dev_watchdog+0x132/0x1da()
[12434.816114] Hardware name: System Product Name
[12434.816117] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out
[12434.816120] Modules linked in: bridge stp llc bnep rfcomm l2cap
bluetooth ipv6 snd_pcm_oss snd_mixer_oss snd_seq_oss
snd_seq_midi_event snd_seq snd_seq_device kvm_intel kvm acpi_cpufreq
snd_hda_codec_analog snd_hda_intel uhci_hcd snd_hda_codec snd_hwdep
snd_pcm snd_timer ide_cd_mod firewire_ohci firewire_core snd soundcore
usbcore r8169 cdrom processor crc_itu_t nls_base snd_page_alloc mii
evdev thermal pcspkr unix [last unloaded: ehci_hcd]
[12434.816164] Pid: 0, comm: swapper Not tainted
2.6.31-rc9-ajb-00012-g3ff323f-dirty #86
[12434.816167] Call Trace:
[12434.816169] <IRQ> [<ffffffff812aa117>] ? dev_watchdog+0x132/0x1da
[12434.816180] [<ffffffff8103eb72>] warn_slowpath_common+0x7c/0xa9
[12434.816185] [<ffffffff8103ec1e>] warn_slowpath_fmt+0x69/0x6b
[12434.816190] [<ffffffff81039e47>] ? default_wake_function+0x12/0x14
[12434.816195] [<ffffffff8102c24c>] ? __wake_up_common+0x4b/0x7b
[12434.816200] [<ffffffff8102f793>] ? __wake_up+0x48/0x54
[12434.816205] [<ffffffff81298b7d>] ? netdev_drivername+0x48/0x4f
[12434.816209] [<ffffffff812aa117>] dev_watchdog+0x132/0x1da
[12434.816214] [<ffffffff810510f2>] ? __queue_work+0x3a/0x43
[12434.816218] [<ffffffff812a9fe5>] ? dev_watchdog+0x0/0x1da
[12434.816223] [<ffffffff81048d76>] run_timer_softirq+0x198/0x20d
[12434.816229] [<ffffffff8101d0c6>] ? lapic_next_event+0x1d/0x21
[12434.816234] [<ffffffff8104464f>] __do_softirq+0xd6/0x19a
[12434.816239] [<ffffffff8100c19c>] call_softirq+0x1c/0x28
[12434.816242] [<ffffffff8100d51d>] do_softirq+0x39/0x77
[12434.816246] [<ffffffff8104430c>] irq_exit+0x44/0x7e
[12434.816252] [<ffffffff81305914>] smp_apic_timer_interrupt+0x8d/0x9b
[12434.816258] [<ffffffff8100bb73>] apic_timer_interrupt+0x13/0x20
[12434.816260] <EOI> [<ffffffff810117ac>] ? mwait_idle+0xb9/0xf0
[12434.816269] [<ffffffff81303df5>] ? atomic_notifier_call_chain+0x13/0x15
[12434.816273] [<ffffffff8100a30a>] ? cpu_idle+0x57/0x98
[12434.816278] [<ffffffff812f0612>] ? rest_init+0x66/0x68
[12434.816283] [<ffffffff815299da>] ? start_kernel+0x343/0x34e
[12434.816288] [<ffffffff8152903a>] ? x86_64_start_reservations+0xaa/0xae
[12434.816292] [<ffffffff8152911f>] ? x86_64_start_kernel+0xe1/0xe8
[12434.816295] ---[ end trace 1353478188007667 ]---
[12435.635167] r8169: eth0: link up
At this point even unloading and reloading the r8169 module couldn't
bring the network back. I even tried unloading the module, doing a
pm-hibernate and restore reload and still nothing which was odd as I
though the power cycle should have un-wedged any hardware.
A couple of questions:
1. It seems the failure case has a lot more "restoring config space"
going on. Is this a wider range problem that just happens to hit r8169
harder?
2. Is the oops a red herring or could the failure to resume be because
the shutdown occurs before the hardware has flushed all in flight
packets?
--
Alex, homepage: http://www.bennee.com/~alex/
http://www.half-llama.co.uk
^ permalink raw reply
* Re: [PATCH RESEND] bonding: remap muticast addresses without using dev_close() and dev_open()
From: Or Gerlitz @ 2009-09-10 7:58 UTC (permalink / raw)
To: Moni Shoua
Cc: Jay Vosburgh, David Miller, Jason Gunthorpe, netdev,
bonding-devel
In-Reply-To: <4AA39E42.9070702@Voltaire.COM>
Moni Shoua wrote:
> This patch fixes commit e36b9d16c6a6d0f59803b3ef04ff3c22c3844c10. The approach there is to call dev_close()/dev_open() whenever the device type is changed in order to remap the device IP multicast addresses to HW multicast addresses. This approach suffers from 2 drawbacks [...] The fix here is to directly remap the IP multicast addresses to HW multicast addresses for a bonding device that changes its type, and nothing else.
Moni,
The approach and patch look good. First, I think it may be more easier
to review and maintain if you separate this to two patches, the first
simply reverting e36b9d16c6a6d0f59803b3ef04ff3c22c3844c10 and the second
the approach suggested by this patch. Second, I think you may be able to
do well with only one event, see next
> @@ -1460,14 +1460,17 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
> */
> if (bond->slave_cnt == 0) {
> if (bond_dev->type != slave_dev->type) {
> - dev_close(bond_dev);
> pr_debug("%s: change device type from %d to %d\n",
> bond_dev->name, bond_dev->type, slave_dev->type);
> +
> + netdev_bonding_change(bond_dev, NETDEV_BONDING_OLDTYPE);
> +
> if (slave_dev->type != ARPHRD_ETHER)
> bond_setup_by_slave(bond_dev, slave_dev);
> else
> ether_setup(bond_dev);
> - dev_open(bond_dev);
> +
> + netdev_bonding_change(bond_dev, NETDEV_BONDING_NEWTYPE);
> }
can't you achieve the same impact if just calling
netdev_bonding_change(bond_dev, NETDEV_BONDING_NEWTYPE) after doing the
setup_by_slave, and have the stack call ip_mc_unmap(...) and then
ip_mc_map(...) ???
Or.
^ 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