Bug 727324

Summary: Able to softlockup kernel-PAE-2.6.35.13-92.fc14.i686 when running with multiple CPUs (smp)
Product: [Fedora] Fedora Reporter: David Shaw <dshaw>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 14CC: gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-10-05 19:19:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Program to softlockup the kernel none

Description David Shaw 2011-08-01 20:02:15 UTC
Created attachment 516206 [details]
Program to softlockup the kernel

Description of problem:

Running a program that does a lot of fork/waitpids from multiple threads can cause the kernel to softlockup.  It does not recover afterwards.  This seems to only happen if there is multiple CPUs (I tested with four).

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

kernel-PAE-2.6.35.13-92.fc14.i686

How reproducible:

Every time

Steps to Reproduce:
1. Run the attached program
  
Actual results:

If the kernel is set to panic on softlockup (kernel.softlockup_panic=1) then there is a panic.  Otherwise, the system just hits softlockup over and over again.  The system is not usable (not pingable, etc).

Expected results:

Nothing should happen.

Additional info:

I also tried this on kernel-PAE-2.6.35.12-88.fc14.i686.rpm and kernel-PAE-2.6.35.13-91.fc14.i686.rpm and saw the same problem.

However, I could *not* reproduce this using kernel-PAE-2.6.35.6-45.fc14.i686.rpm (the kernel that shipped with F14).

Comment 1 David Shaw 2011-10-05 19:19:10 UTC
This bug seems to have been resolved (intentionally or not) in kernel-PAE-2.6.35.14-96.fc14.i686