2006-11-28 18:11:25

by Fernando Lopez-Lezcano

[permalink] [raw]
Subject: 2.6.19-rc6-rt7: Kernel BUG at kernel/rtmutex.c:672

(testing -rt8 but just in case)

I got this overnight, found the machine catatonic this morning, machine
is an Athlon X2 4400 running FC6 x86_64 booting into a rebuilt
2.6.19-rc6-rt7 rpm package based on Ingo's packages (same .config except
for 4KSTACKS=off). I'm including a dmesg after the reboot and the bug
traces.

(a normal non-root user was left logged in and was running jackd with
realtime privileges, irqs' priority reordered with the rtirq script - I
was getting, and still are under -rt8, lots of audio xruns but that's
for another thread).

-- Fernando


Attachments:
msg.1 (15.68 kB)
dmesg.1 (24.93 kB)
Download all attachments

2006-11-28 20:08:11

by Ingo Molnar

[permalink] [raw]
Subject: Re: 2.6.19-rc6-rt7: Kernel BUG at kernel/rtmutex.c:672


* Fernando Lopez-Lezcano <[email protected]> wrote:

> (a normal non-root user was left logged in and was running jackd with
> realtime privileges, irqs' priority reordered with the rtirq script -
> I was getting, and still are under -rt8, lots of audio xruns but
> that's for another thread).

do you get those xruns even with maxcpus=1? I.e. is it an SMP-only
regression - or is UP affected too? [if it's UP then it would be simpler
to trace that xrun]

Ingo

2006-11-28 20:07:22

by Ingo Molnar

[permalink] [raw]
Subject: Re: 2.6.19-rc6-rt7: Kernel BUG at kernel/rtmutex.c:672


* Fernando Lopez-Lezcano <[email protected]> wrote:

> Nov 28 03:26:39 localhost kernel: Kernel BUG at kernel/rtmutex.c:672

hm, this means the lock was taken twice by the same task: enabling
CONFIG_PROVE_LOCKING ought to tell us the precise locking info and
backtraces that causes this situation. I looked at the code and it wasnt
obvious at first sight. (we should only be holding cache_chain_mutex
here, and l3->list_lock should not be taken at this point.)

Ingo

2006-11-28 21:36:23

by Fernando Lopez-Lezcano

[permalink] [raw]
Subject: Re: 2.6.19-rc6-rt7: Kernel BUG at kernel/rtmutex.c:672

On Tue, 2006-11-28 at 21:06 +0100, Ingo Molnar wrote:
> * Fernando Lopez-Lezcano <[email protected]> wrote:
>
> > (a normal non-root user was left logged in and was running jackd with
> > realtime privileges, irqs' priority reordered with the rtirq script -
> > I was getting, and still are under -rt8, lots of audio xruns but
> > that's for another thread).
>
> do you get those xruns even with maxcpus=1? I.e. is it an SMP-only
> regression - or is UP affected too? [if it's UP then it would be simpler
> to trace that xrun]

It appears to be smp related, I just booted with maxcpus=1 and I'm
seeing a lot less in terms of xruns (three so far in the range 0.029 to
0.041 ms).

-- Fernando