Bug 240510

Summary: EL5 boot hangs at "Starting udev"
Product: Red Hat Enterprise Linux 5 Reporter: Haruo Tomita <haruo.tomita>
Component: kernelAssignee: Prarit Bhargava <prarit>
Status: CLOSED DUPLICATE QA Contact: Martin Jenner <mjenner>
Severity: high Docs Contact:
Priority: high    
Version: 5.0CC: dzickus, tao
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-07-30 11:17:17 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
It reappears 100%.
none
It will reappear 100% by multi-CPU.
none
intel rng driver update patch none

Description Haruo Tomita 2007-05-18 00:49:42 UTC
Description of problem:
EL5 boot hangs at "Starting udev"
In PC of 16CPUs, it hangs according to the probability of 3%.

Version-Release number of selected component (if applicable):
kernel-2.6.18-8.1.3.EL

How reproducible:
100%

Steps to Reproduce:
1. boot EL5
2. 
3.
  
Actual results:
EL5 boot hangs at "Stating Udev".

Expected results:
EL5 boots.

Additional info:
I found the method reproducing this issue. 
It certainly reappears by the attached test program.

1. boot EL5
2. ./start_udev.sh
3.

Comment 1 Haruo Tomita 2007-05-18 01:03:49 UTC
Created attachment 154967 [details]
It reappears 100%.

Comment 2 Haruo Tomita 2007-05-18 01:08:14 UTC
Created attachment 154968 [details]
It will reappear 100% by multi-CPU.

Comment 3 Haruo Tomita 2007-05-18 01:21:53 UTC
Created attachment 154969 [details]
intel rng driver update patch

Comment 4 Haruo Tomita 2007-05-18 01:24:02 UTC
(In reply to comment #3)
> Created an attachment (id=154969) [edit]
> intel rng driver update patch

This issue is reported below. 

http://lkml.org/lkml/2007/2/27/117
 
I created the patch for EL5. 
In the environment of x86, it works well. Please check a patch.


Comment 6 Daniel Riek 2007-06-05 19:04:23 UTC
As a patch is available and the request came from engineering I am proposing
this as an exception for 5.1 and pm_acking.

The severity needs to be reviewed. I am setting prio to high for now (is it 3%
or 100%?, workarounds?) as this did not come through support.

Comment 7 Haruo Tomita 2007-06-05 23:29:35 UTC
(In reply to comment #6)

> The severity needs to be reviewed. I am setting prio to high for now (is it 3%
> or 100%?, workarounds?) as this did not come through support.

I think that there is no workarounds. The probability of a hang is about 3%. 
Reproducibility is 100%.




Comment 8 Issue Tracker 2007-07-26 07:37:10 UTC
This issue is considered as a show-stopper by Hitachi Linux division; they
are actually starting to use RHEL5 from 5.1 but without this being fixed
they are considering to put back all of their Linux business residing
RHEL5.1. I'll have score/exception raised. 


This event sent from IssueTracker by tumeya 
 issue 127015

Comment 9 Larry Troan 2007-07-26 18:23:13 UTC
Has the patch been submitted upstream or is it already in some upstream kernel?

Wow! 

Per Jay, this is a MASSIVE patch which among other things redefines a type
(unsigned to int) in mod_init which could cause "indian" issues. It also exports
  a new variable. This change is all in mainline code.

We need to have Hitachi/Toshiba submit a SMALL patch that fixes the specific
problem in order for us to consider accepting the fix in a RHEL5 minor release
such as 5.1 or 5.2.  

Setting to NEEDINFO