Re: BUG: scheduling while atomic: ifconfig/0x00000002/4170

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Satyam Sharma
Date: Wednesday, September 5, 2007 - 10:02 pm

Hi,



-currentgit would be -rc5 right?



Is this reproducible? Also, please send your .config.

BTW the calltrace below shows that eth1 was the wireless interface when
you tried to "down" it.



I don't think the "scheduling while atomic" bug you saw is related to
the other problem you're seeing ... these are probably a bunch of all
different issues, but I'm not sure if eth1394 is involved at all.



True, messed up it indeed is.



Cc'ing ipw3945 ...




iwl3945 is wmaster0





These look like interesting bits here ... sysfs_create_symlink() failed
with the infamous -EEXIST. Those were actually two different calls to
dev_change_name()->device_rename()->sysfs_create_symlink() it appears.

If this is reproducible, please rebuild with a kernel with debugging
config options enabled and reproduce.



But did this wmaster0 -> eth1 actually succeed, is the question.








Probably tangential, but Herbert, is the call to synchronize_rcu() in
dev_deactivate() really correct?

I saw that you put it in commit d4828d85d188dc70 about a year back
and it's supposed to ensure that all outstanding transmissions from
dev_queue_xmit() are over before proceeding. However, I think it may not
serve that purpose -- as the comment before synchronize_rcu() and its
use of call_rcu() [and not of call_rcu_bh()] indicate, synchronize_rcu()
is used to synchronize with all outstanding rcu_read_lock() uses. OTOH,
dev_queue_xmit() uses rcu_read_lock_*bh*() which isn't really the same --
bh / non-bh RCU callbacks have separate lists in the RCU implementation,
so I don't really see anything preventing old transmissions to remain
outstanding even after the synchronize_rcu() call in dev_deactivate (?)

Whether that has anything to do with this particular bug or not,
I have no idea ...



Unrelated, but I also wish the "BUG: scheduling while atomic" was the more
instructive show_regs() trace and not a dump_stack() ... I'll make such a
patch today itself.
-
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
BUG: scheduling while atomic: ifconfig/0x00000002/4170, Florian Lohoff, (Sun Sep 2, 11:44 am)
Re: BUG: scheduling while atomic: ifconfig/0x00000002/4170, Michal Piotrowski, (Sun Sep 2, 4:59 pm)
Re: BUG: scheduling while atomic: ifconfig/0x00000002/4170, Satyam Sharma, (Wed Sep 5, 10:02 pm)
Re: BUG: scheduling while atomic: ifconfig/0x00000002/4170, Paul E. McKenney, (Thu Sep 6, 8:46 am)
Re: BUG: scheduling while atomic: ifconfig/0x00000002/4170, Paul E. McKenney, (Fri Sep 7, 7:25 am)
[RFC] mac80211: fix virtual interface locking, Johannes Berg, (Fri Sep 7, 7:38 am)
Re: BUG: scheduling while atomic: ifconfig/0x00000002/4170, Johannes Berg, (Thu Sep 13, 12:16 am)