Bug 168735 - netdump hangs while dumping via e100 driver on ia64
Summary: netdump hangs while dumping via e100 driver on ia64
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: netdump
Version: 4.0
Hardware: ia64
OS: Linux
Target Milestone: ---
: ---
Assignee: Thomas Graf
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-09-19 21:38 UTC by Doug Chapman
Modified: 2014-06-18 08:28 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2008-06-13 20:37:28 UTC

Attachments (Terms of Use)

Description Doug Chapman 2005-09-19 21:38:48 UTC
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, ignoring it
netdump[25971]: Got too many timeouts waiting for SHOW_STATUS for client, 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:

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:

Comment 1 Dave Anderson 2005-09-20 12:46:20 UTC
Can probably be marked as a dup of 168733.

Comment 2 Jeff Moyer 2005-09-20 14:36:29 UTC
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.

Comment 3 Dave Anderson 2005-09-20 15:18:10 UTC
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?

Comment 4 Thomas Graf 2008-06-13 20:37:28 UTC
Tainted kernel.

Note You need to log in before you can comment on or make changes to this bug.