From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050719 Red Hat/1.0.6-1.4.1 Firefox/1.0.6 Description of problem: I am seeing netdump hang in the process of dumping the vmcore file on an e100 network device on my HP ia64 systems. I have run this on also on e1000 and tg3 where I am seeing what I believe is a different problem (see bugzilla 168733). The other issue is regarding the full vmcore not being dumped but the system reboots, this issue is the dump hangs and does not reboot. I have tried this with both ia64 and i386 as the netdump server. I have only used ia64 as the netdump client. During dumping the dump will stop then I will get the following messages in syslog: netdump[25971]: Got too many timeouts waiting for memory page for client 10.12.11.31, ignoring it netdump[25971]: Got too many timeouts waiting for SHOW_STATUS for client 10.12.11.31, rebooting it The client is hung at this point. Version-Release number of selected component (if applicable): kernel-2.6.9-20.EL netdump-0.7.7-3 netdump-server-0.7.7-3 How reproducible: Always Steps to Reproduce: 1. configure netdump server 2. configure netdump client on ia64 using NIC with e100 driver 3. force panic with: echo c > /proc/sysrq-trigger Actual Results: After approx 70MB of data was dumped (variable amount each time) the dump hung, then about a minute later the netdump server generated the syslog messages listed above. Additional info:
Can probably be marked as a dup of 168733.
I think Doug is probably right. This may well be a different bug, since the send and receive paths are not working on the client in this case. We'll leave both open for now.
Agreed -- Doug clarified the difference between the two situations just now. This one's fairly typical (client neither sending or receiving). I can't recall ever seeing the other failure mode, where after a memory page timeout occurred, the client was still able to receive the SHOW_STATUS packet and then reboot itself?
Tainted kernel.