Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently

Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently

[Sid Boyce]

Avi Kivity wrote:
>
> 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.
> > >
> > > Regards
> > That's very much appreciated. The point is that all vanilla kernels up
> > to 2.6.20+ have not had the problems now seen on 2.6.20-rc1 and
> > 2.6.20-rc2 and like other problems reported, sic framebuffer, etc.,
> > there is a distinct likelihood that it's related to those kernels and
> > worth reporting here where it will also be seen by the openSUSE kernel
> > developers.
>
> Try running an strace on kwin and reporting the result.
>
>
> -- 
> Do not meddle in the internals of kernels, for they are subtle and 
> quick to panic.
>
Modified /opt/kde3/bin/startkde as below, but got no output, not even an 
empty file.
strace -s 256 -f kwin --lock -o /home/lancelot/KWIN.out &
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

Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently

[Avi Kivity]

Sid Boyce wrote:
>> > That's very much appreciated. The point is that all vanilla kernels up
>> > to 2.6.20+ have not had the problems now seen on 2.6.20-rc1 and
>> > 2.6.20-rc2 and like other problems reported, sic framebuffer, etc.,
>> > there is a distinct likelihood that it's related to those kernels and
>> > worth reporting here where it will also be seen by the openSUSE kernel
>> > developers.
>>
>> Try running an strace on kwin and reporting the result.
>>
>>
> Modified /opt/kde3/bin/startkde as below, but got no output, not even 
> an empty file.
> strace -s 256 -f kwin --lock -o /home/lancelot/KWIN.out &

Perhaps that line is never executed.

Try running kwin from your konsole after it dies, with the strace of 
course. Oh, and put the '-o ...' before the kwin command, not after.


-- 
error compiling committee.c: too many arguments to function

Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently

[Sid Boyce]

Avi Kivity wrote:
> Sid Boyce wrote:
>>> > That's very much appreciated. The point is that all vanilla 
>>> kernels up
>>> > to 2.6.20+ have not had the problems now seen on 2.6.20-rc1 and
>>> > 2.6.20-rc2 and like other problems reported, sic framebuffer, etc.,
>>> > there is a distinct likelihood that it's related to those kernels and
>>> > worth reporting here where it will also be seen by the openSUSE 
>>> kernel
>>> > developers.
>>>
>>> Try running an strace on kwin and reporting the result.
>>>
>>>
>> Modified /opt/kde3/bin/startkde as below, but got no output, not even 
>> an empty file.
>> strace -s 256 -f kwin --lock -o /home/lancelot/KWIN.out &
>
> Perhaps that line is never executed.
>
> Try running kwin from your konsole after it dies, with the strace of 
> course. Oh, and put the '-o ...' before the kwin command, not after.
>
>

Oops!, above text should read the same as the subject line,  problems 
seen on 2.6.21-rc1 and 2.6.21-rc2.
The strace is huge 2737627 2007-03-02 03:28 KWIN.out.  Further digging 
shows kwin, kicker and klauncher and perhaps other kdeinit stuff also 
die - no desktop icons after those 3 are started from the commandline. 
Moving kdesktop_lock out of /opt/kde3/bin, everything comes back after 
the video is blanked -- no password required.
I shall run like that (2.6.21-rc2-git1 currently) and wait for openSUSE 
to upgrade to 2.6.21. I can send the straces of kicker and kwin on if 
you think it's still worth it.
Thanks and 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

Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently

[Sid Boyce]

Avi Kivity wrote:
>
> Sid Boyce wrote:
> > Avi Kivity wrote:
> >> Sid Boyce wrote:
> >>>> > That's very much appreciated. The point is that all vanilla
> >>>> kernels up
> >>>> > to 2.6.20+ have not had the problems now seen on 2.6.20-rc1 and
> >>>> > 2.6.20-rc2 and like other problems reported, sic framebuffer, 
> etc.,
> >>>> > there is a distinct likelihood that it's related to those kernels
> >>>> and
> >>>> > worth reporting here where it will also be seen by the openSUSE
> >>>> kernel
> >>>> > developers.
> >>>>
> >>>> Try running an strace on kwin and reporting the result.
> >>>>
> >>>>
> >>> Modified /opt/kde3/bin/startkde as below, but got no output, not
> >>> even an empty file.
> >>> strace -s 256 -f kwin --lock -o /home/lancelot/KWIN.out &
> >>
> >> Perhaps that line is never executed.
> >>
> >> Try running kwin from your konsole after it dies, with the strace of
> >> course. Oh, and put the '-o ...' before the kwin command, not after.
> >>
> >>
> >
> > Oops!, above text should read the same as the subject line,  problems
> > seen on 2.6.21-rc1 and 2.6.21-rc2.
> > The strace is huge 2737627 2007-03-02 03:28 KWIN.out.  Further digging
> > shows kwin, kicker and klauncher and perhaps other kdeinit stuff also
> > die - no desktop icons after those 3 are started from the commandline.
> > Moving kdesktop_lock out of /opt/kde3/bin, everything comes back after
> > the video is blanked -- no password required.
> > I shall run like that (2.6.21-rc2-git1 currently) and wait for
> > openSUSE to upgrade to 2.6.21. I can send the straces of kicker and
> > kwin on if you think it's still worth it.
>
> Post the last few lines of the strace.
>
>
> -- 
> Do not meddle in the internals of kernels, for they are subtle and 
> quick to panic.
>
 From kwin, the exit was caused by me doing CTRL-ALT-BKSPC after the 
kdeinit stuff had exited.
=============================================================
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  gettimeofday({1172806052, 373523}, NULL) = 0
7670  gettimeofday({1172806052, 373583}, NULL) = 0
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  select(4, [3], [3], NULL, NULL)   = 1 (out [3])
7670  writev(3, [{"\22\0\17\0q\0@\0#\0\0\0#\0\0\0 
\0\0\0\t\0\0\0C\0\0\0\1\0\0\0\1\0\0\0\244\334\4\10\364\237}\267\230\r\304\277\220\200`\267\244\334\4\10\2\0
@\0\22\0\7\0q\0@\0\365\0\0\0\6\0\0\0 
\0\0\0\1\0\0\0\364\346H\0\10\0\2\0q\0@\0\10\0\2\0\33\0@\0\10\0\2\0\34\0@\0\10\0\2\0\7\0\300\0\22\0\7\0\v\0\0\1\0\1\0\0\4
\0\0\0 
\0\0\0\1\0\0\0\177\1\0\0\10\0\2\0t\5@\0\10\0\2\0u\5@\0\10\0\2\0\v\0\0\1\22\0\7\0009\1\0\0k\1\0\0!\0\0\0 
\0\0\0\1\0\0\0\0\0\0\0\35\0\3\0u\5@\0\0\200\0\
0\34\0\6\0u\5@\0\4\0\0\1\0\0\0\0\0\0\0\0\0\0\0\200"..., 320}], 1) = 320
7670  read(3, 
"\34\227\226@9\1\0\0\222\1\0\0\217\313J\0\0\1\0\0\2\0\0\0\0\0\0\0009\1\0\0\34\275\227@q\0@\0#\0\0\0\217\313J\0\0\0\0\0\2\0\0\0\0\0\0\0q\0@\0\34
\275\230@q\0@\0\365\0\0\0\217\313J\0\0\0\0\0\2\0\0\0\0\0\0\0q\0@\0\23Z\231@q\0@\0q\0@\0\0\275j\10\370Y\227\277\214\33\t\10\200\275j\10q\0@\0\23Z\232@\33\0@\0
\33\0@\0\0\275j\10\370Y\227\277\214\33\t\10\200\275j\10\33\0@\0\23Z\232@9\1\0\0\33\0@\0\0\275j\10\370Y\227\277\214\33\t\10\200\275j\10\33\0@\0\f\6\232@q\0@\0
\27\0\0\0\326\5\27\0\3\0\34\10\0\0\0\0\250X\227"..., 4096) = 1280
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 
"\34N\246@\7\0\300\0E\1\0\0\222\313J\0\0\1\0\0\2\0\0\0\0\0\0\0\7\0\300\0", 
4096) = 32
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  select(4, [3], [3], NULL, NULL)   = 1 (out [3])
7670  writev(3, [{"\24\0\6\0\357\0\340\0u\0\0\0u\0\0\0\0\0\0\0\1\0\0\0", 
24}], 1) = 24
7670  select(4, [3], [], NULL, NULL)    = 1 (in [3])
7670  read(3, "\1 
\247@\1\0\0\0u\0\0\0\4\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0", 
4096) = 36
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  select(4, [3], [3], NULL, NULL)   = 1 (out [3])
7670  writev(3, 
[{"\24\0\6\0\357\0\340\0\0\1\0\0\4\0\0\0\0\0\0\0\0\10\0\0", 24}], 1) = 24
7670  select(4, [3], [], NULL, NULL)    = 1 (in [3])
7670  read(3, "\1 
\250@\2\0\0\0\4\0\0\0\0\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\202\1\0\0|\1\0\0", 
4096) = 40
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  select(4, [3], [3], NULL, NULL)   = 1 (out [3])
7670  writev(3, [{"\24\0\6\0\7\0\300\0u\0\0\0u\0\0\0\0\0\0\0\1\0\0\0", 
24}], 1) = 24
7670  select(4, [3], [], NULL, NULL)    = 1 (in [3])
7670  read(3, "\1 
\251@\1\0\0\0u\0\0\0\4\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0", 
4096) = 36
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  select(4, [3], [3], NULL, NULL)   = 1 (out [3])
7670  writev(3, 
[{"\24\0\6\0\7\0\300\0\0\1\0\0\4\0\0\0\0\0\0\0\0\10\0\0", 24}], 1) = 24
7670  select(4, [3], [], NULL, NULL)    = 1 (in [3])
7670  read(3, "\1 
\252@\2\0\0\0\4\0\0\0\0\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\r\1\0\0%\1\0\0", 
4096) = 40
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  select(4, [3], [3], NULL, NULL)   = 1 (out [3])
7670  writev(3, 
[{"\24\0\6\0\7\0\300\0E\1\0\0001\1\0\0\0\0\0\0\240\206\1\0", 24}], 1) = 24
7670  select(4, [3], [], NULL, NULL)    = 1 (in [3])
7670  read(3, 
"\1\10\253@\1\0\0\0001\1\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0000\1\0\0", 
4096) = 36
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  select(4, [3], [3], NULL, NULL)   = 1 (out [3])
7670  writev(3, 
[{";\3\v\0*\0@\0\0\0\0\0\27\0\0\0\326\5\27\0\4\6\0\0\1\0\27\0\34\6\0\0\r\0\27\0\0\0\27\0@\6\231\4\234\6\v\0>\1@\0\0\0\0\0\27\0\0\0\326\5\27\0
\4\6\0\0\1\0\27\0\34\6\0\0\r\0\27\0\0\0\27\0@\6\231\4;\3\v\0002\0@\0\0\0\0\0\27\0\0\0\326\5\27\0\4\6\0\0\1\0\27\0\34\6\0\0\r\0\27\0\0\0\27\0@\6\231\0048\3\7\
0002\0@\0\0005\0\0\0\0\0\0n\0@\0\0\0\0\0\0\0\0\0008\3\5\0002\0@\0\0!\0\0\1\0\0\0\374\377\377\377F\0\5\0q\0@\0002\0@\0\0\0\0\0@\6\30\0008\3\6\0002\0@\0\0%\0\0
\0\0\0\0r\5@\0\0\0\0\0008\3\6\0002\0@\0\0001\0\0\1"..., 284}], 1) = 284
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  select(4, [3], [3], NULL, NULL)   = 1 (out [3])
7670  writev(3, 
[{"F\5\5\0v\0@\0P\0@\0\0\0\0\0\27\0\27\0008\5\4\0*\0@\0\0\0\10\0\0\0\0\0005\30\4\0\0\10@\0009\1\0\0\27\0\27\0\234\4\5\0\1\10@\0\0\10@\0\344\0
\0\0\0\0\0\0008\4\4\0*\0@\0\0\4\0\0n\0@\0008\4\5\0*\0@\0\0!\0\0\1\0\0\0\374\377\377\377F\377\5\0\0\10@\0*\0@\0\0\0\0\0\27\0\27\0B\4\5\0\0\10@\0y\0@\0\0\0\2\0
\0\0\24\0B\4\5\0\0\10@\0y\0@\0\26\0\2\0\26\0\24\0B\4\5\0\0\10@\0y\0@\0\2\0\0\0\24\0\0\0B\4\5\0\0\10@\0y\0@\0\2\0\26\0\24\0\26\0@\0\4\0\0\10@\0y\0@\0\1\0\1\0@
\0\4\0\0\10@\0y\0@\0\1\0\25\0@\0\4\0\0\10@\0y\0@\0"..., 956}], 1) = 956
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  select(4, [3], [3], NULL, NULL)   = 1 (out [3])
7670  writev(3, 
[{"F\7\5\0v\0@\0P\0@\0\0\0\0\0\27\0\27\0005\30\4\0\2\10@\0009\1\0\0\27\0\27\0\234\4\5\0\3\10@\0\2\10@\0\344\0\0\0\0\0\0\0008\4\4\0*\0@\0\0\4\
0\0n\0@\0008\4\5\0*\0@\0\0!\0\0\1\0\0\0\374\377\377\377F\0\5\0\2\10@\0*\0@\0\0\0\0\0\27\0\27\0B\4\5\0\2\10@\0y\0@\0\0\0\2\0\0\0\24\0B\4\5\0\2\10@\0y\0@\0\26\
0\2\0\26\0\24\0B\4\5\0\2\10@\0y\0@\0\2\0\0\0\24\0\0\0B\4\5\0\2\10@\0y\0@\0\2\0\26\0\24\0\26\0@\0\4\0\2\10@\0y\0@\0\1\0\1\0@\0\4\0\2\10@\0y\0@\0\1\0\25\0@\0\4
\0\2\10@\0y\0@\0\25\0\1\0@\0\4\0\2\10@\0y\0@\0\25\0"..., 940}], 1) = 940
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  select(4, [3], [3], NULL, NULL)   = 1 (out [3])
7670  writev(3, 
[{"F\7\5\0v\0@\0P\0@\0\0\0\0\0\27\0\27\0005\30\4\0\4\10@\0009\1\0\0\27\0\27\0\234\4\5\0\5\10@\0\4\10@\0\344\0\0\0\0\0\0\0008\4\4\0*\0@\0\0\4\
0\0n\0@\0008\4\5\0*\0@\0\0!\0\0\1\0\0\0\374\377\377\377F\0\5\0\4\10@\0*\0@\0\0\0\0\0\27\0\27\0B\4\5\0\4\10@\0y\0@\0\0\0\2\0\0\0\24\0B\4\5\0\4\10@\0y\0@\0\26\
0\2\0\26\0\24\0B\4\5\0\4\10@\0y\0@\0\2\0\0\0\24\0\0\0B\4\5\0\4\10@\0y\0@\0\2\0\26\0\24\0\26\0@\0\4\0\4\10@\0y\0@\0\1\0\1\0@\0\4\0\4\10@\0y\0@\0\1\0\25\0@\0\4
\0\4\10@\0y\0@\0\25\0\1\0@\0\4\0\4\10@\0y\0@\0\25\0"..., 940}], 1) = 940
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  select(4, [3], [3], NULL, NULL)   = 1 (out [3])
7670  writev(3, 
[{"F\7\5\0v\0@\0P\0@\0\0\0\0\0\27\0\27\0005\30\4\0\6\10@\0009\1\0\0\27\0\27\0\234\4\5\0\7\10@\0\6\10@\0\344\0\0\0\0\0\0\0008\4\4\0*\0@\0\0\4\
0\0n\0@\0008\4\5\0*\0@\0\0!\0\0\1\0\0\0\374\377\377\377F\0\5\0\6\10@\0*\0@\0\0\0\0\0\27\0\27\0I\2\5\0#\0@\0\0\0\0\0\20\0\20\0\377\377\377\377", 
132}], 1) = 1
32
7670  select(4, [3], [], NULL, NULL)    = 1 (in [3])
7670  read(3, 
"\1\0305A\0\1\0\0\0\0\0\0\320\223U\10\30Z\227\277LP\24\10\340\33\36\10\360Y\227\277\222\222\222W\314\314\314\313\315\315\315\316\315\315\315\31
6\315\315\315\316\315\315\315\316\315\315\315\316\315\315\315\316\315\315\315\316\315\315\315\316\314\314\314\316\314\314\314\316\313\313\313\316\313\313\313
\317\277\277\277\275QQQ%\316\316\316\360\356\356\356\377\321\321\321\377\342\342\342\377\342\342\342\377\342\342\342\377\342\342\342\377\342\342\342\377\342\
342\342\377\342\342\342\377\342\342\342\377\342"..., 4096) = 1056
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  select(4, [3], [3], NULL, NULL)   = 1 (out [3])
7670  writev(3, [{"I\2\5\0&\0@\0\0\0\0\0\20\0\20\0\377\377\377\377", 
20}], 1) = 20
7670  select(4, [3], [], NULL, NULL)    = 1 (in [3])
7670  read(3, 
"\1\0106A@\0\0\0\0\0\0\0\364\337\34\10\30Z\227\277LP\24\10\340\33\36\10\360Y\227\277W\313\316\316\316\316\316\316\316\316\316\316\316\317\275%\
360\377\377\377\377\377\377\377\377\377\377\377\377\377\377\240\370\377\377\377\377\377\377\377\377\377\377\377\377\377\377\253\370\377\377\377\377\377\377\3
77\377\377\377\377\377\377\377\253\370\377\377\377\377\377\377\377\377\377\377\377\377\377\377\253\370\377\377\377\377\377\377\377\377\377\377\377\377\377\37
7\253\370\377\377\377\377\377\377\377\377\377\377"..., 4096) = 288
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  select(4, [3], [3], NULL, NULL)   = 1 (out [3])
7670  writev(3, 
[{"5\30\4\0\10\10@\0009\1\0\0\20\0\20\0>\30\7\0#\0@\0\10\10@\0P\0@\0\0\0\0\0\0\0\0\0\20\0\20\0005\1\4\0\t\10@\0009\1\0\0\20\0\20\0008\1\4\0\3
05\0@\0\0\1\0\0\0\0\0\0F\0\5\0\t\10@\0\305\0@\0\0\0\0\0\20\0\20\0008\1\5\0\305\0@\0\0\t\0\0\3\0\0\0$\0@\0F\1\5\0\t\10@\0\305\0@\0\0\0\0\0\20\0\20\0005\10\4\0
\n\10@\0009\1\0\0\20\0\20\0007\10\4\0\v\10@\0\n\10@\0\0\0\0\0008\10\5\0\v\10@\0\f\0\0\0\377\0\0\0\377\0\0\0F\10\5\0\n\10@\0\v\10@\0\0\0\0\0\20\0\20\0>\10\7\0
&\0@\0\n\10@\0\v\10@\0\0\0\0\0\0\0\0\0\20\0\20\0<\10"..., 1972}], 1) = 1972
7670  select(4, [3], [], NULL, NULL)    = 1 (in [3])
7670  read(3, "\16YBA\n\10@\0\0\0>\0\250\220U\10 
|\35\10\2\0\0\300\1\0\0\0\340`\213\10\1\1\\A\0\0\0\0009\1\0\0\0\0\0\0\216\4\307\1\216\4\307\1\20\0_\10(Z\227
\277", 4096) = 64
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  select(4, [3], [3], NULL, NULL)   = 1 (out [3])
7670  writev(3, 
[{"*\1\3\0\7\0\300\0\220\313J\0\31\0\v\0\7\0\300\0\0\0\0\0! 
\0\0\7\0\300\0/\1\0\0#\1\0\0\220\313J\0\0\0\0\0\0\0\0\0\0\0\0\0", 56}], 
1) = 56
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  select(4, [3], [3], NULL, NULL)   = 1 (out [3])
7670  writev(3, [{"\24\0\6\0\v\0\0\1\0\1\0\0\4\0\0\0\0\0\0\0\0\10\0\0", 
24}], 1) = 24
7670  select(4, [3], [], NULL, NULL)    = 1 (in [3])
7670  read(3, "\1 
_A\1\0\0\0\4\0\0\0\0\0\0\0\1\0\0\0\271g\t\10`\312$\10\210\260\215\10\177\1\0\0", 
4096) = 36
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  gettimeofday({1172806052, 392707}, NULL) = 0
7670  ioctl(5, FIONREAD, [0])           = 0
7670  write(6, "\0", 1)                 = 1
7670  ioctl(5, FIONREAD, [1])           = 0
7670  ioctl(5, FIONREAD, [1])           = 0
7670  ioctl(5, FIONREAD, [1])           = 0
7670  ioctl(5, FIONREAD, [1])           = 0
7670  select(4, [3], [3], NULL, NULL)   = 1 (out [3])
7670  writev(3, [{"\22\0\7\0009\1\0\0k\1\0\0!\0\0\0 
\0\0\0\1\0\0\0\7\0\300\0\23\0\3\0\33\0@\0[\1\0\0\23\0\3\0\7\0\300\0[\1\0\0\22\0\7\0\33\0@\0\\\1\0\0\6\0\0
\0 
\0\0\0\1\0\0\0\310\0\0\0\35\0\3\0\34\0@\0\0\0\0\0\35\0\3\0\34\0@\0\2\0\0\0\35\0\3\0\34\0@\0\20\0\0\0\35\0\3\0\34\0@\0\22\0\0\0\35\0\3\0\34\0@\0\0\0\0\0\35
\0\3\0\34\0@\0\2\0\0\0\35\0\3\0\34\0@\0\20\0\0\0\35\0\3\0\34\0@\0\22\0\0\0\35\0\3\0\34\0@\0\1\0\0\0\35\0\3\0\34\0@\0\3\0\0\0\35\0\3\0\34\0@\0\21\0\0\0\35\0\3
\0\34\0@\0\23\0\0\0\35\0\3\0\34\0@\0\1\0\0\0\35\0\3"..., 3588}], 1) = 3588
7670  select(4, [3], [], NULL, NULL)    = 1 (in [3])
7670  read(3, 
"\34\275`A9\1\0\0k\1\0\0\243\313J\0\0\1\0\0\2\0\0\0\0\0\0\0009\1\0\0\34\275cA\33\0@\0\\\1\0\0\243\313J\0\0\1\0\0\2\0\0\0\0\0\0\0\33\0@\0\1\30\t
B\0\1\0\0\0\0\0\0\20\220U\10\30Z\227\277LP\24\10\340\33\36\10\360Y\227\277\222\222\222W\314\314\314\313\315\315\315\316\315\315\315\316\315\315\315\316\315\3
15\315\316\315\315\315\316\315\315\315\316\315\315\315\316\315\315\315\316\314\314\314\316\314\314\314\316\313\313\313\316\313\313\313\317\277\277\277\275QQQ
%\316\316\316\360\356\356\356\377\321\321\321\377"..., 4096) = 1120
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  select(4, [3], [3], NULL, NULL)   = 1 (out [3])
7670  writev(3, [{"I\2\5\0&\0@\0\0\0\0\0\20\0\20\0\377\377\377\377", 
20}], 1) = 20
7670  select(4, [3], [], NULL, NULL)    = 1 (in [3])
7670  read(3, 
"\1\10\nB@\0\0\0\0\0\0\0\364\337\34\10\30Z\227\277LP\24\10\340\33\36\10\360Y\227\277W\313\316\316\316\316\316\316\316\316\316\316\316\317\275%\
360\377\377\377\377\377\377\377\377\377\377\377\377\377\377\240\370\377\377\377\377\377\377\377\377\377\377\377\377\377\377\253\370\377\377\377\377\377\377\3
77\377\377\377\377\377\377\377\253\370\377\377\377\377\377\377\377\377\377\377\377\377\377\377\253\370\377\377\377\377\377\377\377\377\377\377\377\377\377\37
7\253\370\377\377\377\377\377\377\377\377\377\377"..., 4096) = 288
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  select(4, [3], [3], NULL, NULL)   = 1 (out [3])
7670  writev(3, 
[{"5\30\4\0\32\10@\0009\1\0\0\20\0\20\0>\30\7\0#\0@\0\32\10@\0P\0@\0\0\0\0\0\0\0\0\0\20\0\20\0005\1\4\0\33\10@\0009\1\0\0\20\0\20\0008\1\4\0\
305\0@\0\0\1\0\0\0\0\0\0F\0\5\0\33\10@\0\305\0@\0\0\0\0\0\20\0\20\0008\1\5\0\305\0@\0\0\t\0\0\3\0\0\0$\0@\0F\1\5\0\33\10@\0\305\0@\0\0\0\0\0\20\0\20\0005\10\
4\0\34\10@\0009\1\0\0\20\0\20\0007\10\4\0\35\10@\0\34\10@\0\0\0\0\0008\10\5\0\35\10@\0\f\0\0\0\377\0\0\0\377\0\0\0F\10\5\0\34\10@\0\35\10@\0\0\0\0\0\20\0\20\
0>\10\7\0&\0@\0\34\10@\0\35\10@\0\0\0\0\0\0\0\0\0\20"..., 2192}], 1) = 2192
7670  read(3, "\16Y\26B\34\10@\0\0\0>\0\220\307_\10 
|\35\10\2\0\0\300\1\0\0\0\340`\213\10", 4096) = 32
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  gettimeofday({1172806052, 399402}, NULL) = 0
7670  select(11, [3 4 5 7 9 10], [], [], {0, 0}) = 1 (in [5], left {0, 0})
7670  read(5, "\0", 1)                  = 1
7670  gettimeofday({1172806052, 399533}, NULL) = 0
7670  gettimeofday({1172806052, 399609}, NULL) = 0
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  gettimeofday({1172806052, 399676}, NULL) = 0
7670  select(11, [3 4 5 7 9 10], [], [], {0, 43031}) = 1 (in [3], left 
{0, 33000})
7670  gettimeofday({1172806052, 410534}, NULL) = 0
7670  read(3, 
"\34\22:B\357\0\340\0E\1\0\0\264\313J\0\0\1\0\0\2\0\0\0\0\0\0\0\357\0\340\0", 
4096) = 32
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  select(4, [3], [3], NULL, NULL)   = 1 (out [3])
7670  writev(3, 
[{"\24\0\6\0\357\0\340\0E\1\0\0001\1\0\0\0\0\0\0\240\206\1\0", 24}], 1) = 24
7670  select(4, [3], [], NULL, NULL)    = 1 (in [3])
7670  read(3, 
"\1\10;B\1\0\0\0001\1\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0000\1\0\0", 
4096) = 36
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  gettimeofday({1172806052, 411213}, NULL) = 0
7670  select(11, [3 4 5 7 9 10], [], [], {0, 31494}) = 0 (Timeout)
7670  gettimeofday({1172806052, 444173}, NULL) = 0
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  select(11, [3 4 5 7 9 10], [], [], NULL) = 1 (in [3])
7670  read(3, 
"\34\22;B\7\0\300\0v\1\0\0\200\314J\0\0\1\0\0\2\0\0\0\0\0\0\0\7\0\300\0", 
4096) = 32
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  select(4, [3], [3], NULL, NULL)   = 1 (out [3])
7670  writev(3, [{"\24\0\6\0\7\0\300\0v\1\0\0\6\0\0\0\0\0\0\0\4\0\0\0", 
24}], 1) = 24
7670  select(4, [3], [], NULL, NULL)    = 1 (in [3])
7670  read(3, "\1 
<B\4\0\0\0\6\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0000\2\0\0\300\377\377\377\310\0\0\0\25\0\0\0", 
4096) = 48
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  select(11, [3 4 5 7 9 10], [], [], NULL) = 1 (in [3])
7670  read(3, 
"\34N<B\7\0\300\0\365\0\0\0\235|K\0\0\0\0\0\2\0\0\0\0\0\0\0\7\0\300\0", 
4096) = 32
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  select(4, [3], [3], NULL, NULL)   = 1 (out [3])
7670  writev(3, 
[{"\24\0\6\0\7\0\300\0\365\0\0\0\6\0\0\0\0\0\0\0\1\0\0\0", 24}], 1) = 24
7670  select(4, [3], [], NULL, NULL)    = 1 (in [3])
7670  read(3, "\1 
=B\1\0\0\0\6\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\234|K\0", 
4096) = 36
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  select(11, [3 4 5 7 9 10], [], [], NULL) = 1 (in [3])
7670  read(3, 
"\34N=B\7\0\300\0\365\0\0\0\327|K\0\0\0\0\0\2\0\0\0\0\0\0\0\7\0\300\0", 
4096) = 32
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  select(4, [3], [3], NULL, NULL)   = 1 (out [3])
7670  writev(3, 
[{"\24\0\6\0\7\0\300\0\365\0\0\0\6\0\0\0\0\0\0\0\1\0\0\0", 24}], 1) = 24
7670  select(4, [3], [], NULL, NULL)    = 1 (in [3])
7670  read(3, "\1 
 >B\1\0\0\0\6\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\326|K\0", 
4096) = 36
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  read(3, 0x8056308, 4096)          = -1 EAGAIN (Resource 
temporarily unavailable)
7670  select(11, [3 4 5 7 9 10], [], [], NULL) = 1 (in [3])
7670  read(3, "", 4096)                 = 0
7670  write(2, "kwin: Fatal IO error: client killed\n", 36) = 36
7670  munmap(0xb6a38000, 14077)         = 0
7670  munmap(0xb6a3c000, 172966)        = 0
7670  munmap(0xb6997000, 135746)        = 0
7670  munmap(0xb6990000, 25872)         = 0
7670  munmap(0xb7f3d000, 416)           = 0
7670  munmap(0xb7f3b000, 7933)          = 0
7670  munmap(0xb698f000, 410)           = 0
7670  munmap(0xb698e000, 1450)          = 0
7670  munmap(0xb698c000, 5379)          = 0

The strace from kicker started from the command line.
=============================
KMenuBase::setProperty( "frameShadow", value ) failed: property invalid, 
read-only or does not exist
KMenuBase::setProperty( "frameShape", value ) failed: property invalid, 
read-only or does not exist
lancelot@barrabas:~> QObject::connect: No such signal 
Kicker::settingsChanged(SettingsCategory)
QObject::connect:  (sender name:   'kicker')
QObject::connect:  (receiver name: 'animtt')
X Error: BadWindow (invalid Window parameter) 3
  Major opcode:  18
  Minor opcode:  0
  Resource id:  0x22000a3
X Error: BadWindow (invalid Window parameter) 3
  Major opcode:  19
  Minor opcode:  0
  Resource id:  0x22000a3
X Error: BadWindow (invalid Window parameter) 3
  Major opcode:  18
  Minor opcode:  0
  Resource id:  0x2800007
X Error: BadWindow (invalid Window parameter) 3
  Major opcode:  19
  Minor opcode:  0
  Resource id:  0x2800007
X Error: BadWindow (invalid Window parameter) 3
  Major opcode:  18
  Minor opcode:  0
  Resource id:  0x2a00161
X Error: BadWindow (invalid Window parameter) 3
  Major opcode:  19
  Minor opcode:  0
  Resource id:  0x2a00161
X Error: BadWindow (invalid Window parameter) 3
  Major opcode:  18
  Minor opcode:  0
  Resource id:  0x2c00007
X Error: BadWindow (invalid Window parameter) 3
  Major opcode:  19
  Minor opcode:  0
  Resource id:  0x2c00007
X Error: BadWindow (invalid Window parameter) 3
  Major opcode:  18
  Minor opcode:  0
  Resource id:  0x3000007
X Error: BadWindow (invalid Window parameter) 3
  Major opcode:  19
  Minor opcode:  0
  Resource id:  0x3000007

lancelot@barrabas:~> WARNING: DCOPReply<>: cast to 'QString' error
WARNING: DCOPReply<>: cast to 'QString' error
WARNING: DCOPReply<>: cast to 'QString' error
X Error: BadWindow (invalid Window parameter) 3
  Major opcode:  20
  Minor opcode:  0
  Resource id:  0x0
X Error: BadWindow (invalid Window parameter) 3
  Major opcode:  20
  Minor opcode:  0
  Resource id:  0x0
WARNING: DCOPReply<>: cast to 'QString' error
WARNING: DCOPReply<>: cast to 'QString' error
WARNING: DCOPReply<>: cast to 'QString' error
WARNING: DCOPReply<>: cast to 'QString' error
WARNING: DCOPReply<>: cast to 'QString' error
WARNING: DCOPReply<>: cast to 'QString' error
X Error: BadWindow (invalid Window parameter) 3
  Major opcode:  20
  Minor opcode:  0
  Resource id:  0x0
WARNING: DCOPReply<>: cast to 'QString' error
WARNING: DCOPReply<>: cast to 'QString' error
WARNING: DCOPReply<>: cast to 'QString' error
X Error: BadWindow (invalid Window parameter) 3
  Major opcode:  20
  Minor opcode:  0
  Resource id:  0x0
WARNING: DCOPReply<>: cast to 'QString' error
WARNING: DCOPReply<>: cast to 'QString' error
WARNING: DCOPReply<>: cast to 'QString' error

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

Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently

[Sid Boyce]

 >>/ 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.
 >
 > Regards
That's very much appreciated. The point is that all vanilla kernels up 
to 2.6.20+ have not had the problems now seen on 2.6.20-rc1 and 
2.6.20-rc2 and like other problems reported, sic framebuffer, etc., 
there is a distinct likelihood that it's related to those kernels and 
worth reporting here where it will also be seen by the openSUSE kernel 
developers.
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

2.6.21-rc1 and 2.6.21-rc2 kwin dies silently

[Sid Boyce]

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.

-- 
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

Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently

[auxsvr]

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.

Regards

Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently

[Andrew Morton]

(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.

Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently

[Sid Boyce]

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.

-- 
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

Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently

[Sid Boyce]

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

Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently

[Adrian Bunk]

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?

> Regards
> Sid.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently

[Eric W. Biederman]

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

Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently

[Sid Boyce]

Eric W. Biederman wrote:
> 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
>
>
>   
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

Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently

[Randy Dunlap]

On Thu, 22 Mar 2007 01:32:36 +0000 Sid Boyce wrote:

> Eric W. Biederman wrote:
> > 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
> >
> >
> >   
> Reading the manpage doesn't help, so I shall have to delve  into the 
> docs or  futher help is needed.

There's not a lot of docs out there.

The man-page:  http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html

Linus's email doc:
http://www.kernel.org/pub/software/scm/git/docs/howto/isolate-bugs-with-bisect.txt

I worked on something over last weekend, but it doesn't really add
much to the references above.

> :/usr/src/linux-2.6.20-git11 # git-bisect good 
> ac98695d6c1508b724f246f38ce57fb4e3cec356
> No revs to be shown.

Did you tell git where to begin with good and bad?  I.e., you have
to tell it the bracketing of where to do the binary search.

> :/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


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently

[Adrian Bunk]

On Wed, Mar 21, 2007 at 06:42:58PM -0700, Randy Dunlap wrote:
> On Thu, 22 Mar 2007 01:32:36 +0000 Sid Boyce wrote:
> 
> >...
> There's not a lot of docs out there.
> 
> The man-page:  http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
> 
> Linus's email doc:
> http://www.kernel.org/pub/software/scm/git/docs/howto/isolate-bugs-with-bisect.txt
> 
> I worked on something over last weekend, but it doesn't really add
> much to the references above.
>...


FWIW:
My standard instructions for users who are asked to bisect are [1]:


<--  snip  -->

# install git and cogito on your computer

# clone Linus' tree:
cg-clone \ 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

# start bisecting:
cd linux-2.6
git bisect start
git bisect bad 86a71dbd3e81e8870d0f0e56b87875f57e58222b
git bisect good ac98695d6c1508b724f246f38ce57fb4e3cec356

# start round
cp /path/to/.config .
make oldconfig
make
# install kernel, check whether it's good or bad, then:
git bisect [bad|good]
# start next round


After at about 8 reboots, you'll have found the guilty commit
("...  is first bad commit").


More information on git bisecting:
  man git-bisect

<--  snip  -->


> ~Randy

cu
Adrian

[1] the start and end commits and the number of reboots are variable,
    but the rest of the text is generic

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently

[Sid Boyce]

Adrian Bunk wrote:
> On Wed, Mar 21, 2007 at 06:42:58PM -0700, Randy Dunlap wrote:
>   
>> On Thu, 22 Mar 2007 01:32:36 +0000 Sid Boyce wrote:
>>
>>     
>>> ...
>>>       
>> There's not a lot of docs out there.
>>
>> The man-page:  http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
>>
>> Linus's email doc:
>> http://www.kernel.org/pub/software/scm/git/docs/howto/isolate-bugs-with-bisect.txt
>>
>> I worked on something over last weekend, but it doesn't really add
>> much to the references above.
>> ...
>>     
>
>
> FWIW:
> My standard instructions for users who are asked to bisect are [1]:
>
>
> <--  snip  -->
>
> # install git and cogito on your computer
>
> # clone Linus' tree:
> cg-clone \ 
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>
> # start bisecting:
> cd linux-2.6
> git bisect start
> git bisect bad 86a71dbd3e81e8870d0f0e56b87875f57e58222b
> git bisect good ac98695d6c1508b724f246f38ce57fb4e3cec356
>
> # start round
> cp /path/to/.config .
> make oldconfig
> make
> # install kernel, check whether it's good or bad, then:
> git bisect [bad|good]
> # start next round
>
>
> After at about 8 reboots, you'll have found the guilty commit
> ("...  is first bad commit").
>
>
> More information on git bisecting:
>   man git-bisect
>
> <--  snip  -->
>
>
>   
>> ~Randy
>>     
>
> cu
> Adrian
>
> [1] the start and end commits and the number of reboots are variable,
>     but the rest of the text is generic
>
>   
Kernel built and installed, so I shall have something to report in the 
next couple of days.
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

Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently

[boris]

On Thu, Mar 22, 2007 at 07:49:16PM +0000, Sid Boyce wrote:

> Kernel built and installed, so I shall have something to report in the
> next couple of days.

I see this kwin bug too
on a Thinkpad (x86_64) as well as on a Pmac (powerpc64).
It is only triggerd when the screen is locked AND! set
to standby mode (display/backlight is turned off - acpi).

boris

Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently

[Sid Boyce]

Adrian Bunk wrote:
> On Wed, Mar 21, 2007 at 06:42:58PM -0700, Randy Dunlap wrote:
>   
>> On Thu, 22 Mar 2007 01:32:36 +0000 Sid Boyce wrote:
>>
>>     
>>> ...
>>>       
>> There's not a lot of docs out there.
>>
>> The man-page:  http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
>>
>> Linus's email doc:
>> http://www.kernel.org/pub/software/scm/git/docs/howto/isolate-bugs-with-bisect.txt
>>
>> I worked on something over last weekend, but it doesn't really add
>> much to the references above.
>> ...
>>     
>
>
> FWIW:
> My standard instructions for users who are asked to bisect are [1]:
>
>
> <--  snip  -->
>
> # install git and cogito on your computer
>
> # clone Linus' tree:
> cg-clone \ 
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>
> # start bisecting:
> cd linux-2.6
> git bisect start
> git bisect bad 86a71dbd3e81e8870d0f0e56b87875f57e58222b
> git bisect good ac98695d6c1508b724f246f38ce57fb4e3cec356
>
> # start round
> cp /path/to/.config .
> make oldconfig
> make
> # install kernel, check whether it's good or bad, then:
> git bisect [bad|good]
> # start next round
>
>
> After at about 8 reboots, you'll have found the guilty commit
> ("...  is first bad commit").
>
>
> More information on git bisecting:
>   man git-bisect
>
> <--  snip  -->
>
>
>   
>> ~Randy
>>     
>
> cu
> Adrian
>
> [1] the start and end commits and the number of reboots are variable,
>     but the rest of the text is generic
>
>   
This is what I've got so far on the first boot, I shall have to check 
the manpage for git-bisect again to see if there is anything else to be 
added, nothing enlightening seen so far - further reboots to be done.
barrabas:/usr/src/GIT/linux-2.6 # git bisect bad
Bisecting: 22 revisions left to test after this
[3fc605a2aa38899c12180ca311f1eeb61a6d867e] knfsd: allow the server to 
provide a gid list when using AUTH_UNIX authentication
rrabas:/usr/src/GIT/linux-2.6 # git bisect bad
Bisecting: 11 revisions left to test after this
[ed8b4d4d7a31923db32f4684535944d69eb43677] qconf: hide empty list items
barrabas:/usr/src/GIT/linux-2.6 #
rrabas:/usr/src/GIT/linux-2.6 # git bisect bad
Bisecting: 6 revisions left to test after this
[66e7c7230fed159e138fc1292ee662b8bbdb74d6] qconf: relocate Search Command
barrabas:/usr/src/GIT/linux-2.6 #

barrabas:/usr/src/GIT/linux-2.6 # git bisect bad
Bisecting: 3 revisions left to test after this
[895a39a084e5478121a74752a291165c4502378f] Make mkcompile_h use LANG=C 
and LC_ALL=C for $CC -v

barrabas:/usr/src/GIT/linux-2.6 # git bisect bad
Bisecting: 2 revisions left to test after this
[8c7e4498adfdb4aea5a0d056590ec18d099ba062] search a little harder for 
mkimage

barrabas:/usr/src/GIT/linux-2.6 # git bisect bad
Bisecting: 1 revisions left to test after this
[b7de8e7e3c7b79a72c20c7fd58bd65df3d146b13] ia64: fix noncoherent DMA API 
so devres builds

 # git bisect bad
b7de8e7e3c7b79a72c20c7fd58bd65df3d146b13 is first bad commit
commit b7de8e7e3c7b79a72c20c7fd58bd65df3d146b13
Author: Roland Dreier <rdreier@cisco.com>
Date:   Wed Feb 14 00:32:53 2007 -0800

    [PATCH] ia64: fix noncoherent DMA API so devres builds

    On ia64, drivers/base/dma-mapping.c doesn't build because it calls
    dma_alloc_noncoherent() and dma_free_noncoherent(), which appear to be
    terminally broken; the calls end up generating errors like

        drivers/base/dma-mapping.c: In function 'dmam_noncoherent_release':
        drivers/base/dma-mapping.c:32: error: 'struct 
ia64_machine_vector' has no member named 'platform_dma_free_coherent'

    because the multiple levels of macro expansion in 
<asm/dma-mapping.h> and
    <asm/machvec.h> end up turning a call to dma_free_noncoherent() into
    ia64_mv.platform_dma_free_coherent (instead of the intended
    ia64_mv.dma_free_coherent).

    This patch fixes this by converting dma_{alloc,free}_noncoherent() into
    inline functions that call the corresponding coherent functions, 
instead of
    trying to do this with macros.

    Signed-off-by: Roland Dreier <rolandd@cisco.com>
    Acked-by: Tony Luck <tony.luck@intel.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
:040000 040000 ac36019577dc1846a5655918cf9d6b2541c398cf 
ba536f54303cc9495b7839763ed1121d3a22154c M      include

barrabas:/usr/src/GIT/linux-2.6 # git bisect bad 
86a71dbd3e81e8870d0f0e56b87875f57e58222b
Bisecting: 44 revisions left to test after this
[208367eeec8d6f6fcee1a0672af2149aeee7b658] sysctl: cdrom: remove 
unnecessary insert_at_head flag

barrabas:/usr/src/GIT/linux-2.6 # git bisect good 
ac98695d6c1508b724f246f38ce57fb4e3cec356
Bisecting: 44 revisions left to test after this
[208367eeec8d6f6fcee1a0672af2149aeee7b658] sysctl: cdrom: remove 
unnecessary insert_at_head flag

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

Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently

[Eric W. Biederman]

Sid Boyce <g3vbv@blueyonder.co.uk> writes:

> This is what I've got so far on the first boot, I shall have to check the
> manpage for git-bisect again to see if there is anything else to be added,
> nothing enlightening seen so far - further reboots to be done.

I'm a little confused at what I am seeing below.
Normally what happens is that after a kernel compile and test.  You call
"git-bisect bad" or "git-bisect good" and then git-bisect picks the next
kernel to test.  Then you compile and test that one.  It looks like
you called git-bisect bad several times in a row without testing....


Eric

> barrabas:/usr/src/GIT/linux-2.6 # git bisect bad
> Bisecting: 22 revisions left to test after this
> [3fc605a2aa38899c12180ca311f1eeb61a6d867e] knfsd: allow the server to provide a
> gid list when using AUTH_UNIX authentication
> rrabas:/usr/src/GIT/linux-2.6 # git bisect bad
> Bisecting: 11 revisions left to test after this
> [ed8b4d4d7a31923db32f4684535944d69eb43677] qconf: hide empty list items
> barrabas:/usr/src/GIT/linux-2.6 #
> rrabas:/usr/src/GIT/linux-2.6 # git bisect bad
> Bisecting: 6 revisions left to test after this
> [66e7c7230fed159e138fc1292ee662b8bbdb74d6] qconf: relocate Search Command
> barrabas:/usr/src/GIT/linux-2.6 #
>
> barrabas:/usr/src/GIT/linux-2.6 # git bisect bad
> Bisecting: 3 revisions left to test after this
> [895a39a084e5478121a74752a291165c4502378f] Make mkcompile_h use LANG=C and
> LC_ALL=C for $CC -v
>
> barrabas:/usr/src/GIT/linux-2.6 # git bisect bad
> Bisecting: 2 revisions left to test after this
> [8c7e4498adfdb4aea5a0d056590ec18d099ba062] search a little harder for mkimage
>
> barrabas:/usr/src/GIT/linux-2.6 # git bisect bad
> Bisecting: 1 revisions left to test after this
> [b7de8e7e3c7b79a72c20c7fd58bd65df3d146b13] ia64: fix noncoherent DMA API so
> devres builds
>
> # git bisect bad
> b7de8e7e3c7b79a72c20c7fd58bd65df3d146b13 is first bad commit
> commit b7de8e7e3c7b79a72c20c7fd58bd65df3d146b13
> Author: Roland Dreier <rdreier@cisco.com>
> Date:   Wed Feb 14 00:32:53 2007 -0800
>
>    [PATCH] ia64: fix noncoherent DMA API so devres builds
>
>    On ia64, drivers/base/dma-mapping.c doesn't build because it calls
>    dma_alloc_noncoherent() and dma_free_noncoherent(), which appear to be
>    terminally broken; the calls end up generating errors like
>
>        drivers/base/dma-mapping.c: In function 'dmam_noncoherent_release':
>        drivers/base/dma-mapping.c:32: error: 'struct ia64_machine_vector' has no
> member named 'platform_dma_free_coherent'
>
>    because the multiple levels of macro expansion in <asm/dma-mapping.h> and
>    <asm/machvec.h> end up turning a call to dma_free_noncoherent() into
>    ia64_mv.platform_dma_free_coherent (instead of the intended
>    ia64_mv.dma_free_coherent).
>
>    This patch fixes this by converting dma_{alloc,free}_noncoherent() into
>    inline functions that call the corresponding coherent functions, instead of
>    trying to do this with macros.
>
>    Signed-off-by: Roland Dreier <rolandd@cisco.com>
>    Acked-by: Tony Luck <tony.luck@intel.com>
>    Cc: Al Viro <viro@zeniv.linux.org.uk>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> :040000 040000 ac36019577dc1846a5655918cf9d6b2541c398cf
> ba536f54303cc9495b7839763ed1121d3a22154c M      include
>
> barrabas:/usr/src/GIT/linux-2.6 # git bisect bad
> 86a71dbd3e81e8870d0f0e56b87875f57e58222b
> Bisecting: 44 revisions left to test after this
> [208367eeec8d6f6fcee1a0672af2149aeee7b658] sysctl: cdrom: remove unnecessary
> insert_at_head flag
>
> barrabas:/usr/src/GIT/linux-2.6 # git bisect good
> ac98695d6c1508b724f246f38ce57fb4e3cec356
> Bisecting: 44 revisions left to test after this
> [208367eeec8d6f6fcee1a0672af2149aeee7b658] sysctl: cdrom: remove unnecessary
> insert_at_head flag
>
> 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

Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently

[Sid Boyce]

Eric W. Biederman wrote:
> Sid Boyce <g3vbv@blueyonder.co.uk> writes:
>
>   
>> This is what I've got so far on the first boot, I shall have to check the
>> manpage for git-bisect again to see if there is anything else to be added,
>> nothing enlightening seen so far - further reboots to be done.
>>     
>
> I'm a little confused at what I am seeing below.
> Normally what happens is that after a kernel compile and test.  You call
> "git-bisect bad" or "git-bisect good" and then git-bisect picks the next
> kernel to test.  Then you compile and test that one.  It looks like
> you called git-bisect bad several times in a row without testing....
>
>
> Eric
>
>   
This is the procedure I followed.
<--  snip  -->

# install git and cogito on your computer

# clone Linus' tree:
cg-clone  
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

# start bisecting:
cd linux-2.6
git bisect start
git bisect bad 86a71dbd3e81e8870d0f0e56b87875f57e58222b
git bisect good ac98695d6c1508b724f246f38ce57fb4e3cec356

# start round
cp /path/to/.config .
make oldconfig
make
# install kernel, check whether it's good or bad, then:
git bisect [bad|good]
========================================================
I built and installed the kernel downloaded using "cg-clone", booted it 
up  and ran "git bisect bad".  I'm also somewhat confused as the first 
failing kernel is 2.6.20-git11, the Makefile says the kernel got with 
cg-clone is actually 2.6.21-rc4 and it built as  2.6.20-g208367ee.
Regards
Sid.

>> barrabas:/usr/src/GIT/linux-2.6 # git bisect bad
>> Bisecting: 22 revisions left to test after this
>> [3fc605a2aa38899c12180ca311f1eeb61a6d867e] knfsd: allow the server to provide a
>> gid list when using AUTH_UNIX authentication
>> rrabas:/usr/src/GIT/linux-2.6 # git bisect bad
>> Bisecting: 11 revisions left to test after this
>> [ed8b4d4d7a31923db32f4684535944d69eb43677] qconf: hide empty list items
>> barrabas:/usr/src/GIT/linux-2.6 #
>> rrabas:/usr/src/GIT/linux-2.6 # git bisect bad
>> Bisecting: 6 revisions left to test after this
>> [66e7c7230fed159e138fc1292ee662b8bbdb74d6] qconf: relocate Search Command
>> barrabas:/usr/src/GIT/linux-2.6 #
>>
>> barrabas:/usr/src/GIT/linux-2.6 # git bisect bad
>> Bisecting: 3 revisions left to test after this
>> [895a39a084e5478121a74752a291165c4502378f] Make mkcompile_h use LANG=C and
>> LC_ALL=C for $CC -v
>>
>> barrabas:/usr/src/GIT/linux-2.6 # git bisect bad
>> Bisecting: 2 revisions left to test after this
>> [8c7e4498adfdb4aea5a0d056590ec18d099ba062] search a little harder for mkimage
>>
>> barrabas:/usr/src/GIT/linux-2.6 # git bisect bad
>> Bisecting: 1 revisions left to test after this
>> [b7de8e7e3c7b79a72c20c7fd58bd65df3d146b13] ia64: fix noncoherent DMA API so
>> devres builds
>>
>> # git bisect bad
>> b7de8e7e3c7b79a72c20c7fd58bd65df3d146b13 is first bad commit
>> commit b7de8e7e3c7b79a72c20c7fd58bd65df3d146b13
>> Author: Roland Dreier <rdreier@cisco.com>
>> Date:   Wed Feb 14 00:32:53 2007 -0800
>>
>>    [PATCH] ia64: fix noncoherent DMA API so devres builds
>>
>>    On ia64, drivers/base/dma-mapping.c doesn't build because it calls
>>    dma_alloc_noncoherent() and dma_free_noncoherent(), which appear to be
>>    terminally broken; the calls end up generating errors like
>>
>>        drivers/base/dma-mapping.c: In function 'dmam_noncoherent_release':
>>        drivers/base/dma-mapping.c:32: error: 'struct ia64_machine_vector' has no
>> member named 'platform_dma_free_coherent'
>>
>>    because the multiple levels of macro expansion in <asm/dma-mapping.h> and
>>    <asm/machvec.h> end up turning a call to dma_free_noncoherent() into
>>    ia64_mv.platform_dma_free_coherent (instead of the intended
>>    ia64_mv.dma_free_coherent).
>>
>>    This patch fixes this by converting dma_{alloc,free}_noncoherent() into
>>    inline functions that call the corresponding coherent functions, instead of
>>    trying to do this with macros.
>>
>>    Signed-off-by: Roland Dreier <rolandd@cisco.com>
>>    Acked-by: Tony Luck <tony.luck@intel.com>
>>    Cc: Al Viro <viro@zeniv.linux.org.uk>
>>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>> :040000 040000 ac36019577dc1846a5655918cf9d6b2541c398cf
>> ba536f54303cc9495b7839763ed1121d3a22154c M      include
>>
>> barrabas:/usr/src/GIT/linux-2.6 # git bisect bad
>> 86a71dbd3e81e8870d0f0e56b87875f57e58222b
>> Bisecting: 44 revisions left to test after this
>> [208367eeec8d6f6fcee1a0672af2149aeee7b658] sysctl: cdrom: remove unnecessary
>> insert_at_head flag
>>
>> barrabas:/usr/src/GIT/linux-2.6 # git bisect good
>> ac98695d6c1508b724f246f38ce57fb4e3cec356
>> Bisecting: 44 revisions left to test after this
>> [208367eeec8d6f6fcee1a0672af2149aeee7b658] sysctl: cdrom: remove unnecessary
>> insert_at_head flag
>>
>> 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
>>     
>
>
>   


-- 
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

Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently

[Adrian Bunk]

On Wed, Mar 28, 2007 at 04:26:05AM +0100, Sid Boyce wrote:
> Eric W. Biederman wrote:
> >Sid Boyce <g3vbv@blueyonder.co.uk> writes:
> >
> >  
> >>This is what I've got so far on the first boot, I shall have to check the
> >>manpage for git-bisect again to see if there is anything else to be added,
> >>nothing enlightening seen so far - further reboots to be done.
> >>    
> >
> >I'm a little confused at what I am seeing below.
> >Normally what happens is that after a kernel compile and test.  You call
> >"git-bisect bad" or "git-bisect good" and then git-bisect picks the next
> >kernel to test.  Then you compile and test that one.  It looks like
> >you called git-bisect bad several times in a row without testing....
> >
> >
> >Eric
> >
> >  
> This is the procedure I followed.
> <--  snip  -->
> 
> # install git and cogito on your computer
> 
> # clone Linus' tree:
> cg-clone  
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> 
> # start bisecting:
> cd linux-2.6
> git bisect start
> git bisect bad 86a71dbd3e81e8870d0f0e56b87875f57e58222b
> git bisect good ac98695d6c1508b724f246f38ce57fb4e3cec356
> 
> # start round
> cp /path/to/.config .
> make oldconfig
> make
> # install kernel, check whether it's good or bad, then:
> git bisect [bad|good]
> ========================================================
> I built and installed the kernel downloaded using "cg-clone", booted it 
> up  and ran "git bisect bad".  I'm also somewhat confused as the first 
> failing kernel is 2.6.20-git11, the Makefile says the kernel got with 
> cg-clone is actually 2.6.21-rc4 and it built as  2.6.20-g208367ee.
> Regards
> Sid.
> 
> >>barrabas:/usr/src/GIT/linux-2.6 # git bisect bad
> >>Bisecting: 22 revisions left to test after this
> >>[3fc605a2aa38899c12180ca311f1eeb61a6d867e] knfsd: allow the server to 
> >>provide a
> >>gid list when using AUTH_UNIX authentication
> >>rrabas:/usr/src/GIT/linux-2.6 # git bisect bad
>...

I think I got your problem:

After rebooting, you do "git bisect [bad|good]"  *once*.

Then recompile the kernel from the current tree, reboot, and again
*once* "git bisect [bad|good]".

etc.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently

[Eric W. Biederman]

Adrian Bunk <bunk@stusta.de> writes:


> I think I got your problem:
>
> After rebooting, you do "git bisect [bad|good]"  *once*.
>
> Then recompile the kernel from the current tree, reboot, and again
> *once* "git bisect [bad|good]".
>
> etc.

Sounds right.

Someone else doing the bisect suggested that
0475ac0845f9295bc5f69af45f58dff2c104c8d1 is the problem commit.
Unfortunately I can't see anything wrong there.

Sid when you get that far if you can confirm or deny that
0475ac0845f9295bc5f69af45f58dff2c104c8d1 is the problem commit
I would appreciate the extra data point.  Having two people
report the problem at the exact same place would confirm for
me that we actually have a good trace, and that I really am
blind.

Eric

Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently

[Sid Boyce]

Adrian Bunk wrote:
> On Wed, Mar 28, 2007 at 04:26:05AM +0100, Sid Boyce wrote:
>   
>> Eric W. Biederman wrote:
>>     
>>> Sid Boyce <g3vbv@blueyonder.co.uk> writes:
>>>
>>>  
>>>       
>>>> This is what I've got so far on the first boot, I shall have to check the
>>>> manpage for git-bisect again to see if there is anything else to be added,
>>>> nothing enlightening seen so far - further reboots to be done.
>>>>    
>>>>         
>>> I'm a little confused at what I am seeing below.
>>> Normally what happens is that after a kernel compile and test.  You call
>>> "git-bisect bad" or "git-bisect good" and then git-bisect picks the next
>>> kernel to test.  Then you compile and test that one.  It looks like
>>> you called git-bisect bad several times in a row without testing....
>>>
>>>
>>> Eric
>>>
>>>  
>>>       
>> This is the procedure I followed.
>> <--  snip  -->
>>
>> # install git and cogito on your computer
>>
>> # clone Linus' tree:
>> cg-clone  
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>>
>> # start bisecting:
>> cd linux-2.6
>> git bisect start
>> git bisect bad 86a71dbd3e81e8870d0f0e56b87875f57e58222b
>> git bisect good ac98695d6c1508b724f246f38ce57fb4e3cec356
>>
>> # start round
>> cp /path/to/.config .
>> make oldconfig
>> make
>> # install kernel, check whether it's good or bad, then:
>> git bisect [bad|good]
>> ========================================================
>> I built and installed the kernel downloaded using "cg-clone", booted it 
>> up  and ran "git bisect bad".  I'm also somewhat confused as the first 
>> failing kernel is 2.6.20-git11, the Makefile says the kernel got with 
>> cg-clone is actually 2.6.21-rc4 and it built as  2.6.20-g208367ee.
>> Regards
>> Sid.
>>
>>     
>>>> barrabas:/usr/src/GIT/linux-2.6 # git bisect bad
>>>> Bisecting: 22 revisions left to test after this
>>>> [3fc605a2aa38899c12180ca311f1eeb61a6d867e] knfsd: allow the server to 
>>>> provide a
>>>> gid list when using AUTH_UNIX authentication
>>>> rrabas:/usr/src/GIT/linux-2.6 # git bisect bad
>>>>         
>> ...
>>     
>
> I think I got your problem:
>
> After rebooting, you do "git bisect [bad|good]"  *once*.
>
> Then recompile the kernel from the current tree, reboot, and again
> *once* "git bisect [bad|good]".
>
> etc.
>
> cu
> Adrian
>
>   
If I boot up on 2.6.20-git10 and run "git bisect bad", "git bisect good 
v2.6.20-git10" or "git bisect bad v2.6.20-git11", it says it's not a git 
repo.

I am still no clearer what's required.  If I do "cg-clone" I get 
2.6.21-rc5. The previous one got me 2.6.21-rc4.
The manpages and the tutorials I've looked at are quite cryptic and the 
commands do not produce the expected results.
As indicated above, I followed the instructions bullet by bullet without 
any clear understanding of the tools.
1) Ran the commands as above,cg-clone; git start; git bisect bad 
<checksum>;git bisect good <checksum of 2.6.20-git10 > I presume.
2) 2.6.20-git10 is the last good kernel.
3) 2.6.20-git11 and later are all bad.
4) I do cg-clone which gives a kernel whose Makefile is 2.6.21-rc4 (or 
whatever is current).
5) I get a kernel named 2.6.20-g208367e after make - rebooted and it 
fails the same way as 2.6.20-git11.
6) ran "git bisect bad".
Looking through the directories after cg-clone
barrabas:/ftp/mar07/GIT/linux-2.6 # ls .git/refs/tags/
v2.6.11       v2.6.12-rc5  v2.6.13-rc4  v2.6.14-rc2  v2.6.15-rc2  
v2.6.16      v2.6.16-rc6  v2.6.17-rc5  v2.6.18-rc4  v2.6.19-rc2  
v2.6.20-rc1  v2.6.20-rc7
v2.6.11-tree  v2.6.12-rc6  v2.6.13-rc5  v2.6.14-rc3  v2.6.15-rc3  
v2.6.16-rc1  v2.6.17      v2.6.17-rc6  v2.6.18-rc5  v2.6.19-rc3  
v2.6.20-rc2  v2.6.21-rc1
v2.6.12       v2.6.13      v2.6.13-rc6  v2.6.14-rc4  v2.6.15-rc4  
v2.6.16-rc2  v2.6.17-rc1  v2.6.18      v2.6.18-rc6  v2.6.19-rc4  
v2.6.20-rc3  v2.6.21-rc2
v2.6.12-rc2   v2.6.13-rc1  v2.6.13-rc7  v2.6.14-rc5  v2.6.15-rc5  
v2.6.16-rc3  v2.6.17-rc2  v2.6.18-rc1  v2.6.18-rc7  v2.6.19-rc5  
v2.6.20-rc4  v2.6.21-rc3
v2.6.12-rc3   v2.6.13-rc2  v2.6.14      v2.6.15      v2.6.15-rc6  
v2.6.16-rc4  v2.6.17-rc3  v2.6.18-rc2  v2.6.19      v2.6.19-rc6  
v2.6.20-rc5  v2.6.21-rc4
v2.6.12-rc4   v2.6.13-rc3  v2.6.14-rc1  v2.6.15-rc1  v2.6.15-rc7  
v2.6.16-rc5  v2.6.17-rc4  v2.6.18-rc3  v2.6.19-rc1  v2.6.20      
v2.6.20-rc6  v2.6.21-rc5
barrabas:/ftp/mar07/GIT/linux-2.6 # ls .git/refs/bisect/
bad  good-ac98695d6c1508b724f246f38ce57fb4e3cec356
barrabas:/ftp/mar07/GIT/linux-2.6 # ls .git/refs/heads/
bisect  master  origin
barrabas:/ftp/mar07/GIT/linux-2.6 # less .git/refs/heads/bisect
208367eeec8d6f6fcee1a0672af2149aeee7b658

barrabas:/ftp/mar07/GIT/linux-2.6 # ls .git/branches/

barrabas:/ftp/mar07/GIT/linux-2.6 # ls
arch   COPYING  crypto         drivers  .git        include  ipc     
kernel  .mailmap     Makefile  net     REPORTING-BUGS  security  usr
block  CREDITS  Documentation  fs       .gitignore  init     Kbuild  
lib     MAINTAINERS  mm        README  scripts         sound

# less BISECT_LOG
git-bisect start
# bad: [86a71dbd3e81e8870d0f0e56b87875f57e58222b] sysctl: hide the 
sysctl proc inodes from selinux
git-bisect bad 86a71dbd3e81e8870d0f0e56b87875f57e58222b
# good: [ac98695d6c1508b724f246f38ce57fb4e3cec356] Merge branch 'master' 
of /home/trondmy/kernel/linux-2.6/
git-bisect good ac98695d6c1508b724f246f38ce57fb4e3cec356

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

Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently

[Adrian Bunk]

On Thu, Mar 29, 2007 at 12:35:42PM +0100, Sid Boyce wrote:
>...
> 1) Ran the commands as above,cg-clone; git start; git bisect bad 
> <checksum>;git bisect good <checksum of 2.6.20-git10 > I presume.
> 2) 2.6.20-git10 is the last good kernel.
> 3) 2.6.20-git11 and later are all bad.
> 4) I do cg-clone which gives a kernel whose Makefile is 2.6.21-rc4 (or 
> whatever is current).
>...

No, that's what should be repeated:

# start round
cp /path/to/.config .
make oldconfig
make
# install kernel, check whether it's good or bad, then:
git bisect [bad|good]
# start next round

> Regards
> Sid.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently

[Eric W. Biederman]

Sid I think I have found the problem. Could you try the following patch. 
I believe I accidentally switched the sense of a test....

diff --git a/kernel/exit.c b/kernel/exit.c
index f132349..b55ed4c 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -790,7 +790,7 @@ static void exit_notify(struct task_struct *tsk)
 	
 	pgrp = task_pgrp(tsk);
 	if ((task_pgrp(t) != pgrp) &&
-	    (task_session(t) != task_session(tsk)) &&
+	    (task_session(t) == task_session(tsk)) &&
 	    will_become_orphaned_pgrp(pgrp, tsk) &&
 	    has_stopped_jobs(pgrp)) {
 		__kill_pgrp_info(SIGHUP, SEND_SIG_PRIV, pgrp);

Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently

[Sid Boyce]

Eric W. Biederman wrote:
> Sid I think I have found the problem. Could you try the following patch. 
> I believe I accidentally switched the sense of a test....
>
> diff --git a/kernel/exit.c b/kernel/exit.c
> index f132349..b55ed4c 100644
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -790,7 +790,7 @@ static void exit_notify(struct task_struct *tsk)
>  	
>  	pgrp = task_pgrp(tsk);
>  	if ((task_pgrp(t) != pgrp) &&
> -	    (task_session(t) != task_session(tsk)) &&
> +	    (task_session(t) == task_session(tsk)) &&
>  	    will_become_orphaned_pgrp(pgrp, tsk) &&
>  	    has_stopped_jobs(pgrp)) {
>  		__kill_pgrp_info(SIGHUP, SEND_SIG_PRIV, pgrp);
>
>
>
>
>   
AOK I shall apply to 2.6.21-rc5-git4 and test.
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

Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently

[Sid Boyce]

Sid Boyce wrote:
> Eric W. Biederman wrote:
>> Sid I think I have found the problem. Could you try the following 
>> patch. I believe I accidentally switched the sense of a test....
>>
>> diff --git a/kernel/exit.c b/kernel/exit.c
>> index f132349..b55ed4c 100644
>> --- a/kernel/exit.c
>> +++ b/kernel/exit.c
>> @@ -790,7 +790,7 @@ static void exit_notify(struct task_struct *tsk)
>>     
>>      pgrp = task_pgrp(tsk);
>>      if ((task_pgrp(t) != pgrp) &&
>> -        (task_session(t) != task_session(tsk)) &&
>> +        (task_session(t) == task_session(tsk)) &&
>>          will_become_orphaned_pgrp(pgrp, tsk) &&
>>          has_stopped_jobs(pgrp)) {
>>          __kill_pgrp_info(SIGHUP, SEND_SIG_PRIV, pgrp);
>>
>>
>>
>>
>>   
> AOK I shall apply to 2.6.21-rc5-git4 and test.
> Regards
> Sid.
> 

Thanks, the patch works - tested on 2.6.21-rc5-git4.
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