On Fri, Sep 27, 2013 at 09:01:58PM +0200, Zdenek Kabelac wrote: >Dne 27.9.2013 18:01, Veaceslav Falico napsal(a): >>On Fri, Sep 27, 2013 at 09:58:28AM -0600, Bjorn Helgaas wrote: >>>[+cc Veaceslav, linux-pci] >>> >>>On Fri, Sep 27, 2013 at 7:34 AM, Zdenek Kabelac <[email protected]> wrote: >>>>Hi >>>> >>>>With recent build of 3.12-rc2 I'm getting this warning report from kernel: >>>>(hw Lenovo T61, C2D, 4GB Ram) >>>>(repost since linux-kernel@ rejected my gmail email....) >>> >>>This looks related to the MSI/kobject issues Veaceslav is working on. >>>See >>>http://lkml.kernel.org/r/[email protected] >>>and related messages. >>> >>>We don't have a resolution yet. If you have >>>CONFIG_DEBUG_KOBJECT_RELEASE=y, you could try turning that off. I >>>don't know if it would help, and it would only be a temporary >>>workaround anyway. >> >>I've looked at the original post - >>http://www.mail-archive.com/[email protected]/msg510798.html >>hope that's it - and it seems that it's disabling DEBUG_KOBJECT_RELEASE >>won't help - the warning is about the re-registering, not about freeing it. >> >>As a workaround I'd suggest adding some kind of delay between removing and >>adding the msi - as in - rmmod e1000e; sleep 1; modprobe e1000e; - or >>something like that, so that there is enough time for the /msqi_irqs/ to go >>away. >> > >I'm not readding e1000e modules myself - however I've no idea what >NetworkManager does. Here are messages prior warning: > >NetworkManager[304]: <info> monitoring kernel firmware directory >'/lib/firmware'. >NetworkManager[304]: <info> rfkill1: found WiFi radio killswitch (at >/sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/ieee80211/phy0/rfkill1) >(driver iwl3945) >NetworkManager[304]: <info> WiFi hardware radio set enabled >NetworkManager[304]: <info> WiFi enabled by radio killswitch; enabled >by state file >NetworkManager[304]: <info> WWAN enabled by radio killswitch; >disabled by state file >NetworkManager[304]: <info> WiMAX enabled by radio killswitch; >enabled by state file >NetworkManager[304]: <info> Networking is enabled by state file >NetworkManager[304]: <info> (eth0): carrier is OFF >NetworkManager[304]: <info> (eth0): new Ethernet device (driver: >'e1000e' ifindex: 2) >NetworkManager[304]: <info> (eth0): exported as >/org/freedesktop/NetworkManager/Devices/0 >NetworkManager[304]: <info> (eth0): device state change: unmanaged -> >unavailable (reason 'managed') [10 20 2] >NetworkManager[304]: <info> (eth0): bringing up device. >rpcbind: cannot create socket for udp6 >rpcbind: cannot create socket for tcp6 >kernel: [ 5.727025] WARNING! power/level is deprecated; use >power/control instead > > >So it looks like 'bringing up' causes recreation of msi_irqs ?
Yep, seems like that. .ndo_stop() (e1000_close(), which removes msi irqs and the /msi_irqs/ kset) instantly followed by .ndo_open() (e1000_open(), which enables the requested msi irqs via pci_enable_msi() - and, consequently, re-creates the /msi_irqs/ kset) triggers it - because the kset, in the meanwhile, isn't freed - maybe because of some readers, maybe because of the delay introduced by DEBUG_KOBJECT_RELEASE. I'm now slowly fighting this (and adjacent) issues, will put you on CC if I'll come up with patches. In the meanwhile - can you please try disabling DEBUG_KOBJECT_RELEASE and test if you see the warning _constantly_? Cause if you do - we might have another issue here... > >Zdenek > > > > > ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk _______________________________________________ E1000-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
