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: Got too many timeouts waiting for memory page for client 10.12.11.31, ignoring it
netdump: 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
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.
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?