Re: circular locking, mirred, 2.6.24.2

[Jarek Poplawski <jarkao2@gmail.com>]

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.