Bug 188185 - netdump encounters spinlock recursion
netdump encounters spinlock recursion
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: netdump (Show other bugs)
5
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Neil Horman
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-04-06 15:12 EDT by Chaskiel Grundman
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-08 14:46:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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 15:12 EDT, Chaskiel Grundman
no flags Details

  None (edit)
Description Chaskiel Grundman 2006-04-06 15:12:24 EDT
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:
always

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 15:12:24 EDT
Created attachment 127423 [details]
answers to netdump questionnaire
Comment 2 Chaskiel Grundman 2006-04-06 15:14:23 EDT
bad edit there:

Version-Release number of selected component (if applicable):
netdump-0.7.14-1.2.1
netdump-server-0.7.0-1
kernel-2.6.16-1.2080_FC5
Comment 3 Neil Horman 2006-06-08 08:10:28 EDT
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
(pcnet32_rx->netif_rx->netpoll_rx->__netpoll_rx->arp_reply->netpoll_send_skb)

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