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
Created attachment 127423 [details] answers to netdump questionnaire
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
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)