when the init scripts run pump, the pump process never returns. i have modified the script to fork pump into the background, everything work fine (ip/broadcast are assigned) but the pump process tries to use 100% of cpu. any suggestions? redhat 5.2 installations work find. rehat 6.0/sparc works fine. ed ed
what does 'strace -p <pid of pump>' say?
there are twp pump processes. when i run strace against the process that is not using cpu time i get: "read(3, " and nothing else. when i run strace against the process that is using cpu time, there is no output to strace. -ed ------- Additional Comments From 10/19/99 23:39 ------- [Disclaimer: I have no right to, or expectation of, support from RedHat on this problem; my email is purely intended to assist in its solution rather than request assistance for its solution. Similarly, if there's anything I can do to help figure this problem out just let me know; otherwise, just ignore me. ] I have what may be a variation on this problem: my system hangs when executing the pump command in the initialization scripts. Forking the pump off into the background does not good (the hang happens a little bit further on in the initialization, but not much). The last several lines from doing an "strace -f /sbin/pump $PUMPARGS -i $DEVICE " (copied by hand because of the system hang) are: ... connect(2, {sun_family=AF_UNIX, sun_path="/dev/log"}, 16) = -1 ECONNREFUSED close(2) rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 2 ioctl(2, SIOCGIFFLAGS, 0xbffccd4) = 0 ioctl(2, SIOCGIFFLAGS, 0xbffccd4) = 0 close(2) socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 2 ioctl(2, SIOCSIFADDR, 0xbfffcd64) = 0 ioctl(2, SIOCSIFNETMASK, 0xbfffcd64) = 0 ioctl(2, SIOCSIFBFDADDR The hand happened in the middle of the ioctl printout. I've only tried this once; I don't know if the hang would happen in a different place in other cases. I'm using an Intel EtherPro 10/100+ PCI card; the entry from /proc/pci is: Bus 0, device 13, function 0: Ethernet controller: Intel 82557 (rev 8). Medium devsel. Fast back-to-back capable. IRQ 12. Master Capable. Latency=64. Min Gnt=8.Max Lat=56. Non-prefetchable 32 bit memory at 0xec101000 [0xec101000]. I/O at 0xe800 [0xe801]. Non-prefetchable 32 bit memory at 0xec000000 [0xec000000]. The IRQ it uses (12) is also used by several other boards; I don't believe that any of the others are particularly active (SCSI controller with no disks, USB driver with no USB devices, etc). I have a 400MHz Celeron system, not overclocked. Again, anything I can usefully do to help, just let me know; otherwise I'll just lurk as a cc (if the bug system allows that) on this bug and see what I can figure out on my own. -- Randy Smith randy.com
I'm currently seeing the same thing happening. I also have an Intel EEPRO 100 82557 (rev 8) in a Sony Vaio PCG-Z505R. It appears to be forking to never- never land. If I kill pump after it has spiked my cpu to 100, I can continue normally, with all dhcp info having been added. I've tried using pump version 0.7.3-2 to no avail. Thanks all.
I'm seeing similar behavior under kernel 2.2.14, but interestingly not in any of the 2.2.13 kernels I've tried. It also seemed to work with the early 2.2.14 prereleases, but stopped working around pre8 or so.
21 Feb 2000 I just purchased a new system from www.sunsetsystems.com with Red Hat 6.1 installed and cannot boot it cleanly because of this pump problem - is there still no resolution? I'm using dhcpcd instead of pump. henikoff
This is fixed by the pump available from ftp://people.redhat.com/ewt. Please try this and reopen the bug if it doesn't fix your problem.