Re: Regression in gdm-2.18 since 2.6.24

[Srivatsa Vaddagiri]

On Thu, Apr 03, 2008 at 08:19:16PM +0100, Ken Moffat wrote:
>  Next I went forward to 2.6.25-rc8.  Here, I found that 'patch'
> would not revert the first hunk of that attachment because of a
> context change.  So, I tried reverting only the second hunk (I didn't
> know why it had been changed, so maybe they were to fix different
> problems) - interestingly, that passed all 5 attempts to restart,
> and failed all 5 attempts to shutdown.  I then tried the second
> attachment (which reverts both hunks from rc8) and all of my tests
> passed.

Just to confirm, are you saying you applied patch below on top of
2.6.25-rc8 and it solved your shutdown issues?


---
 kernel/sched_fair.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

Index: current/kernel/sched_fair.c
===================================================================
--- current.orig/kernel/sched_fair.c
+++ current/kernel/sched_fair.c
@@ -510,7 +510,7 @@
 
 	if (!initial) {
 		/* sleeps upto a single latency don't count. */
-		if (sched_feat(NEW_FAIR_SLEEPERS)) {
+		if (sched_feat(NEW_FAIR_SLEEPERS) && entity_is_task(se)) {
 			vruntime -= calc_delta_fair(sysctl_sched_latency,
 						    &cfs_rq->load);
 		}
@@ -1145,7 +1145,7 @@
 	 * More easily preempt - nice tasks, while not making
 	 * it harder for + nice tasks.
 	 */
-	if (unlikely(se->load.weight > NICE_0_LOAD))
+	if (unlikely(se->load.weight != NICE_0_LOAD))
 		gran = calc_delta_fair(gran, &se->load);
 
 	if (pse->vruntime + gran < se->vruntime)


The (reverse of above) patch was required to solve latency issues reported by
several folks (ex: http://ozlabs.org/pipermail/linuxppc-dev/2008-January/050355.html ).

I don't see any obvious reason why this patch affects shutdown. Is there
any way you can get more debug data? Basically when the machine enters
into problem state, I want to see dmesg, /proc/sched_debug output and Sysrq-T
o/p. You could get this by logging into the system over network or (if n/w
is not working in that state) by running this script:

[First ensure that syslogd is capturing kernel messages in
/var/log/messages:

Edit /etc/syslog.conf to ensure it has this line uncommented:

kern.*          /var/log/messages

Restart syslog after any changes
]

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

#!/bin/bash

/etc/init.d syslog stop
mv /var/log/messages /var/log/messages.old.$$
touch /var/log/messages
/etc/init.d syslog start

<Initiate Gnome shutdown thr' command line interface> &

sleep 10
echo "Process List" 	> /tmp/sched-log
ps -elf 		>> /tmp/sched-log
echo 			>> /tmp/sched-log
echo "Sched debug"	>> /tmp/sched-log
cat /proc/sched_debug 	>> /tmp/sched-log
echo "Process stack trace" >> /tmp/sched-log
echo 1 > /proc/sys/kernel/sysrq
echo t > /proc/sysrq-trigger 

echo "dmesg output"	>> /tmp/sched-log
cat /var/log/messages 	>> /tmp/sched-log


<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

sched-log file size would be large. You could send it to me privately or
host it on a website and send a pointer to it.

- vatsa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/