Bug 464701

Summary: BUG: soft lockup - CPU#1 stuck for 61s! [named:1880]
Product: [Fedora] Fedora Reporter: Bojan Smojver <bojan>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: high    
Version: 9CC: kernel-maint
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-10-14 22:35:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Kernel messages on lockup
none
Output of lspci -vv and lspci -nn (Shuttle K45) none

Description Bojan Smojver 2008-09-29 22:22:50 UTC
Created attachment 318016 [details]
Kernel messages on lockup

Description of problem:
Upon an unsuccessful IPSec tunnel creation, the kernel locks up.

Version-Release number of selected component (if applicable):
2.6.26.3-29.fc9.i686

How reproducible:
Always.

Steps to Reproduce:
1. Configure and bring up IPSec tunnel (phase I)
2. Make sure the other end isn't actually responding to IPSec traffic properly.
3. Attempt to ping trough the tunnel.
  
Actual results:
Kernel locks up (more diagnostics will be attached).

Expected results:
Should continue as normal.

Additional info:
Output of lspci will be attached too.

Comment 1 Bojan Smojver 2008-09-29 22:23:40 UTC
Created attachment 318018 [details]
Output of lspci -vv and lspci -nn (Shuttle K45)

Comment 2 Chuck Ebbert 2008-09-30 04:42:56 UTC
I'm pretty sure this is fixed in 2.6.26.5-45. There was a deadlock in __xfrm_state_destroy() fixed by commit 37b08e34a98c664bea86e3fae718ac45a46b7276 which was put into 2.6.26.4.

Comment 3 Bojan Smojver 2008-09-30 06:35:28 UTC
All right, I see this update is destined for stable. Will report back with findings.

Comment 4 Chuck Ebbert 2008-10-04 05:56:06 UTC
Close the bug if it's fixed.

Comment 5 Bojan Smojver 2008-10-04 08:47:52 UTC
Will do, but I have to get our Cisco guy to screw the setup on the other end in order to replicate. Best case scenario, Tuesday, Sydney time.