[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080307101504.M78767@visp.net.lb>
Date: Fri, 7 Mar 2008 12:19:03 +0200
From: "Denys Fedoryshchenko" <denys@...p.net.lb>
To: Jarek Poplawski <jarkao2@...il.com>
Cc: jamal <hadi@...erus.ca>, netdev@...r.kernel.org
Subject: Re: circular locking, mirred, 2.6.24.2
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
> 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@...r.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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists