On Thu, 2006-01-12 at 19:59 -0800, Andrew Morton wrote:
> applied, or with all of David's patches applied, an FC5-test1 machine hangs
> during the login process (local vt or sshd). An FC1 machine doesn't
> exhibit the problem.
So the 'successful' login reported at 19:21:45 never actually completed
and gave you a shell?
I can't make out which process it is that's misbehaving... and your
login was pid 2292 but I don't see your SysRq-T output going up that
far. Am I missing something?
I note you're running auditd -- FC5-test1 enabled syscall auditing by
default. Does the problem persist if you prevent the auditd initscript
from starting up? If so, let's turn auditing back on and actually make
use of it -- assuming the offending process is actually one of your own
after the login has changed uid, can you set an audit rule to log all
syscalls from your own userid? (add '-Aexit,always -Fuid=500'
to /etc/audit.rules, assuming 500 is your own uid). Then show me the
appropriate section from /var/log/audit/audit.log.
I tested both with and without audit on PPC -- David, did you test this
patch with auditing enabled on i386?
Will attempt to reproduce locally... I've _also_ seen login hangs on
current linus trees but they've been different (and on that machine I
haven't had the TIF_RESTORE_SIGMASK patches either). It happens on disk
activity though -- after 'rpm -i <kernelpackage>' the whole machine
locks up and I have no more file system access. If your SysRq-T got to
the disk, I suspect you aren't seeing the same problem.
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
