Bug 188185 - netdump encounters spinlock recursion
Summary: netdump encounters spinlock recursion
Alias: None
Product: Fedora
Classification: Fedora
Component: netdump   
(Show other bugs)
Version: 5
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Neil Horman
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2006-04-06 19:12 UTC by Chaskiel Grundman
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-08-08 18:46:41 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
answers to netdump questionnaire (18.84 KB, text/plain)
2006-04-06 19:12 UTC, Chaskiel Grundman
no flags Details

Description Chaskiel Grundman 2006-04-06 19:12:24 UTC
Description of problem:

Version-Release number of selected component (if applicable):
netdumping an FC5 guest in a vmware session with alt-sysrq-c results in a
BUG: spinlock recursion on CPU#0
message and the netdump does not complete

How reproducible:

Steps to Reproduce:
1. Install FC5 in vmware workstation 4.5.x or 5.5.x
2. yum update the system (kernel-2.6.16-1.2080_FC5)
3. configure netdump (I use NETDUMPKEYEXCHANGE=none, but that should not matter)
Actual results:
netdump-server creates vmcore-incomplete, logs errors.
client does not reboot.

Expected results:

netdump-server creates vmcore.
client reboots after netdump
Additional info:
netdump questionnaire attached

Comment 1 Chaskiel Grundman 2006-04-06 19:12:24 UTC
Created attachment 127423 [details]
answers to netdump questionnaire

Comment 2 Chaskiel Grundman 2006-04-06 19:14:23 UTC
bad edit there:

Version-Release number of selected component (if applicable):

Comment 3 Neil Horman 2006-06-08 12:10:28 UTC
Can you please provide a binary capture of the netdump in progress from this
system using tcpdump?  I think this may be the result of us needing to send a
arp reply from within the receive path which causes the lp->lock semaphore to be
taken twice in the same context in pcnet32.  At least thats the only way I see
us getting from the rx to the tx path within a netdump operations

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