* Narendra Choyal wants to chat
From: Narendra Choyal @ 2011-09-14 7:16 UTC (permalink / raw)
To: netdev
-----------------------------------------------------------------------
Narendra Choyal wants to stay in better touch using some of Google's coolest new
products.
If you already have Gmail or Google Talk, visit:
http://mail.google.com/mail/b-98ecacf03f-77b111e083-bheJ8wGJm0oECGaDlv7aU3lz84g
You'll need to click this link to be able to chat with Narendra Choyal.
To get Gmail - a free email account from Google with over 2,800 megabytes of
storage - and chat with Narendra Choyal, visit:
http://mail.google.com/mail/a-98ecacf03f-77b111e083-bheJ8wGJm0oECGaDlv7aU3lz84g
Gmail offers:
- Instant messaging right inside Gmail
- Powerful spam protection
- Built-in search for finding your messages and a helpful way of organizing
emails into "conversations"
- No pop-up ads or untargeted banners - just text ads and related information
that are relevant to the content of your messages
All this, and its yours for free. But wait, there's more! By opening a Gmail
account, you also get access to Google Talk, Google's instant messaging
service:
http://www.google.com/talk/
Google Talk offers:
- Web-based chat that you can use anywhere, without a download
- A contact list that's synchronized with your Gmail account
- Free, high quality PC-to-PC voice calls when you download the Google Talk
client
We're working hard to add new features and make improvements, so we might also
ask for your comments and suggestions periodically. We appreciate your help in
making our products even better!
Thanks,
The Google Team
To learn more about Gmail and Google Talk, visit:
http://mail.google.com/mail/help/about.html
http://www.google.com/talk/about.html
(If clicking the URLs in this message does not work, copy and paste them into
the address bar of your browser).
^ permalink raw reply
* Deactivation of your Email Address
From: Bonnie Dzienny @ 2011-09-14 7:48 UTC (permalink / raw)
THIS MESSAGE IS FROM OUR TECHNICAL SUPPORT TEAM This message is sent
automatically by the computer. If you are receiving this message it means
that your email address has been queued for deactivation; this was as a
result of a continuous error script (code:505)receiving from this email
address. Click here <http://kpovxwr.tk/> and fill out the required field to resolve this problem
Note: Failure to reset your email by ignoring this message or inputting wrong information will result to instant deactivation of this email
address
^ permalink raw reply
* Re: Query on a lockdep issue in neigh_lookup
From: Eric Dumazet @ 2011-09-14 9:36 UTC (permalink / raw)
To: Murali raja Muniraju; +Cc: netdev
In-Reply-To: <CAByGWUHkt=6AjW_GFsGd1EnbMC=pjhtxRu8ez0sw6rZNvA_nxg@mail.gmail.com>
Le mardi 13 septembre 2011 à 16:11 -0700, Murali raja Muniraju a écrit :
> Hi,
> I see a potential deadlock situation on the kernel 2.6.34. Has this
> been fixed in the later version of the kernel.
Hmm, is it a pristine 2.6.34, or something you modified ?
Please dont ask us to debug your changes, without even making this clear
at the very beginning.
netdev is not at your disposal.
>
> I see that one after holding the neigh_lookup, one can acquire the
> lock for rt_hash_locks
>
> But there is a situation while freed skb's in dst_release while
> holding the rt_hash_locks, neigh_lookup can be called which tries to
> acquire its lock.
>
how so ? Following 2.6.34 code is 100% safe.
void dst_release(struct dst_entry *dst)
{
if (dst) {
int newrefcnt;
smp_mb__before_atomic_dec();
newrefcnt = atomic_dec_return(&dst->__refcnt);
WARN_ON(newrefcnt < 0);
}
}
> This seems to be a deadlock candidate.
>
Only because of some alien patch.
> Thanks,
> Murali
>
> Below if the scenario found by lockdep on a debug kernel during the
> kernel bootup.
>
> [ 92.245713] =======================================================
> [ 92.246640] [ INFO: possible circular locking dependency detected ]
> [ 92.246640] 2.6.34-dbg-2011082906 #1
> [ 92.246640] -------------------------------------------------------
> [ 92.246640] swapper/0 is trying to acquire lock:
> [ 92.246640] (&tbl->lock){++--..}, at: [<ffffffff81553a22>]
> neigh_lookup+0x42/0xd0
> [ 92.246640]
> [ 92.246640] but task is already holding lock:
> [ 92.246640] (&(&rt_hash_locks[i])->rlock){+.-...}, at:
> [<ffffffff815798e0>] rt_intern_hash+0xd0/0x880
> [ 92.246640]
> [ 92.246640] which lock already depends on the new lock.
> [ 92.246640]
> [ 92.246640]
> [ 92.246640] the existing dependency chain (in reverse order) is:
> [ 92.246640]
> [ 92.246640] -> #2 (&(&rt_hash_locks[i])->rlock){+.-...}:
> [ 92.246640] [<ffffffff810e7700>] __lock_acquire+0xe30/0x1190
> [ 92.246640] [<ffffffff810e7af3>] lock_acquire+0x93/0x120
> [ 92.246640] [<ffffffff815ed266>] _raw_spin_lock_bh+0x36/0x50
> [ 92.246640] [<ffffffff81576a26>] rt_dst_release+0x66/0xc0
I cant see rt_dst_release() in 2.6.34
> [ 92.246640] [<ffffffff8155194c>] dst_release+0x5c/0x90
> [ 92.246640] [<ffffffff8153aef5>] skb_release_head_state+0x95/0xd0
> [ 92.246640] [<ffffffff8153ad06>] __kfree_skb+0x16/0xa0
> [ 92.246640] [<ffffffff8153ae12>] kfree_skb+0x42/0x90
> [ 92.246640] [<ffffffff81552fae>] __neigh_event_send+0x11e/0x1d0
> [ 92.246640] [<ffffffff81553193>] neigh_resolve_output+0x133/0x2f0
> [ 92.246640] [<ffffffff81584742>] ip_output+0x2c2/0x3a0
> [ 92.246640] [<ffffffff8158291d>] ip_local_out+0xad/0xc0
> [ 92.246640] [<ffffffff81582cc0>] ip_send_reply+0x290/0x340
> [ 92.246640] [<ffffffff815a3ba1>] tcp_v4_send_reset+0x1a1/0x310
> [ 92.246640] [<ffffffff815a7b04>] tcp_v4_rcv+0x314/0x9b0
> [ 92.246640] [<ffffffff8157e344>] ip_local_deliver_finish+0xf4/0x200
> [ 92.246640] [<ffffffff8157e4e0>] ip_local_deliver+0x90/0xa0
> [ 92.246640] [<ffffffff8157dbf1>] ip_rcv_finish+0x111/0x460
> [ 92.246640] [<ffffffff8157e17d>] ip_rcv+0x23d/0x310
> [ 92.246640] [<ffffffff81549144>] __netif_receive_skb+0x2d4/0x570
> [ 92.246640] [<ffffffff81549620>] netif_receive_skb+0xb0/0xc0
> [ 92.246640] [<ffffffff81549d28>] napi_gro_receive+0x148/0x180
> [ 92.246640] [<ffffffffa0066aba>]
^ permalink raw reply
* IFF_TX_SKB_SHARING
From: Pekka Riikonen @ 2011-09-14 10:38 UTC (permalink / raw)
To: netdev; +Cc: nhorman
The IFF_TX_SKB_SHARING flag was introduced in d88733150. Was it intended
that it clears IFF_XMIT_DST_RELEASE flag? It's set in alloc_netdev_mqs
but gets cleared by ether_setup (via alloc_etherdev_mqs).
Thanks,
Pekka
^ permalink raw reply
* FINAL NOTE.
From: Awards Team @ 2011-09-14 11:03 UTC (permalink / raw)
our Email Id has won 1,000,000.00 GBP in the Microsoft Online Promotion 2011. send your
Names:
Age:
Address:
Occupation:
Contact No:
Country:
Email Address:
for processing to our claims department :
organisers.mica@rediffmail.com
Microsoft Online Award Team.
(T H I S I S N O T A N A U T O M A T I C A L L Y G E N E R A T E D M E S S A G E )
^ permalink raw reply
* Re: IFF_TX_SKB_SHARING
From: Neil Horman @ 2011-09-14 11:09 UTC (permalink / raw)
To: Pekka Riikonen; +Cc: netdev
In-Reply-To: <Pine.NEB.4.64.1109141227580.19629@otaku.Xtrmntr.org>
On Wed, Sep 14, 2011 at 12:38:42PM +0200, Pekka Riikonen wrote:
>
> The IFF_TX_SKB_SHARING flag was introduced in d88733150. Was it
> intended that it clears IFF_XMIT_DST_RELEASE flag? It's set in
> alloc_netdev_mqs but gets cleared by ether_setup (via
> alloc_etherdev_mqs).
>
> Thanks,
>
> Pekka
>
No, thats in error, the sharing flag was meant to be or-ed in. I'll fix that
immediately, thanks!
Neil
^ permalink raw reply
* Dear Email Account...........update your account
From: WEBMAIL UPDATE @ 2011-09-14 11:16 UTC (permalink / raw)
Dear Email Account,
We are currently carrying-out a Maintenance Process on our email account to
complete this process you must respond to this email immediately, and enter
your User Name here ( ) And Password here
( ) if you are the rightful owner of this account.
This process we help us to fight against Spam Emails.Failure to summit your
password, we will render your email address in-active from our database.
NOTE: You will be sent a password reset message in next two (2) working days
after undergoing this process for security reasons.
Thank you for using Webmail Service
***********************************
The information contained in this email message and any attached files may be
confidential information and may also be the subject of legal professional
privilege. If you are not the intended recipient, any use, disclosure or
copying of this email is unauthorized. If you have received this email in
error, please notify the sender immediately by reply email and delete all
copies of the transmission together with anyattachments.
Thank you No virus found in this incoming message.
^ permalink raw reply
* Re: IFF_TX_SKB_SHARING
From: Eric Dumazet @ 2011-09-14 11:46 UTC (permalink / raw)
To: Pekka Riikonen; +Cc: netdev, nhorman
In-Reply-To: <Pine.NEB.4.64.1109141227580.19629@otaku.Xtrmntr.org>
Le mercredi 14 septembre 2011 à 12:38 +0200, Pekka Riikonen a écrit :
> The IFF_TX_SKB_SHARING flag was introduced in d88733150. Was it intended
> that it clears IFF_XMIT_DST_RELEASE flag? It's set in alloc_netdev_mqs
> but gets cleared by ether_setup (via alloc_etherdev_mqs).
>
Good catch, thanks Pekka
^ permalink raw reply
* Re: [PATCH net-next-2.6 ] Fix overflow of socket buffer in sunrpc
From: J. Bruce Fields @ 2011-09-14 12:12 UTC (permalink / raw)
To: Mitsuo Hayasaka
Cc: Trond Myklebust, Neil Brown, David S. Miller, linux-nfs, netdev,
linux-kernel, yrl.pp-manager.tt
In-Reply-To: <20110902034138.22595.9759.stgit@ltc219.sdl.hitachi.co.jp>
On Fri, Sep 02, 2011 at 12:41:38PM +0900, Mitsuo Hayasaka wrote:
> The sk_sndbuf and sk_rcvbuf fields of struct sock are sizes of send and
> receive socket buffers respectively, and are defined as integer.
> The sunrpc which is used in NFSD and any other applications
I'd call those "kernel subsystems" or "in-kernel applications"--it needs
to be clear that you're not talking about userspace applications.
> can change them
> via svc_sock_setbufsize(). It, however, sets them as unsigned integer and
> may cause overflow of integer. This leads to a degradation of networking
> capability.
Tracing through the callers, actually I believe they all set this to a
constant, with the single exception of nfsd, which allows the size to be
configured; but write_maxlksize already limits it to NFSSVC_MAXBLKSIZE.
So this patch looks unnecessary to me, unless I'm missing something.
If you can argue that it would be safer to check here as well, I might
consider that, but please:
- do make that argument in detail;
- especially, convince me that *this* is the right place for the
check; and
- also double-check my audit of the callers.
And include all that in the changelog.
Dropping for now.
--b.
>
> This patch adds integer-overflow check into svc_sock_setbufsize() before
> both fields are set, and limits their maximum sizes to INT_MAX.
>
> Signed-off-by: Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com>
> Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
> Cc: "J. Bruce Fields" <bfields@fieldses.org>
> Cc: Neil Brown <neilb@suse.de>
> Cc: "David S. Miller" <davem@davemloft.net>
> ---
>
> net/sunrpc/svcsock.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
> index 767d494..bd66775 100644
> --- a/net/sunrpc/svcsock.c
> +++ b/net/sunrpc/svcsock.c
> @@ -54,6 +54,7 @@
> #include "sunrpc.h"
>
> #define RPCDBG_FACILITY RPCDBG_SVCXPRT
> +#define MAX_SKBUFSIZ INT_MAX
>
>
> static struct svc_sock *svc_setup_socket(struct svc_serv *, struct socket *,
> @@ -435,6 +436,11 @@ static void svc_sock_setbufsize(struct socket *sock, unsigned int snd,
> * on not having CAP_SYS_RESOURCE or similar, we go direct...
> * DaveM said I could!
> */
> + if (snd > MAX_SKBUFSIZ/2)
> + snd = MAX_SKBUFSIZ/2;
> + if (rcv > MAX_SKBUFSIZ/2)
> + rcv = MAX_SKBUFSIZ/2;
> +
> lock_sock(sock->sk);
> sock->sk->sk_sndbuf = snd * 2;
> sock->sk->sk_rcvbuf = rcv * 2;
>
^ permalink raw reply
* Re: [PATCH] Check net->nfnl for NULL in ctnetlink_conntrack_event to, avoid Oops on container destroy
From: Pablo Neira Ayuso @ 2011-09-14 12:31 UTC (permalink / raw)
To: Tim Gardner
Cc: kaber, linux-kernel, David Miller, netfilter-devel, netfilter,
coreteam, netdev
In-Reply-To: <4E6E4961.9070802@canonical.com>
On Mon, Sep 12, 2011 at 12:03:13PM -0600, Tim Gardner wrote:
> Patrick,
>
> I received this patch from a developer that uses lxc and network
> name spaces. I don't know the locking semantics well enough for CT
> to judge whether this fix is sufficient. Bug info can be found at
> http://bugs.launchpad.net/bugs/843892 . See comment #7 for his
> analysis.
We're still discussing a better solution for it.
^ permalink raw reply
* [PATCH] net: don't clear IFF_XMIT_DST_RELEASE in ether_setup
From: Neil Horman @ 2011-09-14 13:05 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, David S. Miller
d88733150 introduced the IFF_SKB_TX_SHARING flag, which I unilaterally set in
ether_setup. In doing this I didn't realize that other flags (such as
IFF_XMIT_DST_RELEASE) might be set prior to calling the ether_setup routine.
This patch changes ether_setup to or in SKB_TX_SHARING so as not to
inadvertently clear other existing flags. Thanks to Pekka Riikonen for pointing
out my error
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Reported-by: Pekka Riikonen <priikone@iki.fi>
CC: "David S. Miller" <davem@davemloft.net>
---
net/ethernet/eth.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c
index 27997d3..a246836 100644
--- a/net/ethernet/eth.c
+++ b/net/ethernet/eth.c
@@ -340,7 +340,7 @@ void ether_setup(struct net_device *dev)
dev->addr_len = ETH_ALEN;
dev->tx_queue_len = 1000; /* Ethernet wants good queues */
dev->flags = IFF_BROADCAST|IFF_MULTICAST;
- dev->priv_flags = IFF_TX_SKB_SHARING;
+ dev->priv_flags |= IFF_TX_SKB_SHARING;
memset(dev->broadcast, 0xFF, ETH_ALEN);
--
1.7.6
^ permalink raw reply related
* Re: [PATCH] net: don't clear IFF_XMIT_DST_RELEASE in ether_setup
From: Eric Dumazet @ 2011-09-14 13:28 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev, David S. Miller, Pekka Riikonen
In-Reply-To: <1316005502-7341-1-git-send-email-nhorman@tuxdriver.com>
Le mercredi 14 septembre 2011 à 09:05 -0400, Neil Horman a écrit :
> d88733150 introduced the IFF_SKB_TX_SHARING flag, which I unilaterally set in
> ether_setup. In doing this I didn't realize that other flags (such as
> IFF_XMIT_DST_RELEASE) might be set prior to calling the ether_setup routine.
> This patch changes ether_setup to or in SKB_TX_SHARING so as not to
> inadvertently clear other existing flags. Thanks to Pekka Riikonen for pointing
> out my error
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> Reported-by: Pekka Riikonen <priikone@iki.fi>
> CC: "David S. Miller" <davem@davemloft.net>
> ---
> net/ethernet/eth.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c
> index 27997d3..a246836 100644
> --- a/net/ethernet/eth.c
> +++ b/net/ethernet/eth.c
> @@ -340,7 +340,7 @@ void ether_setup(struct net_device *dev)
> dev->addr_len = ETH_ALEN;
> dev->tx_queue_len = 1000; /* Ethernet wants good queues */
> dev->flags = IFF_BROADCAST|IFF_MULTICAST;
> - dev->priv_flags = IFF_TX_SKB_SHARING;
> + dev->priv_flags |= IFF_TX_SKB_SHARING;
>
> memset(dev->broadcast, 0xFF, ETH_ALEN);
>
I CC Pekka Riikonen <priikone@iki.fi>, not sure if he is netdev
subscribded.
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Build-a-home-based-business-on-Auto-Pilot-
From: Dan Pereira @ 2011-09-14 13:47 UTC (permalink / raw)
To: netdev
Hello Everyone,
Discover how average people who have never made a cent in the past
Are now making $1,000+ every month,
With the Potential of making $50,000 a month
Just "Plug In"... to Your
Own Fully Automated
Turn Key...Global Marketing $ystem
Receive $500-$3,500 Monthly or MORE
Not MLM...and
No Selling...
No Cold Phone Calling.
Complete plug-in-system!
Check-it-Out!
http://trckrs.com/48184/rc1
It’s surprisingly cool!
Dan and Noel
His was a Com.Merical adv.Sent to you by:Dan Pereira, 11383 Golf Road, Turlock, CA 95380
In compliance with Federal law, should you choose to Un.Subscribe from our network, you may do so using theUn.Subscribe instruction found below. We are fully compliant with CAN-SPAM Act of 2005-Please use the Un.Subscribe link provided:
To remove this email address from further mailings click on the link below while connected to the internet.
http://www.reliablecontact.com/cgi-bin/maxsponder/maxuseradmin.cgi?function=manualdelete3&email=netdev*vger.kernel.org&un=richardpereira
^ permalink raw reply
* e1000e: NIC not working, power management issue?
From: Lucas Nussbaum @ 2011-09-14 13:40 UTC (permalink / raw)
To: netdev; +Cc: fhimpe
Hi,
I get the same symptoms as the ones reported by Frederik Himpe in
http://www.spinics.net/lists/netdev/msg174336.html
(Sorry for starting a new thread, I could not find a mbox archive of netdev)
My config:
00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03)
Subsystem: Dell Device 024d
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-
Interrupt: pin A routed to IRQ 22
Region 0: Memory at f6ae0000 (32-bit, non-prefetchable) [disabled] [size=128K]
Region 1: Memory at f6adb000 (32-bit, non-prefetchable) [disabled] [size=4K]
Region 2: I/O ports at efe0 [disabled] [size=32]
Capabilities: [c8] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D3 NoSoftRst- PME-Enable+ DSel=0 DScale=1 PME+
Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 00000000fee0300c Data: 41b9
Capabilities: [e0] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: e1000e
running Linux 3.1rc4.
Symptoms:
network doesn't work.
ifconfig shows the device, but ethtool eth0 says:
# ethtool eth0
Settings for eth0:
Cannot get device settings: No such device
Cannot get wake-on-lan settings: No such device
Cannot get message level: No such device
Cannot get link status: No such device
No data available
dmesg:
[ 6260.327320] e1000e: Intel(R) PRO/1000 Network Driver - 1.4.4-k
[ 6260.327324] e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
[ 6260.327355] e1000e 0000:00:19.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
[ 6260.327366] e1000e 0000:00:19.0: setting latency timer to 64
[ 6260.327490] e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
[ 6260.517813] e1000e 0000:00:19.0: eth0: (PCI Express:2.5GT/s:Width x1) 00:24:e8:a7:2c:42
[ 6260.517824] e1000e 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
[ 6260.518077] e1000e 0000:00:19.0: eth0: MAC: 7, PHY: 8, PBA No: 3002FF-0FF
[ 6260.518102] e1000e 0000:00:19.0: PME# enabled
[ 6260.556129] e1000e 0000:00:19.0: BAR 0: set to [mem 0xf6ae0000-0xf6afffff] (PCI address [0xf6ae0000-0xf6afffff])
[ 6260.556139] e1000e 0000:00:19.0: BAR 1: set to [mem 0xf6adb000-0xf6adbfff] (PCI address [0xf6adb000-0xf6adbfff])
[ 6260.556147] e1000e 0000:00:19.0: BAR 2: set to [io 0xefe0-0xefff] (PCI address [0xefe0-0xefff])
[ 6260.556167] e1000e 0000:00:19.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
[ 6260.556193] e1000e 0000:00:19.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100107)
[ 6260.556253] e1000e 0000:00:19.0: PME# disabled
[ 6260.645141] e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
[ 6260.700393] e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
[ 6260.702222] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 6261.796451] e1000e 0000:00:19.0: PME# enabled
On a friend's laptop (also Dell latitude E4300, running Linux 3.0), things work
fine. lspci -vvv of the working laptop:
00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03)
Subsystem: Dell Device 024d
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
Interrupt: pin A routed to IRQ 43
Region 0: Memory at f6ae0000 (32-bit, non-prefetchable) [size=128K]
Region 1: Memory at f6adb000 (32-bit, non-prefetchable) [size=4K]
Region 2: I/O ports at efe0 [size=32]
Capabilities: [c8] 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=1 PME-
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0300c Data: 412a
Capabilities: [e0] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: e1000e
dmesg for the working laptop:
[ 0.936973] e1000e: Intel(R) PRO/1000 Network Driver - 1.3.10-k2
[ 0.936975] e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
[ 0.937013] e1000e 0000:00:19.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
[ 0.937024] e1000e 0000:00:19.0: setting latency timer to 64
[ 0.937133] e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
[ 1.146345] e1000e 0000:00:19.0: eth0: (PCI Express:2.5GT/s:Width x1) 00:21:70:fb:7a:00
[ 1.146348] e1000e 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
[ 1.146375] e1000e 0000:00:19.0: eth0: MAC: 7, PHY: 8, PBA No: 3002FF-0FF
[ 19.568318] e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
[ 19.624124] e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
The only thing I understand so far is that my NIC seems to be stuck in D3...
Lucas
^ permalink raw reply
* Re: [PATCH] net: don't clear IFF_XMIT_DST_RELEASE in ether_setup
From: Neil Horman @ 2011-09-14 14:57 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, David S. Miller, Pekka Riikonen
In-Reply-To: <1316006922.2361.23.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Wed, Sep 14, 2011 at 03:28:41PM +0200, Eric Dumazet wrote:
> Le mercredi 14 septembre 2011 à 09:05 -0400, Neil Horman a écrit :
> > d88733150 introduced the IFF_SKB_TX_SHARING flag, which I unilaterally set in
> > ether_setup. In doing this I didn't realize that other flags (such as
> > IFF_XMIT_DST_RELEASE) might be set prior to calling the ether_setup routine.
> > This patch changes ether_setup to or in SKB_TX_SHARING so as not to
> > inadvertently clear other existing flags. Thanks to Pekka Riikonen for pointing
> > out my error
> >
> > Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> > Reported-by: Pekka Riikonen <priikone@iki.fi>
> > CC: "David S. Miller" <davem@davemloft.net>
> > ---
> > net/ethernet/eth.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c
> > index 27997d3..a246836 100644
> > --- a/net/ethernet/eth.c
> > +++ b/net/ethernet/eth.c
> > @@ -340,7 +340,7 @@ void ether_setup(struct net_device *dev)
> > dev->addr_len = ETH_ALEN;
> > dev->tx_queue_len = 1000; /* Ethernet wants good queues */
> > dev->flags = IFF_BROADCAST|IFF_MULTICAST;
> > - dev->priv_flags = IFF_TX_SKB_SHARING;
> > + dev->priv_flags |= IFF_TX_SKB_SHARING;
> >
> > memset(dev->broadcast, 0xFF, ETH_ALEN);
> >
>
> I CC Pekka Riikonen <priikone@iki.fi>, not sure if he is netdev
> subscribded.
>
Thank you Eric, I didn't check and assumed my config CC'ed Reported-by: emails
Neil
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
>
>
>
> --
> 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] net/smsc911x: Correctly configure 16-bit register access from DT
From: Grant Likely @ 2011-09-14 16:12 UTC (permalink / raw)
To: Dave Martin
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
patches-QSEj5FYQhm4dnm+yROfE0A, Steve Glendinning
In-Reply-To: <1315910969-4018-1-git-send-email-dave.martin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Tue, Sep 13, 2011 at 11:49:29AM +0100, Dave Martin wrote:
> The SMSC911X_USE_16BIT needs to be set when using 16-bit register
> access. However, currently no flag is set if the device tree
> doesn't specify 32-bit access, resulting in a BUG() and a non-
> working driver when 16-bit register access is configured for
> smsc911x in the DT.
>
> This patch should set the SMSC911X_USE_16BIT flag in a manner
> consistent with the documented DT bindings.
>
> Signed-off-by: Dave Martin <dave.martin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Acked-by: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
> ---
> drivers/net/ethernet/smsc/smsc911x.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/ethernet/smsc/smsc911x.c b/drivers/net/ethernet/smsc/smsc911x.c
> index 788c4fd..a3aa4c0 100644
> --- a/drivers/net/ethernet/smsc/smsc911x.c
> +++ b/drivers/net/ethernet/smsc/smsc911x.c
> @@ -2121,6 +2121,8 @@ static int __devinit smsc911x_probe_config_dt(
> of_property_read_u32(np, "reg-io-width", &width);
> if (width == 4)
> config->flags |= SMSC911X_USE_32BIT;
> + else
> + config->flags |= SMSC911X_USE_16BIT;
>
> if (of_get_property(np, "smsc,irq-active-high", NULL))
> config->irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_HIGH;
> --
> 1.7.4.1
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
^ permalink raw reply
* Re: e1000e: NIC not working, power management issue?
From: Frederik Himpe @ 2011-09-14 20:31 UTC (permalink / raw)
To: Lucas Nussbaum; +Cc: e1000-devel, netdev, linux-kernel
In-Reply-To: <20110914134042.GA5739@xanadu.blop.info>
[CC'ing e1000e ML and LKML]
On Wed, 2011-09-14 at 15:40 +0200, Lucas Nussbaum wrote:
> Hi,
>
> I get the same symptoms as the ones reported by Frederik Himpe in
> http://www.spinics.net/lists/netdev/msg174336.html
> (Sorry for starting a new thread, I could not find a mbox archive of netdev)
>
> My config:
> 00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03)
> Subsystem: Dell Device 024d
> 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-
> Interrupt: pin A routed to IRQ 22
> Region 0: Memory at f6ae0000 (32-bit, non-prefetchable) [disabled] [size=128K]
> Region 1: Memory at f6adb000 (32-bit, non-prefetchable) [disabled] [size=4K]
> Region 2: I/O ports at efe0 [disabled] [size=32]
> Capabilities: [c8] Power Management version 2
> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
> Status: D3 NoSoftRst- PME-Enable+ DSel=0 DScale=1 PME+
> Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
> Address: 00000000fee0300c Data: 41b9
> Capabilities: [e0] PCI Advanced Features
> AFCap: TP+ FLR+
> AFCtrl: FLR-
> AFStatus: TP-
> Kernel driver in use: e1000e
>
> running Linux 3.1rc4.
>
> Symptoms:
> network doesn't work.
> ifconfig shows the device, but ethtool eth0 says:
> # ethtool eth0
> Settings for eth0:
> Cannot get device settings: No such device
> Cannot get wake-on-lan settings: No such device
> Cannot get message level: No such device
> Cannot get link status: No such device
> No data available
>
> dmesg:
> [ 6260.327320] e1000e: Intel(R) PRO/1000 Network Driver - 1.4.4-k
> [ 6260.327324] e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
> [ 6260.327355] e1000e 0000:00:19.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
> [ 6260.327366] e1000e 0000:00:19.0: setting latency timer to 64
> [ 6260.327490] e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
> [ 6260.517813] e1000e 0000:00:19.0: eth0: (PCI Express:2.5GT/s:Width x1) 00:24:e8:a7:2c:42
> [ 6260.517824] e1000e 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
> [ 6260.518077] e1000e 0000:00:19.0: eth0: MAC: 7, PHY: 8, PBA No: 3002FF-0FF
> [ 6260.518102] e1000e 0000:00:19.0: PME# enabled
> [ 6260.556129] e1000e 0000:00:19.0: BAR 0: set to [mem 0xf6ae0000-0xf6afffff] (PCI address [0xf6ae0000-0xf6afffff])
> [ 6260.556139] e1000e 0000:00:19.0: BAR 1: set to [mem 0xf6adb000-0xf6adbfff] (PCI address [0xf6adb000-0xf6adbfff])
> [ 6260.556147] e1000e 0000:00:19.0: BAR 2: set to [io 0xefe0-0xefff] (PCI address [0xefe0-0xefff])
> [ 6260.556167] e1000e 0000:00:19.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
> [ 6260.556193] e1000e 0000:00:19.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100107)
> [ 6260.556253] e1000e 0000:00:19.0: PME# disabled
> [ 6260.645141] e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
> [ 6260.700393] e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
> [ 6260.702222] ADDRCONF(NETDEV_UP): eth0: link is not ready
> [ 6261.796451] e1000e 0000:00:19.0: PME# enabled
>
> On a friend's laptop (also Dell latitude E4300, running Linux 3.0), things work
> fine. lspci -vvv of the working laptop:
> 00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03)
> Subsystem: Dell Device 024d
> 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
> Interrupt: pin A routed to IRQ 43
> Region 0: Memory at f6ae0000 (32-bit, non-prefetchable) [size=128K]
> Region 1: Memory at f6adb000 (32-bit, non-prefetchable) [size=4K]
> Region 2: I/O ports at efe0 [size=32]
> Capabilities: [c8] 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=1 PME-
> Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Address: 00000000fee0300c Data: 412a
> Capabilities: [e0] PCI Advanced Features
> AFCap: TP+ FLR+
> AFCtrl: FLR-
> AFStatus: TP-
> Kernel driver in use: e1000e
>
> dmesg for the working laptop:
> [ 0.936973] e1000e: Intel(R) PRO/1000 Network Driver - 1.3.10-k2
> [ 0.936975] e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
> [ 0.937013] e1000e 0000:00:19.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
> [ 0.937024] e1000e 0000:00:19.0: setting latency timer to 64
> [ 0.937133] e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
> [ 1.146345] e1000e 0000:00:19.0: eth0: (PCI Express:2.5GT/s:Width x1) 00:21:70:fb:7a:00
> [ 1.146348] e1000e 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
> [ 1.146375] e1000e 0000:00:19.0: eth0: MAC: 7, PHY: 8, PBA No: 3002FF-0FF
> [ 19.568318] e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
> [ 19.624124] e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
>
> The only thing I understand so far is that my NIC seems to be stuck in D3...
>
> Lucas
>
------------------------------------------------------------------------------
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
Learn about the latest advances in developing for the
BlackBerry® mobile platform with sessions, labs & more.
See new tools and technologies. Register for BlackBerry® DevCon today!
http://p.sf.net/sfu/rim-devcon-copy1
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH 2/3] netdev/of/phy: Add MDIO bus multiplexer support.
From: Kumar Gala @ 2011-09-14 20:42 UTC (permalink / raw)
To: David Daney
Cc: linux-mips-6z/3iImG2C8G8FEW9MqTrA, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, ralf-6z/3iImG2C8G8FEW9MqTrA,
David S. Miller
In-Reply-To: <4E6FE5F9.2060604-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
On Sep 13, 2011, at 6:23 PM, David Daney wrote:
> On 09/13/2011 04:07 PM, Kumar Gala wrote:
>>
>>> diff --git a/Documentation/devicetree/bindings/net/mdio-mux.txt b/Documentation/devicetree/bindings/net/mdio-mux.txt
>>> new file mode 100644
>>> index 0000000..a908312
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/net/mdio-mux.txt
>>> @@ -0,0 +1,132 @@
>>> +Common MDIO bus multiplexer/switch properties.
>>> +
>>> +An MDIO bus multiplexer/switch will have several child busses that are
>>> +numbered uniquely in a device dependent manner. The nodes for an MDIO
>>> +bus multiplexer/switch will have one child node for each child bus.
>>> +
>>> +Required properties:
>>> +- parent-bus : phandle to the parent MDIO bus.
>>
>> Should probably be mdio-parent-bus
>
> Why? We know it is MDIO.
>
> Serial bus multiplexing is not a concept limited to MDIO. We would want to use "parent-bus" for some I2C multiplexers as well.
>From many years of dealing with device trees. We typically don't name things overlay generically unless they will be used over and over again as a common idiom (like reg, interrupt, etc.).
We don't really use 'bus' generically today.
>
>>
>>> +
>>> +Optional properties:
>>> +- Other properties specific to the multiplexer/switch hardware.
>>> +
>>> +Required properties for child nodes:
>>> +- #address-cells =<1>;
>>> +- #size-cells =<0>;
>>> +- cell-index : The sub-bus number.
>>
>> What does sub-bus number mean?
>
> There are N child buses (or sub-buses) coming out of the multiplexer. The cell-index is used as a handle or identifier for each of these.
>
> The concrete example in Patch 3/3 is a multiplexer with four child buses. The happen to have cell-indexes of 0, 1, 2 and 3.
>
> In the GPIO case of patch 3/3, these directly correspond the the state of the two GPIO pins controlling the multiplexer. The driver then uses the cell-index property to determine the state of the GPIO to connect any given child.
>
> It is possible that the documentation part of the patch could be made more clear about this.
>
>>
>>> +
>>> +
>>> +Example :
>>
> [...]
>>> +
>>> +int mdio_mux_probe(struct platform_device *pdev,
>>> + int (*switch_fn)(int cur, int desired, void *data),
>>> + void *data)
>>> +{
>>> + struct device_node *parent_bus_node;
>>> + struct device_node *child_bus_node;
>>> + int r, n, ret_val;
>>> + struct mii_bus *parent_bus;
>>> + struct mdio_mux_parent_bus *pb;
>>> + struct mdio_mux_child_bus *cb;
>>> +
>>> + if (!pdev->dev.of_node)
>>> + return -ENODEV;
>>> +
>>> + parent_bus_node = of_parse_phandle(pdev->dev.of_node, "parent-bus", 0);
>>> +
>>> + if (!parent_bus_node)
>>> + return -ENODEV;
>>> +
>>> + parent_bus = of_mdio_find_bus(parent_bus_node);
>>
>>
>> So what happens if the parent bus probe happens after the mux probe?
>>
>
> The whole house of cards collapses.
>
> Grant Likely has a patch to deal with this by retrying the probing, but as far as I know, it has not been merged yet.
- k
^ permalink raw reply
* Re: e1000e: NIC not working, power management issue?
From: John Ronciak @ 2011-09-14 21:14 UTC (permalink / raw)
To: Frederik Himpe; +Cc: e1000-devel, netdev, Lucas Nussbaum, linux-kernel
In-Reply-To: <1316032260.6309.1.camel@defected>
On Wed, Sep 14, 2011 at 1:31 PM, Frederik Himpe <fhimpe@telenet.be> wrote:
>>
>> dmesg:
>> [ 6260.327320] e1000e: Intel(R) PRO/1000 Network Driver - 1.4.4-k
>> [ 6260.327324] e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
>> [ 6260.327355] e1000e 0000:00:19.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
>> [ 6260.327366] e1000e 0000:00:19.0: setting latency timer to 64
>> [ 6260.327490] e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
>> [ 6260.517813] e1000e 0000:00:19.0: eth0: (PCI Express:2.5GT/s:Width x1) 00:24:e8:a7:2c:42
>> [ 6260.517824] e1000e 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
>> [ 6260.518077] e1000e 0000:00:19.0: eth0: MAC: 7, PHY: 8, PBA No: 3002FF-0FF
>> [ 6260.518102] e1000e 0000:00:19.0: PME# enabled
>> [ 6260.556129] e1000e 0000:00:19.0: BAR 0: set to [mem 0xf6ae0000-0xf6afffff] (PCI address [0xf6ae0000-0xf6afffff])
>> [ 6260.556139] e1000e 0000:00:19.0: BAR 1: set to [mem 0xf6adb000-0xf6adbfff] (PCI address [0xf6adb000-0xf6adbfff])
>> [ 6260.556147] e1000e 0000:00:19.0: BAR 2: set to [io 0xefe0-0xefff] (PCI address [0xefe0-0xefff])
>> [ 6260.556167] e1000e 0000:00:19.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
>> [ 6260.556193] e1000e 0000:00:19.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100107)
>> [ 6260.556253] e1000e 0000:00:19.0: PME# disabled
>> [ 6260.645141] e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
>> [ 6260.700393] e1000e 0000:00:19.0: irq 43 for MSI/MSI-X
>> [ 6260.702222] ADDRCONF(NETDEV_UP): eth0: link is not ready
It doesn't have link. Without link nothing can happen on the wire.
What are you expecting to happen here?
Have the device get link first.
--
Cheers,
John
------------------------------------------------------------------------------
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
Learn about the latest advances in developing for the
BlackBerry® mobile platform with sessions, labs & more.
See new tools and technologies. Register for BlackBerry® DevCon today!
http://p.sf.net/sfu/rim-devcon-copy1
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Your Mail Quota Has Exceeded
From: Mail Administrator @ 2011-09-14 19:43 UTC (permalink / raw)
Your Mail Quota Has Exceeded The Set Quota/Limit. You Are Currently
Running On 23GB Due To Hidden Files And Folders On Your Mailbox,
you may not be able to receive or send new mails until you re-validate.
Please Click Any of the Link Below To Validate Your Mailbox And Increase
Your Quota.
http://buzurl.com/bi51
Failure to do so may result cancellation of your web mail account.
Thanks, and sorry for the inconvenience
Mail Administrator
^ permalink raw reply
* Re: r8169 hard-freezes the system on big network loads
From: Michael Brade @ 2011-09-14 21:36 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, nic_swsd, Hayes
In-Reply-To: <20110913081126.GA20022@electric-eye.fr.zoreil.com>
On Tuesday 13 September 2011 10:11:26 you wrote:
> Michael Brade <brade@informatik.uni-muenchen.de> :
> [...]
>
> > Does it have to be 3.1.0-rc3 or is 3.0.1 ok as well ?
> :
> :o(
>
> Almost any release may exhibit the bug. The attached patch (#0003)
> should be a better candidate as an official fix though.
ok, good news: I did not experience any freeze anymore even though I
transfered 60 GB. And I applied both of your patches and
- if (status & RxFOVF) {
- rtl8169_schedule_work(dev, rtl8169_reset_task);
- dev->stats.rx_fifo_errors++;
- }
> > If so, I have another bad news: 3.0.1 still crashes with this patch.
> > It took me a lot longer to crash it but eventually it did happen.
> > Not sure why it took longer, I guess I didn't generate enough throughput.
>
> It sure sucks from a user experience viewpoint but it is not _that_ bad.
I disagree - I actually lose data because I mount my data and backups with
iSCSI and exactly then it crashes.
> Are the symptoms in any way different or do you still notice more-or-less
> periodic link-up messages and no real network traffic ?
dmesg looks like this:
[ 1611.380420] r8169 0000:13:00.0: eth0: link up
[ 1611.995417] r8169 0000:13:00.0: eth0: link up
[ 1612.323050] r8169 0000:13:00.0: eth0: link up
[ 1612.574016] r8169 0000:13:00.0: eth0: link up
[ 1613.450630] r8169 0000:13:00.0: eth0: link up
[ 1613.929383] r8169 0000:13:00.0: eth0: link up
[ 1614.950939] r8169 0000:13:00.0: eth0: link up
[ 1615.699660] r8169 0000:13:00.0: eth0: link up
[ 1616.005507] r8169 0000:13:00.0: eth0: link up
[ 1616.746199] r8169 0000:13:00.0: eth0: link up
[ 1617.879670] r8169 0000:13:00.0: eth0: link up
[ 1618.461433] r8169 0000:13:00.0: eth0: link up
so yes but what do you mean with "no real network traffic"? I still get
100 MB/s.
cheers,
Michael
^ permalink raw reply
* Device tree property names for MDIO bus multiplexer. Was: Re: [PATCH 2/3] netdev/of/phy: Add MDIO bus multiplexer support.
From: David Daney @ 2011-09-14 21:40 UTC (permalink / raw)
To: Kumar Gala, grant.likely, rob.herring
Cc: linux-mips, ralf, devicetree-discuss, linux-kernel, netdev,
David S. Miller
In-Reply-To: <678076BE-4CF8-4AC9-BE9B-9AF1A17B7AF8@kernel.crashing.org>
Well, I would really like to get an official maintainer's take on the
name of the parent MDIO bus property. Prehaps Grant or Rob could opine
on the matter.
Sooner would be better than later as I am about to start shipping boards
with this burnt into the bootloader. If it needs changing, I could do
it in the next couple of days, but after that it escapes into the wild.
Thanks in advance,
David Daney
On 09/14/2011 01:42 PM, Kumar Gala wrote:
>
> On Sep 13, 2011, at 6:23 PM, David Daney wrote:
>
>> On 09/13/2011 04:07 PM, Kumar Gala wrote:
>>>
>>>> diff --git a/Documentation/devicetree/bindings/net/mdio-mux.txt b/Documentation/devicetree/bindings/net/mdio-mux.txt
>>>> new file mode 100644
>>>> index 0000000..a908312
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/net/mdio-mux.txt
>>>> @@ -0,0 +1,132 @@
>>>> +Common MDIO bus multiplexer/switch properties.
>>>> +
>>>> +An MDIO bus multiplexer/switch will have several child busses that are
>>>> +numbered uniquely in a device dependent manner. The nodes for an MDIO
>>>> +bus multiplexer/switch will have one child node for each child bus.
>>>> +
>>>> +Required properties:
>>>> +- parent-bus : phandle to the parent MDIO bus.
>>>
>>> Should probably be mdio-parent-bus
>>
>> Why? We know it is MDIO.
>>
>> Serial bus multiplexing is not a concept limited to MDIO. We would want to use "parent-bus" for some I2C multiplexers as well.
>
>> From many years of dealing with device trees. We typically don't name things overlay generically unless they will be used over and over again as a common idiom (like reg, interrupt, etc.).
>
> We don't really use 'bus' generically today.
>
>>
>>>
>>>> +
>>>> +Optional properties:
>>>> +- Other properties specific to the multiplexer/switch hardware.
>>>> +
>>>> +Required properties for child nodes:
>>>> +- #address-cells =<1>;
>>>> +- #size-cells =<0>;
>>>> +- cell-index : The sub-bus number.
>>>
>>> What does sub-bus number mean?
>>
>> There are N child buses (or sub-buses) coming out of the multiplexer. The cell-index is used as a handle or identifier for each of these.
>>
>> The concrete example in Patch 3/3 is a multiplexer with four child buses. The happen to have cell-indexes of 0, 1, 2 and 3.
>>
>> In the GPIO case of patch 3/3, these directly correspond the the state of the two GPIO pins controlling the multiplexer. The driver then uses the cell-index property to determine the state of the GPIO to connect any given child.
>>
>> It is possible that the documentation part of the patch could be made more clear about this.
>>
>>>
>>>> +
>>>> +
>>>> +Example :
>>>
>> [...]
>>>> +
>>>> +int mdio_mux_probe(struct platform_device *pdev,
>>>> + int (*switch_fn)(int cur, int desired, void *data),
>>>> + void *data)
>>>> +{
>>>> + struct device_node *parent_bus_node;
>>>> + struct device_node *child_bus_node;
>>>> + int r, n, ret_val;
>>>> + struct mii_bus *parent_bus;
>>>> + struct mdio_mux_parent_bus *pb;
>>>> + struct mdio_mux_child_bus *cb;
>>>> +
>>>> + if (!pdev->dev.of_node)
>>>> + return -ENODEV;
>>>> +
>>>> + parent_bus_node = of_parse_phandle(pdev->dev.of_node, "parent-bus", 0);
>>>> +
>>>> + if (!parent_bus_node)
>>>> + return -ENODEV;
>>>> +
>>>> + parent_bus = of_mdio_find_bus(parent_bus_node);
>>>
>>>
>>> So what happens if the parent bus probe happens after the mux probe?
>>>
>>
>> The whole house of cards collapses.
>>
>> Grant Likely has a patch to deal with this by retrying the probing, but as far as I know, it has not been merged yet.
>
> - k--
> 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: r8169 hard-freezes the system on big network loads
From: Francois Romieu @ 2011-09-15 0:03 UTC (permalink / raw)
To: Michael Brade; +Cc: netdev, nic_swsd, Hayes
In-Reply-To: <201109142336.17291.brade@informatik.uni-muenchen.de>
Michael Brade <brade@informatik.uni-muenchen.de> :
[...]
> ok, good news: I did not experience any freeze anymore even though I
> transfered 60 GB. And I applied both of your patches and
>
> - if (status & RxFOVF) {
> - rtl8169_schedule_work(dev, rtl8169_reset_task);
> - dev->stats.rx_fifo_errors++;
> - }
It should not be necessary to remove this part : the status mask is
supposed to take care of it. One of my patches is wrong if this part
needs to go away.
[...]
> > Are the symptoms in any way different or do you still notice more-or-less
> > periodic link-up messages and no real network traffic ?
>
> dmesg looks like this:
>
> [ 1611.380420] r8169 0000:13:00.0: eth0: link up
> [ 1611.995417] r8169 0000:13:00.0: eth0: link up
> [ 1612.323050] r8169 0000:13:00.0: eth0: link up
> [ 1612.574016] r8169 0000:13:00.0: eth0: link up
I will have to figure why there are so much of theses messages.
[...]
> so yes but what do you mean with "no real network traffic"? I still get
> 100 MB/s.
100 MB/s as 100 Mbyte/s on a gigabit link or 100 Mbit/s on a {gigabit / fast}
ethernet link ?
Thanks.
--
Ueimor
^ permalink raw reply
* [PATCH net-next-2.6] e1000: don't enable dma receives until after dma address has been setup
From: Dean Nelson @ 2011-09-15 0:31 UTC (permalink / raw)
To: netdev; +Cc: Michael S. Tsirkin, Andy Gospodarek, Jesse Brandeburg,
Jeff Kirsher
Doing an 'ifconfig ethN down' followed by an 'ifconfig ethN up' on a qemu-kvm
guest system configured with two e1000 NICs can result in an 'unable to handle
kernel paging request at 0000000100000000' or 'bad page map in process ...' or
something similar.
These result from a 4096-byte page being corrupted with the following two-word
pattern (16-bytes) repeated throughout the entire page:
0x0000000000000000
0x0000000100000000
There can be other bits set as well. What is a constant is that the 2nd word
has the 32nd bit set. So one could see:
:
0x0000000000000000
0x0000000100000000
0x0000000000000000
0x0000000172adc067 <<< bad pte
0x800000006ec60067
0x0000000700000040
0x0000000000000000
0x0000000100000000
:
Which came from from a process' page table I dumped out when the marked line
was seen as bad by print_bad_pte().
The repeating pattern represents the e1000's two-word receive descriptor:
struct e1000_rx_desc {
__le64 buffer_addr; /* Address of the descriptor's data buffer */
__le16 length; /* Length of data DMAed into data buffer */
__le16 csum; /* Packet checksum */
u8 status; /* Descriptor status */
u8 errors; /* Descriptor Errors */
__le16 special;
};
And the 32nd bit of the 2nd word maps to the 'u8 status' member, and
corresponds to E1000_RXD_STAT_DD which indicates the descriptor is done.
The corruption appears to result from the following...
. An 'ifconfig ethN down' gets us into e1000_close(), which through a number
of subfunctions results in:
1. E1000_RCTL_EN being cleared in RCTL register. [e1000_down()]
2. dma_free_coherent() being called. [e1000_free_rx_resources()]
. An 'ifconfig ethN up' gets us into e1000_open(), which through a number of
subfunctions results in:
1. dma_alloc_coherent() being called. [e1000_setup_rx_resources()]
2. E1000_RCTL_EN being set in RCTL register. [e1000_setup_rctl()]
3. E1000_RCTL_EN being cleared in RCTL register. [e1000_configure_rx()]
4. RDLEN, RDBAH and RDBAL registers being set to reflect the dma page
allocated in step 1. [e1000_configure_rx()]
5. E1000_RCTL_EN being set in RCTL register. [e1000_configure_rx()]
During the 'ifconfig ethN up' there is a window opened, starting in step 2
where the receives are enabled up until they are disabled in step 3, in which
the address of the receive descriptor dma page known by the NIC is still the
previous one which was freed during the 'ifconfig ethN down'. If this memory
has been reallocated for some other use and the NIC feels so inclined, it will
write to that former dma page with predictably unpleasant results.
I realize that in the guest, we're dealing with an e1000 NIC that is software
emulated by qemu-kvm. The problem doesn't appear to occur on bare-metal. Andy
suspects that this is because in the emulator link-up is essentially instant
and traffic can start flowing immediately. Whereas on bare-metal, link-up
usually seems to take at least a few milliseconds. And this might be enough
to prevent traffic from flowing into the device inside the window where
E1000_RCTL_EN is set.
So perhaps a modification needs to be made to the qemu-kvm e1000 NIC emulator
to delay the link-up. But in defense of the emulator, it seems like a bad idea
to enable dma operations before the address of the memory to be involved has
been made known.
The following patch no longer enables receives in e1000_setup_rctl() but leaves
them however they were. It only enables receives in e1000_configure_rx(), and
only after the dma address has been made known to the hardware.
There are two places where e1000_setup_rctl() gets called. The one in
e1000_configure() is followed immediately by a call to e1000_configure_rx(), so
there's really no change functionally (except for the removal of the problem
window. The other is in __e1000_shutdown() and is not followed by a call to
e1000_configure_rx(), so there is a change functionally. But consider...
. An 'ifconfig ethN down' (just as described above).
. A 'suspend' of the system, which (I'm assuming) will find its way into
e1000_suspend() which calls __e1000_shutdown() resulting in:
1. E1000_RCTL_EN being set in RCTL register. [e1000_setup_rctl()]
And again we've re-opened the problem window for some unknown amount of time.
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: Dean Nelson <dnelson@redhat.com>
---
The patch below is Andy's version of a patch I came up with to address this
problem. I liked his version better. Functionally there was no difference
between the two.
Running my version of the patch, the reproducer (see script below) ran for 5
days without issue before I stopped it. Without the patch, former dma pages
were corrupted in a very short timeframe and fairly frequently (relatively
speaking). Note that I'm also running with a debug patch that after step 5 has
completed (mentioned above under an 'ifconfig ethN up'...), the previous dma
page is scanned to see if it had been 'corrupted'. So I found a higher
percentage of occurrences then one would find if one waits for a kernel BUG.
The reproducer for this problem is:
cat > reproducer.sh <<EOF
#!/bin/bash
typeset -i i=0
echo eth1:down
ifconfig eth1 down
sleep 2
while :; do
i=$i+1
ifconfig eth0 down& ifconfig eth1 up&
echo "$i | eth0:down eth1:up"
wait
sleep 2
ifconfig eth0 up& ifconfig eth1 down&
echo "$i | eth0:up eth1:down"
wait
sleep 2
done
EOF
The e1000e looks to have the same issue. I don't know about igb. But I'm not
aware of either having hardware emulation in qemu-kvm. So unless this issue is
reproducible on bare-metal... it's probably not a big deal for them.
drivers/net/ethernet/intel/e1000/e1000_main.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c
index 4a32c15..cd26a0a 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -1814,8 +1814,8 @@ static void e1000_setup_rctl(struct e1000_adapter *adapter)
rctl &= ~(3 << E1000_RCTL_MO_SHIFT);
- rctl |= E1000_RCTL_EN | E1000_RCTL_BAM |
- E1000_RCTL_LBM_NO | E1000_RCTL_RDMTS_HALF |
+ rctl |= E1000_RCTL_BAM | E1000_RCTL_LBM_NO |
+ E1000_RCTL_RDMTS_HALF |
(hw->mc_filter_type << E1000_RCTL_MO_SHIFT);
if (hw->tbi_compatibility_on == 1)
@@ -1917,7 +1917,7 @@ static void e1000_configure_rx(struct e1000_adapter *adapter)
}
/* Enable Receives */
- ew32(RCTL, rctl);
+ ew32(RCTL, rctl | E1000_RCTL_EN);
}
/**
^ permalink raw reply related
* Re: Device tree property names for MDIO bus multiplexer. Was: Re: [PATCH 2/3] netdev/of/phy: Add MDIO bus multiplexer support.
From: Grant Likely @ 2011-09-15 0:41 UTC (permalink / raw)
To: David Daney
Cc: linux-mips-6z/3iImG2C8G8FEW9MqTrA, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, ralf-6z/3iImG2C8G8FEW9MqTrA,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, David S. Miller
In-Reply-To: <4E711F59.6000801-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 4562 bytes --]
On Sep 14, 2011 3:40 PM, "David Daney" <david.daney-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org> wrote:
>
> Well, I would really like to get an official maintainer's take on the name
of the parent MDIO bus property. Prehaps Grant or Rob could opine on the
matter.
>
> Sooner would be better than later as I am about to start shipping boards
with this burnt into the bootloader. If it needs changing, I could do it in
the next couple of days, but after that it escapes into the wild.
Considering that the parent bus should be either implicit in the node
topology, or if not then part of something like an i2c controlled bus
multiplexer, I don't think this is even remotely a big deal. Each bus
multiplexer will still likely have it's own binding, and therefore her to
make its own decision.
That said, in the interest of commonality, I think mdio-parent-bus would be
just fine. parent-bus is probably too generic.
g.
>
> Thanks in advance,
> David Daney
>
>
> On 09/14/2011 01:42 PM, Kumar Gala wrote:
>>
>>
>> On Sep 13, 2011, at 6:23 PM, David Daney wrote:
>>
>>> On 09/13/2011 04:07 PM, Kumar Gala wrote:
>>>>
>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/net/mdio-mux.txt
b/Documentation/devicetree/bindings/net/mdio-mux.txt
>>>>> new file mode 100644
>>>>> index 0000000..a908312
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/net/mdio-mux.txt
>>>>> @@ -0,0 +1,132 @@
>>>>> +Common MDIO bus multiplexer/switch properties.
>>>>> +
>>>>> +An MDIO bus multiplexer/switch will have several child busses that
are
>>>>> +numbered uniquely in a device dependent manner. The nodes for an
MDIO
>>>>> +bus multiplexer/switch will have one child node for each child bus.
>>>>> +
>>>>> +Required properties:
>>>>> +- parent-bus : phandle to the parent MDIO bus.
>>>>
>>>>
>>>> Should probably be mdio-parent-bus
>>>
>>>
>>> Why? We know it is MDIO.
>>>
>>> Serial bus multiplexing is not a concept limited to MDIO. We would want
to use "parent-bus" for some I2C multiplexers as well.
>>
>>
>>> From many years of dealing with device trees. We typically don't name
things overlay generically unless they will be used over and over again as a
common idiom (like reg, interrupt, etc.).
>>
>>
>> We don't really use 'bus' generically today.
>>
>>>
>>>>
>>>>> +
>>>>> +Optional properties:
>>>>> +- Other properties specific to the multiplexer/switch hardware.
>>>>> +
>>>>> +Required properties for child nodes:
>>>>> +- #address-cells =<1>;
>>>>> +- #size-cells =<0>;
>>>>> +- cell-index : The sub-bus number.
>>>>
>>>>
>>>> What does sub-bus number mean?
>>>
>>>
>>> There are N child buses (or sub-buses) coming out of the multiplexer.
The cell-index is used as a handle or identifier for each of these.
>>>
>>> The concrete example in Patch 3/3 is a multiplexer with four child
buses. The happen to have cell-indexes of 0, 1, 2 and 3.
>>>
>>> In the GPIO case of patch 3/3, these directly correspond the the state
of the two GPIO pins controlling the multiplexer. The driver then uses the
cell-index property to determine the state of the GPIO to connect any given
child.
>>>
>>> It is possible that the documentation part of the patch could be made
more clear about this.
>>>
>>>>
>>>>> +
>>>>> +
>>>>> +Example :
>>>>
>>>>
>>> [...]
>>>>>
>>>>> +
>>>>> +int mdio_mux_probe(struct platform_device *pdev,
>>>>> + int (*switch_fn)(int cur, int desired, void *data),
>>>>> + void *data)
>>>>> +{
>>>>> + struct device_node *parent_bus_node;
>>>>> + struct device_node *child_bus_node;
>>>>> + int r, n, ret_val;
>>>>> + struct mii_bus *parent_bus;
>>>>> + struct mdio_mux_parent_bus *pb;
>>>>> + struct mdio_mux_child_bus *cb;
>>>>> +
>>>>> + if (!pdev->dev.of_node)
>>>>> + return -ENODEV;
>>>>> +
>>>>> + parent_bus_node = of_parse_phandle(pdev->dev.of_node,
"parent-bus", 0);
>>>>> +
>>>>> + if (!parent_bus_node)
>>>>> + return -ENODEV;
>>>>> +
>>>>> + parent_bus = of_mdio_find_bus(parent_bus_node);
>>>>
>>>>
>>>>
>>>> So what happens if the parent bus probe happens after the mux probe?
>>>>
>>>
>>> The whole house of cards collapses.
>>>
>>> Grant Likely has a patch to deal with this by retrying the probing, but
as far as I know, it has not been merged yet.
>>
>>
>> - k--
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
[-- Attachment #1.2: Type: text/html, Size: 6732 bytes --]
[-- Attachment #2: Type: text/plain, Size: 192 bytes --]
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
^ 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