Adrian Bunk <bunk@xxxxxxxxx> writes:Reading the manpage doesn't help, so I shall have to delve into the docs or futher help is needed.
On Wed, Mar 21, 2007 at 05:43:11PM +0000, Sid Boyce wrote:
Sid Boyce wrote:Thanks for this search.
Andrew Morton wrote: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.
(cc restored. Please always do reply-to-all)I shall go back to 2.6.20-git3 and work forward. Up to 2.6.20-git2 was OK.
On Wed, 28 Feb 2007 18:05:13 +0200 auxsvr@xxxxxxxxx wrote:2.6.20 worked.
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 toThis is the linux kernel mailing list. Perhaps you should post your problem to the opensuse mailing list.
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.
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.
Regards
Sid.
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