Re: [Patch] restore the RCU callback to defer put_task_struct() Re: Problems with 2.6.17-rt8

[Bill Huey (hui) <billh@gnuppy.monkey.org>]

On Mon, Aug 14, 2006 at 10:56:39AM -0700, Robert Crocombe wrote:
> I assume that replies were trimmed on accident, so I have resplattered 
> everyone.
> 
> On 8/11/06, hui Bill Huey <billh@gnuppy.monkey.org> wrote:
> >Can you try it without RAID ? do you have a RAID set up ? You have tons
> >of options turned on in your .config, if you can isolate the problematic
> >system that, would be helpful to me since I don't have a lot of hardware.
> 
> Boo, I thought my config was pretty concise :(.  Okay, I really
> chopped it this time.
> 
> And yeah, it is a RAID config.  But for extra bonus points, I found a
> spare SCSI disk and installed Fedora Core 5 and did a 'yum upgrade' to
> whatever was current as of today.  So it's a single disk config now.
> Problem still occurs with 't2' patched kernel.
> 
> config and dmesg attached, kaboom-like stuff appended.

It looks like a screw interaction between the latency tracer and the mutex
code that creates such a wacked out looking stack trace. Unfortunately,
I've been unsuccessful at reproducing it, so I'm going to focus on a partial
clean up so that the rtmutex is a bit more friendly to the latency tracer.

This is kind of a pain.

You have all sorts of strange things going on in that config like NUMA
emulation and stuff which I can't imagine why you'd have that on, 1000
a sec tick, etc... If you can do a bit of work and narrow which option
is it, then I might be able to reproduce the situation over here. I'm
bothered by that bug, but it's going to need to be attacked from a couple
angles, two of which I just mentioned. If I can get a bit of help from
you where I can isolate the subsystem, it would be helpful while I'll
examine the tracing here.

bill