Messages in this thread | | | Subject | Re: Regression in gdm-2.18 since 2.6.24 | From | Peter Zijlstra <> | Date | Tue, 08 Apr 2008 10:42:49 +0200 |
| |
On Tue, 2008-04-08 at 14:20 +0530, Srivatsa Vaddagiri wrote: > On Mon, Apr 07, 2008 at 12:48:33AM +0100, Ken Moffat wrote: > > Well, I found your analysis convincing. Unfortunately, my hardware > > disagreed. Testing -rc8 with CONFIG_GROUP_SCHED disabled (a test is > > a mixture of 5 attempts to restart and 5 to shutdown): > > > > 1. the base version success is 4/10 > > > > 2. increasing the granularity by a factor of 10 as you requested, > > success is 8/10 > > This makes me think that we are just exposing a timing related problem > in gdm here. > > How abt a larger factor? > > # echo 200000000 > /proc/sys/kernel/sched_wakeup_granularity_ns > > Does that make it 10/10 ?! > > Anyway, it would be interesting to analyze the failure scenario more > (with help from gdm developers). Can you get some more debug data in this > regard? > > Before you shutdown, > > # strace -p <gdm-binary-pid1> 2>/tmp/gdmlog1 & > # strace -p <gdm-binary-pid2> 2>/tmp/gdmlog2 & > > Now shutdown and wait few minutes to confirm its not working. Send me > the strace log files ..Hopefully this will give a hint on what they are > deadlocked on (in the last log you sent, i can see both gdm-binaries in > sleep state ..whether that was a momentary state or whether they are > actually deadlocked, will be confirmed by strace logs above). > > > If I was confused earlier, I guess I must be dazed and confused > > now! > > me too! > > Ingo/Peter, Any other suggestions you have?
Sounds like a race condition to me; non of these changes affect correctness in a strict manner of speaking.
| |