* Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently
@ 2007-02-28 16:24 Sid Boyce
0 siblings, 0 replies; 27+ messages in thread
From: Sid Boyce @ 2007-02-28 16:24 UTC (permalink / raw)
To: linux-kernel
>>/ 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently
2007-03-29 11:35 ` Sid Boyce
@ 2007-03-30 18:00 ` Adrian Bunk
0 siblings, 0 replies; 27+ messages in thread
From: Adrian Bunk @ 2007-03-30 18:00 UTC (permalink / raw)
To: Sid Boyce; +Cc: Eric W. Biederman, Randy Dunlap, linux-kernel, auxsvr
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently
2007-03-29 11:37 ` Sid Boyce
@ 2007-03-29 16:16 ` Sid Boyce
0 siblings, 0 replies; 27+ messages in thread
From: Sid Boyce @ 2007-03-29 16:16 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Adrian Bunk, Randy Dunlap, linux-kernel, auxsvr
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently
2007-03-29 4:04 ` Eric W. Biederman
@ 2007-03-29 11:37 ` Sid Boyce
2007-03-29 16:16 ` Sid Boyce
0 siblings, 1 reply; 27+ messages in thread
From: Sid Boyce @ 2007-03-29 11:37 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Adrian Bunk, Randy Dunlap, linux-kernel, auxsvr
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently
2007-03-28 4:14 ` Adrian Bunk
2007-03-28 13:17 ` Eric W. Biederman
@ 2007-03-29 11:35 ` Sid Boyce
2007-03-30 18:00 ` Adrian Bunk
1 sibling, 1 reply; 27+ messages in thread
From: Sid Boyce @ 2007-03-29 11:35 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Eric W. Biederman, Randy Dunlap, linux-kernel, auxsvr
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently
2007-03-28 3:26 ` Sid Boyce
2007-03-28 4:14 ` Adrian Bunk
@ 2007-03-29 4:04 ` Eric W. Biederman
2007-03-29 11:37 ` Sid Boyce
1 sibling, 1 reply; 27+ messages in thread
From: Eric W. Biederman @ 2007-03-29 4:04 UTC (permalink / raw)
To: g3vbv; +Cc: Adrian Bunk, Randy Dunlap, linux-kernel, auxsvr
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);
^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently
2007-03-28 4:14 ` Adrian Bunk
@ 2007-03-28 13:17 ` Eric W. Biederman
2007-03-29 11:35 ` Sid Boyce
1 sibling, 0 replies; 27+ messages in thread
From: Eric W. Biederman @ 2007-03-28 13:17 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Sid Boyce, Randy Dunlap, linux-kernel, auxsvr
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently
2007-03-28 3:26 ` Sid Boyce
@ 2007-03-28 4:14 ` Adrian Bunk
2007-03-28 13:17 ` Eric W. Biederman
2007-03-29 11:35 ` Sid Boyce
2007-03-29 4:04 ` Eric W. Biederman
1 sibling, 2 replies; 27+ messages in thread
From: Adrian Bunk @ 2007-03-28 4:14 UTC (permalink / raw)
To: Sid Boyce; +Cc: Eric W. Biederman, Randy Dunlap, linux-kernel, auxsvr
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently
2007-03-27 13:48 ` Eric W. Biederman
@ 2007-03-28 3:26 ` Sid Boyce
2007-03-28 4:14 ` Adrian Bunk
2007-03-29 4:04 ` Eric W. Biederman
0 siblings, 2 replies; 27+ messages in thread
From: Sid Boyce @ 2007-03-28 3:26 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Adrian Bunk, Randy Dunlap, linux-kernel, auxsvr
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently
2007-03-27 3:38 ` Sid Boyce
@ 2007-03-27 13:48 ` Eric W. Biederman
2007-03-28 3:26 ` Sid Boyce
0 siblings, 1 reply; 27+ messages in thread
From: Eric W. Biederman @ 2007-03-27 13:48 UTC (permalink / raw)
To: g3vbv; +Cc: Adrian Bunk, Randy Dunlap, linux-kernel, auxsvr
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently
2007-03-22 10:59 ` Adrian Bunk
2007-03-22 19:49 ` Sid Boyce
@ 2007-03-27 3:38 ` Sid Boyce
2007-03-27 13:48 ` Eric W. Biederman
1 sibling, 1 reply; 27+ messages in thread
From: Sid Boyce @ 2007-03-27 3:38 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Randy Dunlap, Eric W. Biederman, linux-kernel, auxsvr
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently
2007-03-22 19:49 ` Sid Boyce
@ 2007-03-26 12:02 ` boris
0 siblings, 0 replies; 27+ messages in thread
From: boris @ 2007-03-26 12:02 UTC (permalink / raw)
To: Sid Boyce
Cc: Adrian Bunk, Randy Dunlap, Eric W. Biederman, linux-kernel, auxsvr
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently
2007-03-22 10:59 ` Adrian Bunk
@ 2007-03-22 19:49 ` Sid Boyce
2007-03-26 12:02 ` boris
2007-03-27 3:38 ` Sid Boyce
1 sibling, 1 reply; 27+ messages in thread
From: Sid Boyce @ 2007-03-22 19:49 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Randy Dunlap, Eric W. Biederman, linux-kernel, auxsvr
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently
2007-03-22 1:42 ` Randy Dunlap
@ 2007-03-22 10:59 ` Adrian Bunk
2007-03-22 19:49 ` Sid Boyce
2007-03-27 3:38 ` Sid Boyce
0 siblings, 2 replies; 27+ messages in thread
From: Adrian Bunk @ 2007-03-22 10:59 UTC (permalink / raw)
To: Randy Dunlap; +Cc: g3vbv, Eric W. Biederman, linux-kernel, auxsvr
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently
2007-03-22 1:32 ` Sid Boyce
@ 2007-03-22 1:42 ` Randy Dunlap
2007-03-22 10:59 ` Adrian Bunk
0 siblings, 1 reply; 27+ messages in thread
From: Randy Dunlap @ 2007-03-22 1:42 UTC (permalink / raw)
To: g3vbv; +Cc: Eric W. Biederman, Adrian Bunk, linux-kernel, auxsvr
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 ***
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently
2007-03-21 20:17 ` Eric W. Biederman
@ 2007-03-22 1:32 ` Sid Boyce
2007-03-22 1:42 ` Randy Dunlap
0 siblings, 1 reply; 27+ messages in thread
From: Sid Boyce @ 2007-03-22 1:32 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Adrian Bunk, linux-kernel, auxsvr
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently
2007-03-21 19:34 ` Adrian Bunk
@ 2007-03-21 20:17 ` Eric W. Biederman
2007-03-22 1:32 ` Sid Boyce
0 siblings, 1 reply; 27+ messages in thread
From: Eric W. Biederman @ 2007-03-21 20:17 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Sid Boyce, linux-kernel, auxsvr
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently
2007-03-21 17:43 ` Sid Boyce
@ 2007-03-21 19:34 ` Adrian Bunk
2007-03-21 20:17 ` Eric W. Biederman
0 siblings, 1 reply; 27+ messages in thread
From: Adrian Bunk @ 2007-03-21 19:34 UTC (permalink / raw)
To: Sid Boyce, Eric W. Biederman; +Cc: linux-kernel, auxsvr
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently
2007-03-08 7:34 ` Sid Boyce
@ 2007-03-21 17:43 ` Sid Boyce
2007-03-21 19:34 ` Adrian Bunk
0 siblings, 1 reply; 27+ messages in thread
From: Sid Boyce @ 2007-03-21 17:43 UTC (permalink / raw)
To: linux-kernel; +Cc: auxsvr, Adrian Bunk
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently
2007-03-08 5:47 ` Andrew Morton
@ 2007-03-08 7:34 ` Sid Boyce
2007-03-21 17:43 ` Sid Boyce
0 siblings, 1 reply; 27+ messages in thread
From: Sid Boyce @ 2007-03-08 7:34 UTC (permalink / raw)
To: Andrew Morton; +Cc: auxsvr, linux-kernel, Adrian Bunk
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently
2007-02-28 16:05 ` auxsvr
@ 2007-03-08 5:47 ` Andrew Morton
2007-03-08 7:34 ` Sid Boyce
0 siblings, 1 reply; 27+ messages in thread
From: Andrew Morton @ 2007-03-08 5:47 UTC (permalink / raw)
To: auxsvr; +Cc: linux-kernel, Sid Boyce, Adrian Bunk
(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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently
[not found] <45E939E1.8050501@argo.co.il>
@ 2007-03-03 20:30 ` Sid Boyce
0 siblings, 0 replies; 27+ messages in thread
From: Sid Boyce @ 2007-03-03 20:30 UTC (permalink / raw)
To: Avi Kivity; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently
2007-03-01 15:11 ` Avi Kivity
@ 2007-03-02 4:22 ` Sid Boyce
0 siblings, 0 replies; 27+ messages in thread
From: Sid Boyce @ 2007-03-02 4:22 UTC (permalink / raw)
To: Avi Kivity; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently
2007-03-01 13:52 ` Sid Boyce
@ 2007-03-01 15:11 ` Avi Kivity
2007-03-02 4:22 ` Sid Boyce
0 siblings, 1 reply; 27+ messages in thread
From: Avi Kivity @ 2007-03-01 15:11 UTC (permalink / raw)
To: g3vbv; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently
[not found] <45E5DE32.2070902@argo.co.il>
@ 2007-03-01 13:52 ` Sid Boyce
2007-03-01 15:11 ` Avi Kivity
0 siblings, 1 reply; 27+ messages in thread
From: Sid Boyce @ 2007-03-01 13:52 UTC (permalink / raw)
To: Avi Kivity; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently
2007-02-28 15:19 Sid Boyce
@ 2007-02-28 16:05 ` auxsvr
2007-03-08 5:47 ` Andrew Morton
0 siblings, 1 reply; 27+ messages in thread
From: auxsvr @ 2007-02-28 16:05 UTC (permalink / raw)
To: linux-kernel
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently
@ 2007-02-28 15:19 Sid Boyce
2007-02-28 16:05 ` auxsvr
0 siblings, 1 reply; 27+ messages in thread
From: Sid Boyce @ 2007-02-28 15:19 UTC (permalink / raw)
To: linux-kernel
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
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2007-03-30 18:01 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-28 16:24 2.6.21-rc1 and 2.6.21-rc2 kwin dies silently Sid Boyce
[not found] <45E939E1.8050501@argo.co.il>
2007-03-03 20:30 ` Sid Boyce
[not found] <45E5DE32.2070902@argo.co.il>
2007-03-01 13:52 ` Sid Boyce
2007-03-01 15:11 ` Avi Kivity
2007-03-02 4:22 ` Sid Boyce
-- strict thread matches above, loose matches on Subject: below --
2007-02-28 15:19 Sid Boyce
2007-02-28 16:05 ` auxsvr
2007-03-08 5:47 ` Andrew Morton
2007-03-08 7:34 ` Sid Boyce
2007-03-21 17:43 ` Sid Boyce
2007-03-21 19:34 ` Adrian Bunk
2007-03-21 20:17 ` Eric W. Biederman
2007-03-22 1:32 ` Sid Boyce
2007-03-22 1:42 ` Randy Dunlap
2007-03-22 10:59 ` Adrian Bunk
2007-03-22 19:49 ` Sid Boyce
2007-03-26 12:02 ` boris
2007-03-27 3:38 ` Sid Boyce
2007-03-27 13:48 ` Eric W. Biederman
2007-03-28 3:26 ` Sid Boyce
2007-03-28 4:14 ` Adrian Bunk
2007-03-28 13:17 ` Eric W. Biederman
2007-03-29 11:35 ` Sid Boyce
2007-03-30 18:00 ` Adrian Bunk
2007-03-29 4:04 ` Eric W. Biederman
2007-03-29 11:37 ` Sid Boyce
2007-03-29 16:16 ` Sid Boyce
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.