Ok, i will proceed and will try all required options after few hours (need to 
go another city, work).
I will try to set max as possible debug options.

On bug_feb.txt it is triggering ONLY lockdep warning, but full network lockup 
occur very rarely. But even it happens with me 2 times, i am not sure it is 
same problem. Let's stick maybe to this one (lockdep warning) which is easy 
to reproduce.
I will open also bugzilla report.

Regarding testing with compiled in modules, i did
CONFIG_IFB=y 
CONFIG_DUMMY=y
CONFIG_BONDING=y
CONFIG_MACVLAN=y 
CONFIG_EQUALIZER=y
CONFIG_TUN=y

It is still triggering lockdep.
Here is full dmesg:
http://www.nuclearcat.com/files/dmesg_1234.txt



On Fri, 7 Mar 2008 09:31:50 +0000, Jarek Poplawski wrote
quoted text
> On Fri, Mar 07, 2008 at 01:43:33AM +0200, Denys Fedoryshchenko wrote:
> > About reproducing, I think .config matter
> > Mine is at http://www.nuclearcat.com/files/config.txt
> 
> I see: CONFIG_4KSTACKS=y  but CONFIG_DEBUG_STACKOVERFLOW is not set.
> This doesn't look safe to me... And can trigger really strange things.
> 
> Probably dmesg could be interesting too. And since it all takes place
> and can change in time, I wonder if it isn't better to open a report
> in bugzilla for this. Of course, you should remember to mask any
> confidential information.
> 
> I'm also not sure this: 
> http://www.nuclearcat.com/files/bug_feb.txt
> is a full script (no more ifbs?) or an example. Doesn't "magic sysrq"
> work during such lockups?
> 
> Denys, there were some reports on similar problems with ifb on SMP,
> but this was hard to trigger and debugging stopped for some reason.
> It seems there were some timer OOPSes, but this could be because
> wrong locking too. This could be even because some other apps can't
> handle their lost net traffic. Without some good log traces this 
> could be impossible to tell. And such debugging shouldn't be done at 
> production of course: it's really hard to foresee any locking 
> changes. So, until you are willing to respond to our proposals and 
> try the patches I can see no problem with assisting this problem.
> 
> BTW, probably it's easier to stick to one kernel version, so maybe
> 2.6.24.3 isn't a bad choice if 2.6.25-rc4 didn't help at all.
> 
> Regards,
> Jarek P.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html