Do this, try to get again kmail [or any other app to freeze]. When it is
hung in there, do:
$ ps axfwl > ps.log.
Now get the PID of the guy and do:
$ find /proc/PID -ls -perm a+r -exec cat {} \; > proc.log
Then go to a console and do Ctrl+ScrollLock - get that output from the
klogd->syslogd and look for the entry that matches the hang process and the
PID. Record the trace and send everything. The traces will look like:
kmail S 00000001 4291079704 4518 394 (NOTLB)
Call Trace:
[<c013d3b5>] do_clock_nanosleep+0x1c5/0x360
[<c011e5c0>] default_wake_function+0x0/0x20
[<c011e5c0>] default_wake_function+0x0/0x20
[<c013cfa0>] nanosleep_wake_up+0x0/0x10
[<c01107c0>] do_gettimeofday+0x20/0xb0
[<c013d03e>] sys_nanosleep+0x6e/0x100
[<c0109a7f>] syscall_call+0x7/0xb
I am trying to see what it is exactly waiting for. From your data, it is
evident that it is somewhere in the rw process where he is getting
stuck, but it needs to be confirmed and traced to a where.
Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own
(and my fault)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/