linux-kernel - Re: [ANNOUNCE] 3.6.11.1-rt32

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>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <516B1BF9.3000002@osadl.org>
Date:	Sun, 14 Apr 2013 23:13:29 +0200
From:	Carsten Emde <C.Emde@...dl.org>
To:	Steven Rostedt <rostedt@...dmis.org>
CC:	LKML <linux-kernel@...r.kernel.org>,
	RT <linux-rt-users@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	John Kacur <jkacur@...hat.com>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Subject: Re: [ANNOUNCE] 3.6.11.1-rt32

Hi Steven,

>>> I'm pleased to announce the 3.6.11.1-rt32 stable release.
>> Unfortunately, there is another compile error:
>> drivers/gpu/drm/i915/i915_gem.c: In function ‘i915_gem_wait_for_error’:
>> drivers/gpu/drm/i915/i915_gem.c:118:3: warning: passing argument 1 of
>> ‘rt_spin_lock’ from incompatible pointer type [enabled by default]
>> In file included from include/linux/spinlock.h:273:0,
>>                    from include/linux/wait.h:24,
>>                    from include/linux/fs.h:396,
>>                    from include/drm/drmP.h:47,
>>                    from drivers/gpu/drm/i915/i915_gem.c:28:
>> [..]
>> I would propose to adopt the mechanism that Sebastian introduced in
>> 3.8.4-rt2 (https://lkml.org/lkml/2013/3/26/600). The kernel compiles
>> and runs without any problem with the below patch on a system that
>> requires the i915 driver module.
> Thanks Carsten, I'll be updating this later today.
Thank you.

> BTW, did you get any core dumps from the work queue race that we've
> been seeing?
No, not yet. Originally, the farm systems did not use crashkernels by
default. I understood that it does no harm but could help in cases like
this one. Therefore, I've started to reconfigure all farm system with
crashkernels - starting with the two systems that had the work queue
race crashes. The kernel messages here (one is a 12-core, the other one
a 32-core box) look exactly like the one 
(https://lkml.org/lkml/2013/3/18/325)
you saw in your 40-core machine (https://lkml.org/lkml/2013/3/18/430).
We'll need to wait for the next crash that will give us a core dump we
may then dissect.

	-Carsten.
--
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/