Messages in this thread | | | Date | Thu, 12 Jan 2006 20:54:51 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH] [5/6] Handle TIF_RESTORE_SIGMASK for i386 |
| |
David Woodhouse <dwmw2@infradead.org> wrote: > > 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?
Yup.
> 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?
Yes, that dmesg output seems to have been truncated.
Here's another one, better:
http://www.zip.com.au/~akpm/linux/patches/stuff/dmesg
Note that I have /bin/zsh in /etc/passwd.
> I note you're running auditd -- FC5-test1 enabled syscall auditing by > default.
This is basically the fc5-t1 .config, only it has selinux turned off due to earlier problems. Suggest you base testing on my config-sony.
> Does the problem persist if you prevent the auditd initscript > from starting up?
<chkconfig auditd off> <reboot> <problem persists>
> If so, let's turn auditing back on
<chkconfig auditd 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.
<does that> <reboots> <logs in>
You wouldn't believe how much stuff that produces. Or maybe you would.
<several minutes pass, disk LED flashing>
<crap starts scrolling past too fast to read. Some complaint from auditd, afaict>
<does alt-SUB>
<grabs the last bit of auditd.log>
http://www.zip.com.au/~akpm/linux/patches/stuff/auditd.log
That looks like the crap I saw scrolling past. How come it came out on the console after a few minutes?
> 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.
Sounds like the jens-barrier-bug. Fixed in current -linus. - 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/
| |