Description of problem: The problem shows up when installing the latest RPM-kernel update (2.4.20-13.8bigmem), with the predecessor 2.4.18-27.8.0bigmem or ealier everything is fine. Latest glibc update is also installed like all RPM updates available from the RedHat web-site for 8.0. Hardware is a Fujitsu Siemens HPC-Line 2 Processor Athlon 2200+ with a Tyan board. It does not matter, if APIC is disabled or not. Problem is, that signals behave weird. Different phenomenons: 1) start sleep 1000 in the background: prompt# sleep 1000 & [1] 986 Now attach strace to the process: prompt# strace -p 986 gettimeofday({1054049100, 159434}, NULL) = 0 nanosleep({972, 34012000}, Now press Ctrl-C. What happens now, is, that the shell says, the sleep is suspended, ps reports status T and another strace shows nothing. A kill -CONT 986 makes sleep 'run' again and change to status S 2) start an arbitrary rpm Update: rpm -U /bla/bla/bla.rpm what takes a while. Press Ctrl-C. The rpm goes to suspend status, like i would expect pressing Ctrl-Z . 3) rpm update of the kernel (same RPM using -U --force) stops (sometimes, unclear, in what situation) to do anything. strace shows, that the rpm makes a call to pause() and waits. There are no child processes. An strace with -f shows, that rpm starts a shell subprocess and this guy in turn starts modprobe, what exits with _exit(-1) . The shell exits with exit(0). The rpm process seems not to get any SIGCHLD. Probably this is in fact an rpm problem, but i don't see the signal mask having set the bit for SIGCHLD in /proc/<PID>/stat Version-Release number of selected component (if applicable): 2.4.20-13.8bigmem shows the problems, any earlier does not. How reproducible: see above, example 1 is quite simple. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: IMHO it is not a TTY implementation problem, because of the rpm subprocess phenomenon.
The problem is not visible on a Dell Xeon single processor with identical installation
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/