linux-kernel - Re: Planet CCRMA rt kernel errors (Real-time kernel)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Fri, 20 Jan 2012 12:01:21 +0100
From:	John Kacur <jkacur@...hat.com>
To:	"William M. Quarles" <walrus@...lsouth.net>
Cc:	linux-rt-users@...r.kernel.org,
	Fernando Lopez-Lezcano <nando@...ma.stanford.edu>,
	planetccrma <planetccrma@...ma.stanford.edu>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Planet CCRMA rt kernel errors (Real-time kernel)

On Wed, Jan 11, 2012 at 9:35 PM, William M. Quarles
<walrus@...lsouth.net> wrote:
> Hello linux-rt-users list,
>
> Fernando at CCRMA asked me to forward these bugs on to you. I hope that you can
> find the information useful.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=773169
> https://bugzilla.redhat.com/show_bug.cgi?id=773170

Note, the above bugs were closed because they shouldn't have been
reported there in the first place, so it would have been nice if you
had taken the time to write two emails with the text of your problems
instead of pointing us there. You are more likely to get a response
that way. You also need to report the exact kernel versions.
Never-the-less:

I'll ignore the first bug for now, but ask you to retest when the
newest v3.0.14-rt32 is available. (Assuming this is the kernel version
you're working with, v3.0-rt, else let us know)

As for the second "bug", with MAX_STACK_TRACE_ENTRIES, this is a known
problem. If you don't care about lockdep, then you can ignore the
message, it won't harm anything it's just reporting that lockdep is
being disabled, but if you don't care about lockdep, you can also
disable it at config time.

You can also try to find this variable and up the number of trace
entries that are allowed, in fact I do this quite often. However, it
can be a game of whack-a-mole, because you up that value, and then
reach the max of another value, and then you have to up that too. It
is also possible to up everything so high that you will no-longer get
good rt performance.

Thanks
John
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/