lkml.org 
[lkml]   [2008]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: Regression in gdm-2.18 since 2.6.24
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


\
 
 \ /
  Last update: 2008-04-04 16:29    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site