* 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: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: 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
* 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: [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
* 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: 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: 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
* 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
* [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
* 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
* 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
* 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: [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: 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: 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: 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: Build failure when installing atm ambassador firmware
From: Shea Levy @ 2012-08-01 15:40 UTC (permalink / raw)
To: chas williams - CONTRACTOR; +Cc: netdev, linux-kernel@vger.kernel.org
In-Reply-To: <20120801072247.589c7162@thirdoffive.cmf.nrl.navy.mil>
Hi Chas,
On 08/01/2012 07:22 AM, chas williams - CONTRACTOR wrote:
> 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.
>
Indeed, creating the directory first fixes the issue. Is this expected
behaviour, or a bug in the build system?
>
> 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.
Yeah, I had an extra bit of quotation that I've now removed. Thanks!
Cheers,
Shea Levy
^ permalink raw reply
* [PATCH 1/6] tracepath: re-use printf return in print_host
From: Mike Frysinger @ 2012-08-01 15:45 UTC (permalink / raw)
To: YOSHIFUJI Hideaki; +Cc: netdev
Since the printf funcs already return the length of chars displayed,
use that value instead of re-calculating the length with strlen.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
tracepath.c | 11 ++++-------
tracepath6.c | 11 ++++-------
2 files changed, 8 insertions(+), 14 deletions(-)
diff --git a/tracepath.c b/tracepath.c
index bcec20d..ca84a69 100644
--- a/tracepath.c
+++ b/tracepath.c
@@ -68,13 +68,10 @@ void data_wait(int fd)
void print_host(const char *a, const char *b, int both)
{
- int plen = 0;
- printf("%s", a);
- plen = strlen(a);
- if (both) {
- printf(" (%s)", b);
- plen += strlen(b) + 3;
- }
+ int plen;
+ plen = printf("%s", a);
+ if (both)
+ plen += printf(" (%s)", b);
if (plen >= HOST_COLUMN_SIZE)
plen = HOST_COLUMN_SIZE - 1;
printf("%*s", HOST_COLUMN_SIZE - plen, "");
diff --git a/tracepath6.c b/tracepath6.c
index 0cbe3a1..5c2db8f 100644
--- a/tracepath6.c
+++ b/tracepath6.c
@@ -80,13 +80,10 @@ void data_wait(int fd)
void print_host(const char *a, const char *b, int both)
{
- int plen = 0;
- printf("%s", a);
- plen = strlen(a);
- if (both) {
- printf(" (%s)", b);
- plen += strlen(b) + 3;
- }
+ int plen;
+ plen = printf("%s", a);
+ if (both)
+ plen += printf(" (%s)", b);
if (plen >= HOST_COLUMN_SIZE)
plen = HOST_COLUMN_SIZE - 1;
printf("%*s", HOST_COLUMN_SIZE - plen, "");
--
1.7.9.7
^ permalink raw reply related
* [PATCH 2/6] fix up strict-aliasing warnings
From: Mike Frysinger @ 2012-08-01 15:45 UTC (permalink / raw)
To: YOSHIFUJI Hideaki; +Cc: netdev
In-Reply-To: <1343835928-21541-1-git-send-email-vapier@gentoo.org>
Current build of some tools results in gcc warning about strict-aliasing
violations. So change those freaky casts to memcpy's. When the pointer
types work out, gcc will optimize this away anyways.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
ping.c | 4 ++--
ping6.c | 13 +++++++++----
tracepath.c | 2 +-
tracepath6.c | 2 +-
4 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/ping.c b/ping.c
index 1425d1d..1110a1a 100644
--- a/ping.c
+++ b/ping.c
@@ -444,7 +444,7 @@ main(int argc, char **argv)
int i;
rspace[1] = 4+nroute*8;
for (i=0; i<nroute; i++)
- *(__u32*)&rspace[4+i*8] = route[i];
+ memcpy(&rspace[4+i*8], &route[i], 4);
}
if (setsockopt(icmp_sock, IPPROTO_IP, IP_OPTIONS, rspace, rspace[1]) < 0) {
rspace[3] = 2;
@@ -464,7 +464,7 @@ main(int argc, char **argv)
rspace[1+IPOPT_OLEN] = 3 + nroute*4;
rspace[1+IPOPT_OFFSET] = IPOPT_MINOFF;
for (i=0; i<nroute; i++)
- *(__u32*)&rspace[4+i*4] = route[i];
+ memcpy(&rspace[4+i*4], &route[i], 4);
if (setsockopt(icmp_sock, IPPROTO_IP, IP_OPTIONS, rspace, 4 + nroute*4) < 0) {
perror("ping: record route");
diff --git a/ping6.c b/ping6.c
index 1673937..ce102d0 100644
--- a/ping6.c
+++ b/ping6.c
@@ -1142,18 +1142,21 @@ int build_niquery(__u8 *_nih)
{
struct ni_hdr *nih;
int cc;
+ __u16 this_nonce;
nih = (struct ni_hdr *)_nih;
nih->ni_cksum = 0;
- CLR(ntohs((*(__u16*)(nih->ni_nonce))) % mx_dup_ck);
+ memcpy(&this_nonce, &nih->ni_nonce, sizeof(this_nonce));
+ CLR(ntohs(this_nonce) % mx_dup_ck);
nih->ni_type = ICMPV6_NI_QUERY;
cc = sizeof(*nih);
datalen = 0;
memcpy(nih->ni_nonce, ni_nonce, sizeof(nih->ni_nonce));
- *(__u16*)(nih->ni_nonce) = htons(ntransmitted + 1);
+ this_nonce = htons(ntransmitted + 1);
+ memcpy(&nih->ni_nonce, &this_nonce, sizeof(this_nonce));
nih->ni_code = ni_subject_type;
nih->ni_qtype = htons(ni_query);
@@ -1367,7 +1370,7 @@ parse_reply(struct msghdr *msg, int cc, void *addr, struct timeval *tv)
#endif
if (c->cmsg_len < CMSG_LEN(sizeof(int)))
continue;
- hops = *(int*)CMSG_DATA(c);
+ memcpy(&hops, CMSG_DATA(c), sizeof(int));
}
}
@@ -1391,7 +1394,9 @@ parse_reply(struct msghdr *msg, int cc, void *addr, struct timeval *tv)
return 0;
} else if (icmph->icmp6_type == ICMPV6_NI_REPLY) {
struct ni_hdr *nih = (struct ni_hdr *)icmph;
- __u16 seq = ntohs(*(__u16 *)nih->ni_nonce);
+ __u16 seq;
+ memcpy(&seq, &nih->ni_nonce, sizeof(seq));
+ seq = ntohs(seq);
if (memcmp(&nih->ni_nonce[2], &ni_nonce[2], sizeof(ni_nonce) - sizeof(__u16)))
return 1;
if (gather_statistics((__u8*)icmph, sizeof(*icmph), cc,
diff --git a/tracepath.c b/tracepath.c
index ca84a69..0a14b1b 100644
--- a/tracepath.c
+++ b/tracepath.c
@@ -142,7 +142,7 @@ restart:
if (cmsg->cmsg_type == IP_RECVERR) {
e = (struct sock_extended_err *) CMSG_DATA(cmsg);
} else if (cmsg->cmsg_type == IP_TTL) {
- rethops = *(int*)CMSG_DATA(cmsg);
+ memcpy(&rethops, CMSG_DATA(cmsg), sizeof(int));
} else {
printf("cmsg:%d\n ", cmsg->cmsg_type);
}
diff --git a/tracepath6.c b/tracepath6.c
index 5c2db8f..77a3563 100644
--- a/tracepath6.c
+++ b/tracepath6.c
@@ -170,7 +170,7 @@ restart:
#ifdef IPV6_2292HOPLIMIT
case IPV6_2292HOPLIMIT:
#endif
- rethops = *(int*)CMSG_DATA(cmsg);
+ memcpy(&rethops, CMSG_DATA(cmsg), sizeof(int));
break;
default:
printf("cmsg6:%d\n ", cmsg->cmsg_type);
--
1.7.9.7
^ permalink raw reply related
* [PATCH 3/6] tracepath: fix typo in -l error message
From: Mike Frysinger @ 2012-08-01 15:45 UTC (permalink / raw)
To: YOSHIFUJI Hideaki; +Cc: netdev, Jeroen Roovers
In-Reply-To: <1343835928-21541-1-git-send-email-vapier@gentoo.org>
From: Jeroen Roovers <jer@gentoo.org>
Signed-off-by: Jeroen Roovers <jer@gentoo.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
tracepath.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tracepath.c b/tracepath.c
index 0a14b1b..90e1b28 100644
--- a/tracepath.c
+++ b/tracepath.c
@@ -306,7 +306,7 @@ main(int argc, char **argv)
break;
case 'l':
if ((mtu = atoi(optarg)) <= overhead) {
- fprintf(stderr, "Error: length must be >= %d\n", overhead);
+ fprintf(stderr, "Error: length must be > %d\n", overhead);
exit(1);
}
break;
--
1.7.9.7
^ permalink raw reply related
* [PATCH 5/6] start gitignore files
From: Mike Frysinger @ 2012-08-01 15:45 UTC (permalink / raw)
To: YOSHIFUJI Hideaki; +Cc: netdev
In-Reply-To: <1343835928-21541-1-git-send-email-vapier@gentoo.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
.gitignore | 22 ++++++++++++++++++++++
doc/.gitignore | 2 ++
2 files changed, 24 insertions(+)
create mode 100644 .gitignore
create mode 100644 doc/.gitignore
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..30ed00c
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,22 @@
+*~
+*.o
+
+*.diff
+*.orig
+*.patch
+*.rej
+
+core
+.gdb_history
+.gdbinit
+
+/arping
+/clockdiff
+/ping
+/ping6
+/rarpd
+/rdisc
+/tftpd
+/tracepath
+/tracepath6
+/traceroute6
diff --git a/doc/.gitignore b/doc/.gitignore
new file mode 100644
index 0000000..085639f
--- /dev/null
+++ b/doc/.gitignore
@@ -0,0 +1,2 @@
+*.html
+*.8
--
1.7.9.7
^ permalink raw reply related
* [PATCH 4/6] ping: fix building on older systems
From: Mike Frysinger @ 2012-08-01 15:45 UTC (permalink / raw)
To: YOSHIFUJI Hideaki; +Cc: netdev
In-Reply-To: <1343835928-21541-1-git-send-email-vapier@gentoo.org>
The SO_MARK define is somewhat recent (linux-2.6.25), so check for its
existence before we try to use it.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
ping_common.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/ping_common.c b/ping_common.c
index 287d0e6..6fd252d 100644
--- a/ping_common.c
+++ b/ping_common.c
@@ -486,6 +486,7 @@ void setup(int icmp_sock)
fprintf(stderr, "Warning: no SO_TIMESTAMP support, falling back to SIOCGSTAMP\n");
}
#endif
+#ifdef SO_MARK
if (options & F_MARK) {
if (setsockopt(icmp_sock, SOL_SOCKET, SO_MARK,
&mark, sizeof(mark)) == -1) {
@@ -499,6 +500,7 @@ void setup(int icmp_sock)
#endif
}
}
+#endif
/* Set some SNDTIMEO to prevent blocking forever
* on sends, when device is too slow or stalls. Just put limit
--
1.7.9.7
^ permalink raw reply related
* [PATCH 6/6] doc: fix parallel build of html/man pages
From: Mike Frysinger @ 2012-08-01 15:45 UTC (permalink / raw)
To: YOSHIFUJI Hideaki; +Cc: netdev
In-Reply-To: <1343835928-21541-1-git-send-email-vapier@gentoo.org>
The use of the same tempdir prevents building of these files in parallel.
So build all of them in unique tempdirs so we can do them in parallel.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
doc/Makefile | 37 ++++++++++++++++++++++++-------------
1 file changed, 24 insertions(+), 13 deletions(-)
diff --git a/doc/Makefile b/doc/Makefile
index 7ec4f1c..a9c303e 100644
--- a/doc/Makefile
+++ b/doc/Makefile
@@ -12,29 +12,40 @@ man: $(MANFILES)
# lots of some strange temporary junk directories and files.
# So, scope it to a temporary dir and clean all after each run.
-$(HTMLFILES): index.db
- @-rm -rf tmp.db2html
- @mkdir tmp.db2html
- @set -e; cd tmp.db2html; docbook2html ../$< ; mv *.html ..
- @-rm -rf tmp.db2html
+SETUP_TMPDIR = \
+ t="tmp.db2html.$@"; \
+ rm -rf $$t; \
+ mkdir $$t; \
+ pushd $$t >/dev/null
+CLEAN_TMPDIR = \
+ popd >/dev/null; \
+ rm -rf $$t
+
+MAKE_HTML = \
+ @set -e; \
+ $(SETUP_TMPDIR); \
+ docbook2html ../$<; \
+ mv *.html ..; \
+ $(CLEAN_TMPDIR)
+$(HTMLFILES): index.db
+ $(MAKE_HTML)
iputils.html: iputils.db
- @-rm -rf tmp.db2html
- @mkdir tmp.db2html
- @set -e; cd tmp.db2html; docbook2html -u -o html ../$< ; mv html/$@ ..
- @-rm -rf tmp.db2html
+ $(MAKE_HTML)
# docbook2man produces utterly ugly output and I did not find
# any way to customize this but hacking backend perl script a little.
# Well, hence...
$(MANFILES): index.db
- @-mkdir tmp.db2man
- @set -e; cd tmp.db2man; nsgmls ../$< | sgmlspl ../docbook2man-spec.pl ; mv $@ ..
- @-rm -rf tmp.db2man
+ @set -e; \
+ $(SETUP_TMPDIR); \
+ nsgmls ../$< | sgmlspl ../docbook2man-spec.pl; \
+ mv $@ ..; \
+ $(CLEAN_TMPDIR)
clean:
- @rm -rf $(MANFILES) $(HTMLFILES) iputils.html tmp.db2html tmp.db2man
+ @rm -rf $(MANFILES) $(HTMLFILES) iputils.html tmp.db2html* tmp.db2man*
snapshot:
@date "+%y%m%d" > snapshot.db
--
1.7.9.7
^ permalink raw reply related
* Re: assert_cfg80211_lock warning with Linux v3.5-8833-g2d53492
From: Arend van Spriel @ 2012-08-01 15:51 UTC (permalink / raw)
To: John W. Linville
Cc: Josh Boyer, Johannes Berg, Brett Rudley, Roland Vossen,
linux-wireless, netdev, Seth Forshee
In-Reply-To: <50194D7A.6060400@broadcom.com>
On 08/01/2012 05:38 PM, Arend van Spriel wrote:
>> 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
Diving in further it seems brcmsmac can not grab the cfg80211_mutex. So
another solution is needed.
Gr. AvS
^ 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