* Re: assert_cfg80211_lock warning with Linux v3.5-8833-g2d53492
From: Arend van Spriel @ 2012-08-01 15:38 UTC (permalink / raw)
To: John W. Linville
Cc: Josh Boyer, Johannes Berg, Brett Rudley, Roland Vossen,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Seth Forshee
In-Reply-To: <20120801141810.GB27433-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
On 08/01/2012 04:18 PM, John W. Linville wrote:
> On Wed, Aug 01, 2012 at 09:12:33AM -0400, Josh Boyer wrote:
>
>> > [ 26.573028] ------------[ cut here ]------------
>> > [ 26.573042] WARNING: at net/wireless/core.h:125 assert_cfg80211_lock.part.8+0x15/0x17 [cfg80211]()
>> > [ 26.573045] Hardware name: XPS 8300
>> > [ 26.573046] Modules linked in: xt_CHECKSUM iptable_mangle bridge stp llc ip6t_REJECT nf_conntrack_ipv4 nf_conntrack_ipv6 nf_defrag_ipv6 nf_defrag_ipv4 xt_state nf_conntrack ib_iser rdma_cm ib_addr ip6table_filter tpm_bios ip6_tables iw_cm ib_cm ib_sa ib_mad ib_core iscsi_tcp snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel arc4 brcmsmac snd_hda_codec cordic brcmutil snd_hwdep mac80211 snd_pcm snd_page_alloc snd_timer cfg80211 snd coretemp rfkill serio_raw i2c_i801 soundcore lpc_ich bcma dcdbas microcode mfd_core mei vhost_net tun macvtap macvlan kvm_intel nfsd kvm auth_rpcgss nfs_acl lockd uinput crc32c_intel ghash_clmulni_intel broadcom tg3 usb_storage uas radeon i2c_algo_bit drm_kms_helper ttm drm i2c_core sunrpc be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i cxgb3 mdio libcxg
bi libiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi
>> > [ 26.573143] Pid: 757, comm: NetworkManager Not tainted 3.6.0-0.rc0.git8.1.fc18.x86_64 #1
>> > [ 26.573145] Call Trace:
>> > [ 26.573153] [<ffffffff8106782f>] warn_slowpath_common+0x7f/0xc0
>> > [ 26.573159] [<ffffffff8106788a>] warn_slowpath_null+0x1a/0x20
>> > [ 26.573170] [<ffffffffa04c730d>] assert_cfg80211_lock.part.8+0x15/0x17 [cfg80211]
>> > [ 26.573181] [<ffffffffa04a8dcb>] freq_reg_info+0x6b/0x80 [cfg80211]
> brcmsmac needs to hold cfg80211_mutex before calling freq_reg_info...
>
> It looks like those calls were added in mid-June.
>
I think mid-june sounds about right. We never observed the warning when
changes to use regulatory infrastructure were tested/reviewed. Should
this precondition be mentioned in cfg80211.h?
Gr. AvS
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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: iputils git tree
From: Mike Frysinger @ 2012-08-01 15:21 UTC (permalink / raw)
To: YOSHIFUJI Hideaki; +Cc: Noah Meyerhans, netdev
In-Reply-To: <5018B587.4030705@linux-ipv6.org>
[-- Attachment #1: Type: Text/Plain, Size: 561 bytes --]
On Wednesday 01 August 2012 00:50:15 YOSHIFUJI Hideaki wrote:
> (2012年08月01日 13:16), Mike Frysinger wrote:ll
> > i can clone git://git.linux-ipv6.org/gitroot/iputils.git now, but it
> > seems to be pointing at a different clone than is viewable from gitweb.
> > it's stuck at:
> >
> > commit 2384927c0ac1bb3ad21966350644d08faadb7a76
> > Author: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
> > Date: Wed Oct 6 20:59:20 2010 +0900
> >
> > iputils-s20101006
>
> Sorry, files were out of sync. Updated.
thanks, it works now
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: iputils git tree
From: Mike Frysinger @ 2012-08-01 15:21 UTC (permalink / raw)
To: YOSHIFUJI Hideaki; +Cc: Noah Meyerhans, David Miller, netdev
In-Reply-To: <5018AE19.7050002@linux-ipv6.org>
[-- Attachment #1: Type: Text/Plain, Size: 443 bytes --]
On Wednesday 01 August 2012 00:18:33 YOSHIFUJI Hideaki wrote:
> In fact my first motivation was to integrate Debian, Fedora and
> other distro updates in to single source. I sometimes look
> into their sources and integrate some of their changes.
i think we should get bugging the maintainers to push to you rather than
forcing you to go out and locate patches. especially when the patches are
often times underdocumented.
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* RE: [PATCH net-next] igb: add delay to allow igb loopback test to succeed on 8086:10c9
From: Wyborny, Carolyn @ 2012-08-01 14:56 UTC (permalink / raw)
To: Stefan Assmann, netdev@vger.kernel.org; +Cc: e1000-devel@lists.sourceforge.net
In-Reply-To: <1343821463-18052-1-git-send-email-sassmann@kpanic.de>
-----Original Message-----
From: Stefan Assmann [mailto:sassmann@kpanic.de]
Sent: Wednesday, August 01, 2012 4:44 AM
To: netdev@vger.kernel.org
Cc: e1000-devel@lists.sourceforge.net; Wyborny, Carolyn; sassmann@kpanic.de
Subject: [PATCH net-next] igb: add delay to allow igb loopback test to succeed on 8086:10c9
Some 8086:10c9 NICs have a problem completing the ethtool loopback test.
The result looks like this:
ethtool -t eth1
The test result is FAIL
The test extra info:
Register test (offline) 0
Eeprom test (offline) 0
Interrupt test (offline) 0
Loopback test (offline) 13
Link test (on/offline) 0
A bisect clearly points to commit a95a07445ee97a2fef65befafbadcc30ca1bd145.
However that seems to only trigger the bug. While adding some printk the problem disappeared, so this might be a timing issue. After some trial and error I discovered that adding a small delay just before igb_write_phy_reg() in igb_integrated_phy_loopback() allows the loopback test to succeed.
I was unable to figure out the root cause so far but I expect it to be somewhere in the following executing path igb_integrated_phy_loopback
->igb_write_phy_reg_igp
->igb_write_phy_reg_mdic
->igb_acquire_phy_82575
->igb_acquire_swfw_sync_82575
As this workaround only introduces a minor delay, which is not in the hot path I hope this is acceptable. The problem could only be oberved on
8086:10c9 NICs so far and not all of them show the behaviour. I did not restrict the workaround to this type of NIC as it should do no harm to other igb NICs.
With the patch below the loopback test succeeded 500 times in a row using a NIC that would otherwise fail.
Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
---
drivers/net/ethernet/intel/igb/igb_ethtool.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c b/drivers/net/ethernet/intel/igb/igb_ethtool.c
index a19c84c..f62fa25 100644
--- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
+++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
@@ -1497,6 +1497,9 @@ static int igb_integrated_phy_loopback(struct igb_adapter *adapter)
break;
}
+ /* add small delay to avoid loopback test failure */
+ msleep(50);
+
/* force 1000, set loopback */
igb_write_phy_reg(hw, PHY_CONTROL, 0x4140);
--
1.7.4.4
ACK. Jeff will be pulling this into his tree.
Thanks,
Carolyn
Carolyn Wyborny
Linux Development
LAN Access Division
Intel Corporation
^ permalink raw reply related
* Re: TCP stalls with 802.3ad + bridge + kvm guest
From: Peter Samuelson @ 2012-08-01 14:41 UTC (permalink / raw)
To: Jay Vosburgh, netdev; +Cc: jgoerzen
In-Reply-To: <26496.1343419205@death.nxdomain>
[Peter Samuelson]
> > ixgbe [10 Gbit port] -- bonding [802.3ad] -- bridge -- KVM guest
> >
> >It all works, except that with some flows in the KVM guest - I
> >can reproduce using smbclient - transfers keep stalling, such that I'm
> >averaging well under 1 MB/s. Should be more like 100 MB/s.
> >
> >Oddly, this only occurs when both the 802.3ad and KVM are used:
> >
> > Server Agg Client TCP stalls
> > --------------------------------------------------
> > external none KVM guest no
> > external 802.3ad KVM host no
> > KVM host 802.3ad KVM guest no
> > external 802.3ad KVM guest yes
[Jay Vosburgh]
> Does the problem happen if the bond is a different mode
> (balance-xor, for example)?
No, the balance-xor mode seems to work normally. I am testing it with
only a single slave interface, same way I'm testing LACP mode.
> Do the various stats on the host and guest show any drops?
> E.g., from "netstat -i" and "tc -s qdisc"
I am not sure what to make of 'netstat -i'. Some test boots, I get
26000 or so RX packets dropped on bond0 and eth2 (the slave interface),
but not during the actual file transfer tests. The current test boot,
with LACP enabled, 'netstat -i' shows only 19 dropped RX packets from
bond0 (compared to 740k total RX packets), after several test runs.
Thanks,
Peter
^ permalink raw reply
* Re: assert_cfg80211_lock warning with Linux v3.5-8833-g2d53492
From: John W. Linville @ 2012-08-01 14:18 UTC (permalink / raw)
To: Josh Boyer
Cc: Johannes Berg, Brett Rudley, Roland Vossen,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Seth Forshee
In-Reply-To: <20120801131232.GA1785-8k7Gwy46GHkf7BdofF/totBPR1lH4CV8@public.gmane.org>
On Wed, Aug 01, 2012 at 09:12:33AM -0400, Josh Boyer wrote:
> <snip a bunch of ALSA/input stuff>
>
> [ 21.762086] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
> [ 25.698788] Bridge firewalling registered
> [ 25.746690] device virbr0-nic entered promiscuous mode
> [ 26.573028] ------------[ cut here ]------------
> [ 26.573042] WARNING: at net/wireless/core.h:125 assert_cfg80211_lock.part.8+0x15/0x17 [cfg80211]()
> [ 26.573045] Hardware name: XPS 8300
> [ 26.573046] Modules linked in: xt_CHECKSUM iptable_mangle bridge stp llc ip6t_REJECT nf_conntrack_ipv4 nf_conntrack_ipv6 nf_defrag_ipv6 nf_defrag_ipv4 xt_state nf_conntrack ib_iser rdma_cm ib_addr ip6table_filter tpm_bios ip6_tables iw_cm ib_cm ib_sa ib_mad ib_core iscsi_tcp snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel arc4 brcmsmac snd_hda_codec cordic brcmutil snd_hwdep mac80211 snd_pcm snd_page_alloc snd_timer cfg80211 snd coretemp rfkill serio_raw i2c_i801 soundcore lpc_ich bcma dcdbas microcode mfd_core mei vhost_net tun macvtap macvlan kvm_intel nfsd kvm auth_rpcgss nfs_acl lockd uinput crc32c_intel ghash_clmulni_intel broadcom tg3 usb_storage uas radeon i2c_algo_bit drm_kms_helper ttm drm i2c_core sunrpc be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i cxgb3 mdio libcxgbi
libiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi
> [ 26.573143] Pid: 757, comm: NetworkManager Not tainted 3.6.0-0.rc0.git8.1.fc18.x86_64 #1
> [ 26.573145] Call Trace:
> [ 26.573153] [<ffffffff8106782f>] warn_slowpath_common+0x7f/0xc0
> [ 26.573159] [<ffffffff8106788a>] warn_slowpath_null+0x1a/0x20
> [ 26.573170] [<ffffffffa04c730d>] assert_cfg80211_lock.part.8+0x15/0x17 [cfg80211]
> [ 26.573181] [<ffffffffa04a8dcb>] freq_reg_info+0x6b/0x80 [cfg80211]
brcmsmac needs to hold cfg80211_mutex before calling freq_reg_info...
It looks like those calls were added in mid-June.
> [ 26.573193] [<ffffffffa06b6c99>] brcms_c_channel_set_chanspec+0x2c9/0x350 [brcmsmac]
> [ 26.573204] [<ffffffffa06b7330>] brcms_c_set_phy_chanspec+0x30/0x70 [brcmsmac]
> [ 26.573216] [<ffffffffa06c1a45>] brcms_c_init+0xb25/0x12f0 [brcmsmac]
> [ 26.573225] [<ffffffffa047e61c>] ? bcma_host_pci_write32+0x3c/0x50 [bcma]
> [ 26.573235] [<ffffffffa06b322c>] brcms_init+0x5c/0x70 [brcmsmac]
> [ 26.573247] [<ffffffffa06bff5e>] brcms_c_up+0x23e/0x520 [brcmsmac]
> [ 26.573290] [<ffffffffa06b34a9>] brcms_up+0x29/0x30 [brcmsmac]
> [ 26.573299] [<ffffffffa06b3d0d>] brcms_ops_start+0x6d/0xe0 [brcmsmac]
> [ 26.573324] [<ffffffffa0626a01>] ieee80211_do_open+0x2e1/0x11b0 [mac80211]
> [ 26.573342] [<ffffffffa062793d>] ieee80211_open+0x6d/0x80 [mac80211]
> [ 26.573349] [<ffffffff8158fecf>] __dev_open+0x8f/0xf0
> [ 26.573357] [<ffffffff81590191>] __dev_change_flags+0xa1/0x180
> [ 26.573363] [<ffffffff81590328>] dev_change_flags+0x28/0x70
> [ 26.573371] [<ffffffff8159e278>] do_setlink+0x378/0xa00
> [ 26.573380] [<ffffffff810ac5a5>] ? sched_clock_cpu+0xc5/0x120
> [ 26.573386] [<ffffffff81021db3>] ? native_sched_clock+0x13/0x80
> [ 26.573392] [<ffffffff81359a51>] ? nla_parse+0x31/0xe0
> [ 26.573398] [<ffffffff815a09ae>] rtnl_newlink+0x37e/0x560
> [ 26.573407] [<ffffffff812d54a9>] ? selinux_capable+0x39/0x50
> [ 26.573412] [<ffffffff812d1a58>] ? security_capable+0x18/0x20
> [ 26.573418] [<ffffffff815a01d4>] rtnetlink_rcv_msg+0x114/0x2f0
> [ 26.573424] [<ffffffff8159d047>] ? rtnl_lock+0x17/0x20
> [ 26.573431] [<ffffffff8159d047>] ? rtnl_lock+0x17/0x20
> [ 26.573440] [<ffffffff815a00c0>] ? __rtnl_unlock+0x20/0x20
> [ 26.573447] [<ffffffff815bbf11>] netlink_rcv_skb+0xa1/0xb0
> [ 26.573454] [<ffffffff8159d075>] rtnetlink_rcv+0x25/0x40
> [ 26.573460] [<ffffffff815bb89d>] netlink_unicast+0x19d/0x220
> [ 26.573466] [<ffffffff815bbbfb>] netlink_sendmsg+0x2db/0x360
> [ 26.573474] [<ffffffff81576268>] ? sock_update_classid+0x148/0x2e0
> [ 26.573480] [<ffffffff8156fd7c>] sock_sendmsg+0xbc/0xf0
> [ 26.573487] [<ffffffff810ac66f>] ? local_clock+0x6f/0x80
> [ 26.573495] [<ffffffff810d5a17>] ? lock_release_non_nested+0x2f7/0x330
> [ 26.573501] [<ffffffff81570dec>] __sys_sendmsg+0x3ac/0x3c0
> [ 26.573504] [<ffffffff81021db3>] ? native_sched_clock+0x13/0x80
> [ 26.573508] [<ffffffff81021e29>] ? sched_clock+0x9/0x10
> [ 26.573511] [<ffffffff810ac5a5>] ? sched_clock_cpu+0xc5/0x120
> [ 26.573515] [<ffffffff810d05ad>] ? trace_hardirqs_off+0xd/0x10
> [ 26.573519] [<ffffffff810ac66f>] ? local_clock+0x6f/0x80
> [ 26.573523] [<ffffffff811c6939>] ? fget_light+0xf9/0x520
> [ 26.573526] [<ffffffff811c687c>] ? fget_light+0x3c/0x520
> [ 26.573530] [<ffffffff815737d9>] sys_sendmsg+0x49/0x90
> [ 26.573537] [<ffffffff816d8429>] system_call_fastpath+0x16/0x1b
> [ 26.573541] ---[ end trace 9edc8e6bb8e18f3f ]---
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
* assert_cfg80211_lock warning with Linux v3.5-8833-g2d53492
From: Josh Boyer @ 2012-08-01 13:12 UTC (permalink / raw)
To: Johannes Berg, John W. Linville, Brett Rudley, Roland Vossen
Cc: linux-wireless, netdev
Hi All,
With the latest Linus tree as of this morning, I'm getting the warning
below continuously. I've attached the first two instances of it. The
machine is a Dell XPS 8300 with a BCM4313 wireless chip in it.
Userspace is Fedora 17 and NetworkManager is controlling things though I
don't have it set to connect to any networks.
Please let me know if you've seen this before and if there is more
information I can provide.
josh
[ 15.587855] brcmsmac bcma0:0: mfg 4bf core 812 rev 24 class 0 irq 16
[ 15.636460] cfg80211: World regulatory domain updated:
[ 15.636462] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 15.636463] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 15.636465] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 15.636466] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 15.636467] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 15.636468] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 15.703640] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[ 15.957344] ALSA sound/pci/hda/hda_intel.c:2745 Using COMBO position fix
[ 15.957532] snd_hda_intel 0000:00:1b.0: irq 46 for MSI/MSI-X
[ 16.253325] cfg80211: Calling CRDA for country: US
[ 16.271042] cfg80211: Regulatory domain changed to country: US
[ 16.271045] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 16.271048] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
[ 16.271051] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
[ 16.271053] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 16.271055] cfg80211: (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 16.271057] cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 16.271060] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
<snip a bunch of ALSA/input stuff>
[ 21.762086] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[ 25.698788] Bridge firewalling registered
[ 25.746690] device virbr0-nic entered promiscuous mode
[ 26.573028] ------------[ cut here ]------------
[ 26.573042] WARNING: at net/wireless/core.h:125 assert_cfg80211_lock.part.8+0x15/0x17 [cfg80211]()
[ 26.573045] Hardware name: XPS 8300
[ 26.573046] Modules linked in: xt_CHECKSUM iptable_mangle bridge stp llc ip6t_REJECT nf_conntrack_ipv4 nf_conntrack_ipv6 nf_defrag_ipv6 nf_defrag_ipv4 xt_state nf_conntrack ib_iser rdma_cm ib_addr ip6table_filter tpm_bios ip6_tables iw_cm ib_cm ib_sa ib_mad ib_core iscsi_tcp snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel arc4 brcmsmac snd_hda_codec cordic brcmutil snd_hwdep mac80211 snd_pcm snd_page_alloc snd_timer cfg80211 snd coretemp rfkill serio_raw i2c_i801 soundcore lpc_ich bcma dcdbas microcode mfd_core mei vhost_net tun macvtap macvlan kvm_intel nfsd kvm auth_rpcgss nfs_acl lockd uinput crc32c_intel ghash_clmulni_intel broadcom tg3 usb_storage uas radeon i2c_algo_bit drm_kms_helper ttm drm i2c_core sunrpc be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i cxgb3 mdio libcxgbi li
biscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi
[ 26.573143] Pid: 757, comm: NetworkManager Not tainted 3.6.0-0.rc0.git8.1.fc18.x86_64 #1
[ 26.573145] Call Trace:
[ 26.573153] [<ffffffff8106782f>] warn_slowpath_common+0x7f/0xc0
[ 26.573159] [<ffffffff8106788a>] warn_slowpath_null+0x1a/0x20
[ 26.573170] [<ffffffffa04c730d>] assert_cfg80211_lock.part.8+0x15/0x17 [cfg80211]
[ 26.573181] [<ffffffffa04a8dcb>] freq_reg_info+0x6b/0x80 [cfg80211]
[ 26.573193] [<ffffffffa06b6c99>] brcms_c_channel_set_chanspec+0x2c9/0x350 [brcmsmac]
[ 26.573204] [<ffffffffa06b7330>] brcms_c_set_phy_chanspec+0x30/0x70 [brcmsmac]
[ 26.573216] [<ffffffffa06c1a45>] brcms_c_init+0xb25/0x12f0 [brcmsmac]
[ 26.573225] [<ffffffffa047e61c>] ? bcma_host_pci_write32+0x3c/0x50 [bcma]
[ 26.573235] [<ffffffffa06b322c>] brcms_init+0x5c/0x70 [brcmsmac]
[ 26.573247] [<ffffffffa06bff5e>] brcms_c_up+0x23e/0x520 [brcmsmac]
[ 26.573290] [<ffffffffa06b34a9>] brcms_up+0x29/0x30 [brcmsmac]
[ 26.573299] [<ffffffffa06b3d0d>] brcms_ops_start+0x6d/0xe0 [brcmsmac]
[ 26.573324] [<ffffffffa0626a01>] ieee80211_do_open+0x2e1/0x11b0 [mac80211]
[ 26.573342] [<ffffffffa062793d>] ieee80211_open+0x6d/0x80 [mac80211]
[ 26.573349] [<ffffffff8158fecf>] __dev_open+0x8f/0xf0
[ 26.573357] [<ffffffff81590191>] __dev_change_flags+0xa1/0x180
[ 26.573363] [<ffffffff81590328>] dev_change_flags+0x28/0x70
[ 26.573371] [<ffffffff8159e278>] do_setlink+0x378/0xa00
[ 26.573380] [<ffffffff810ac5a5>] ? sched_clock_cpu+0xc5/0x120
[ 26.573386] [<ffffffff81021db3>] ? native_sched_clock+0x13/0x80
[ 26.573392] [<ffffffff81359a51>] ? nla_parse+0x31/0xe0
[ 26.573398] [<ffffffff815a09ae>] rtnl_newlink+0x37e/0x560
[ 26.573407] [<ffffffff812d54a9>] ? selinux_capable+0x39/0x50
[ 26.573412] [<ffffffff812d1a58>] ? security_capable+0x18/0x20
[ 26.573418] [<ffffffff815a01d4>] rtnetlink_rcv_msg+0x114/0x2f0
[ 26.573424] [<ffffffff8159d047>] ? rtnl_lock+0x17/0x20
[ 26.573431] [<ffffffff8159d047>] ? rtnl_lock+0x17/0x20
[ 26.573440] [<ffffffff815a00c0>] ? __rtnl_unlock+0x20/0x20
[ 26.573447] [<ffffffff815bbf11>] netlink_rcv_skb+0xa1/0xb0
[ 26.573454] [<ffffffff8159d075>] rtnetlink_rcv+0x25/0x40
[ 26.573460] [<ffffffff815bb89d>] netlink_unicast+0x19d/0x220
[ 26.573466] [<ffffffff815bbbfb>] netlink_sendmsg+0x2db/0x360
[ 26.573474] [<ffffffff81576268>] ? sock_update_classid+0x148/0x2e0
[ 26.573480] [<ffffffff8156fd7c>] sock_sendmsg+0xbc/0xf0
[ 26.573487] [<ffffffff810ac66f>] ? local_clock+0x6f/0x80
[ 26.573495] [<ffffffff810d5a17>] ? lock_release_non_nested+0x2f7/0x330
[ 26.573501] [<ffffffff81570dec>] __sys_sendmsg+0x3ac/0x3c0
[ 26.573504] [<ffffffff81021db3>] ? native_sched_clock+0x13/0x80
[ 26.573508] [<ffffffff81021e29>] ? sched_clock+0x9/0x10
[ 26.573511] [<ffffffff810ac5a5>] ? sched_clock_cpu+0xc5/0x120
[ 26.573515] [<ffffffff810d05ad>] ? trace_hardirqs_off+0xd/0x10
[ 26.573519] [<ffffffff810ac66f>] ? local_clock+0x6f/0x80
[ 26.573523] [<ffffffff811c6939>] ? fget_light+0xf9/0x520
[ 26.573526] [<ffffffff811c687c>] ? fget_light+0x3c/0x520
[ 26.573530] [<ffffffff815737d9>] sys_sendmsg+0x49/0x90
[ 26.573537] [<ffffffff816d8429>] system_call_fastpath+0x16/0x1b
[ 26.573541] ---[ end trace 9edc8e6bb8e18f3f ]---
[ 26.575489] ieee80211 phy0: brcms_ops_bss_info_changed: qos enabled: false (implement)
[ 26.575571] ieee80211 phy0: brcms_ops_config: change power-save mode: false (implement)
[ 26.576055] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 26.729219] tg3 0000:03:00.0: irq 48 for MSI/MSI-X
[ 26.746776] IPv6: ADDRCONF(NETDEV_UP): p3p1: link is not ready
[ 27.084202] tg3 0000:03:00.0: p3p1: Link is down
[ 27.089383] IPv6: ADDRCONF(NETDEV_UP): virbr0: link is not ready
[ 28.413963] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
[ 28.430879] NFSD: starting 90-second grace period
[ 28.666424] ------------[ cut here ]------------
[ 28.666441] WARNING: at net/wireless/core.h:125 assert_cfg80211_lock.part.8+0x15/0x17 [cfg80211]()
[ 28.666451] Hardware name: XPS 8300
[ 28.666451] Modules linked in: ipt_MASQUERADE iptable_nat nf_nat xt_CHECKSUM iptable_mangle bridge stp llc ip6t_REJECT nf_conntrack_ipv4 nf_conntrack_ipv6 nf_defrag_ipv6 nf_defrag_ipv4 xt_state nf_conntrack ib_iser rdma_cm ib_addr ip6table_filter tpm_bios ip6_tables iw_cm ib_cm ib_sa ib_mad ib_core iscsi_tcp snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel arc4 brcmsmac snd_hda_codec cordic brcmutil snd_hwdep mac80211 snd_pcm snd_page_alloc snd_timer cfg80211 snd coretemp rfkill serio_raw i2c_i801 soundcore lpc_ich bcma dcdbas microcode mfd_core mei vhost_net tun macvtap macvlan kvm_intel nfsd kvm auth_rpcgss nfs_acl lockd uinput crc32c_intel ghash_clmulni_intel broadcom tg3 usb_storage uas radeon i2c_algo_bit drm_kms_helper ttm drm i2c_core sunrpc be2iscsi bnx2i cnic uio cxgb4i c
xgb4 cxgb3i cxgb3 mdio libcxgbi libiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi
[ 28.666504] Pid: 109, comm: kworker/u:5 Tainted: G W 3.6.0-0.rc0.git8.1.fc18.x86_64 #1
[ 28.666505] Call Trace:
[ 28.666510] [<ffffffff8106782f>] warn_slowpath_common+0x7f/0xc0
[ 28.666514] [<ffffffff8106788a>] warn_slowpath_null+0x1a/0x20
[ 28.666519] [<ffffffffa04c730d>] assert_cfg80211_lock.part.8+0x15/0x17 [cfg80211]
[ 28.666525] [<ffffffffa04a8dcb>] freq_reg_info+0x6b/0x80 [cfg80211]
[ 28.666531] [<ffffffffa06b6c99>] brcms_c_channel_set_chanspec+0x2c9/0x350 [brcmsmac]
[ 28.666537] [<ffffffffa06b7330>] brcms_c_set_phy_chanspec+0x30/0x70 [brcmsmac]
[ 28.666542] [<ffffffffa06baf71>] brcms_c_set_chanspec+0xa1/0x1d0 [brcmsmac]
[ 28.666548] [<ffffffffa06bcb1e>] brcms_c_set_channel+0x11e/0x140 [brcmsmac]
[ 28.666552] [<ffffffffa06b23c8>] brcms_ops_config+0x108/0x1f0 [brcmsmac]
[ 28.666563] [<ffffffffa060ed92>] ieee80211_hw_config+0x142/0x3f0 [mac80211]
[ 28.666572] [<ffffffffa0619f5f>] ieee80211_scan_work+0x21f/0x7b0 [mac80211]
[ 28.666576] [<ffffffff8108bdef>] process_one_work+0x20f/0x760
[ 28.666578] [<ffffffff8108bd87>] ? process_one_work+0x1a7/0x760
[ 28.666580] [<ffffffff8108c7ce>] ? worker_thread+0x21e/0x450
[ 28.666587] [<ffffffffa0619d40>] ? ieee80211_run_deferred_scan+0x120/0x120 [mac80211]
[ 28.666592] [<ffffffff8108c70e>] worker_thread+0x15e/0x450
[ 28.666595] [<ffffffff8108c5b0>] ? rescuer_thread+0x230/0x230
[ 28.666597] [<ffffffff81092527>] kthread+0xb7/0xc0
[ 28.666600] [<ffffffff816d9604>] kernel_thread_helper+0x4/0x10
[ 28.666603] [<ffffffff816cf970>] ? retint_restore_args+0x13/0x13
[ 28.666605] [<ffffffff81092470>] ? __init_kthread_worker+0x70/0x70
[ 28.666607] [<ffffffff816d9600>] ? gs_change+0x13/0x13
[ 28.666608] ---[ end trace 9edc8e6bb8e18f40 ]---
^ permalink raw reply
* [PATCH net-next] igb: add delay to allow igb loopback test to succeed on 8086:10c9
From: Stefan Assmann @ 2012-08-01 11:44 UTC (permalink / raw)
To: netdev; +Cc: e1000-devel, carolyn.wyborny, sassmann
Some 8086:10c9 NICs have a problem completing the ethtool loopback test.
The result looks like this:
ethtool -t eth1
The test result is FAIL
The test extra info:
Register test (offline) 0
Eeprom test (offline) 0
Interrupt test (offline) 0
Loopback test (offline) 13
Link test (on/offline) 0
A bisect clearly points to commit a95a07445ee97a2fef65befafbadcc30ca1bd145.
However that seems to only trigger the bug. While adding some printk the
problem disappeared, so this might be a timing issue. After some trial and
error I discovered that adding a small delay just before igb_write_phy_reg()
in igb_integrated_phy_loopback() allows the loopback test to succeed.
I was unable to figure out the root cause so far but I expect it to be
somewhere in the following executing path
igb_integrated_phy_loopback
->igb_write_phy_reg_igp
->igb_write_phy_reg_mdic
->igb_acquire_phy_82575
->igb_acquire_swfw_sync_82575
As this workaround only introduces a minor delay, which is not in the hot
path I hope this is acceptable. The problem could only be oberved on
8086:10c9 NICs so far and not all of them show the behaviour. I did not
restrict the workaround to this type of NIC as it should do no harm to
other igb NICs.
With the patch below the loopback test succeeded 500 times in a row
using a NIC that would otherwise fail.
Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
---
drivers/net/ethernet/intel/igb/igb_ethtool.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c b/drivers/net/ethernet/intel/igb/igb_ethtool.c
index a19c84c..f62fa25 100644
--- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
+++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
@@ -1497,6 +1497,9 @@ static int igb_integrated_phy_loopback(struct igb_adapter *adapter)
break;
}
+ /* add small delay to avoid loopback test failure */
+ msleep(50);
+
/* force 1000, set loopback */
igb_write_phy_reg(hw, PHY_CONTROL, 0x4140);
--
1.7.4.4
^ permalink raw reply related
* binding UDP port 0 with SO_REUSEADDR
From: Tobias S. Josefowitz @ 2012-08-01 11:36 UTC (permalink / raw)
To: netdev
Hey all,
I recently noticed that binding UDP port 0 with SO_REUSEADDR yields
unexpected results for me - the kernel occasionally gives out UDP
ports used by other processes, if they were bound with SO_REUSEADDR,
too.
I did some digging, it seems that
f24d43c07e208372aa3d3bff419afbf43ba87698 introduced this behaviour.
I'm not at all sure if this could/should be called a bug, but I need
to say, it was severly unexpected at my side, and that probably goes
for others, too.
Just bringing this to your attention, I have no suggestions on it whatsoever.
Best,
Tobi
^ permalink raw reply
* Re: Build failure when installing atm ambassador firmware
From: chas williams - CONTRACTOR @ 2012-08-01 11:22 UTC (permalink / raw)
To: Shea Levy; +Cc: netdev, linux-kernel@vger.kernel.org
In-Reply-To: <50188D89.3040404@shealevy.com>
On Tue, 31 Jul 2012 21:59:37 -0400
Shea Levy <shea@shealevy.com> wrote:
> Hello,
>
> When building with
> MODLIB=/nix/store/ghx6s9hnk9irim7c7f63zrxqiv6xjh3w-linux-3.5/lib/modules/3.5.0
> and
> ="/nix/store/ghx6s9hnk9irim7c7f63zrxqiv6xjh3w-linux-3.5/lib/firmware",
> building Linux 3.5 with CONFIG_ATM_AMBASSADOR=m fails with:
>
> "make[2]: *** No rule to make target
> `"/nix/store/ghx6s9hnk9irim7c7f63zrxqiv6xjh3w-linux-3.5/lib/firmware"/./',
> needed by
> `"/nix/store/ghx6s9hnk9irim7c7f63zrxqiv6xjh3w-linux-3.5/lib/firmware"/atmsar11.fw'.
> Stop."
i think it might be trying to tell you that the target directory
$INSTALL_FW_PATH doesn't exist and is a prerequisite to actually
perform the action.
it complains about atmsar11.fw first because it just happens to be the
first firmware that needs to be installed.
/scratch/chas/net-next relax.53% ls -ld /tmp/funk
ls: cannot access /tmp/funk: No such file or directory
/scratch/chas/net-next relax.54% make INSTALL_FW_PATH="/tmp/funk" firmware_install
make[1]: *** No rule to make target `/tmp/funk/./', needed by `/tmp/funk/atmsar11.fw'. Stop.
make: *** [firmware_install] Error 2
/scratch/chas/net-next relax.55% mkdir /tmp/funk
/scratch/chas/net-next relax.56% make INSTALL_FW_PATH="/tmp/funk" firmware_install
INSTALL /tmp/funk/atmsar11.fw
MKDIR /tmp/funk/e100/
INSTALL /tmp/funk/e100/d101m_ucode.bin
INSTALL /tmp/funk/e100/d101s_ucode.bin
INSTALL /tmp/funk/e100/d102e_ucode.bin
...
i am somewhat concerned that it appears to have an extra set of "'s in
the path as well. how are you passing in INSTALL_FW_PATH? i can get
the same result with:
/scratch/chas/net-next relax.57% make 'INSTALL_FW_PATH="/tmp/funk"' firmware_install
make[1]: *** No rule to make target `"/tmp/funk"/./', needed by `"/tmp/funk"/atmsar11.fw'. Stop.
make: *** [firmware_install] Error 2
but it would be wrong to do it this way.
^ permalink raw reply
* Re: wlcore: might_sleep operation in interrupt handler
From: Denis Yefremov @ 2012-08-01 10:48 UTC (permalink / raw)
To: Johannes Berg
Cc: Luciano Coelho, John W. Linville, Eliad Peller, Arik Nemtsov,
Eyal Shapira, linux-wireless, netdev, linux-kernel, ldv-project
In-Reply-To: <CADKZ3FLs444RfLx=RyBPKs+Lza_mZHhT=zHauMt3BUnqAUtY0w@mail.gmail.com>
Sorry. My mistake. In this case it seems that sleep functions can
be called from thread_fn, since interrupt line is disabled globally.
And nothing bad will happen if you know that device can be
blocked for relatively long time.
^ permalink raw reply
* Re: [PATCH v2 3/6] mv643xx.c: Add basic device tree support.
From: Ian Molton @ 2012-08-01 8:50 UTC (permalink / raw)
To: linux-arm-kernel, andrew, thomas.petazzoni, ben.dooks, arnd,
netdev
In-Reply-To: <20120731164652.GD28852@lunn.ch>
On 31/07/12 17:46, Andrew Lunn wrote:
> Hi Ian
>
> Probably the driver change will get upstream by netdev. The rest will
> go via the Orion maintainers into arm-soc. So you should probably move
> this board-dt.c change into a patch of its own, or make it part of:
>
> csb1724: Enable device tree based mv643xx ethernet support.
Its not csb1724 specific; I've merged it into
kirkwood: Add a clock setup helper for mv643xx ethernet.
and renamed it to:
kirkwood: Add fixups for DT based mv643xx ethernet.
As this described its purpose better. Hopefully in time, we can
pass something in DT that will allow us to remove that code.
-Ian
^ permalink raw reply
* Re: [PATCH] bnx2x: fix mem leak when command is unknown
From: Dmitry Kravkov @ 2012-08-01 7:41 UTC (permalink / raw)
To: Jesper Juhl; +Cc: Eilon Greenstein, netdev, linux-kernel
In-Reply-To: <alpine.LNX.2.00.1207312337590.7100@swampdragon.chaosbits.net>
On Tue, 2012-07-31 at 23:39 +0200, Jesper Juhl wrote:
> In bnx2x_mcast_enqueue_cmd() we'll leak the memory allocated to
> 'new_cmd' if we hit the deafault case of the 'switch (cmd)'.
> Add a 'kfree(new_cmd)' to that case to avoid the leak.
>
> Signed-off-by: Jesper Juhl <jj@chaosbits.net>
> ---
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c | 1 +
> 1 file changed, 1 insertion(+)
>
> note: due to lack of hardware this patch is compile tested only.
>
> diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c
> index 734fd87..62f754b 100644
> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c
> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c
> @@ -2485,6 +2485,7 @@ static int bnx2x_mcast_enqueue_cmd(struct bnx2x *bp,
> break;
>
> default:
> + kfree(new_cmd);
> BNX2X_ERR("Unknown command: %d\n", cmd);
> return -EINVAL;
> }
> --
> 1.7.11.3
>
Thanks a lot, Jesper.
Acked-by: Dmitry Kravkov <dmitry@broadcom.com>
>
^ permalink raw reply
* OFFER PROPOSAL,
From: Mrs.wong @ 2012-08-01 20:20 UTC (permalink / raw)
To: Recipients
I HAVE A SECURED BUSINESS OFFER IF INTERESTED KINDLY REPLY FOR MORE INFORMATION.
^ permalink raw reply
* Re: iputils git tree
From: YOSHIFUJI Hideaki @ 2012-08-01 4:50 UTC (permalink / raw)
To: Mike Frysinger; +Cc: Noah Meyerhans, netdev, YOSHIFUJI Hideaki
In-Reply-To: <201208010016.22035.vapier@gentoo.org>
(2012年08月01日 13:16), Mike Frysinger wrote:ll
> On Wednesday 01 August 2012 00:10:06 YOSHIFUJI Hideaki wrote:
>> Hello.
>>
>> (2012/08/01 12:21), YOSHIFUJI Hideaki wrote:
>>> (2012/08/01 11:46), Noah Meyerhans wrote:
>>>> On Sun, Mar 18, 2012 at 09:07:42PM -0400, Mike Frysinger wrote:
>>>>> the iputils homepage says to use:
>>>>> git://git.linux-ipv6.org/gitroot/iputils.git
>>>>>
>>>>> but attempting to clone from that gets me connection refused. the
>>>>> gitweb is
>>>>>
>>>>> still alive though and shows recent commits:
>>>>> http://www.linux-ipv6.org/gitweb/gitweb.cgi?p=gitroot/iputils.git;a
>>>>> =summary
>>>>>
>>>>> so where can i clone this tree ?
>>>>
>>>> Hi all. The iputils git repo still seems unavailable for cloning. Is
>>>> there any possibility we could get this fixed? I was able to clone from
>>>> git://git.linux-ipv6.org/gitroot/iputils.git
>>>> at some point in the past, but it was more than a year ago.
>>>
>>> Sorry, I'll fix.
>>
>> DNS entry has been updated and you can reach it after a while.
>> I am sorry for any inconvenience.
>
> i can clone git://git.linux-ipv6.org/gitroot/iputils.git now, but it seems to
> be pointing at a different clone than is viewable from gitweb. it's stuck at:
>
> commit 2384927c0ac1bb3ad21966350644d08faadb7a76
> Author: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
> Date: Wed Oct 6 20:59:20 2010 +0900
>
> iputils-s20101006
Sorry, files were out of sync. Updated.
--yoshfuji
^ permalink raw reply
* Re: iputils git tree
From: YOSHIFUJI Hideaki @ 2012-08-01 4:18 UTC (permalink / raw)
To: Noah Meyerhans; +Cc: David Miller, netdev, vapier, YOSHIFUJI Hideaki
In-Reply-To: <20120801040957.GL11095@morgul.net>
Hello.
(2012年08月01日 13:09), Noah Meyerhans wrote:
> On Tue, Jul 31, 2012 at 08:29:18PM -0700, David Miller wrote:
>> iputils has been unmaintained for at least 2 years.
>>
>> Someone needs to step up and take over maintainence of it.
>>
>> Otherwise, expect the current situation to continue.
>
> I was under the impresion that iputils had been handed over from Alexey
> to Hideaki YOSHIFUJI. The fork at linux-ipv6.org certainly doesn't
> appear dead. I count 12 commits this year to the repository visible at
> http://www.linux-ipv6.org/gitweb/gitweb.cgi?p=gitroot/iputils.git;a=summary
> It's not exactly a screaming fast pace, but it's something.
>
> There are several (mostly relatively minor) bugs that have been fixed in
> the Debian packages (of which I'm the maintainer). There's another
> assortment of patches in the Debian bug tracker that haven't yet been
> merged in. I imagine Fedora and RHEL have a collection of similar
> modifications. So I suspect that iputils really isn't dead, but it's
> just that nobody's bothering to push changes back upstream. I'm more
> than happy to start doing so.
>
> noah
>
In fact my first motivation was to integrate Debian, Fedora and
other distro updates in to single source. I sometimes look
into their sources and integrate some of their changes.
Anyway, I am happy if distro changes are posted and discussed.
Regards,
--yoshfuji
^ permalink raw reply
* Re: iputils git tree
From: Mike Frysinger @ 2012-08-01 4:16 UTC (permalink / raw)
To: YOSHIFUJI Hideaki; +Cc: Noah Meyerhans, netdev
In-Reply-To: <5018AC1E.2010704@linux-ipv6.org>
[-- Attachment #1: Type: Text/Plain, Size: 1394 bytes --]
On Wednesday 01 August 2012 00:10:06 YOSHIFUJI Hideaki wrote:
> Hello.
>
> (2012/08/01 12:21), YOSHIFUJI Hideaki wrote:
> > (2012/08/01 11:46), Noah Meyerhans wrote:
> >> On Sun, Mar 18, 2012 at 09:07:42PM -0400, Mike Frysinger wrote:
> >>> the iputils homepage says to use:
> >>> git://git.linux-ipv6.org/gitroot/iputils.git
> >>>
> >>> but attempting to clone from that gets me connection refused. the
> >>> gitweb is
> >>>
> >>> still alive though and shows recent commits:
> >>> http://www.linux-ipv6.org/gitweb/gitweb.cgi?p=gitroot/iputils.git;a
> >>> =summary
> >>>
> >>> so where can i clone this tree ?
> >>
> >> Hi all. The iputils git repo still seems unavailable for cloning. Is
> >> there any possibility we could get this fixed? I was able to clone from
> >> git://git.linux-ipv6.org/gitroot/iputils.git
> >> at some point in the past, but it was more than a year ago.
> >
> > Sorry, I'll fix.
>
> DNS entry has been updated and you can reach it after a while.
> I am sorry for any inconvenience.
i can clone git://git.linux-ipv6.org/gitroot/iputils.git now, but it seems to
be pointing at a different clone than is viewable from gitweb. it's stuck at:
commit 2384927c0ac1bb3ad21966350644d08faadb7a76
Author: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Wed Oct 6 20:59:20 2010 +0900
iputils-s20101006
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: iputils git tree
From: YOSHIFUJI Hideaki @ 2012-08-01 4:10 UTC (permalink / raw)
To: Noah Meyerhans; +Cc: netdev, Mike Frysinger, YOSHIFUJI Hideaki
In-Reply-To: <5018A0A8.4000107@linux-ipv6.org>
Hello.
(2012/08/01 12:21), YOSHIFUJI Hideaki wrote:
> (2012/08/01 11:46), Noah Meyerhans wrote:
>> On Sun, Mar 18, 2012 at 09:07:42PM -0400, Mike Frysinger wrote:
>>> the iputils homepage says to use:
>>> git://git.linux-ipv6.org/gitroot/iputils.git
>>>
>>> but attempting to clone from that gets me connection refused. the
>>> gitweb is
>>> still alive though and shows recent commits:
>>> http://www.linux-ipv6.org/gitweb/gitweb.cgi?p=gitroot/iputils.git;a=summary
>>>
>>>
>>> so where can i clone this tree ?
>>
>> Hi all. The iputils git repo still seems unavailable for cloning. Is
>> there any possibility we could get this fixed? I was able to clone from
>> git://git.linux-ipv6.org/gitroot/iputils.git
>> at some point in the past, but it was more than a year ago.
>>
>> Thanks.
>> noah
>>
>
> Sorry, I'll fix.
DNS entry has been updated and you can reach it after a while.
I am sorry for any inconvenience.
--yoshfuji
^ permalink raw reply
* Re: iputils git tree
From: Noah Meyerhans @ 2012-08-01 4:09 UTC (permalink / raw)
To: David Miller; +Cc: yoshfuji, netdev, vapier
In-Reply-To: <20120731.202918.621064199466580610.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]
On Tue, Jul 31, 2012 at 08:29:18PM -0700, David Miller wrote:
> iputils has been unmaintained for at least 2 years.
>
> Someone needs to step up and take over maintainence of it.
>
> Otherwise, expect the current situation to continue.
I was under the impresion that iputils had been handed over from Alexey
to Hideaki YOSHIFUJI. The fork at linux-ipv6.org certainly doesn't
appear dead. I count 12 commits this year to the repository visible at
http://www.linux-ipv6.org/gitweb/gitweb.cgi?p=gitroot/iputils.git;a=summary
It's not exactly a screaming fast pace, but it's something.
There are several (mostly relatively minor) bugs that have been fixed in
the Debian packages (of which I'm the maintainer). There's another
assortment of patches in the Debian bug tracker that haven't yet been
merged in. I imagine Fedora and RHEL have a collection of similar
modifications. So I suspect that iputils really isn't dead, but it's
just that nobody's bothering to push changes back upstream. I'm more
than happy to start doing so.
noah
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [PATCH] iputils - ping and ping6
From: YOSHIFUJI Hideaki @ 2012-08-01 4:08 UTC (permalink / raw)
To: Jan Synacek, 'netdev@vger.kernel.org', YOSHIFUJI Hideaki
In-Reply-To: <500CFBA9.7010807@redhat.com>
Hello.
(2012/07/23 16:22), Jan Synacek wrote:
> Hello Hideaki-san,
>
> currently, ping and ping6 drop all the capabilities regardless of whether the
> user wants to set marks (-m option) or not. Setting marks requires
> cap_net_admin, though, and doesn't work.
>
> This patch defers the dropping if the "-m" is specified and correct capability
> is set.
Applied, Thank you.
Please add signed-off line next time. Thank you.
--yoshfuji
^ permalink raw reply
* Re: iputils git tree
From: YOSHIFUJI Hideaki @ 2012-08-01 3:21 UTC (permalink / raw)
To: Noah Meyerhans; +Cc: netdev, Mike Frysinger
In-Reply-To: <20120801024656.GK11095@morgul.net>
(2012年08月01日 11:46), Noah Meyerhans wrote:
> On Sun, Mar 18, 2012 at 09:07:42PM -0400, Mike Frysinger wrote:
>> the iputils homepage says to use:
>> git://git.linux-ipv6.org/gitroot/iputils.git
>>
>> but attempting to clone from that gets me connection refused. the gitweb is
>> still alive though and shows recent commits:
>> http://www.linux-ipv6.org/gitweb/gitweb.cgi?p=gitroot/iputils.git;a=summary
>>
>> so where can i clone this tree ?
>
> Hi all. The iputils git repo still seems unavailable for cloning. Is
> there any possibility we could get this fixed? I was able to clone from
> git://git.linux-ipv6.org/gitroot/iputils.git
> at some point in the past, but it was more than a year ago.
>
> Thanks.
> noah
>
Sorry, I'll fix.
--yoshfuji
^ permalink raw reply
* Re: iputils git tree
From: David Miller @ 2012-08-01 3:29 UTC (permalink / raw)
To: frodo; +Cc: yoshfuji, netdev, vapier
In-Reply-To: <20120801024656.GK11095@morgul.net>
From: Noah Meyerhans <frodo@morgul.net>
Date: Tue, 31 Jul 2012 19:46:56 -0700
> On Sun, Mar 18, 2012 at 09:07:42PM -0400, Mike Frysinger wrote:
>> the iputils homepage says to use:
>> git://git.linux-ipv6.org/gitroot/iputils.git
>>
>> but attempting to clone from that gets me connection refused. the gitweb is
>> still alive though and shows recent commits:
>> http://www.linux-ipv6.org/gitweb/gitweb.cgi?p=gitroot/iputils.git;a=summary
>>
>> so where can i clone this tree ?
>
> Hi all. The iputils git repo still seems unavailable for cloning. Is
> there any possibility we could get this fixed? I was able to clone from
> git://git.linux-ipv6.org/gitroot/iputils.git
> at some point in the past, but it was more than a year ago.
iputils has been unmaintained for at least 2 years.
Someone needs to step up and take over maintainence of it.
Otherwise, expect the current situation to continue.
^ permalink raw reply
* Re: iputils git tree
From: Noah Meyerhans @ 2012-08-01 2:46 UTC (permalink / raw)
To: yoshfuji, netdev; +Cc: Mike Frysinger
In-Reply-To: <201203182107.43855.vapier@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 675 bytes --]
On Sun, Mar 18, 2012 at 09:07:42PM -0400, Mike Frysinger wrote:
> the iputils homepage says to use:
> git://git.linux-ipv6.org/gitroot/iputils.git
>
> but attempting to clone from that gets me connection refused. the gitweb is
> still alive though and shows recent commits:
> http://www.linux-ipv6.org/gitweb/gitweb.cgi?p=gitroot/iputils.git;a=summary
>
> so where can i clone this tree ?
Hi all. The iputils git repo still seems unavailable for cloning. Is
there any possibility we could get this fixed? I was able to clone from
git://git.linux-ipv6.org/gitroot/iputils.git
at some point in the past, but it was more than a year ago.
Thanks.
noah
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: 802.15.4 Issues
From: Alan Ott @ 2012-08-01 2:40 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
Alexander Smirnov, Tony Cheneau
In-Reply-To: <50180217.8040706-yzvJWuRpmD1zbRFIqnYvSA@public.gmane.org>
On 07/31/2012 12:04 PM, Alan Ott wrote:
> I'm trying to follow the directions at linux-wsn[1] and am not having
> much luck. Since I don't have the at91sam9g20ek board, I'm trying this
> on my desktop PC with an Econotag[2] (using the serial.c driver I pulled
> from [3]) and on a BeagleBone with an MRF24J40 (using a driver I made [4]).
> Like I said, I feel like there's something fundamental I'm doing wrong.
There was....
If you don't run izcoordinator with -d, it won't set the PAN and/or
short address.
izcoordinator -i wpan0 -d 1 -s 2 -p 777 -c 11 -l lease
This should go in the instructions at [1]. Alexander, if you give me
permissions I'll fix it.
While we're on instructions... :
"insmod iz listphy" (remove insmod)
Now to figure out why my ping doesn't work....
Alan.
> [1] http://code.google.com/p/linux-wsn/wiki/Mainline
> [2] http://www.redwirellc.com/store/node/1
> [3]
> http://linux-zigbee.git.sourceforge.net/git/gitweb.cgi?p=linux-zigbee/kernel;a=summary
> [4] http://permalink.gmane.org/gmane.linux.network.zigbee.devel/1135
> [5] http://sourceforge.net/apps/trac/linux-zigbee/wiki/GettingStarted-0.2
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
^ permalink raw reply
* Re: [PATCH 0/7] netpoll and netconsole fixes for 3.6
From: Cong Wang @ 2012-08-01 2:22 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Neil Horman
In-Reply-To: <1343403484-29347-1-git-send-email-amwang@redhat.com>
Ping... Any more reviews?
On Fri, 2012-07-27 at 23:37 +0800, Cong Wang wrote:
> This patch fixes serval problems in netconsole and netpoll.
>
> I ran this patch in my KVM guest with some netpoll test cases,
> even covered with some corner cases, everything worked as expected.
>
> BTW, my kernel config enables the following validatation options:
>
> CONFIG_DEBUG_ATOMIC_SLEEP=y
> CONFIG_PROVE_LOCKING=y
> CONFIG_PROVE_RCU=y
> CONFIG_LOCKDEP=y
> CONFIG_RCU_CPU_STALL_TIMEOUT=60
> CONFIG_LOCKUP_DETECTOR=y
> CONFIG_HARDLOCKUP_DETECTOR=y
>
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Cong Wang <amwang@redhat.com>
>
> ---
>
> Cong Wang (7):
> netpoll: use GFP_ATOMIC in slave_enable_netpoll() and __netpoll_setup()
> netpoll: make __netpoll_cleanup non-block
> netconsole: do not release spin_lock when calling __netpoll_cleanup
> bridge: call NETDEV_RELEASE notifier in br_del_if()
> netpoll: take rcu_read_lock_bh() in netpoll_rx()
> netpoll: use netpoll_rx_on() in netpoll_rx()
> netpoll: take rcu_read_lock_bh() in netpoll_send_skb_on_dev()
>
> drivers/net/bonding/bond_main.c | 6 +--
> drivers/net/netconsole.c | 5 --
> include/linux/netpoll.h | 25 +++++++-----
> net/8021q/vlan_dev.c | 6 +--
> net/bridge/br_device.c | 6 +--
> net/bridge/br_if.c | 1 +
> net/core/netpoll.c | 78 +++++++++++++++++++++++++-------------
> 7 files changed, 70 insertions(+), 57 deletions(-)
>
^ 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