Re: [ipw3945-devel] 2.6.24-rc5-mm1 -- INFO: possible circular locking dependency detected -- pm-suspend/5800 is trying to acquire lock
On Dec 18, 2007 9:58 PM, Zhu Yi [EMAIL PROTECTED] wrote: On Tue, 2007-12-18 at 15:57 +0100, Johannes Berg wrote: Thanks. This is a bug in iwlwifi. The problem is actually another case where my workqueue debugging with lockdep is triggering a warning :)) Here's the thing: iwl3945_cancel_deferred_work does cancel_delayed_work_sync(priv-init_alive_start); (which is the ((priv-init_alive_start)-work) lock) but it is called from within a locked section of mutex_lock(priv-mutex); (locked from iwl3945_pci_suspend) On the other hand, the task that runs from the init_alive_start workqueue is iwl3945_bg_init_alive_start() which will lock the same mutex. So the deadlock condition is that you can be in cancel_delayed_work_sync() above while the mutex is locked, and be waiting for iwl_3945_bg_init_alive_start() which tries to lock the mutex. Thanks for the analysis. Miles, please try the attached patch. I'll send a patch for both 3945 and 4965 to linux-wireless later. I tested it and it looks good here. Thanks! Miles -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
2.6.24-rc5-mm1 -- INFO: possible circular locking dependency detected -- pm-suspend/5800 is trying to acquire lock
I have only seen this happen once, and cannot reproduce it. I'll keep
trying, though.
Dec 16 22:10:48 syntropy kernel: [ 231.718023]
===
Dec 16 22:10:48 syntropy kernel: [ 231.718025] [ INFO: possible
circular locking dependency detected ]
Dec 16 22:10:48 syntropy kernel: [ 231.718028] 2.6.24-rc5-mm1 #7
Dec 16 22:10:48 syntropy kernel: [ 231.718029]
---
Dec 16 22:10:48 syntropy kernel: [ 231.718032] pm-suspend/5800 is
trying to acquire lock:
Dec 16 22:10:48 syntropy kernel: [ 231.718034]
((priv-init_alive_start)-work){--..}, at:
[__cancel_work_timer+0x8a/0x17f] __cancel_work_timer+0x8a/0x17f
Dec 16 22:10:48 syntropy kernel: [ 231.718045]
Dec 16 22:10:48 syntropy kernel: [ 231.718046] but task is already
holding lock:
Dec 16 22:10:48 syntropy kernel: [ 231.718047] (priv-mutex){--..},
at: [f8a587e7] iwl3945_pci_suspend+0x1d/0x65 [iwl3945]
Dec 16 22:10:48 syntropy kernel: [ 231.718065]
Dec 16 22:10:48 syntropy kernel: [ 231.718066] which lock already
depends on the new lock.
Dec 16 22:10:48 syntropy kernel: [ 231.718067]
Dec 16 22:10:48 syntropy kernel: [ 231.718068]
Dec 16 22:10:48 syntropy kernel: [ 231.718069] the existing
dependency chain (in reverse order) is:
Dec 16 22:10:48 syntropy kernel: [ 231.718071]
Dec 16 22:10:48 syntropy kernel: [ 231.718072] - #1 (priv-mutex){--..}:
Dec 16 22:10:48 syntropy kernel: [ 231.718075]
[__lock_acquire+0xa17/0xbf4] __lock_acquire+0xa17/0xbf4
Dec 16 22:10:48 syntropy kernel: [ 231.718083]
[mac80211:lock_acquire+0x76/0x1d8] lock_acquire+0x76/0x9d
Dec 16 22:10:48 syntropy kernel: [ 231.718088]
[pcmcia:mutex_lock_nested+0xf7/0xd7d] mutex_lock_nested+0xf7/0x294
Dec 16 22:10:48 syntropy kernel: [ 231.718096][f8a56ff7]
iwl3945_bg_init_alive_start+0x2d/0x1d7 [iwl3945]
Dec 16 22:10:48 syntropy kernel: [ 231.718109]
[run_workqueue+0xbb/0x18b] run_workqueue+0xbb/0x18b
Dec 16 22:10:48 syntropy kernel: [ 231.718115]
[worker_thread+0xbe/0xcd] worker_thread+0xbe/0xcd
Dec 16 22:10:48 syntropy kernel: [ 231.718121]
[kthread+0x3b/0x61] kthread+0x3b/0x61
Dec 16 22:10:48 syntropy kernel: [ 231.718126]
[kernel_thread_helper+0x7/0x10] kernel_thread_helper+0x7/0x10
Dec 16 22:10:48 syntropy kernel: [ 231.718133][] 0x
Dec 16 22:10:48 syntropy kernel: [ 231.718145]
Dec 16 22:10:48 syntropy kernel: [ 231.718146] - #0
((priv-init_alive_start)-work){--..}:
Dec 16 22:10:48 syntropy kernel: [ 231.718149]
[__lock_acquire+0x93e/0xbf4] __lock_acquire+0x93e/0xbf4
Dec 16 22:10:48 syntropy kernel: [ 231.718155]
[mac80211:lock_acquire+0x76/0x1d8] lock_acquire+0x76/0x9d
Dec 16 22:10:48 syntropy kernel: [ 231.718161]
[__cancel_work_timer+0xb3/0x17f] __cancel_work_timer+0xb3/0x17f
Dec 16 22:10:48 syntropy kernel: [ 231.718167]
[iwl3945:cancel_delayed_work_sync+0xb/0x0d]
cancel_delayed_work_sync+0xb/0xd
Dec 16 22:10:48 syntropy kernel: [ 231.718173][f8a542cb]
__iwl3945_down+0x51/0x310 [iwl3945]
Dec 16 22:10:48 syntropy kernel: [ 231.718184][f8a587f7]
iwl3945_pci_suspend+0x2d/0x65 [iwl3945]
Dec 16 22:10:48 syntropy kernel: [ 231.718196]
[pci_device_suspend+0x1b/0x4b] pci_device_suspend+0x1b/0x4b
Dec 16 22:10:48 syntropy kernel: [ 231.718203]
[device_suspend+0x17e/0x259] device_suspend+0x17e/0x259
Dec 16 22:10:48 syntropy kernel: [ 231.718210]
[suspend_devices_and_enter+0x3d/0x138]
suspend_devices_and_enter+0x3d/0x138
Dec 16 22:10:48 syntropy kernel: [ 231.718217]
[enter_state+0x121/0x17d] enter_state+0x121/0x17d
Dec 16 22:10:48 syntropy kernel: [ 231.718222]
[state_store+0x96/0xac] state_store+0x96/0xac
Dec 16 22:10:48 syntropy kernel: [ 231.718228]
[kobj_attr_store+0x1a/0x22] kobj_attr_store+0x1a/0x22
Dec 16 22:10:48 syntropy kernel: [ 231.718234]
[sysfs_write_file+0xb8/0xe3] sysfs_write_file+0xb8/0xe3
Dec 16 22:10:48 syntropy kernel: [ 231.718242]
[vfs_write+0xa4/0x120] vfs_write+0xa4/0x120
Dec 16 22:10:48 syntropy kernel: [ 231.718248]
[sys_write+0x3b/0x60] sys_write+0x3b/0x60
Dec 16 22:10:48 syntropy kernel: [ 231.718254]
[sysenter_past_esp+0x6b/0xc1] sysenter_past_esp+0x6b/0xc1
Dec 16 22:10:48 syntropy kernel: [ 231.718259][] 0x
Dec 16 22:10:48 syntropy kernel: [ 231.718269]
Dec 16 22:10:48 syntropy kernel: [ 231.718269] other info that might
help us debug this:
Dec 16 22:10:48 syntropy kernel: [ 231.718271]
Dec 16 22:10:48 syntropy kernel: [ 231.718272] 4 locks held by pm-suspend/5800:
Dec 16 22:10:48 syntropy kernel: [ 231.718274] #0:
(buffer-mutex){--..}, at: [sysfs_write_file+0x25/0xe3]
sysfs_write_file+0x25/0xe3
Dec 16 22:10:48 syntropy kernel: [ 231.718280] #1:
(pm_mutex){--..}, at: [enter_state+0x166/0x17d]
enter_state+0x166/0x17d
Dec 16 22:10:48 syntropy kernel: [ 231.718286] #2: (dpm_mtx){--..},
at: [device_suspend+0x2b/0x259] device_suspend+0x2b/0x259
Dec 16 22:10:48 syntropy kernel: [ 231.718291] #3:
(priv-mutex){--..}, at: [f8a587e7]
Re: 2.6.22-rc4-mm2 -- ipw2200 -- SIOCSIFADDR: No buffer space available
On 6/7/07, Björn Steinbrink [EMAIL PROTECTED] wrote:
[...]
Miles, could you try if this patch helps?
Björn
Stop destroying devices when all of their ifas are gone, as we no longer
recreate them when ifas are added.
Signed-off-by: Björn Steinbrink [EMAIL PROTECTED]
--
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index fa97b96..abf6352 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -327,12 +327,8 @@ static void __inet_del_ifa(struct in_device *in_dev,
struct in_ifaddr **ifap,
}
}
- if (destroy) {
+ if (destroy)
inet_free_ifa(ifa1);
-
- if (!in_dev-ifa_list)
- inetdev_destroy(in_dev);
- }
}
static void inet_del_ifa(struct in_device *in_dev, struct in_ifaddr **ifap,
Björn,
Thanks. You patch worked for me.
Miles
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.19-rc5-mm2 -- bcm43xx busted (backing out the bcm43xx patches fixes it)
On 11/15/06, Larry Finger [EMAIL PROTECTED] wrote:
Rafael J. Wysocki wrote:
On Wednesday, 15 November 2006 00:21, Miles Lane wrote:
Hello,
The last three MM kernels have fail to give me a working bcm43xx driver.
The odd thing is that dmesg output seems to indicate that the driver
is working okay. NetworkManager doesn't see the driver, though.
iwlist scan fails to find any access points, too. iwconfig shows
Access Point: invalid.
I can confirm the symptoms, I see them too on my test boxes.
I tried backing out the following patches, and it fixes the problem:
drivers/net/wireless/bcm43xx/bcm43xx.h
drivers/net/wireless/bcm43xx/bcm43xx_main.c
drivers/net/wireless/bcm43xx/bcm43xx_power.c
drivers/net/wireless/bcm43xx/bcm43xx_wx.c
drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
The missing patch is shown below. This patch was entitled [PATCH] bcm43xx:
Readd dropped
assignment and submitted to wireless-2.6 by Daniel Drake on 10/17/06, but it
seems to have fallen
through the cracks. It is a fix to a patch entitled [PATCH] ieee80211: Move
IV/ICV stripping into
ieee80211_rx also submitted by Daniel Drake on 9/26/2006.
NOTE to maintainers: This problem affects BOTH wireless-2.6 and 2.6.19-rcX-mmY.
At present, the
Move IV/ICV patch has not been incorporated into 2.6.19-rcX and it is OK.
Larry
In the patch sent by Daniel Drake under the title [PATCH] ieee80211: Move
IV/ICV stripping into ieee80211_rx, a needed line was accidentally removed.
As my current copy of wireless-2.6.git does not contain this line, I am
(re)submitting a patch to restore that line.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
@@ -543,6 +543,7 @@ int bcm43xx_rx(struct bcm43xx_private *b
break;
}
+ frame_ctl = le16_to_cpu(wlhdr-frame_ctl);
switch (WLAN_FC_GET_TYPE(frame_ctl)) {
case IEEE80211_FTYPE_MGMT:
ieee80211_rx_mgt(bcm-ieee, wlhdr, stats);
Thanks! I have verified that this patch solves the problem for me.
Miles
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-mm1 -- ieee80211: Info elem: parse failed: info_element-len + 2 left : info_element-len+2=28 left=9, id=221.
On 9/27/06, Jesper Juhl [EMAIL PROTECTED] wrote: On 27/09/06, Miles Lane [EMAIL PROTECTED] wrote: On 9/26/06, Andrew Morton [EMAIL PROTECTED] wrote: [added netdev] On Tue, 26 Sep 2006 12:04:40 -0700 Miles Lane [EMAIL PROTECTED] wrote: ieee80211: Info elem: parse failed: info_element-len + 2 left : info_element-len+2=28 left=9, id=221. ieee80211: Info elem: parse failed: info_element-len + 2 left : info_element-len+2=28 left=9, id=221. ieee80211: Info elem: parse failed: info_element-len + 2 left : info_element-len+2=28 left=9, id=221. From dmesg output: ieee80211: 802.11 data/management/control stack, git-1.1.13 ieee80211: Copyright (C) 2004-2005 Intel Corporation [EMAIL PROTECTED] ieee80211_crypt: registered algorithm 'NULL' ieee80211_crypt: registered algorithm 'WEP' ieee80211_crypt: registered algorithm 'CCMP' ieee80211_crypt: registered algorithm 'TKIP' I suspect that whatever caused this is now in mainline. Are you able to test Linus's current git tree? Sorry, I don't have oodles of disk space free to hold all the git historical information (iirc, it's huge). [snip] You could just grab the latest snapshot (at the time of this writing that's 2.6.18-git8) from kernel.org - that way you wouldn't get all the historical git data. Thanks Jesper. I'll test this when I am back in the airport in a few days. I'll add in the packet dump, if it's reproducible with 2.6.18-mm1. Miles - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-mm1 -- ieee80211: Info elem: parse failed: info_element-len + 2 left : info_element-len+2=28 left=9, id=221.
On 9/26/06, Andrew Morton [EMAIL PROTECTED] wrote: [added netdev] On Tue, 26 Sep 2006 12:04:40 -0700 Miles Lane [EMAIL PROTECTED] wrote: ieee80211: Info elem: parse failed: info_element-len + 2 left : info_element-len+2=28 left=9, id=221. ieee80211: Info elem: parse failed: info_element-len + 2 left : info_element-len+2=28 left=9, id=221. ieee80211: Info elem: parse failed: info_element-len + 2 left : info_element-len+2=28 left=9, id=221. From dmesg output: ieee80211: 802.11 data/management/control stack, git-1.1.13 ieee80211: Copyright (C) 2004-2005 Intel Corporation [EMAIL PROTECTED] ieee80211_crypt: registered algorithm 'NULL' ieee80211_crypt: registered algorithm 'WEP' ieee80211_crypt: registered algorithm 'CCMP' ieee80211_crypt: registered algorithm 'TKIP' I suspect that whatever caused this is now in mainline. Are you able to test Linus's current git tree? Sorry, I don't have oodles of disk space free to hold all the git historical information (iirc, it's huge). I could conceivably put it together, but I'd been some help and time. I am currently travelling, but I do have my kernel test laptop with me. Also, I am currently staying in a building running off of solar power, so I need to be a bit careful with power consumption. I'll be in a place with AC power in five days. Lastly, I don't know how I triggered the problem. I am happy to try to reproduce it for you, though. Miles - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-rc4-mm[1,2,3] -- Network card not getting assigned an eth device name
On 8/27/06, David Miller [EMAIL PROTECTED] wrote:
From: Andrew Morton [EMAIL PROTECTED]
Date: Sun, 27 Aug 2006 00:19:43 -0700
Jeremy reported that a while back too. I do not know what is causing it
and as far as I know no net developers have yet looked into it.
A debugging patch like this one should help figure out the culprit.
If we don't see the gibberish netdevice name printed in the kernel
logs, then likely something is corrupting the netdevice structure or
the memory holding the name.
diff --git a/net/core/dev.c b/net/core/dev.c
index d4a1ec3..45f9b19 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -738,6 +738,11 @@ int dev_change_name(struct net_device *d
if (!dev_valid_name(newname))
return -EINVAL;
+#if 1
+ printk([%s:%d]: Changing netdevice name from [%s] to [%s]\n,
+ current-comm, current-pid,
+ dev-name, newname);
+#endif
if (strchr(newname, '%')) {
err = dev_alloc_name(dev, newname);
Dan, do you have any idea why NetworkManager from Ubuntu 6.06.1
would be corrupting network device names on recent MM kernels?
I haven't seen this happening with Ubuntu's kernels. If you like, I can
send you my kernel .config file.
Here's what I get:
[NetworkManager:5399]: Changing netdevice name from [eth0] to [��]
��: link down
ADDRCONF(NETDEV_UP): ��: link is not ready
[NetworkManager:5399]: Changing netdevice name from [eth1] to [7G*e]
7G*e: no IPv6 routers present
Here's the result of strace -f -F -v -a50 NetworkManager:
execve(./NetworkManager.bak, [./NetworkManager.bak],
[TERM=linux, SHELL=/bin/bash, HUSHLOGIN=FALSE,
OLDPWD=/home/miles, USER=root,
LS_COLORS=no=00:fi=00:di=01;34:l..., SUDO_USER=miles,
SUDO_UID=1000, PATH=/usr/local/sbin:/usr/local/...,
MAIL=/var/mail/miles, PWD=/usr/sbin, LANG=en_US.UTF-8,
HISTCONTROL=ignoredups, SUDO_COMMAND=/bin/bash,
HOME=/home/miles, SHLVL=2, LANGUAGE=en_US:en_GB:en,
LOGNAME=root, LESSOPEN=| /usr/bin/lesspipe %s, SUDO_GID=1000,
LESSCLOSE=/usr/bin/lesspipe %s %..., _=/usr/bin/strace]) = 0
uname({sysname=Linux, nodename=Dumbleedor,
release=2.6.18-rc4-mm3, version=#32 Sun Aug 27 01:01:35 PDT 2006,
machine=i686}) = 0
brk(0)= 0x808b000
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb7f8a000
access(/etc/ld.so.nohwcap, F_OK)= -1 ENOENT (No such
file or directory)
old_mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb7f88000
access(/etc/ld.so.preload, R_OK)= -1 ENOENT (No such
file or directory)
open(/etc/ld.so.cache, O_RDONLY)= 3
fstat64(3, {st_dev=makedev(3, 10), st_ino=195836,
st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096,
st_blocks=216, st_size=102666, st_atime=2006/08/28-00:34:02,
st_mtime=2006/08/25-22:58:56, st_ctime=2006/08/25-22:58:56}) = 0
old_mmap(NULL, 102666, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f6e000
close(3) = 0
access(/etc/ld.so.nohwcap, F_OK)= -1 ENOENT (No such
file or directory)
open(/usr/lib/libhal.so.1, O_RDONLY)= 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\\36\0..., 512) = 512
fstat64(3, {st_dev=makedev(3, 10), st_ino=830757,
st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096,
st_blocks=64, st_size=30448, st_atime=2006/08/28-00:34:02,
st_mtime=2006/05/22-08:09:25, st_ctime=2006/07/05-21:10:31}) = 0
old_mmap(NULL, 33464, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE,
3, 0) = 0xb7f65000
old_mmap(0xb7f6d000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7000) = 0xb7f6d000
close(3) = 0
access(/etc/ld.so.nohwcap, F_OK)= -1 ENOENT (No such
file or directory)
open(/lib/libiw.so.28, O_RDONLY)= 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\25..., 512) = 512
fstat64(3, {st_dev=makedev(3, 10), st_ino=814477,
st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096,
st_blocks=48, st_size=23228, st_atime=2006/08/28-00:34:02,
st_mtime=2006/02/09-15:38:09, st_ctime=2006/07/05-21:19:53}) = 0
old_mmap(NULL, 26188, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE,
3, 0) = 0xb7f5e000
old_mmap(0xb7f64000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x5000) = 0xb7f64000
close(3) = 0
access(/etc/ld.so.nohwcap, F_OK)= -1 ENOENT (No such
file or directory)
open(/usr/lib/libnl.so.1, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\\236..., 512) = 512
fstat64(3, {st_dev=makedev(3, 10), st_ino=831039,
st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096,
st_blocks=368, st_size=180452, st_atime=2006/08/28-00:34:03,
st_mtime=2006/03/22-05:46:12, st_ctime=2006/03/29-09:41:12}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE,
Re: [PATCH] ipw2200: support WEXT-18 enc_capa v3
On 1/25/06, Zhu Yi [EMAIL PROTECTED] wrote: [PATCH] ipw2200: support WEXT-18 enc_capa v3 Dan Williams added a corresponding patch to IPW2100. This patch does the same thing for ipw2200. Signed-off-by: Miles Lane [EMAIL PROTECTED] Signed-off-by: Zhu Yi [EMAIL PROTECTED] This patch is still missing from Linus' tree. Is this going to make it soon? Thanks, Miles - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
