Eric W. Biederman wrote:
Adrian Bunk <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 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
Reading the manpage doesn't help, so I shall have to delve into the
docs or futher help is needed.
:/usr/src/linux-2.6.20-git11 # git-bisect good
ac98695d6c1508b724f246f38ce57fb4e3cec356
No revs to be shown.
:/usr/src/linux-2.6.20-git11 # ls .git/refs/bisect/
bad
good-ac98695d6c1508b724f246f38ce57fb4e3cec356
:/usr/src/linux-2.6.20-git11 # less
.git/refs/bisect/good-ac98695d6c1508b724f246f38ce57fb4e3cec356
ac98695d6c1508b724f246f38ce57fb4e3cec356
:/usr/src/linux-2.6.20-git11 # less .git/refs/bisect/bad
86a71dbd3e81e8870d0f0e56b87875f57e58222b
Regards
Sid.
--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist,
Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
