* [PATCH] mac80211: fix mesh forwarding when ratelimited too
From: Milton Miller @ 2010-12-30 8:01 UTC (permalink / raw)
To: John W. Linville, Johannes Berg, Javier Cardona
Cc: David S. Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <201012262159.oBQLxOsw008865@hera.kernel.org>
Commit b51aff057c9d0ef6c529dc25fd9f775faf7b6c63 said:
Under memory pressure, the mac80211 mesh code
may helpfully print a message that it failed
to clone a mesh frame and then will proceed
to crash trying to use it anyway. Fix that.
Avoid the reference whenever the frame copy is unsuccessful
regardless of the debug message being suppressed or printed.
Cc: stable@kernel.org [2.6.27+]
Signed-off-by: Milton Miller <miltonm@bga.com>
---
I chose a seperate if vs nesting the ratelimit check to avoid shifting
the printk further to the right.
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index b01e467..e98668f 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1788,11 +1788,11 @@ ieee80211_rx_h_mesh_fwding(struct ieee80211_rx_data *rx)
fwd_skb = skb_copy(skb, GFP_ATOMIC);
- if (!fwd_skb && net_ratelimit()) {
+ if (!fwd_skb && net_ratelimit())
printk(KERN_DEBUG "%s: failed to clone mesh frame\n",
sdata->name);
+ if (!fwd_skb)
goto out;
- }
fwd_hdr = (struct ieee80211_hdr *) fwd_skb->data;
memcpy(fwd_hdr->addr2, sdata->vif.addr, ETH_ALEN);
^ permalink raw reply related
* Re: Why do programs freeze with big network transfers?
From: Eric Dumazet @ 2010-12-30 7:58 UTC (permalink / raw)
To: Adam Nielsen; +Cc: linux-kernel, netdev
In-Reply-To: <ifhc54$efg$1@dough.gmane.org>
Le jeudi 30 décembre 2010 à 17:25 +1000, Adam Nielsen a écrit :
> Hi all,
>
> I'm a bit stuck on this problem so I hope someone can help. My desktop PC is
> running kernel 2.6.33.1 and when I copy some largish files (2-3GB each) onto
> an NFS share my PC becomes unusable, pretty much locking up for 60 seconds at
> a time.
>
> Everything works fine for a little while once the copy has begun - the files
> are read off the software-RAID-0 disks at about 200MB/sec, then after 10
> seconds or so data starts going across the gigabit network at about 40MB/sec
> (speed limited by the target system which pegs at 100% CPU due to lack of
> jumbo packets.)
>
> After a few seconds of data going over the network, X-Windows freezes. No
> screen updates, the mouse cursor won't move, for all intents and purposes the
> system has frozen solid. I'm playing music with XMMS2 and that keeps going,
> but occasionally even that stops too. After a minute (between 45 and 65
> seconds) everything unfreezes and keeps going as per normal. Less than 10
> seconds later everything freezes again for another minute! This keeps going
> until the file transfer has finished.
>
> When things unfreeze the disk is idle, and within 10 seconds the disk starts
> up again and almost immediately the next minute-long freeze begins. While
> things are frozen the network transfer continues, and bizarrely I can log in
> to the machine over SSH where everything seems normal. 'top' reports most
> processes are idle, and running a command line XMMS2 client happily reports
> that the song I am listening to is stuck at exactly the same point until the
> freeze is over, when the seconds start counting up again.
>
> The reason I am stuck is that nothing is appearing in dmesg, so it appears the
> kernel is unaware of the problem. Has anyone seen anything like this before?
> I'm not sure what to do next.
>
> Disks are connected to an Intel ICH9 SATA controller in AHCI mode, LAN is a
> Realtek 8169, video card is nVidia GeForce 8600. Perhaps some combination of
> this is to blame?
>
> I have tried using cat to read these files into /dev/null and the system will
> happily read the files at full speed without freezing, and I have used ttcp's
> speed test function to send data over the network at full speed, which also
> works without X11 freezing. Doing this at the same time (reading from the
> disk and sending network traffic) also works fine without locking up, so it
> seems the problems only arise when NFS gets involved.
>
> 'mount' reports the options on the NFS share as:
> rw,user=adam,tcp,soft,intr,timeo=20,vers=3,addr=192.168.0.6
>
> Any suggestions about what I can do next?
>
> Many thanks,
> Adam.
CC netdev
This rings a bell here, could you try to apply commit
482964e56e1320cb7952faa1932d8ecf59c4bf75
(net: Fix the condition passed to sk_wait_event())
This commit was included in 2.6.36, so you could also try 2.6.36.2
kernel.
http://git2.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=482964e56e1320cb7952faa1932d8ecf59c4bf75
Thanks
^ permalink raw reply
* Re: [PATCH 03/10] net/fec: add mac field into platform data and consolidate fec_get_mac
From: Shawn Guo @ 2010-12-30 7:20 UTC (permalink / raw)
To: Baruch Siach
Cc: davem, gerg, eric, bryan.wu, r64343, B32542, u.kleine-koenig, lw,
w.sang, s.hauer, linux-arm-kernel, netdev
In-Reply-To: <20101230052925.GA11160@jasper.tkos.co.il>
On Thu, Dec 30, 2010 at 07:29:25AM +0200, Baruch Siach wrote:
> Hi Shawn,
>
> On Thu, Dec 30, 2010 at 12:29:00PM +0800, Shawn Guo wrote:
> > On Wed, Dec 29, 2010 at 06:05:20PM +0800, Shawn Guo wrote:
> > > On Wed, Dec 29, 2010 at 08:53:30AM +0200, Baruch Siach wrote:
> > > > Please add netdev@vger.kernel.org to the Cc of all your fec driver
> > > > patches.
> > > >
> > > > On Tue, Dec 28, 2010 at 10:55:48PM +0800, Shawn Guo wrote:
> > > > > Add mac field into fec_platform_data and consolidate function
> > > > > fec_get_mac to get mac address in following order.
> > > > >
> > > > > 1) kernel command line fec_mac=xx:xx:xx...
> > > >
> > > > In the case of dual MAC that you later add support for, the address which one
> > > > is being set? Is there a way to set both in kernel command line?
> > > >
> > > The fec0 gets fec_mac and fec1 gets fec_mac + 1. The following code
> > > in function fec_get_mac takes care of it.
> > >
> > > /* Adjust MAC if using default MAC address */
> > > if (iap == fec_mac_default)
> > > dev->dev_addr[ETH_ALEN-1] = fec_mac_default[ETH_ALEN-1] + fep->pdev->id;
> > > > Also, instead of inventing another kernel command line parameter, it is
> > > > better IMO to use the module parameters mechanism. The greth NIC driver
> > > > already uses this method for setting MAC address. Look for 'macaddr' in
> > > > drivers/net/greth.c, and the explanation at the beginning of
> > > > Documentation/kernel-parameters.txt.
> > > >
> > > Sounds good. Thanks.
> > >
> > I just thought this over again. Module parameter might not be
> > the best here. fec is usually used to mount nfs during boot,
> > which requires a built-in driver other than module.
>
> See the explanation at the beginning of Documentation/kernel-parameters.txt.
> You can give module parameters at the kernel command line.
>
Ah, my dumb.
Just tested, and it works. Thanks, Baruch.
--
Regards,
Shawn
^ permalink raw reply
* Re: [PATCH 03/10] net/fec: add mac field into platform data and consolidate fec_get_mac
From: Baruch Siach @ 2010-12-30 5:29 UTC (permalink / raw)
To: Shawn Guo
Cc: davem, gerg, eric, bryan.wu, r64343, B32542, u.kleine-koenig, lw,
w.sang, s.hauer, linux-arm-kernel, netdev
In-Reply-To: <20101230042858.GA20651@freescale.com>
Hi Shawn,
On Thu, Dec 30, 2010 at 12:29:00PM +0800, Shawn Guo wrote:
> On Wed, Dec 29, 2010 at 06:05:20PM +0800, Shawn Guo wrote:
> > On Wed, Dec 29, 2010 at 08:53:30AM +0200, Baruch Siach wrote:
> > > Please add netdev@vger.kernel.org to the Cc of all your fec driver
> > > patches.
> > >
> > > On Tue, Dec 28, 2010 at 10:55:48PM +0800, Shawn Guo wrote:
> > > > Add mac field into fec_platform_data and consolidate function
> > > > fec_get_mac to get mac address in following order.
> > > >
> > > > 1) kernel command line fec_mac=xx:xx:xx...
> > >
> > > In the case of dual MAC that you later add support for, the address which one
> > > is being set? Is there a way to set both in kernel command line?
> > >
> > The fec0 gets fec_mac and fec1 gets fec_mac + 1. The following code
> > in function fec_get_mac takes care of it.
> >
> > /* Adjust MAC if using default MAC address */
> > if (iap == fec_mac_default)
> > dev->dev_addr[ETH_ALEN-1] = fec_mac_default[ETH_ALEN-1] + fep->pdev->id;
> > > Also, instead of inventing another kernel command line parameter, it is
> > > better IMO to use the module parameters mechanism. The greth NIC driver
> > > already uses this method for setting MAC address. Look for 'macaddr' in
> > > drivers/net/greth.c, and the explanation at the beginning of
> > > Documentation/kernel-parameters.txt.
> > >
> > Sounds good. Thanks.
> >
> I just thought this over again. Module parameter might not be
> the best here. fec is usually used to mount nfs during boot,
> which requires a built-in driver other than module.
See the explanation at the beginning of Documentation/kernel-parameters.txt.
You can give module parameters at the kernel command line.
baruch
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* Re: [PATCH 03/10] net/fec: add mac field into platform data and consolidate fec_get_mac
From: Shawn Guo @ 2010-12-30 4:29 UTC (permalink / raw)
To: Baruch Siach
Cc: davem, gerg, eric, bryan.wu, r64343, B32542, u.kleine-koenig, lw,
w.sang, s.hauer, linux-arm-kernel, netdev
In-Reply-To: <20101229100520.GB19347@freescale.com>
Hi Baruch,
On Wed, Dec 29, 2010 at 06:05:20PM +0800, Shawn Guo wrote:
> Hi Baruch,
>
> On Wed, Dec 29, 2010 at 08:53:30AM +0200, Baruch Siach wrote:
> > Hi Shawn,
> >
> > Please add netdev@vger.kernel.org to the Cc of all your fec driver patches.
> >
> > On Tue, Dec 28, 2010 at 10:55:48PM +0800, Shawn Guo wrote:
> > > Add mac field into fec_platform_data and consolidate function
> > > fec_get_mac to get mac address in following order.
> > >
> > > 1) kernel command line fec_mac=xx:xx:xx...
> >
> > In the case of dual MAC that you later add support for, the address which one
> > is being set? Is there a way to set both in kernel command line?
> >
> The fec0 gets fec_mac and fec1 gets fec_mac + 1. The following code
> in function fec_get_mac takes care of it.
>
> /* Adjust MAC if using default MAC address */
> if (iap == fec_mac_default)
> dev->dev_addr[ETH_ALEN-1] = fec_mac_default[ETH_ALEN-1] + fep->pdev->id;
>
>
> > Also, instead of inventing another kernel command line parameter, it is better
> > IMO to use the module parameters mechanism. The greth NIC driver already uses
> > this method for setting MAC address. Look for 'macaddr' in
> > drivers/net/greth.c, and the explanation at the beginning of
> > Documentation/kernel-parameters.txt.
> >
> Sounds good. Thanks.
>
I just thought this over again. Module parameter might not be
the best here. fec is usually used to mount nfs during boot,
which requires a built-in driver other than module.
--
Regards,
Shawn
^ permalink raw reply
* Re: linux-next: Tree for December 29 (netfilter build errors)
From: Changli Gao @ 2010-12-30 2:18 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, netfilter-devel, linux-next, LKML, netdev
In-Reply-To: <20101229085300.1ceac200.randy.dunlap@oracle.com>
On Thu, Dec 30, 2010 at 12:53 AM, Randy Dunlap <randy.dunlap@oracle.com> wrote:
> On Wed, 29 Dec 2010 13:07:00 +1100 Stephen Rothwell wrote:
>
>> Hi all,
>>
>> Changes since 20101228:
>
>
> In file included from linux-next-20101229/net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:22:
> linux-next-20101229/include/net/netfilter/nf_conntrack.h:94: error: field 'ct_general' has incomplete type
> linux-next-20101229/include/net/netfilter/nf_conntrack.h: In function 'nf_ct_get':
> linux-next-20101229/include/net/netfilter/nf_conntrack.h:174: error: 'const struct sk_buff' has no member named 'nfct'
> linux-next-20101229/include/net/netfilter/nf_conntrack.h: In function 'nf_ct_put':
> linux-next-20101229/include/net/netfilter/nf_conntrack.h:181: error: implicit declaration of function 'nf_conntrack_put'
> CC net/ipv6/exthdrs_core.o
> In file included from linux-next-20101229/include/net/netfilter/nf_conntrack_core.h:18,
> from linux-next-20101229/net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:26:
> linux-next-20101229/include/net/netfilter/nf_conntrack_ecache.h: In function 'nf_ct_ecache_ext_add':
> linux-next-20101229/include/net/netfilter/nf_conntrack_ecache.h:35: error: 'struct net' has no member named 'ct'
> In file included from linux-next-20101229/net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:26:
> linux-next-20101229/include/net/netfilter/nf_conntrack_core.h: In function 'nf_conntrack_confirm':
> linux-next-20101229/include/net/netfilter/nf_conntrack_core.h:60: error: 'struct sk_buff' has no member named 'nfct'
> linux-next-20101229/net/ipv6/netfilter/nf_defrag_ipv6_hooks.c: In function 'nf_ct6_defrag_user':
> linux-next-20101229/net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:36: error: 'struct sk_buff' has no member named 'nfct'
> linux-next-20101229/net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:37: error: implicit declaration of function 'nf_ct_zone'
> linux-next-20101229/net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:37: error: 'struct sk_buff' has no member named 'nfct'
> linux-next-20101229/net/ipv6/netfilter/nf_defrag_ipv6_hooks.c: In function 'ipv6_defrag':
> linux-next-20101229/net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:60: error: 'struct sk_buff' has no member named 'nfct'
> linux-next-20101229/net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:60: error: 'struct sk_buff' has no member named 'nfct'
> make[4]: *** [net/ipv6/netfilter/nf_defrag_ipv6_hooks.o] Error 1
> make[3]: *** [net/ipv6/netfilter] Error 2
>
>
>
This bug has been already fixed in nf-next-2.6:
http://git.kernel.org/?p=linux/kernel/git/kaber/nf-next-2.6.git;a=commitdiff;h=ae90bdeaeac6b964b7a1e853a90a19f358a9ac20;hp=f1c722295e029eace7960fc687efd5afd67dc555
Thanks.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH v2 00/12] make rpc_pipefs be mountable multiple time
From: Rob Landley @ 2010-12-30 2:13 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Trond Myklebust, J. Bruce Fields, Neil Brown, Pavel Emelyanov,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, David S. Miller,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1293628470-28386-1-git-send-email-kas-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
On Wed, Dec 29, 2010 at 7:14 AM, Kirill A. Shutemov <kas-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org> wrote:
>
> Prepare nfs/sunrpc stack to use multiple instances of rpc_pipefs.
> Only for client for now.
What would a test case for this look like? (Is there some way to tell
an nfs mount to use a specific instance of rpc_pipefs or something?)
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: linux-next: Tree for December 29 (netfilter build errors)
From: Shan Wei @ 2010-12-30 2:10 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, netfilter-devel, linux-next, LKML, netdev
In-Reply-To: <20101229085300.1ceac200.randy.dunlap@oracle.com>
Randy Dunlap wrote, at 12/30/2010 12:53 AM:
> On Wed, 29 Dec 2010 13:07:00 +1100 Stephen Rothwell wrote:
>
>> Hi all,
>>
>> Changes since 20101228:
>
>
> In file included from linux-next-20101229/net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:22:
> linux-next-20101229/include/net/netfilter/nf_conntrack.h:94: error: field 'ct_general' has incomplete type
> linux-next-20101229/include/net/netfilter/nf_conntrack.h: In function 'nf_ct_get':
> linux-next-20101229/include/net/netfilter/nf_conntrack.h:174: error: 'const struct sk_buff' has no member named 'nfct'
> linux-next-20101229/include/net/netfilter/nf_conntrack.h: In function 'nf_ct_put':
> linux-next-20101229/include/net/netfilter/nf_conntrack.h:181: error: implicit declaration of function 'nf_conntrack_put'
> CC net/ipv6/exthdrs_core.o
> In file included from linux-next-20101229/include/net/netfilter/nf_conntrack_core.h:18,
> from linux-next-20101229/net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:26:
> linux-next-20101229/include/net/netfilter/nf_conntrack_ecache.h: In function 'nf_ct_ecache_ext_add':
> linux-next-20101229/include/net/netfilter/nf_conntrack_ecache.h:35: error: 'struct net' has no member named 'ct'
> In file included from linux-next-20101229/net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:26:
> linux-next-20101229/include/net/netfilter/nf_conntrack_core.h: In function 'nf_conntrack_confirm':
> linux-next-20101229/include/net/netfilter/nf_conntrack_core.h:60: error: 'struct sk_buff' has no member named 'nfct'
> linux-next-20101229/net/ipv6/netfilter/nf_defrag_ipv6_hooks.c: In function 'nf_ct6_defrag_user':
> linux-next-20101229/net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:36: error: 'struct sk_buff' has no member named 'nfct'
> linux-next-20101229/net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:37: error: implicit declaration of function 'nf_ct_zone'
> linux-next-20101229/net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:37: error: 'struct sk_buff' has no member named 'nfct'
> linux-next-20101229/net/ipv6/netfilter/nf_defrag_ipv6_hooks.c: In function 'ipv6_defrag':
> linux-next-20101229/net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:60: error: 'struct sk_buff' has no member named 'nfct'
> linux-next-20101229/net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:60: error: 'struct sk_buff' has no member named 'nfct'
> make[4]: *** [net/ipv6/netfilter/nf_defrag_ipv6_hooks.o] Error 1
> make[3]: *** [net/ipv6/netfilter] Error 2
CONFIG_NF_DEFRAG_IPV6 depends on CONFIG_NF_CONNTRACK_IPV6 which depends on CONFIG_NF_CONNTRACK.
In you config file, CONFIG_NF_CONNTRACK_IPV6 and CONFIG_NF_CONNTRACK are not set,
but CONFIG_NF_DEFRAG_IPV6 is set with 'y'. This is same with IPv4.
Selecting CONFIG_NF_CONNTRACK and CONFIG_NF_CONNTRACK_IPV6 may help to you.
--
Best Regards
-----
Shan Wei
^ permalink raw reply
* Re: [PATCH 03/10] net/fec: add mac field into platform data and consolidate fec_get_mac
From: Shawn Guo @ 2010-12-30 2:12 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Baruch Siach, davem, gerg, eric, bryan.wu, r64343, B32542, lw,
w.sang, s.hauer, linux-arm-kernel, netdev
In-Reply-To: <20101229124220.GD14221@pengutronix.de>
Hi Uwe,
On Wed, Dec 29, 2010 at 01:42:21PM +0100, Uwe Kleine-König wrote:
> Hello Shawn,
>
> On Wed, Dec 29, 2010 at 07:58:09PM +0800, Shawn Guo wrote:
> > On Wed, Dec 29, 2010 at 11:31:38AM +0100, Uwe Kleine-König wrote:
> > > On Wed, Dec 29, 2010 at 06:05:21PM +0800, Shawn Guo wrote:
> > > > On Wed, Dec 29, 2010 at 08:53:30AM +0200, Baruch Siach wrote:
> > > > if (iap == fec_mac_default)
> > > > dev->dev_addr[ETH_ALEN-1] = fec_mac_default[ETH_ALEN-1] + fep->pdev->id;
> > > Can this overflow? (I didn't check the code, so my concern might be
> > > completely stupid here.)
> > No. dev->dev_addr points to netdev_hw_addr->addr, which is a 32 bytes array.
> I didn't mean an out-of-bound access, but what is if
> fec_mac_default[ETH_ALEN-1] is 0xff and you add 1? Does that result in
> 0x100 or 0? What if id is <0? For big ids you might even handle a
> carry to indixes <ETH_ALEN-2.
>
First of all, all my patch did is changing fep->index to,
fep->pdev->id, which should not bring any problem you are concerned.
Secondly, I do not understand how the overflow on
fec_mac_default[ETH_ALEN-1] can result in a carry on the next array
element. Here is what I'm seeing with fec_mac=00:04:9f:01:30:ff.
eth0 Link encap:Ethernet HWaddr 00:04:9F:01:30:FF
eth1 Link encap:Ethernet HWaddr 00:04:9F:01:30:00
--
Regards,
Shawn
^ permalink raw reply
* RE: Using ethernet device as efficient small packet generator
From: Loke, Chetan @ 2010-12-30 1:11 UTC (permalink / raw)
To: Jon Zhou, juice, Eric Dumazet, Stephen Hemminger, netdev
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Jon Zhou
> Sent: December 23, 2010 3:58 AM
> To: juice@swagman.org; Eric Dumazet; Stephen Hemminger;
> netdev@vger.kernel.org
> Subject: RE: Using ethernet device as efficient small packet generator
>
>
> At another old kernel(2.6.16) with tg3 and bnx2 1G NIC,XEON E5450, I
> only got 490K pps(it is about 300Mbps,30% GE), I think the reason is
> multiqueue unsupported in this kernel.
>
> I will do a test with 1Gb nic on the new kernel later.
>
I can hit close to 1M pps(first time every time) w/ a 64-byte payload on
my VirtualMachine(running 2.6.33) via vmxnet3 vNIC -
[root@localhost ~]# cat /proc/net/pktgen/eth2
Params: count 0 min_pkt_size: 60 max_pkt_size: 60
frags: 0 delay: 0 clone_skb: 0 ifname: eth2
flows: 0 flowlen: 0
queue_map_min: 0 queue_map_max: 0
dst_min: 192.168.222.2 dst_max:
src_min: src_max:
src_mac: 00:50:56:b1:00:19 dst_mac: 00:50:56:c0:00:3e
udp_src_min: 9 udp_src_max: 9 udp_dst_min: 9 udp_dst_max: 9
src_mac_count: 0 dst_mac_count: 0
Flags:
Current:
pkts-sofar: 59241012 errors: 0
started: 1898437021us stopped: 1957709510us idle: 9168us
seq_num: 59241013 cur_dst_mac_offset: 0 cur_src_mac_offset: 0
cur_saddr: 0x0 cur_daddr: 0x2dea8c0
cur_udp_dst: 9 cur_udp_src: 9
cur_queue_map: 0
flows: 0
Result: OK: 59272488(c59263320+d9168) nsec, 59241012 (60byte,0frags)
999468pps 479Mb/sec (479744640bps) errors: 0
Chetan
^ permalink raw reply
* Re: Re: dm9000 patch
From: Greg Ungerer @ 2010-12-30 0:37 UTC (permalink / raw)
To: uClinux development list
Cc: Baruch Siach, netdev, Angelo Dureghello, linux-m68k, linux-kernel
In-Reply-To: <4D1BA0D0.1060407@gmail.com>
Hi Angelo,
On 30/12/10 06:57, Angelo Dureghello wrote:
> Hi all,
> thanks for the help,
> the kernel is a main line kernel. Then yes, i am still using uclinux
> tree for libc/tools.
How is the DM9000 hardware connected to the 5307?
I am wondering how you connected the interrupt (and to
which interrupt) and the addressing (direct of a chip select)?
(For example NETtel based 5307 platform support of the SMC91x code is
in mainline as arch/m68knommu/platform/5307/nettel.c). Can you show
the code you used to setup your dm9000 hardware?
(Specifically I guess I want to know if you use the "auto-vectored"
interrupt mode?)
Thanks
Greg
> I collected another spinlock recursion with a slightly different call
> stack trace, as always, the spinlock recursion issue happen on a high
> tx/rx traffic of the dm9000e, in this case just asking an index.html
> with some images and texts:
>
> [ 1108.930000] BUG: spinlock recursion on CPU#0, httpd/29
> [ 1108.930000] lock: 00c42c06, .magic: dead4ead, .owner: httpd/29,
> .owner_cpu: 0
> [ 1108.930000] Stack from 00d7a688:
> [ 1108.930000] 00d7a6b4 000ad988 001840ca 00c42c06 dead4ead 00d641d4
> 0000001d 00000000
> [ 1108.930000] 00c42c06 000064f0 00c42800 00d7a6e8 000adb5a 00c42c06
> 00184130 00002704
> [ 1108.930000] 00000000 0000001f 0014d17e 00159912 00c42b60 000064f0
> 00c42800 0002cb16
> [ 1108.930000] 00d7a6f8 0014d24e 00c42c06 00000000 00d7a738 000e485c
> 00c42c06 00000000
> [ 1108.930000] 00000000 0000001f 0014d17e 00159912 0000004a 00cfc600
> 000064f0 00009a74
> [ 1108.930000] 0002cb16 00191204 00d7a760 0002b6f2 00d7a760 0002b514
> 0000001f 00c42800
> [ 1108.930000] Call Trace:
> [ 1108.930000] [000ad988] spin_bug+0x86/0x11a
> [ 1108.930000] [000adb5a] do_raw_spin_lock+0x58/0x120
> [ 1108.930000] [0014d24e] _raw_spin_lock_irqsave+0x28/0x32
> [ 1108.930000] [000e485c] dm9000_interrupt+0x1a/0x2e0
> [ 1108.930000] [0002b514] handle_IRQ_event+0x2a/0xec
> [ 1108.930000] [0002b680] __do_IRQ+0xaa/0x128
> [ 1108.930000] [00000bb6] do_IRQ+0x48/0x62
> [ 1108.930000] [000033c6] inthandler+0x6a/0x74
> [ 1108.930000] [000fb626] dev_hard_start_xmit+0x170/0x4c4
> [ 1108.930000] [0010b80e] sch_direct_xmit+0xc0/0x1bc
> [ 1108.930000] [000fe9de] dev_queue_xmit+0x160/0x3e6
> [ 1108.930000] [001195c4] ip_finish_output+0xec/0x320
> [ 1108.930000] [0011a768] ip_output+0x9e/0xa8
> [ 1108.930000] [00119856] ip_local_out+0x26/0x30
> [ 1108.930000] [0011a56e] ip_build_and_send_pkt+0x16e/0x178
> [ 1108.930000] [0012fc96] tcp_v4_send_synack+0x52/0x90
> [ 1108.930000] [00130f86] tcp_v4_conn_request+0x3fa/0x57c
> [ 1108.930000] [0012a1c6] tcp_rcv_state_process+0x25e/0xa66
> [ 1108.930000] [001309a4] tcp_v4_do_rcv+0x7c/0x1c8
> [ 1108.930000] [00132854] tcp_v4_rcv+0x546/0x6d2
> [ 1108.930000] [001153a8] ip_local_deliver+0x9c/0x1b0
> [ 1108.930000] [001158e8] ip_rcv+0x42c/0x5f0
> [ 1108.930000] [000fa74e] __netif_receive_skb+0x196/0x2ec
> [ 1108.930000] [000fe142] process_backlog+0x72/0x11e
> [ 1108.930000] [000fe290] net_rx_action+0xa2/0x150
> [ 1108.930000] [0000e13c] __do_softirq+0x74/0xe4
> [ 1108.930000] [0000e1e2] do_softirq+0x36/0x40
> [ 1108.930000] [0000e6c6] local_bh_enable+0x7a/0xa4
> [ 1108.930000] [000fe972] dev_queue_xmit+0xf4/0x3e6
> [ 1108.930000] [001195c4] ip_finish_output+0xec/0x320
> [ 1108.930000] [0011a768] ip_output+0x9e/0xa8
> [ 1108.930000] [00119856] ip_local_out+0x26/0x30
> [ 1108.930000] [0011a90a] ip_queue_xmit+0x198/0x426
> [ 1108.930000] [0012bcc8] tcp_transmit_skb+0x3f0/0x76c
> [ 1108.930000] [0012cfda] tcp_write_xmit+0x178/0x868
> [ 1108.930000] [0012d6f8] __tcp_push_pending_frames+0x2e/0x9a
> [ 1108.930000] [001222be] tcp_sendmsg+0x82e/0x98c
> [ 1108.930000] [0013d9c0] inet_sendmsg+0x32/0x54
> [ 1108.930000] [000ec25e] sock_aio_write+0xc8/0x138
> [ 1108.930000] [00043e7e] do_sync_write+0x9e/0xfe
> [ 1108.930000] [00043f56] vfs_write+0x78/0x84
> [ 1108.930000] [0004446c] sys_write+0x40/0x7a
> [ 1108.930000] [00003244] system_call+0x84/0xc2
> [ 1108.930000]
>
> seems like while i transmit a packet, dm9000_interrupt try to acquire
> the spinlock owned from the same task.
>
> Compiling the kernel i am getting:
> CC kernel/irq/handle.o
> kernel/irq/handle.c:432:3: warning: #warning __do_IRQ is deprecated.
> Please convert to proper flow handlers
>
> Could the usage of __do_IRQ super-handler be a cause of the issue ?
>
>
> many thanks,
> angelo
>
> On 29/12/2010 19:45, Geert Uytterhoeven wrote:
>> On Wed, Dec 29, 2010 at 19:06, Baruch Siach<baruch@tkos.co.il> wrote:
>>> Hi Angelo,
>>>
>>> On Wed, Dec 29, 2010 at 02:13:22PM +0100, Angelo Dureghello wrote:
>>>> just FYI, i tested kernel 2.6.36.2, unfortunately the issue is still
>>>> there, below the call stack trace.
>>> Help from the m68k experts seems to be needed. Adding the relevant
>>> list to Cc.
>> This is uClinux? Added Cc...
>>
>>>> [ 4.620000] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
>>>> [ 39.390000] BUG: spinlock recursion on CPU#0, httpd/29
>>>> [ 39.390000] lock: 00189c44, .magic: dead4ead, .owner: httpd/29,
>>>> .owner_cpu: 0
>>>> [ 39.390000] Stack from 00d6a990:
>>>> [ 39.390000] 00d6a9bc 000a9710 0017cac7 00189c44 dead4ead
>>>> 00de48f4 0000001d 00000000
>>>> [ 39.390000] 00189c44 0002a646 00145f70 00d6a9f0 000a98e2
>>>> 00189c44 0017cb2d 00189c44
>>>> [ 39.390000] 00d6aad8 0000001f 00145f5c 001523f6 00189c08
>>>> 0002a646 00145f70 0002bc52
>>>> [ 39.390000] 00d6a9fc 00145f7e 00189c44 00d6aa28 0002a75e
>>>> 00189c44 0000001f 00d6aad8
>>>> [ 39.390000] 0000001f 00145f5c 00189c08 0002a646 00145f70
>>>> 0002bc52 00d6aa3c 00000bb6
>>>> [ 39.390000] 0000001f 00189c44 00cfc780 00d6aa84 0000337a
>>>> 0000001f 00d6aa4c 00000001
>>>> [ 39.390000] Call Trace:
>>>> [ 39.390000] [000a9710] spin_bug+0x86/0x11a
>>>> [ 39.390000] [000a98e2] do_raw_spin_lock+0x58/0x120
>>>> [ 39.390000] [00145f7e] _raw_spin_lock+0xe/0x14
>>>> [ 39.390000] [0002a75e] __do_IRQ+0x2c/0x108
>>>> [ 39.390000] [00000bb6] do_IRQ+0x48/0x62
>>>> [ 39.390000] [0000337a] inthandler+0x6a/0x74
>>>> [ 39.390000] [0002a82e] __do_IRQ+0xfc/0x108
>>>> [ 39.390000] [00000bb6] do_IRQ+0x48/0x62
>>>> [ 39.390000] [0000337a] inthandler+0x6a/0x74
>>>> [ 39.390000] [000ef0ce] skb_release_all+0x10/0x20
>>>> [ 39.390000] [000ee6bc] __kfree_skb+0x10/0x92
>>>> [ 39.390000] [000ee75e] consume_skb+0x20/0x34
>>>> [ 39.390000] [000e004e] dm9000_start_xmit+0xdc/0xec
>>>> [ 39.390000] [000f67a2] dev_hard_start_xmit+0x146/0x472
>>>> [ 39.390000] [00106506] sch_direct_xmit+0xc0/0x1bc
>>>> [ 39.390000] [000f9914] dev_queue_xmit+0x160/0x3e4
>>>> [ 39.390000] [00113b3e] ip_finish_output+0xee/0x318
>>>> [ 39.390000] [001142b4] ip_output+0x7c/0x88
>>>> [ 39.390000] [00113dc6] ip_local_out+0x26/0x30
>>>> [ 39.390000] [00114d9a] ip_queue_xmit+0x152/0x374
>>>> [ 39.390000] [00125c8c] tcp_transmit_skb+0x3f0/0x732
>>>> [ 39.390000] [00126f26] tcp_write_xmit+0x178/0x868
>>>> [ 39.390000] [00127644] __tcp_push_pending_frames+0x2e/0x9a
>>>> [ 39.390000] [0011c3d6] tcp_sendmsg+0x82e/0x98c
>>>> [ 39.390000] [00137544] inet_sendmsg+0x32/0x54
>>>> [ 39.390000] [000e79a6] sock_aio_write+0xc8/0x138
>>>> [ 39.390000] [00042590] do_sync_write+0x9e/0xfe
>>>> [ 39.390000] [00042668] vfs_write+0x78/0x84
>>>> [ 39.390000] [00042a92] sys_write+0x40/0x7a
>>>> [ 39.390000] [00003224] system_call+0x84/0xc2
>>>> [ 39.390000]
>>>>
>>>> dm9000e is as default not visible/selectable in menuconfig for
>>>> Coldfire architectures, so this probably cannot be considered as a
>>>> kernel bug.
>>>>
>>>> I going forward in investigations, every help is appreciated,
>>>>
>>>> regards,
>>>> angelo
>>>>
>>>>
>>>>
>>>> On 29/12/2010 07:06, Baruch Siach wrote:
>>>>> Hi Angelo,
>>>>>
>>>>> On Tue, Dec 28, 2010 at 10:52:42PM +0100, Angelo Dureghello wrote:
>>>>>> sorry to contact you directly but i couldn't get any help from the
>>>>>> kernel.org mailing list, since i am not a developer my mails are
>>>>>> generally skipped.
>>>>> The best way to get the contact info for a piece of kernel code, is
>>>>> using the
>>>>> get_maintainer.pl script. Running 'scripts/get_maintainer.pl -f
>>>>> drivers/net/dm9000.c' gives the following output:
>>>>>
>>>>> netdev@vger.kernel.org
>>>>> linux-kernel@vger.kernel.org
>>>>>
>>>>> I added both to Cc.
>>>>>
>>>>>> I am very near to have a custom board working with MCF5307 cpu and
>>>>>> dm9000.
>>>>>> I am using kernel 2.6.36-rc3 with your last patch about
>>>>>> spinlock-recursion already included.
>>>>> You should try to update to the latest .36 kernel, which is currently
>>>>> 2.6.36.2. The problem that you experience might be unrelated to the
>>>>> dm9000
>>>>> driver (or to networking at all), so it might have been fixed in
>>>>> this version.
>>>>>
>>>>>> I have "ping" and "telnet" to the embedded board fully working.
>>>>>> If i try to get a sample web page with some images from the board
>>>>>> httpd with a browser, in 80% of cases i get a trap/oops:
>>>>> Try to enable KALLSYMS in your kernel .config to make your stack
>>>>> trace more
>>>>> meaningful. This is under 'General setup -> Configure standard
>>>>> kernel features
>>>>> (for small systems) -> Load all symbols for debugging/ksymoops'.
>>>>>
>>>>> I hope this helps.
>>>>>
>>>>> baruch
>>>>>
>>>>>> [ 4.590000] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
>>>>>> [ 67.630000] BUG: spinlock recursion on CPU#0, httpd/29
>>>>>> [ 67.630000] lock: 00c42c06, .magic: dead4ead, .owner: httpd/29,
>>>>>> .owner_cpu: 0
>>>>>> [ 67.630000] Stack from 00d7b914:
>>>>>> [ 67.630000] 00d7b940 000a8cf0 0015f693 00c42c06 dead4ead
>>>>>> 00dec1d4 0000001d 00000000
>>>>>> [ 67.630000] 00c42c06 00006188 00c42800 00d7b974 000a8ec2
>>>>>> 00c42c06 0015f6f9 00002704
>>>>>> [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 00c42b60
>>>>>> 00006188 00c42800 0002b312
>>>>>> [ 67.630000] 00d7b984 0014701e 00c42c06 00000000 00d7b9c4
>>>>>> 000df21c 00c42c06 00000000
>>>>>> [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 000005ea
>>>>>> 00cfc640 00006188 000096e8
>>>>>> [ 67.630000] 0002b312 00146fa4 00c42b60 00002704 00d7b9ec
>>>>>> 00029d3a 0000001f 00c42800
>>>>>> [ 67.630000] Call Trace:
>>>>>> [ 67.630000] [000a8cf0] [000a8ec2] [0014701e] [000df21c] [00029d3a]
>>>>>> [ 67.630000] [00029e84] [00000bb6] [0000336e] [000df162] [000effd6]
>>>>>> [ 67.630000] [00100482] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0]
>>>>>> [ 67.630000] [0010dfb2] [0010ef80] [0011fed6] [00121170] [0012188e]
>>>>>> [ 67.630000] [0011ecc6] [001249fe] [000e4084] [0011621c] [00131a44]
>>>>>> [ 67.630000] [000e11ee] [00041944] [00041a1c] [00041e46] [00003218]
>>>>>> [ 67.630000] BUG: spinlock lockup on CPU#0, httpd/29, 00c42c06
>>>>>> [ 67.630000] Stack from 00d7b934:
>>>>>> [ 67.630000] 00d7b974 000a8f66 0015f703 00000000 00dec1d4
>>>>>> 0000001d 00c42c06 00002704
>>>>>> [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 00c42b60
>>>>>> 00006188 00c42800 0002b312
>>>>>> [ 67.630000] 00d7b984 0014701e 00c42c06 00000000 00d7b9c4
>>>>>> 000df21c 00c42c06 00000000
>>>>>> [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 000005ea
>>>>>> 00cfc640 00006188 000096e8
>>>>>> [ 67.630000] 0002b312 00146fa4 00c42b60 00002704 00d7b9ec
>>>>>> 00029d3a 0000001f 00c42800
>>>>>> [ 67.630000] 0016c1b4 00cfc640 0000001f 0016c178 00029d10
>>>>>> 00146fb8 00d7ba20 00029e84
>>>>>> [ 67.630000] Call Trace:
>>>>>> [ 67.630000] [000a8f66] [0014701e] [000df21c] [00029d3a] [00029e84]
>>>>>> [ 67.630000] [00000bb6] [0000336e] [000df162] [000effd6] [00100482]
>>>>>> [ 67.630000] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0] [0010dfb2]
>>>>>> [ 67.630000] [0010ef80] [0011fed6] [00121170] [0012188e] [0011ecc6]
>>>>>> [ 67.630000] [001249fe] [000e4084] [0011621c] [00131a44] [000e11ee]
>>>>>> [ 67.630000] [00041944] [00041a1c] [00041e46] [00003218]
>>>>>>
>>>>>> As i said, i was hoping in your patch but i sadly discovered it is
>>>>>> already included in this kernel version.
>>>>>> Hope you can give me some help or can forward me to an appropriate
>>>>>> mailing list.
>>> --
>>> ~. .~ Tk Open Systems
>>> =}------------------------------------------------ooO--U--Ooo------------{=
>>>
>>> - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
>>> --
>>> 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/
>>>
>>
>>
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev@uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev@uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
>
--
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
^ permalink raw reply
* 2.6.37-rc8: Reported regressions 2.6.35 -> 2.6.36
From: Rafael J. Wysocki @ 2010-12-29 23:18 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Maciej Rutecki, Florian Mickler, Andrew Morton, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
[NOTE: This most likely is the last summary report of regressions introduced
between 2.6.35 and 2.6.36.]
This message contains a list of some post-2.6.35 regressions introduced before
2.6.36, for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved post-2.6.35 regressions, please let us know
either and we'll add them to the list. Also, please let us know if any
of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2010-12-30 99 22 20
2010-12-19 98 28 23
2010-12-05 95 34 31
2010-11-19 92 38 34
2010-10-17 70 27 27
2010-10-10 56 16 15
2010-10-03 52 16 14
2010-09-26 46 15 13
2010-09-20 38 15 15
2010-09-12 28 14 13
2010-08-30 21 16 15
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24752
Subject : Random crashes easily reproducible with make -j5 - intel i915 - kernel 2.6.36 on intel/nvidia hybrid graphics machine
Submitter : Giacomo <delleceste@gmail.com>
Date : 2010-12-10 8:57 (20 days old)
Message-ID : <AANLkTimkQM94u9iz7FVVjehB0mwDwfkNwKhF2F2tYq-r@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=129197146619176&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24722
Subject : Disconnecting my USB mouse hangs the machine and issues kernel warning
Submitter : Heinz Diehl <htd@fancy-poultry.org>
Date : 2010-12-12 12:42 (18 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24392
Subject : AGP aperture disabled, worked in 2.6.35
Submitter : Stephen Kitt <steve@sk2.org>
Date : 2010-12-06 06:31 (24 days old)
First-Bad-Commit: http://git.kernel.org/linus/http://git.kernel.org/linus/96576a9e1a0cdb8a43d3af5846be0948f52b4460
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24202
Subject : [830] drm:intel_prepare_page_flip, *ERROR* Prepared flip multiple times
Submitter : mkkot <marcin2006@gmail.com>
Date : 2010-12-02 14:10 (28 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=23812
Subject : HAL does not provide battery information on RHEL5 and CentOS-5
Submitter : Dag Wieers <dag@wieers.com>
Date : 2010-11-26 18:08 (34 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22842
Subject : iwl3945 suddenly stops working
Submitter : Felipe Contreras <felipe.contreras@gmail.com>
Date : 2010-11-14 11:14 (46 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22782
Subject : 2.6.36: general protection fault during lockfs lockspace removal
Submitter : nik@linuxbox.cz <nik@linuxbox.cz>
Date : 2010-11-12 12:05 (48 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22172
Subject : alsa-util.c: snd_pcm_avail_delay() returned strange values: delay 0 is less than avail 32
Submitter : Tobias <devnull@plzk.org>
Date : 2010-11-06 09:33 (54 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22092
Subject : Kernel v2.6.36 trouble on USB disconnect
Submitter : Ketil Froyn <ketil@froyn.name>
Date : 2010-10-29 8:05 (62 days old)
Message-ID : <<AANLkTik5qVxkEGVAA1PSOGk2KTW+ekHpSwttsQEWzWj+@mail.gmail.com>>
References : http://marc.info/?l=linux-kernel&m=128833956503607&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=21652
Subject : several problems with intel graphics since 2.6.36
Submitter : Norbert Preining <preining@logic.at>
Date : 2010-10-27 14:32 (64 days old)
Message-ID : <20101027143252.GA8676@gamma.logic.tuwien.ac.at>
References : http://marc.info/?l=linux-kernel&m=128818998630241&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=21402
Subject : [KVM] Noacpi Windows guest can not boot up on 32bit KVM host
Submitter : xudong <xudong.hao@intel.com>
Date : 2010-10-29 03:01 (62 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=20332
Subject : [LogFS] [2.6.36-rc7] Kernel BUG at lib/btree.c:465!
Submitter : Prasad Joshi <prasadjoshi124@gmail.com>
Date : 2010-10-12 18:56 (79 days old)
Message-ID : <AANLkTimAbCZNhLQ5nADUiAC+7JpAeJBEmjFwdxyZ-FxO@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=128690910501830&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=20322
Subject : 2.6.36-rc7: inconsistent lock state: inconsistent {IN-RECLAIM_FS-R} -> {RECLAIM_FS-ON-W} usage.
Submitter : Dave Jones <davej@redhat.com>
Date : 2010-10-11 20:10 (80 days old)
Message-ID : <20101011201007.GA29707@redhat.com>
References : http://marc.info/?l=linux-kernel&m=128682782828453&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=20232
Subject : kworker consumes ~100% CPU on HP Elitebook 8540w running 2.6.36_rc6-git4
Submitter : Ozan Caglayan <ozan@pardus.org.tr>
Date : 2010-10-13 06:13 (78 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19392
Subject : WARNING: at drivers/net/wireless/ath/ath5k/base.c:3475 ath5k_bss_info_changed+0x44/0x168 [ath5k]()
Submitter : Justin Mattock <justinmattock@gmail.com>
Date : 2010-09-28 22:30 (93 days old)
Message-ID : <<AANLkTim5WCGKPvEkOkO_YnMF9pg8mvLfQoFBNUFpfa_k@mail.gmail.com>>
References : http://marc.info/?l=linux-kernel&m=128571307018635&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19372
Subject : 2.6.36-rc6: WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:235 radeon_fence_wait+0x35a/0x3c0
Submitter : Alexey Dobriyan <adobriyan@gmail.com>
Date : 2010-09-29 21:29 (92 days old)
Message-ID : <20100929212923.GA5578@core2.telecom.by>
References : http://marc.info/?l=linux-kernel&m=128579579400315&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19052
Subject : 2.6.36-rc5-git1 -- [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking
Submitter : Miles Lane <miles.lane@gmail.com>
Date : 2010-09-22 23:47 (99 days old)
Message-ID : <AANLkTikWQjUQjFJU9MO1+XbSLAEE-GARz+S+Dz2Fgu4h@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=128519926626322&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17121
Subject : Two blank rectangles more than 10 cm long when booting
Submitter : Eric Valette <eric.valette@free.fr>
Date : 2010-08-26 17:24 (126 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17061
Subject : 2.6.36-rc1 on zaurus: bluetooth regression
Submitter : Pavel Machek <pavel@ucw.cz>
Date : 2010-08-21 15:24 (131 days old)
Message-ID : <20100821152445.GA1536@ucw.cz>
References : http://marc.info/?l=linux-kernel&m=128240433828087&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16951
Subject : hackbench regression with 2.6.36-rc1
Submitter : Zhang, Yanmin <yanmin_zhang@linux.intel.com>
Date : 2010-08-18 6:18 (134 days old)
Message-ID : <1282112318.21202.8.camel@ymzhang.sh.intel.com>
References : http://marc.info/?l=linux-kernel&m=128211235904910&w=2
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=21092
Subject : Kernel 2.6.36 Bug during quotaon on reiserfs
Submitter : <markus.gapp@gmx.net>
Date : 2010-10-24 16:57 (67 days old)
Handled-By : Jan Kara <jack@suse.cz>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=35292
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16971
Subject : qla4xxx compile failure on 32-bit PowerPC: missing readq and writeq
Submitter : Meelis Roos <mroos@linux.ee>
Date : 2010-08-19 21:03 (133 days old)
Message-ID : <<<alpine.SOC.1.00.1008192359310.19654@math.ut.ee>>>
References : http://marc.info/?l=linux-kernel&m=128225184900892&w=2
Patch : http://marc.info/?l=linux-scsi&m=128590267608876&w=2
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.35 and 2.6.36, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=16444
Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
^ permalink raw reply
* 2.6.37-rc8: Reported regressions from 2.6.36
From: Rafael J. Wysocki @ 2010-12-29 22:59 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Maciej Rutecki, Florian Mickler, Andrew Morton, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some regressions from 2.6.36,
for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved regressions from 2.6.36, please let us
know either and we'll add them to the list. Also, please let us know
if any of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply
to this message with CCs to the people involved in reporting and handling
the issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2010-12-30 85 32 26
2010-12-19 73 28 24
2010-12-03 55 25 19
2010-11-19 39 29 25
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25842
Subject : thinkpad T410s intel i915 regression
Submitter : Travis Hume <travis-02nwaM6XSaFQx4ORub6hmQ@public.gmane.org>
Date : 2010-12-29 18:21 (1 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25822
Subject : [BUG] kernel BUG at mm/truncate.c:479! on 2.6.37-rc8
Submitter : Gurudas Pai <gurudas.pai-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Date : 2010-12-29 6:58 (1 days old)
Message-ID : <4D1AD935.1020504-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=129360511222037&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25812
Subject : 2.6.37-rc7: Regression: b43: crashes in hwrng_register()
Submitter : Mario 'BitKoenig' Holbe <Mario.Holbe-hs6bpBdVsEZfm0AUMx9V0g@public.gmane.org>
Date : 2010-12-28 13:32 (2 days old)
Message-ID : <slrnihjpnh.7t4.Mario.Holbe-elxHLJlugahyoG5eyubGJTtNMCm3PftOHZ5vskTnxNA@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=129354319002301&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25602
Subject : [regression] 2.6.37-rc5: scsi_eh_11 CPU loop
Submitter : Martin Steigerwald <Martin-3kZCPVa5dk2azgQtNeiOUg@public.gmane.org>
Date : 2010-12-20 10:05 (10 days old)
Message-ID : <201012201105.08993.Martin-3kZCPVa5dk2azgQtNeiOUg@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=129283954108331&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25432
Subject : Alpha fails to build with gcc 4.4
Submitter : Ben Hutchings <ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>
Date : 2010-12-22 01:55 (8 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25402
Subject : kernel (2.6.37-8-generic_amd64) panic on boot (with message "map_single: bounce buffer is not DMA'ble) - possible regression !!!
Submitter : carlos <carlos.palma-sh/6fXdz2Rs@public.gmane.org>
Date : 2010-12-21 19:58 (9 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25392
Subject : scsi_eh_11 CPU loop
Submitter : Zhang, Yanmin <yanmin_zhang-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Date : 2010-08-18 6:18 (134 days old)
Message-ID : <1282112318.21202.8.camel-sz7BYL/Y5Hu/P+R7jlPCFVaTQe2KTcn/@public.gmane.org>
References : http://marc.info/?t=129283967100004&r=1&w=2
http://lkml.org/lkml/2010/12/20/52
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24882
Subject : PM/Hibernate: Memory corruption patch introduces regression (2.6.36.2)
Submitter : <akwatts-DaQTI0RpDDMAvxtiuMwx3w@public.gmane.org>
Date : 2010-12-14 04:00 (16 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24822
Subject : Embedded DisplayPort is detected wrongly on HP ProBook 5320m
Submitter : Takashi Iwai <tiwai-l3A5Bk7waGM@public.gmane.org>
Date : 2010-12-13 11:09 (17 days old)
Handled-By : Chris Wilson <chris-Y6uKTt2uX1cEflXRtASbqLVCufUGDwFn@public.gmane.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24772
Subject : Crash with btrfs rootfs on dm-crypt [ kernel BUG at fs/btrfs/inode.c:806! ] on linux 2.6.37-rc5
Submitter : Fabio Comolli <fabio.comolli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-12-10 20:30 (20 days old)
Message-ID : <AANLkTi=j9zsaYNcu=NgGV=HfE-3rNHzVswov8VrgwjQp@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=129201308706568&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24762
Subject : BUG at perf_ctx_adjust_freq (kernel/perf_event.c:1582)
Submitter : Chris Wilson <chris-Y6uKTt2uX1cEflXRtASbqLVCufUGDwFn@public.gmane.org>
Date : 2010-12-10 12:00 (20 days old)
Message-ID : <c6d829$pqibha-vB7d4uKqMBxScZeZrdtW41DQ4js95KgL@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=129198247531612&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24592
Subject : 2.6.37-rc5: NULL pointer oops in selinux_socket_unix_stream_connect
Submitter : Jeremy Fitzhardinge <jeremy-TSDbQ3PG+2Y@public.gmane.org>
Date : 2010-12-08 21:09 (22 days old)
Message-ID : <4CFFF3F3.90100-TSDbQ3PG+2Y@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=129184256629712&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24582
Subject : Kernel Oops at tty_buffer_request_room when using pppd program (2.6.37-rc4)
Submitter : baoyb <baoyb-pUFDVul4/eDM1kAEIRd3EQ@public.gmane.org>
Date : 2010-12-08 13:55 (22 days old)
Message-ID : <EF6DDE218DB34702B1FA84D6CD7EA771@baoyb>
References : http://marc.info/?l=linux-kernel&m=129181763525738&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24372
Subject : kdump broken on 2.6.37-rc4
Submitter : Stanislaw Gruszka <sgruszka-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Date : 2010-12-03 11:16 (27 days old)
Message-ID : <20101203111623.GA2741-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=129137502323003&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24362
Subject : perf hw in kexeced kernel broken in tip
Submitter : Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Date : 2010-12-01 8:00 (29 days old)
First-Bad-Commit: http://git.kernel.org/linus/33c6d6a7ad0ffab9b1b15f8e4107a2af072a05a0
Message-ID : <4CF60095.1020900-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=129119055922065&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24272
Subject : iotop reports insane per-process disk read/write statistics
Submitter : Brian Rogers <brian-+B9G8rMUbpQ@public.gmane.org>
Date : 2010-12-03 12:00 (27 days old)
First-Bad-Commit: http://git.kernel.org/linus/85893120699f8bae8caa12a8ee18ab5fceac978e
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=23902
Subject : [BUG] 2.6.37-rc3 massive interactivity regression on ARM
Submitter : Mikael Pettersson <mikpe-1zs4UD6AkMk@public.gmane.org>
Date : 2010-11-27 15:16 (33 days old)
First-Bad-Commit: http://git.kernel.org/linus/305e6835e05513406fa12820e40e4a8ecb63743c
Message-ID : <<19697.8378.717761.236202-tgku4HJDRZih8lFjZTKsyTAV6s6igYVG@public.gmane.org>>
References : http://marc.info/?l=linux-kernel&m=129087098911837&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=23472
Subject : 2.6.37-rc2 vs. 2.6.36 laptop backlight changes?
Submitter : Patrick Schaaf <netdev-g5tzxDtodVw@public.gmane.org>
Date : 2010-11-17 13:41 (43 days old)
Message-ID : <1290001262.5727.2.camel@lat1>
References : http://marc.info/?l=linux-kernel&m=129000127920912&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=23102
Subject : [bisected] i915 regression in post 2.6.36 kernels
Submitter : Johannes Hirte <johannes.hirte-3kN+8DYepx7zMJDuovMtMLNAH6kLmebB@public.gmane.org>
Date : 2010-11-10 7:02 (50 days old)
Message-ID : <201011100802.20332.johannes.hirte-3kN+8DYepx7zMJDuovMtMLNAH6kLmebB@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=128937310017057&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22942
Subject : [2.6.37-rc1, OOM] virtblk: OOM in do_virtblk_request()
Submitter : Dave Chinner <david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org>
Date : 2010-11-05 1:30 (55 days old)
Message-ID : <20101105013003.GE13830@dastard>
References : http://marc.info/?l=linux-kernel&m=128892062917641&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22912
Subject : spi_lm70llp module crash on unload (2.6.37-rc1)
Submitter : Randy Dunlap <randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Date : 2010-11-05 0:16 (55 days old)
Message-ID : <20101104171620.00d8c95d.randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=128891627913647&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22882
Subject : (2.6.37-rc1) amd64-agp module crashed on second load
Submitter : Randy Dunlap <randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Date : 2010-11-05 0:13 (55 days old)
Message-ID : <20101104171333.fea1f498.randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=128891605213447&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22642
Subject : 2.6.37-rc1: Disk takes 10 seconds to resume - MacBook2,1
Submitter : Tobias <devnull-fBT1nhYaLZ4@public.gmane.org>
Date : 2010-11-10 19:33 (50 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22562
Subject : Regression in 2.6.37-rc1 - logs spammed with "unable to enumerate USB port" - bisected to commit 3df7169e
Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Date : 2010-11-02 22:32 (58 days old)
First-Bad-Commit: http://git.kernel.org/linus/3df7169e73fc1d71a39cffeacc969f6840cdf52b
Message-ID : <4CD09166.4060202-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=128873713207906&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22542
Subject : [2.6.37-rc1] drm:i195 errors
Submitter : Paul Rolland <rol-fjEKYshTNZ1eoWH0uzbU5w@public.gmane.org>
Date : 2010-11-02 14:58 (58 days old)
Message-ID : <20101102155813.09cb2c6e-Hu5lHNoInTV+MQpiyFM1nV6hYfS7NtTn@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=128870991628970&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22472
Subject : vga_switcheroo fails to switch from intel to ati
Submitter : Radu Andries <admiral0-BoOA+NLF7L6xbKUeIHjxjQ@public.gmane.org>
Date : 2010-11-08 16:46 (52 days old)
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25442
Subject : ixp4xx defines FREQ macro; conflicts with gspca/ov519 driver
Submitter : Ben Hutchings <ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>
Date : 2010-12-22 02:02 (8 days old)
Handled-By : Ben Hutchings <ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=41252
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25422
Subject : nouveau fails to build on ia64
Submitter : Ben Hutchings <ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>
Date : 2010-12-22 01:49 (8 days old)
Handled-By : Ben Hutchings <ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=41242
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25012
Subject : BUG: i915 causes NULL pointer dereference in 2.6.37-rc5-git4
Submitter : Tõnu Raitviir <jussuf-Y27EyoLml9s@public.gmane.org>
Date : 2010-12-15 12:48 (15 days old)
First-Bad-Commit: http://git.kernel.org/linus/da79de97d254145dcb7c08c978b1093eac15ec9c
Message-ID : <alpine.DEB.2.00.1012151238570.4797-rbynxJDbKr47Jk59zykfHYGUQIXJGoOI@public.gmane.org>
References : http://www.spinics.net/lists/dri-devel/msg06282.html
Handled-By : Chris Wilson <chris-Y6uKTt2uX1cEflXRtASbqLVCufUGDwFn@public.gmane.org>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=41502
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22812
Subject : kernel oops on 2.6.37-rc1
Submitter : Andrew <atswartz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-11-12 16:05 (48 days old)
First-Bad-Commit: http://git.kernel.org/linus/a68c439b1966c91f0ef474e2bf275d6792312726
Patch : https://bugzilla.kernel.org/attachment.cgi?id=41192
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22672
Subject : Regression in 2.6.37-rc1 for Intel 945 Graphics Adapter - bisected to commit e9e331a
Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Date : 2010-11-11 01:56 (49 days old)
References : https://bugs.freedesktop.org/show_bug.cgi?id=31803
http://marc.info/?l=linux-kernel&m=128944001311444&w=2
http://www.mail-archive.com/intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org/msg02235.html
Patch : https://patchwork.kernel.org/patch/359472/
https://patchwork.kernel.org/patch/359502/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22662
Subject : divide error in select_task_rq_fair()
Submitter : Myron Stowe <myron.stowe-VXdhtT5mjnY@public.gmane.org>
Date : 2010-11-10 23:58 (50 days old)
Patch : http://lkml.org/lkml/2010/11/13/176
http://lkml.org/lkml/2010/11/13/181
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions from 2.6.36,
unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=21782
Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
^ permalink raw reply
* Re: [RFC PATCH v2] Gemini: Gigabit ethernet driver
From: Ben Hutchings @ 2010-12-29 21:42 UTC (permalink / raw)
To: Eric Dumazet
Cc: Stephen Hemminger, Hans Ulli Kroll, Stephen Hemminger,
Michał Mirosław, gemini-board-dev, netdev,
Christoph Biedl
In-Reply-To: <1293652346.7150.10.camel@edumazet-laptop>
On Wed, 2010-12-29 at 20:52 +0100, Eric Dumazet wrote:
> Le mercredi 29 décembre 2010 à 11:28 -0800, Stephen Hemminger a écrit :
>
> > It looks like the comment/documentation in netdevice.h is incorrect.
> >
> > * struct net_device_stats* (*ndo_get_stats)(struct net_device *dev);
> > * Called when a user wants to get the network device usage
> > * statistics. Drivers must do one of the following:
> > * 1. Define @ndo_get_stats64 to fill in a zero-initialised
> > * rtnl_link_stats64 structure passed by the caller.
> > * 2. Define @ndo_get_stats to update a net_device_stats structure
> > * (which should normally be dev->stats) and return a pointer to
> > * it. The structure may be changed asynchronously only if each
> > * field is written atomically.
> > * 3. Update dev->stats asynchronously and atomically, and define
> > * neither operation.
> >
>
> You mean we should insert a new line ?
> I believe this documentation is up to date.
[...]
It would also be worth explicitly stating that there is no serialisation
of calls to these operations, so drivers may need to use a spinlock in
their implementation. I wrote this description under the mistaken
belief that there was some serialisation, and point 2 reflects that.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: dm9000 patch
From: Joe Perches @ 2010-12-29 21:16 UTC (permalink / raw)
To: Angelo Dureghello
Cc: Geert Uytterhoeven, Baruch Siach, netdev, linux-kernel,
linux-m68k, uClinux development list
In-Reply-To: <4D1BA0D0.1060407@gmail.com>
On Wed, 2010-12-29 at 21:57 +0100, Angelo Dureghello wrote:
> the kernel is a main line kernel. Then yes, i am still using uclinux
> tree for libc/tools.
Does it still occur if you remove the debug line below?
---
drivers/net/dm9000.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dm9000.c b/drivers/net/dm9000.c
index 2d4c4fc..c774430 100644
--- a/drivers/net/dm9000.c
+++ b/drivers/net/dm9000.c
@@ -1077,8 +1077,6 @@ static irqreturn_t dm9000_interrupt(int irq, void *dev_id)
unsigned long flags;
u8 reg_save;
- dm9000_dbg(db, 3, "entering %s\n", __func__);
-
/* A real interrupt coming */
/* holders of db->lock must always block IRQs */
^ permalink raw reply related
* Re: dm9000 patch
From: Angelo Dureghello @ 2010-12-29 20:57 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Baruch Siach, netdev, linux-kernel, linux-m68k,
uClinux development list
In-Reply-To: <AANLkTim0+GbddLdkPFoggeCKpU7on7mta0V2mZZLgviE@mail.gmail.com>
Hi all,
thanks for the help,
the kernel is a main line kernel. Then yes, i am still using uclinux
tree for libc/tools.
I collected another spinlock recursion with a slightly different call
stack trace, as always, the spinlock recursion issue happen on a high
tx/rx traffic of the dm9000e, in this case just asking an index.html
with some images and texts:
[ 1108.930000] BUG: spinlock recursion on CPU#0, httpd/29
[ 1108.930000] lock: 00c42c06, .magic: dead4ead, .owner: httpd/29,
.owner_cpu: 0
[ 1108.930000] Stack from 00d7a688:
[ 1108.930000] 00d7a6b4 000ad988 001840ca 00c42c06 dead4ead
00d641d4 0000001d 00000000
[ 1108.930000] 00c42c06 000064f0 00c42800 00d7a6e8 000adb5a
00c42c06 00184130 00002704
[ 1108.930000] 00000000 0000001f 0014d17e 00159912 00c42b60
000064f0 00c42800 0002cb16
[ 1108.930000] 00d7a6f8 0014d24e 00c42c06 00000000 00d7a738
000e485c 00c42c06 00000000
[ 1108.930000] 00000000 0000001f 0014d17e 00159912 0000004a
00cfc600 000064f0 00009a74
[ 1108.930000] 0002cb16 00191204 00d7a760 0002b6f2 00d7a760
0002b514 0000001f 00c42800
[ 1108.930000] Call Trace:
[ 1108.930000] [000ad988] spin_bug+0x86/0x11a
[ 1108.930000] [000adb5a] do_raw_spin_lock+0x58/0x120
[ 1108.930000] [0014d24e] _raw_spin_lock_irqsave+0x28/0x32
[ 1108.930000] [000e485c] dm9000_interrupt+0x1a/0x2e0
[ 1108.930000] [0002b514] handle_IRQ_event+0x2a/0xec
[ 1108.930000] [0002b680] __do_IRQ+0xaa/0x128
[ 1108.930000] [00000bb6] do_IRQ+0x48/0x62
[ 1108.930000] [000033c6] inthandler+0x6a/0x74
[ 1108.930000] [000fb626] dev_hard_start_xmit+0x170/0x4c4
[ 1108.930000] [0010b80e] sch_direct_xmit+0xc0/0x1bc
[ 1108.930000] [000fe9de] dev_queue_xmit+0x160/0x3e6
[ 1108.930000] [001195c4] ip_finish_output+0xec/0x320
[ 1108.930000] [0011a768] ip_output+0x9e/0xa8
[ 1108.930000] [00119856] ip_local_out+0x26/0x30
[ 1108.930000] [0011a56e] ip_build_and_send_pkt+0x16e/0x178
[ 1108.930000] [0012fc96] tcp_v4_send_synack+0x52/0x90
[ 1108.930000] [00130f86] tcp_v4_conn_request+0x3fa/0x57c
[ 1108.930000] [0012a1c6] tcp_rcv_state_process+0x25e/0xa66
[ 1108.930000] [001309a4] tcp_v4_do_rcv+0x7c/0x1c8
[ 1108.930000] [00132854] tcp_v4_rcv+0x546/0x6d2
[ 1108.930000] [001153a8] ip_local_deliver+0x9c/0x1b0
[ 1108.930000] [001158e8] ip_rcv+0x42c/0x5f0
[ 1108.930000] [000fa74e] __netif_receive_skb+0x196/0x2ec
[ 1108.930000] [000fe142] process_backlog+0x72/0x11e
[ 1108.930000] [000fe290] net_rx_action+0xa2/0x150
[ 1108.930000] [0000e13c] __do_softirq+0x74/0xe4
[ 1108.930000] [0000e1e2] do_softirq+0x36/0x40
[ 1108.930000] [0000e6c6] local_bh_enable+0x7a/0xa4
[ 1108.930000] [000fe972] dev_queue_xmit+0xf4/0x3e6
[ 1108.930000] [001195c4] ip_finish_output+0xec/0x320
[ 1108.930000] [0011a768] ip_output+0x9e/0xa8
[ 1108.930000] [00119856] ip_local_out+0x26/0x30
[ 1108.930000] [0011a90a] ip_queue_xmit+0x198/0x426
[ 1108.930000] [0012bcc8] tcp_transmit_skb+0x3f0/0x76c
[ 1108.930000] [0012cfda] tcp_write_xmit+0x178/0x868
[ 1108.930000] [0012d6f8] __tcp_push_pending_frames+0x2e/0x9a
[ 1108.930000] [001222be] tcp_sendmsg+0x82e/0x98c
[ 1108.930000] [0013d9c0] inet_sendmsg+0x32/0x54
[ 1108.930000] [000ec25e] sock_aio_write+0xc8/0x138
[ 1108.930000] [00043e7e] do_sync_write+0x9e/0xfe
[ 1108.930000] [00043f56] vfs_write+0x78/0x84
[ 1108.930000] [0004446c] sys_write+0x40/0x7a
[ 1108.930000] [00003244] system_call+0x84/0xc2
[ 1108.930000]
seems like while i transmit a packet, dm9000_interrupt try to acquire
the spinlock owned from the same task.
Compiling the kernel i am getting:
CC kernel/irq/handle.o
kernel/irq/handle.c:432:3: warning: #warning __do_IRQ is deprecated.
Please convert to proper flow handlers
Could the usage of __do_IRQ super-handler be a cause of the issue ?
many thanks,
angelo
On 29/12/2010 19:45, Geert Uytterhoeven wrote:
> On Wed, Dec 29, 2010 at 19:06, Baruch Siach<baruch@tkos.co.il> wrote:
>
>> Hi Angelo,
>>
>> On Wed, Dec 29, 2010 at 02:13:22PM +0100, Angelo Dureghello wrote:
>>
>>> just FYI, i tested kernel 2.6.36.2, unfortunately the issue is still
>>> there, below the call stack trace.
>>>
>> Help from the m68k experts seems to be needed. Adding the relevant list to Cc.
>>
> This is uClinux? Added Cc...
>
>
>>> [ 4.620000] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
>>> [ 39.390000] BUG: spinlock recursion on CPU#0, httpd/29
>>> [ 39.390000] lock: 00189c44, .magic: dead4ead, .owner: httpd/29,
>>> .owner_cpu: 0
>>> [ 39.390000] Stack from 00d6a990:
>>> [ 39.390000] 00d6a9bc 000a9710 0017cac7 00189c44 dead4ead
>>> 00de48f4 0000001d 00000000
>>> [ 39.390000] 00189c44 0002a646 00145f70 00d6a9f0 000a98e2
>>> 00189c44 0017cb2d 00189c44
>>> [ 39.390000] 00d6aad8 0000001f 00145f5c 001523f6 00189c08
>>> 0002a646 00145f70 0002bc52
>>> [ 39.390000] 00d6a9fc 00145f7e 00189c44 00d6aa28 0002a75e
>>> 00189c44 0000001f 00d6aad8
>>> [ 39.390000] 0000001f 00145f5c 00189c08 0002a646 00145f70
>>> 0002bc52 00d6aa3c 00000bb6
>>> [ 39.390000] 0000001f 00189c44 00cfc780 00d6aa84 0000337a
>>> 0000001f 00d6aa4c 00000001
>>> [ 39.390000] Call Trace:
>>> [ 39.390000] [000a9710] spin_bug+0x86/0x11a
>>> [ 39.390000] [000a98e2] do_raw_spin_lock+0x58/0x120
>>> [ 39.390000] [00145f7e] _raw_spin_lock+0xe/0x14
>>> [ 39.390000] [0002a75e] __do_IRQ+0x2c/0x108
>>> [ 39.390000] [00000bb6] do_IRQ+0x48/0x62
>>> [ 39.390000] [0000337a] inthandler+0x6a/0x74
>>> [ 39.390000] [0002a82e] __do_IRQ+0xfc/0x108
>>> [ 39.390000] [00000bb6] do_IRQ+0x48/0x62
>>> [ 39.390000] [0000337a] inthandler+0x6a/0x74
>>> [ 39.390000] [000ef0ce] skb_release_all+0x10/0x20
>>> [ 39.390000] [000ee6bc] __kfree_skb+0x10/0x92
>>> [ 39.390000] [000ee75e] consume_skb+0x20/0x34
>>> [ 39.390000] [000e004e] dm9000_start_xmit+0xdc/0xec
>>> [ 39.390000] [000f67a2] dev_hard_start_xmit+0x146/0x472
>>> [ 39.390000] [00106506] sch_direct_xmit+0xc0/0x1bc
>>> [ 39.390000] [000f9914] dev_queue_xmit+0x160/0x3e4
>>> [ 39.390000] [00113b3e] ip_finish_output+0xee/0x318
>>> [ 39.390000] [001142b4] ip_output+0x7c/0x88
>>> [ 39.390000] [00113dc6] ip_local_out+0x26/0x30
>>> [ 39.390000] [00114d9a] ip_queue_xmit+0x152/0x374
>>> [ 39.390000] [00125c8c] tcp_transmit_skb+0x3f0/0x732
>>> [ 39.390000] [00126f26] tcp_write_xmit+0x178/0x868
>>> [ 39.390000] [00127644] __tcp_push_pending_frames+0x2e/0x9a
>>> [ 39.390000] [0011c3d6] tcp_sendmsg+0x82e/0x98c
>>> [ 39.390000] [00137544] inet_sendmsg+0x32/0x54
>>> [ 39.390000] [000e79a6] sock_aio_write+0xc8/0x138
>>> [ 39.390000] [00042590] do_sync_write+0x9e/0xfe
>>> [ 39.390000] [00042668] vfs_write+0x78/0x84
>>> [ 39.390000] [00042a92] sys_write+0x40/0x7a
>>> [ 39.390000] [00003224] system_call+0x84/0xc2
>>> [ 39.390000]
>>>
>>> dm9000e is as default not visible/selectable in menuconfig for
>>> Coldfire architectures, so this probably cannot be considered as a
>>> kernel bug.
>>>
>>> I going forward in investigations, every help is appreciated,
>>>
>>> regards,
>>> angelo
>>>
>>>
>>>
>>> On 29/12/2010 07:06, Baruch Siach wrote:
>>>
>>>> Hi Angelo,
>>>>
>>>> On Tue, Dec 28, 2010 at 10:52:42PM +0100, Angelo Dureghello wrote:
>>>>
>>>>> sorry to contact you directly but i couldn't get any help from the
>>>>> kernel.org mailing list, since i am not a developer my mails are
>>>>> generally skipped.
>>>>>
>>>> The best way to get the contact info for a piece of kernel code, is using the
>>>> get_maintainer.pl script. Running 'scripts/get_maintainer.pl -f
>>>> drivers/net/dm9000.c' gives the following output:
>>>>
>>>> netdev@vger.kernel.org
>>>> linux-kernel@vger.kernel.org
>>>>
>>>> I added both to Cc.
>>>>
>>>>
>>>>> I am very near to have a custom board working with MCF5307 cpu and dm9000.
>>>>> I am using kernel 2.6.36-rc3 with your last patch about
>>>>> spinlock-recursion already included.
>>>>>
>>>> You should try to update to the latest .36 kernel, which is currently
>>>> 2.6.36.2. The problem that you experience might be unrelated to the dm9000
>>>> driver (or to networking at all), so it might have been fixed in this version.
>>>>
>>>>
>>>>> I have "ping" and "telnet" to the embedded board fully working.
>>>>> If i try to get a sample web page with some images from the board
>>>>> httpd with a browser, in 80% of cases i get a trap/oops:
>>>>>
>>>> Try to enable KALLSYMS in your kernel .config to make your stack trace more
>>>> meaningful. This is under 'General setup -> Configure standard kernel features
>>>> (for small systems) -> Load all symbols for debugging/ksymoops'.
>>>>
>>>> I hope this helps.
>>>>
>>>> baruch
>>>>
>>>>
>>>>> [ 4.590000] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
>>>>> [ 67.630000] BUG: spinlock recursion on CPU#0, httpd/29
>>>>> [ 67.630000] lock: 00c42c06, .magic: dead4ead, .owner: httpd/29,
>>>>> .owner_cpu: 0
>>>>> [ 67.630000] Stack from 00d7b914:
>>>>> [ 67.630000] 00d7b940 000a8cf0 0015f693 00c42c06 dead4ead
>>>>> 00dec1d4 0000001d 00000000
>>>>> [ 67.630000] 00c42c06 00006188 00c42800 00d7b974 000a8ec2
>>>>> 00c42c06 0015f6f9 00002704
>>>>> [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 00c42b60
>>>>> 00006188 00c42800 0002b312
>>>>> [ 67.630000] 00d7b984 0014701e 00c42c06 00000000 00d7b9c4
>>>>> 000df21c 00c42c06 00000000
>>>>> [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 000005ea
>>>>> 00cfc640 00006188 000096e8
>>>>> [ 67.630000] 0002b312 00146fa4 00c42b60 00002704 00d7b9ec
>>>>> 00029d3a 0000001f 00c42800
>>>>> [ 67.630000] Call Trace:
>>>>> [ 67.630000] [000a8cf0] [000a8ec2] [0014701e] [000df21c] [00029d3a]
>>>>> [ 67.630000] [00029e84] [00000bb6] [0000336e] [000df162] [000effd6]
>>>>> [ 67.630000] [00100482] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0]
>>>>> [ 67.630000] [0010dfb2] [0010ef80] [0011fed6] [00121170] [0012188e]
>>>>> [ 67.630000] [0011ecc6] [001249fe] [000e4084] [0011621c] [00131a44]
>>>>> [ 67.630000] [000e11ee] [00041944] [00041a1c] [00041e46] [00003218]
>>>>> [ 67.630000] BUG: spinlock lockup on CPU#0, httpd/29, 00c42c06
>>>>> [ 67.630000] Stack from 00d7b934:
>>>>> [ 67.630000] 00d7b974 000a8f66 0015f703 00000000 00dec1d4
>>>>> 0000001d 00c42c06 00002704
>>>>> [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 00c42b60
>>>>> 00006188 00c42800 0002b312
>>>>> [ 67.630000] 00d7b984 0014701e 00c42c06 00000000 00d7b9c4
>>>>> 000df21c 00c42c06 00000000
>>>>> [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 000005ea
>>>>> 00cfc640 00006188 000096e8
>>>>> [ 67.630000] 0002b312 00146fa4 00c42b60 00002704 00d7b9ec
>>>>> 00029d3a 0000001f 00c42800
>>>>> [ 67.630000] 0016c1b4 00cfc640 0000001f 0016c178 00029d10
>>>>> 00146fb8 00d7ba20 00029e84
>>>>> [ 67.630000] Call Trace:
>>>>> [ 67.630000] [000a8f66] [0014701e] [000df21c] [00029d3a] [00029e84]
>>>>> [ 67.630000] [00000bb6] [0000336e] [000df162] [000effd6] [00100482]
>>>>> [ 67.630000] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0] [0010dfb2]
>>>>> [ 67.630000] [0010ef80] [0011fed6] [00121170] [0012188e] [0011ecc6]
>>>>> [ 67.630000] [001249fe] [000e4084] [0011621c] [00131a44] [000e11ee]
>>>>> [ 67.630000] [00041944] [00041a1c] [00041e46] [00003218]
>>>>>
>>>>> As i said, i was hoping in your patch but i sadly discovered it is
>>>>> already included in this kernel version.
>>>>> Hope you can give me some help or can forward me to an appropriate
>>>>> mailing list.
>>>>>
>>>
>> --
>> ~. .~ Tk Open Systems
>> =}------------------------------------------------ooO--U--Ooo------------{=
>> - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
>> --
>> 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
* Re: [RFC PATCH v2] Gemini: Gigabit ethernet driver
From: Stephen Hemminger @ 2010-12-29 19:57 UTC (permalink / raw)
To: Eric Dumazet
Cc: Hans Ulli Kroll, Stephen Hemminger, Ben Hutchings,
Michał Mirosław, gemini-board-dev, netdev,
Christoph Biedl
In-Reply-To: <1293652346.7150.10.camel@edumazet-laptop>
On Wed, 29 Dec 2010 20:52:26 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mercredi 29 décembre 2010 à 11:28 -0800, Stephen Hemminger a écrit :
>
> > It looks like the comment/documentation in netdevice.h is incorrect.
> >
> > * struct net_device_stats* (*ndo_get_stats)(struct net_device *dev);
> > * Called when a user wants to get the network device usage
> > * statistics. Drivers must do one of the following:
> > * 1. Define @ndo_get_stats64 to fill in a zero-initialised
> > * rtnl_link_stats64 structure passed by the caller.
> > * 2. Define @ndo_get_stats to update a net_device_stats structure
> > * (which should normally be dev->stats) and return a pointer to
> > * it. The structure may be changed asynchronously only if each
> > * field is written atomically.
> > * 3. Update dev->stats asynchronously and atomically, and define
> > * neither operation.
> >
>
> You mean we should insert a new line ?
> I believe this documentation is up to date.
>
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index cc916c5..3add243 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -721,7 +721,9 @@ struct xps_dev_maps {
> * struct rtnl_link_stats64 *storage);
> * struct net_device_stats* (*ndo_get_stats)(struct net_device *dev);
> * Called when a user wants to get the network device usage
> - * statistics. Drivers must do one of the following:
> + * statistics.
> + *
> + * Drivers must do one of the following:
^
only
Need to make it clear that get_stats is not needed if get_stats64 is defined.
--
^ permalink raw reply
* Re: [RFC PATCH v2] Gemini: Gigabit ethernet driver
From: Eric Dumazet @ 2010-12-29 19:52 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Hans Ulli Kroll, Stephen Hemminger, Ben Hutchings,
Michał Mirosław, gemini-board-dev, netdev,
Christoph Biedl
In-Reply-To: <20101229112827.203469c2@nehalam>
Le mercredi 29 décembre 2010 à 11:28 -0800, Stephen Hemminger a écrit :
> It looks like the comment/documentation in netdevice.h is incorrect.
>
> * struct net_device_stats* (*ndo_get_stats)(struct net_device *dev);
> * Called when a user wants to get the network device usage
> * statistics. Drivers must do one of the following:
> * 1. Define @ndo_get_stats64 to fill in a zero-initialised
> * rtnl_link_stats64 structure passed by the caller.
> * 2. Define @ndo_get_stats to update a net_device_stats structure
> * (which should normally be dev->stats) and return a pointer to
> * it. The structure may be changed asynchronously only if each
> * field is written atomically.
> * 3. Update dev->stats asynchronously and atomically, and define
> * neither operation.
>
You mean we should insert a new line ?
I believe this documentation is up to date.
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index cc916c5..3add243 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -721,7 +721,9 @@ struct xps_dev_maps {
* struct rtnl_link_stats64 *storage);
* struct net_device_stats* (*ndo_get_stats)(struct net_device *dev);
* Called when a user wants to get the network device usage
- * statistics. Drivers must do one of the following:
+ * statistics.
+ *
+ * Drivers must do one of the following:
* 1. Define @ndo_get_stats64 to fill in a zero-initialised
* rtnl_link_stats64 structure passed by the caller.
* 2. Define @ndo_get_stats to update a net_device_stats structure
^ permalink raw reply related
* Re: [RFC PATCH v2] Gemini: Gigabit ethernet driver
From: Stephen Hemminger @ 2010-12-29 19:28 UTC (permalink / raw)
To: Eric Dumazet
Cc: Hans Ulli Kroll, Stephen Hemminger, Ben Hutchings,
Michał Mirosław, gemini-board-dev, netdev,
Christoph Biedl
In-Reply-To: <1293647441.2413.2.camel@edumazet-laptop>
On Wed, 29 Dec 2010 19:30:41 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mercredi 29 décembre 2010 à 17:56 +0100, Hans Ulli Kroll a écrit :
> >
> > On Mon, 27 Dec 2010, Stephen Hemminger wrote:
> >
> > >
> > >
> > > ----- Original Message -----
> > > > On Mon, 2010-12-27 at 20:21 +0100, Hans Ulli Kroll wrote:
> > > > [...]
> > > > > BTW:
> > > > >
> > > > > Why u64_stats ?
> > > > > I see only a few driver are using u64_stats.
> > > > > vlan, br_device and some intel driver
> > > > > no gigabit driver for marvell devices uses u64_stats
> > > >
> > > > All new net drivers should implement 64-bit stats. net_device_stats is
> > > > kept for backward compatibility because we couldn't change all the
> > > > existing drivers at once (it's not a simple change for all of them).
> > > >
> > > > Ben.
> > >
> > > BS. drivers with old stats are fine. 64 bit only really matters
> > > at higher speed. Anyway, it is the kind of thing that can easily
> > > be fixed later after driver is merged.
> > >
> > >
> >
> > I've readed the Intel driver.
> >
> > So we must also implement to old net_stats interface, for backward
> > compatibility ?
>
> If you implement new (64bit) stats, old one is not used at all.
>
> Check net/core/dev.c : dev_get_stats()
>
> If ndo_get_stats64() method is implemented, its called, and legacy
> interfaces are ignored.
It looks like the comment/documentation in netdevice.h is incorrect.
* struct net_device_stats* (*ndo_get_stats)(struct net_device *dev);
* Called when a user wants to get the network device usage
* statistics. Drivers must do one of the following:
* 1. Define @ndo_get_stats64 to fill in a zero-initialised
* rtnl_link_stats64 structure passed by the caller.
* 2. Define @ndo_get_stats to update a net_device_stats structure
* (which should normally be dev->stats) and return a pointer to
* it. The structure may be changed asynchronously only if each
* field is written atomically.
* 3. Update dev->stats asynchronously and atomically, and define
* neither operation.
--
^ permalink raw reply
* Re: dm9000 patch
From: Geert Uytterhoeven @ 2010-12-29 18:45 UTC (permalink / raw)
To: Baruch Siach
Cc: Angelo Dureghello, netdev, linux-kernel, linux-m68k,
uClinux development list
In-Reply-To: <20101229180650.GE6067@tarshish>
On Wed, Dec 29, 2010 at 19:06, Baruch Siach <baruch@tkos.co.il> wrote:
> Hi Angelo,
>
> On Wed, Dec 29, 2010 at 02:13:22PM +0100, Angelo Dureghello wrote:
>> just FYI, i tested kernel 2.6.36.2, unfortunately the issue is still
>> there, below the call stack trace.
>
> Help from the m68k experts seems to be needed. Adding the relevant list to Cc.
This is uClinux? Added Cc...
>> [ 4.620000] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
>> [ 39.390000] BUG: spinlock recursion on CPU#0, httpd/29
>> [ 39.390000] lock: 00189c44, .magic: dead4ead, .owner: httpd/29,
>> .owner_cpu: 0
>> [ 39.390000] Stack from 00d6a990:
>> [ 39.390000] 00d6a9bc 000a9710 0017cac7 00189c44 dead4ead
>> 00de48f4 0000001d 00000000
>> [ 39.390000] 00189c44 0002a646 00145f70 00d6a9f0 000a98e2
>> 00189c44 0017cb2d 00189c44
>> [ 39.390000] 00d6aad8 0000001f 00145f5c 001523f6 00189c08
>> 0002a646 00145f70 0002bc52
>> [ 39.390000] 00d6a9fc 00145f7e 00189c44 00d6aa28 0002a75e
>> 00189c44 0000001f 00d6aad8
>> [ 39.390000] 0000001f 00145f5c 00189c08 0002a646 00145f70
>> 0002bc52 00d6aa3c 00000bb6
>> [ 39.390000] 0000001f 00189c44 00cfc780 00d6aa84 0000337a
>> 0000001f 00d6aa4c 00000001
>> [ 39.390000] Call Trace:
>> [ 39.390000] [000a9710] spin_bug+0x86/0x11a
>> [ 39.390000] [000a98e2] do_raw_spin_lock+0x58/0x120
>> [ 39.390000] [00145f7e] _raw_spin_lock+0xe/0x14
>> [ 39.390000] [0002a75e] __do_IRQ+0x2c/0x108
>> [ 39.390000] [00000bb6] do_IRQ+0x48/0x62
>> [ 39.390000] [0000337a] inthandler+0x6a/0x74
>> [ 39.390000] [0002a82e] __do_IRQ+0xfc/0x108
>> [ 39.390000] [00000bb6] do_IRQ+0x48/0x62
>> [ 39.390000] [0000337a] inthandler+0x6a/0x74
>> [ 39.390000] [000ef0ce] skb_release_all+0x10/0x20
>> [ 39.390000] [000ee6bc] __kfree_skb+0x10/0x92
>> [ 39.390000] [000ee75e] consume_skb+0x20/0x34
>> [ 39.390000] [000e004e] dm9000_start_xmit+0xdc/0xec
>> [ 39.390000] [000f67a2] dev_hard_start_xmit+0x146/0x472
>> [ 39.390000] [00106506] sch_direct_xmit+0xc0/0x1bc
>> [ 39.390000] [000f9914] dev_queue_xmit+0x160/0x3e4
>> [ 39.390000] [00113b3e] ip_finish_output+0xee/0x318
>> [ 39.390000] [001142b4] ip_output+0x7c/0x88
>> [ 39.390000] [00113dc6] ip_local_out+0x26/0x30
>> [ 39.390000] [00114d9a] ip_queue_xmit+0x152/0x374
>> [ 39.390000] [00125c8c] tcp_transmit_skb+0x3f0/0x732
>> [ 39.390000] [00126f26] tcp_write_xmit+0x178/0x868
>> [ 39.390000] [00127644] __tcp_push_pending_frames+0x2e/0x9a
>> [ 39.390000] [0011c3d6] tcp_sendmsg+0x82e/0x98c
>> [ 39.390000] [00137544] inet_sendmsg+0x32/0x54
>> [ 39.390000] [000e79a6] sock_aio_write+0xc8/0x138
>> [ 39.390000] [00042590] do_sync_write+0x9e/0xfe
>> [ 39.390000] [00042668] vfs_write+0x78/0x84
>> [ 39.390000] [00042a92] sys_write+0x40/0x7a
>> [ 39.390000] [00003224] system_call+0x84/0xc2
>> [ 39.390000]
>>
>> dm9000e is as default not visible/selectable in menuconfig for
>> Coldfire architectures, so this probably cannot be considered as a
>> kernel bug.
>>
>> I going forward in investigations, every help is appreciated,
>>
>> regards,
>> angelo
>>
>>
>>
>> On 29/12/2010 07:06, Baruch Siach wrote:
>> >Hi Angelo,
>> >
>> >On Tue, Dec 28, 2010 at 10:52:42PM +0100, Angelo Dureghello wrote:
>> >>sorry to contact you directly but i couldn't get any help from the
>> >>kernel.org mailing list, since i am not a developer my mails are
>> >>generally skipped.
>> >The best way to get the contact info for a piece of kernel code, is using the
>> >get_maintainer.pl script. Running 'scripts/get_maintainer.pl -f
>> >drivers/net/dm9000.c' gives the following output:
>> >
>> >netdev@vger.kernel.org
>> >linux-kernel@vger.kernel.org
>> >
>> >I added both to Cc.
>> >
>> >>I am very near to have a custom board working with MCF5307 cpu and dm9000.
>> >>I am using kernel 2.6.36-rc3 with your last patch about
>> >>spinlock-recursion already included.
>> >You should try to update to the latest .36 kernel, which is currently
>> >2.6.36.2. The problem that you experience might be unrelated to the dm9000
>> >driver (or to networking at all), so it might have been fixed in this version.
>> >
>> >>I have "ping" and "telnet" to the embedded board fully working.
>> >>If i try to get a sample web page with some images from the board
>> >>httpd with a browser, in 80% of cases i get a trap/oops:
>> >Try to enable KALLSYMS in your kernel .config to make your stack trace more
>> >meaningful. This is under 'General setup -> Configure standard kernel features
>> >(for small systems) -> Load all symbols for debugging/ksymoops'.
>> >
>> >I hope this helps.
>> >
>> >baruch
>> >
>> >>[ 4.590000] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
>> >>[ 67.630000] BUG: spinlock recursion on CPU#0, httpd/29
>> >>[ 67.630000] lock: 00c42c06, .magic: dead4ead, .owner: httpd/29,
>> >>.owner_cpu: 0
>> >>[ 67.630000] Stack from 00d7b914:
>> >>[ 67.630000] 00d7b940 000a8cf0 0015f693 00c42c06 dead4ead
>> >>00dec1d4 0000001d 00000000
>> >>[ 67.630000] 00c42c06 00006188 00c42800 00d7b974 000a8ec2
>> >>00c42c06 0015f6f9 00002704
>> >>[ 67.630000] 00000000 0000001f 00146fa4 00152f0c 00c42b60
>> >>00006188 00c42800 0002b312
>> >>[ 67.630000] 00d7b984 0014701e 00c42c06 00000000 00d7b9c4
>> >>000df21c 00c42c06 00000000
>> >>[ 67.630000] 00000000 0000001f 00146fa4 00152f0c 000005ea
>> >>00cfc640 00006188 000096e8
>> >>[ 67.630000] 0002b312 00146fa4 00c42b60 00002704 00d7b9ec
>> >>00029d3a 0000001f 00c42800
>> >>[ 67.630000] Call Trace:
>> >>[ 67.630000] [000a8cf0] [000a8ec2] [0014701e] [000df21c] [00029d3a]
>> >>[ 67.630000] [00029e84] [00000bb6] [0000336e] [000df162] [000effd6]
>> >>[ 67.630000] [00100482] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0]
>> >>[ 67.630000] [0010dfb2] [0010ef80] [0011fed6] [00121170] [0012188e]
>> >>[ 67.630000] [0011ecc6] [001249fe] [000e4084] [0011621c] [00131a44]
>> >>[ 67.630000] [000e11ee] [00041944] [00041a1c] [00041e46] [00003218]
>> >>[ 67.630000] BUG: spinlock lockup on CPU#0, httpd/29, 00c42c06
>> >>[ 67.630000] Stack from 00d7b934:
>> >>[ 67.630000] 00d7b974 000a8f66 0015f703 00000000 00dec1d4
>> >>0000001d 00c42c06 00002704
>> >>[ 67.630000] 00000000 0000001f 00146fa4 00152f0c 00c42b60
>> >>00006188 00c42800 0002b312
>> >>[ 67.630000] 00d7b984 0014701e 00c42c06 00000000 00d7b9c4
>> >>000df21c 00c42c06 00000000
>> >>[ 67.630000] 00000000 0000001f 00146fa4 00152f0c 000005ea
>> >>00cfc640 00006188 000096e8
>> >>[ 67.630000] 0002b312 00146fa4 00c42b60 00002704 00d7b9ec
>> >>00029d3a 0000001f 00c42800
>> >>[ 67.630000] 0016c1b4 00cfc640 0000001f 0016c178 00029d10
>> >>00146fb8 00d7ba20 00029e84
>> >>[ 67.630000] Call Trace:
>> >>[ 67.630000] [000a8f66] [0014701e] [000df21c] [00029d3a] [00029e84]
>> >>[ 67.630000] [00000bb6] [0000336e] [000df162] [000effd6] [00100482]
>> >>[ 67.630000] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0] [0010dfb2]
>> >>[ 67.630000] [0010ef80] [0011fed6] [00121170] [0012188e] [0011ecc6]
>> >>[ 67.630000] [001249fe] [000e4084] [0011621c] [00131a44] [000e11ee]
>> >>[ 67.630000] [00041944] [00041a1c] [00041e46] [00003218]
>> >>
>> >>As i said, i was hoping in your patch but i sadly discovered it is
>> >>already included in this kernel version.
>> >>Hope you can give me some help or can forward me to an appropriate
>> >>mailing list.
>>
>
> --
> ~. .~ Tk Open Systems
> =}------------------------------------------------ooO--U--Ooo------------{=
> - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
> --
> 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/
>
--
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [RFC PATCH v2] Gemini: Gigabit ethernet driver
From: Eric Dumazet @ 2010-12-29 18:30 UTC (permalink / raw)
To: Hans Ulli Kroll
Cc: Stephen Hemminger, Ben Hutchings, Michał Mirosław,
gemini-board-dev, netdev, Christoph Biedl
In-Reply-To: <alpine.LNX.2.00.1012291750060.9177@localhost>
Le mercredi 29 décembre 2010 à 17:56 +0100, Hans Ulli Kroll a écrit :
>
> On Mon, 27 Dec 2010, Stephen Hemminger wrote:
>
> >
> >
> > ----- Original Message -----
> > > On Mon, 2010-12-27 at 20:21 +0100, Hans Ulli Kroll wrote:
> > > [...]
> > > > BTW:
> > > >
> > > > Why u64_stats ?
> > > > I see only a few driver are using u64_stats.
> > > > vlan, br_device and some intel driver
> > > > no gigabit driver for marvell devices uses u64_stats
> > >
> > > All new net drivers should implement 64-bit stats. net_device_stats is
> > > kept for backward compatibility because we couldn't change all the
> > > existing drivers at once (it's not a simple change for all of them).
> > >
> > > Ben.
> >
> > BS. drivers with old stats are fine. 64 bit only really matters
> > at higher speed. Anyway, it is the kind of thing that can easily
> > be fixed later after driver is merged.
> >
> >
>
> I've readed the Intel driver.
>
> So we must also implement to old net_stats interface, for backward
> compatibility ?
If you implement new (64bit) stats, old one is not used at all.
Check net/core/dev.c : dev_get_stats()
If ndo_get_stats64() method is implemented, its called, and legacy
interfaces are ignored.
^ permalink raw reply
* Re: dm9000 patch
From: Baruch Siach @ 2010-12-29 18:06 UTC (permalink / raw)
To: Angelo Dureghello; +Cc: netdev, linux-kernel, linux-m68k
In-Reply-To: <4D1B33F2.5060600@gmail.com>
Hi Angelo,
On Wed, Dec 29, 2010 at 02:13:22PM +0100, Angelo Dureghello wrote:
> just FYI, i tested kernel 2.6.36.2, unfortunately the issue is still
> there, below the call stack trace.
Help from the m68k experts seems to be needed. Adding the relevant list to Cc.
baruch
> [ 4.620000] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
> [ 39.390000] BUG: spinlock recursion on CPU#0, httpd/29
> [ 39.390000] lock: 00189c44, .magic: dead4ead, .owner: httpd/29,
> .owner_cpu: 0
> [ 39.390000] Stack from 00d6a990:
> [ 39.390000] 00d6a9bc 000a9710 0017cac7 00189c44 dead4ead
> 00de48f4 0000001d 00000000
> [ 39.390000] 00189c44 0002a646 00145f70 00d6a9f0 000a98e2
> 00189c44 0017cb2d 00189c44
> [ 39.390000] 00d6aad8 0000001f 00145f5c 001523f6 00189c08
> 0002a646 00145f70 0002bc52
> [ 39.390000] 00d6a9fc 00145f7e 00189c44 00d6aa28 0002a75e
> 00189c44 0000001f 00d6aad8
> [ 39.390000] 0000001f 00145f5c 00189c08 0002a646 00145f70
> 0002bc52 00d6aa3c 00000bb6
> [ 39.390000] 0000001f 00189c44 00cfc780 00d6aa84 0000337a
> 0000001f 00d6aa4c 00000001
> [ 39.390000] Call Trace:
> [ 39.390000] [000a9710] spin_bug+0x86/0x11a
> [ 39.390000] [000a98e2] do_raw_spin_lock+0x58/0x120
> [ 39.390000] [00145f7e] _raw_spin_lock+0xe/0x14
> [ 39.390000] [0002a75e] __do_IRQ+0x2c/0x108
> [ 39.390000] [00000bb6] do_IRQ+0x48/0x62
> [ 39.390000] [0000337a] inthandler+0x6a/0x74
> [ 39.390000] [0002a82e] __do_IRQ+0xfc/0x108
> [ 39.390000] [00000bb6] do_IRQ+0x48/0x62
> [ 39.390000] [0000337a] inthandler+0x6a/0x74
> [ 39.390000] [000ef0ce] skb_release_all+0x10/0x20
> [ 39.390000] [000ee6bc] __kfree_skb+0x10/0x92
> [ 39.390000] [000ee75e] consume_skb+0x20/0x34
> [ 39.390000] [000e004e] dm9000_start_xmit+0xdc/0xec
> [ 39.390000] [000f67a2] dev_hard_start_xmit+0x146/0x472
> [ 39.390000] [00106506] sch_direct_xmit+0xc0/0x1bc
> [ 39.390000] [000f9914] dev_queue_xmit+0x160/0x3e4
> [ 39.390000] [00113b3e] ip_finish_output+0xee/0x318
> [ 39.390000] [001142b4] ip_output+0x7c/0x88
> [ 39.390000] [00113dc6] ip_local_out+0x26/0x30
> [ 39.390000] [00114d9a] ip_queue_xmit+0x152/0x374
> [ 39.390000] [00125c8c] tcp_transmit_skb+0x3f0/0x732
> [ 39.390000] [00126f26] tcp_write_xmit+0x178/0x868
> [ 39.390000] [00127644] __tcp_push_pending_frames+0x2e/0x9a
> [ 39.390000] [0011c3d6] tcp_sendmsg+0x82e/0x98c
> [ 39.390000] [00137544] inet_sendmsg+0x32/0x54
> [ 39.390000] [000e79a6] sock_aio_write+0xc8/0x138
> [ 39.390000] [00042590] do_sync_write+0x9e/0xfe
> [ 39.390000] [00042668] vfs_write+0x78/0x84
> [ 39.390000] [00042a92] sys_write+0x40/0x7a
> [ 39.390000] [00003224] system_call+0x84/0xc2
> [ 39.390000]
>
> dm9000e is as default not visible/selectable in menuconfig for
> Coldfire architectures, so this probably cannot be considered as a
> kernel bug.
>
> I going forward in investigations, every help is appreciated,
>
> regards,
> angelo
>
>
>
> On 29/12/2010 07:06, Baruch Siach wrote:
> >Hi Angelo,
> >
> >On Tue, Dec 28, 2010 at 10:52:42PM +0100, Angelo Dureghello wrote:
> >>sorry to contact you directly but i couldn't get any help from the
> >>kernel.org mailing list, since i am not a developer my mails are
> >>generally skipped.
> >The best way to get the contact info for a piece of kernel code, is using the
> >get_maintainer.pl script. Running 'scripts/get_maintainer.pl -f
> >drivers/net/dm9000.c' gives the following output:
> >
> >netdev@vger.kernel.org
> >linux-kernel@vger.kernel.org
> >
> >I added both to Cc.
> >
> >>I am very near to have a custom board working with MCF5307 cpu and dm9000.
> >>I am using kernel 2.6.36-rc3 with your last patch about
> >>spinlock-recursion already included.
> >You should try to update to the latest .36 kernel, which is currently
> >2.6.36.2. The problem that you experience might be unrelated to the dm9000
> >driver (or to networking at all), so it might have been fixed in this version.
> >
> >>I have "ping" and "telnet" to the embedded board fully working.
> >>If i try to get a sample web page with some images from the board
> >>httpd with a browser, in 80% of cases i get a trap/oops:
> >Try to enable KALLSYMS in your kernel .config to make your stack trace more
> >meaningful. This is under 'General setup -> Configure standard kernel features
> >(for small systems) -> Load all symbols for debugging/ksymoops'.
> >
> >I hope this helps.
> >
> >baruch
> >
> >>[ 4.590000] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
> >>[ 67.630000] BUG: spinlock recursion on CPU#0, httpd/29
> >>[ 67.630000] lock: 00c42c06, .magic: dead4ead, .owner: httpd/29,
> >>.owner_cpu: 0
> >>[ 67.630000] Stack from 00d7b914:
> >>[ 67.630000] 00d7b940 000a8cf0 0015f693 00c42c06 dead4ead
> >>00dec1d4 0000001d 00000000
> >>[ 67.630000] 00c42c06 00006188 00c42800 00d7b974 000a8ec2
> >>00c42c06 0015f6f9 00002704
> >>[ 67.630000] 00000000 0000001f 00146fa4 00152f0c 00c42b60
> >>00006188 00c42800 0002b312
> >>[ 67.630000] 00d7b984 0014701e 00c42c06 00000000 00d7b9c4
> >>000df21c 00c42c06 00000000
> >>[ 67.630000] 00000000 0000001f 00146fa4 00152f0c 000005ea
> >>00cfc640 00006188 000096e8
> >>[ 67.630000] 0002b312 00146fa4 00c42b60 00002704 00d7b9ec
> >>00029d3a 0000001f 00c42800
> >>[ 67.630000] Call Trace:
> >>[ 67.630000] [000a8cf0] [000a8ec2] [0014701e] [000df21c] [00029d3a]
> >>[ 67.630000] [00029e84] [00000bb6] [0000336e] [000df162] [000effd6]
> >>[ 67.630000] [00100482] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0]
> >>[ 67.630000] [0010dfb2] [0010ef80] [0011fed6] [00121170] [0012188e]
> >>[ 67.630000] [0011ecc6] [001249fe] [000e4084] [0011621c] [00131a44]
> >>[ 67.630000] [000e11ee] [00041944] [00041a1c] [00041e46] [00003218]
> >>[ 67.630000] BUG: spinlock lockup on CPU#0, httpd/29, 00c42c06
> >>[ 67.630000] Stack from 00d7b934:
> >>[ 67.630000] 00d7b974 000a8f66 0015f703 00000000 00dec1d4
> >>0000001d 00c42c06 00002704
> >>[ 67.630000] 00000000 0000001f 00146fa4 00152f0c 00c42b60
> >>00006188 00c42800 0002b312
> >>[ 67.630000] 00d7b984 0014701e 00c42c06 00000000 00d7b9c4
> >>000df21c 00c42c06 00000000
> >>[ 67.630000] 00000000 0000001f 00146fa4 00152f0c 000005ea
> >>00cfc640 00006188 000096e8
> >>[ 67.630000] 0002b312 00146fa4 00c42b60 00002704 00d7b9ec
> >>00029d3a 0000001f 00c42800
> >>[ 67.630000] 0016c1b4 00cfc640 0000001f 0016c178 00029d10
> >>00146fb8 00d7ba20 00029e84
> >>[ 67.630000] Call Trace:
> >>[ 67.630000] [000a8f66] [0014701e] [000df21c] [00029d3a] [00029e84]
> >>[ 67.630000] [00000bb6] [0000336e] [000df162] [000effd6] [00100482]
> >>[ 67.630000] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0] [0010dfb2]
> >>[ 67.630000] [0010ef80] [0011fed6] [00121170] [0012188e] [0011ecc6]
> >>[ 67.630000] [001249fe] [000e4084] [0011621c] [00131a44] [000e11ee]
> >>[ 67.630000] [00041944] [00041a1c] [00041e46] [00003218]
> >>
> >>As i said, i was hoping in your patch but i sadly discovered it is
> >>already included in this kernel version.
> >>Hope you can give me some help or can forward me to an appropriate
> >>mailing list.
>
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* Re: [PATCH net-next 2/3] dcbnl: adding DCBX feature flags get-set
From: John Fastabend @ 2010-12-29 17:21 UTC (permalink / raw)
To: Shmulik Ravid
Cc: davem@davemloft.net, Eilon Greenstein, Liu, Lucy,
netdev@vger.kernel.org
In-Reply-To: <1293631553.29378.30.camel@lb-tlvb-shmulik.il.broadcom.com>
On 12/29/2010 6:05 AM, Shmulik Ravid wrote:
>
> On Tue, 2010-12-28 at 16:15 -0800, John Fastabend wrote:
>> On 12/21/2010 11:32 AM, Shmulik Ravid wrote:
>>> Adding a pair of set-get functions to dcbnl for setting the negotiation
>>> flags of the various DCB features. The user sets these flags (enable,
>>> advertise, willing) for each feature to be used by the device DCBX
>>> engine. The 'get' routine returns which of the features is enabled
>>> after the negotiation.
>>>
>>> Signed-off-by: Shmulik Ravid <shmulikr@broadcom.com>
>>
>> Acked-by: John Fastabend <john.r.fastabend@intel.com>
>>
>> Dave, these are going to conflict with my patches
>>
>> [net-next-2.6,1/3] dcbnl: add support for ieee8021Qaz attributes
>> [net-next-2.6,2/3] dcbnl: add appliction tlv handlers
>>
>> If needed either Shmulik or myself can work out the conflicts if you want a single series that applies cleanly.
>>
>> Thanks,
>> John.
>
> John,
>
> Since I need to modify my patches I can resubmit them on top of your
> patches above so that they would need to be applied after yours are. Is
> this a good way to resolve the conflicts ?
>
> Thanks,
> Shmulik
>
>
Great this would be helpful. Just be sure to note the dependency when you submit the patches. Thanks a lot!
^ permalink raw reply
* Re: [PATCH net-next 1/3] dcbnl: adding DCBX engine capability
From: John Fastabend @ 2010-12-29 17:19 UTC (permalink / raw)
To: Shmulik Ravid
Cc: davem@davemloft.net, Eilon Greenstein, Liu, Lucy,
netdev@vger.kernel.org
In-Reply-To: <1293631142.29378.22.camel@lb-tlvb-shmulik.il.broadcom.com>
On 12/29/2010 5:59 AM, Shmulik Ravid wrote:
>
> On Tue, 2010-12-28 at 16:05 -0800, John Fastabend wrote:
>
>> I would like to use these bits for guests using a VF as well. The
>> problem is multiple lldp agents advertising dcbx tlvs on the same link
>> is not spec compliant. In the VF case there may or may not be a
>> hardware lldp engine all the VF driver (ie ixgbevf) should need to
>> know is that some other entity is managing the DCB attributes.
>>
>> To reflect this I would propose changing DCB_CAP_DCBX_HW and the comments by removing "HW". The two ideas I had were DCB_CAP_DCBX_READONLY or DCB_CAP_DCBX_LLD_MANAGED. Admittedly a bit of a nitpick but its a bit confusing to set the DCBX_HW bit when there really is no HW engine in the 82599 adapter case.
>>
>> Otherwise this all looks good to me. I was hoping someone would get around to this. Thanks a lot!
>>
>> -- John.
>>
>
> I see your point, I like DCB_CAP_DCBX_LLD_MANAGED better. I will change
> it an resubmit the patches. DCB_CAP_DCBX_HW implies 3 things:
> 1. DCBX negotiation is managed by some other entity.
> 2. The user can use the 'get' routines to get the negotiation results.
> 3. The user can use the 'set' routines to set the initial configuration
> for the negotiation.
> I think No 3. is irrelevant to VFs, that is you don't want multiple VF
> drivers trying to change the initial configuration settings. I can think
> of 2 ways to make this distinction, the first is for the VF driver not
> to support the 'set' routines (or always return an error value). The
> second is to add another attribute flag: DCB_CAP_DCBX_LLD_CFG which will
> indicate exactly No 3. while DCB_CAP_DCBX_LLD_MANAGED will indicate No
> 1. and 2. The VF driver will declare DCB_CAP_DCBX_LLD_MANAGED only and a
> driver for an embedded DCBX engine will declare both flags. What do you
> think?
>
> Thanks
> Shmulik.
>
>
>
>
I think having the VF driver not support the 'set' routines is good enough. This is inline with how we handle other operations not supported by the lower layer device. Adding another bit would work as well but it seems simpler to only add flags that are needed.
Then dcbnl should return EOPNOTSUPP for this case.
-- John
^ permalink raw reply
* Re: [RFC PATCH v2] Gemini: Gigabit ethernet driver
From: Hans Ulli Kroll @ 2010-12-29 16:56 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Ben Hutchings, Michał Mirosław, gemini-board-dev,
netdev, Christoph Biedl, Hans Ulli Kroll
In-Reply-To: <1202721929.17594.1293513142947.JavaMail.root@tahiti.vyatta.com>
On Mon, 27 Dec 2010, Stephen Hemminger wrote:
>
>
> ----- Original Message -----
> > On Mon, 2010-12-27 at 20:21 +0100, Hans Ulli Kroll wrote:
> > [...]
> > > BTW:
> > >
> > > Why u64_stats ?
> > > I see only a few driver are using u64_stats.
> > > vlan, br_device and some intel driver
> > > no gigabit driver for marvell devices uses u64_stats
> >
> > All new net drivers should implement 64-bit stats. net_device_stats is
> > kept for backward compatibility because we couldn't change all the
> > existing drivers at once (it's not a simple change for all of them).
> >
> > Ben.
>
> BS. drivers with old stats are fine. 64 bit only really matters
> at higher speed. Anyway, it is the kind of thing that can easily
> be fixed later after driver is merged.
>
>
I've readed the Intel driver.
So we must also implement to old net_stats interface, for backward
compatibility ?
Ulli
^ 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