Your sh process appears to be hung in wait_for_devfsd_finished(). It
would be helpful to know what devfsd was doing at this time. If it
were hung internally (in user-space), it would account for this
behaviour. However, if devfsd crashes, then devfsd_close() will be
called, which will wake any waiters.
> And the following call traces elsewhere:
Are these related?
cron -> pipe_wait()
procmail -> interruptible_sleep_on_locked()
exim -> sys_wait4()
Maybe these are just waiting on mutt(1)?
> Further diagnostic information is available upon request.
That's what I like to hear. Set CONFIG_DEVFS_DEBUG=y and boot with
"devfs=dall" and send me the (verbose) kernel logs. That should show
the sequence of events that lead to this.
> Mr. Gooch, your attention to this matter is much appreciated.
Just "Richard" is fine. I'm not a fan of formality.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
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/