lkml.org 
[lkml]   [2007]   [Mar]   [21]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
From(Eric W. Biederman)
SubjectRe: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently
DateWed, 21 Mar 2007 14:17:40 -0600
Adrian Bunk <bunk@stusta.de> writes:

> On Wed, Mar 21, 2007 at 05:43:11PM +0000, Sid Boyce wrote:
>> Sid Boyce wrote:>> >Andrew Morton wrote:>> >>(cc restored.  Please always do reply-to-all)>> >>>> >> >> >>>On Wed, 28 Feb 2007 18:05:13 +0200 auxsvr@gmail.com wrote:
>> >>>On Wednesday 28 February 2007 17:19, Sid Boyce wrote:
>> >>> >> >>>>openSUSE 10.3 Alpha and KDE-3.5.6, xorg-x11-7.2. KDE is setup not to
>> >>>>require a password to unlock, but it asks for password. When the screen
>> >>>>unlocks, kwin is gone with no errors logged in /var/log/kdm or
>> >>>>/var/log/messages. No problems with 2.6.20.>> >>>>>> >>>>Same problem on openSUSE 10.2 x86_64, KDE-3.5.5 and 2.6.21-rc2.
>> >>>>Regards>> >>>>Sid.>> >>>> >> >>>This is the linux kernel mailing list. Perhaps you should post your 
>> >>>problem to the opensuse mailing list.>> >>> >> >>>> >>2.6.20 worked.>> >>>> >>2.6.20-rc2 did not.>> >>>> >>Working theory: the kernel broke.>> >>>> >>Sid, the chances that anyone can work out what caused this are pretty 
>> >>low. It would be great if you could perform a git bisection search 
>> >>sometime in>> >>the next few weeks, work out which commit caused this.
>> >>>> >>Thanks.>> >>>> >>>> >>>> >> >> >I shall go back to 2.6.20-git3 and work forward. Up to 2.6.20-git2 was OK.
>> >Regards>> >Sid.>> >>> >> I tracked the problem down to 2.6.20-git11. Up to 2.6.20-git10 is OK, 
>> but from 2.6.20-git11 up to current 2.6.21-rc4-git2 all exhibit the problem.>> Thanks for this search.>> Looking at the changes between 2.6.20-git10 and 2.6.20-git11, the only 
> suspicious changes are the 60 sysctl patches by Eric.
>> Eric, can you look at this issue?

git bisect between git10 (ac98695d6c1508b724f246f38ce57fb4e3cec356)
and git11 (86a71dbd3e81e8870d0f0e56b87875f57e58222b) is likely the most
productive thing that can be done right now.  

I can't think of anything in my sysctl patches that would kill an
application.  My sysctl work is right on the border with user space
so it is a good candidate but at the same time there should have
been no user visible changes.  There were a few places where
I removed sys_sysctl support (but not /proc/sys support) but I don't
think any of those were on x86, and they were is such a messed up
state I don't think anyone could have reasonably used them anyway.

So I think either we poke blindly making random guess by hand or
we let git-bisect do it.

Sid do you think you can figure out git-bisect?
git-bisect start
git-bisect bad 86a71dbd3e81e8870d0f0e56b87875f57e58222b
git-bisect good ac98695d6c1508b724f246f38ce57fb4e3cec356

It should narrow the problem down to a single commit in 6-8 tries
after which point we should have enough information to start
making intelligent guesses. 

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

\
 
 \ /
  Last update: 2007-03-21 21:25    [from the cache]
©2003-2008