Bug 167846

Summary:	FC4 Installer spews infinite of "release_dev read/write wait queue active!"
Product:	[Fedora] Fedora	Reporter:	Daniel Levine <daniel.levine>
Component:	kernel	Assignee:	Dave Jones <davej>
Status:	CLOSED WORKSFORME	QA Contact:	Brian Brock <bbrock>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4	CC:	pfrields, pjones, wtogami
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-09-26 21:31:35 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:

Description Daniel Levine 2005-09-08 20:27:31 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803

Description of problem:
I have several Dell 670n workstations. All of them installed fine from 2 sets of Fedora Core 4 CDs. All but one that is. This last machine doesn't want to install. I am unable to do:

- Graphical Install
- Text Based Install
- CD Checksum
- Emergency Repair
- Graphical Install with noprobe option
- Text Install with noprobe

All of these bring me to the same state. It starts to boot, but eventually spews out an inifinite number of:

release_dev: tty3: read/write wait queue active!

It appears to happen after a line that has ide1 on it. I have tried replacing the media and CD/DVD reader with no difference.

I am able to run memtest86. So far no reported errors, but I have 4GB to test.

Version-Release number of selected component (if applicable):
Fedora Core 4 base version of install

How reproducible:
Always

Steps to Reproduce:
1. Insert FC4 install disk 1
2. Install with linux, liunx text, linux noprobe, linux text noprobe, linux repair

Actual Results:
See install start to boot, but then inifinite loop of this message:

release_dev: tty3: read/write wait queue active!

Expected Results: Proceed to normal installation screen.

Additional info:

System has SCSI disk.
Has dual Pentium processors with Hyper Threading turned on.
(System is just like the others purchased from Dell in same batch that work fine)

I am able to reboot with ctrl-alt-del when this happens.
I can also remove the CD with the CD-reader eject button.

Comment 1 Daniel Levine 2005-09-12 14:00:08 UTC

Thinking about this more over the weekend, I'm not cerain if this is an 
anaconda issue or a kernel booting issue.  I suppose I never get fully booted 
into anaconda.

Comment 2 Dave Jones 2005-09-24 01:21:08 UTC

Are you trying to install the x86-64 release ? (The bug is filed against i386)
The reason I ask, is that for x86-64 I believe we use the SMP kernel for installs.

If so, things to try..

- booting with maxcpus=1
- booting with acpi=off

It smells like a race in the tty layer to me, so limiting the install to a
single CPU is probably the best behaviour.

For future releases, we should probably make sure the installer always starts up
with 1 cpu is isolinux.

Comment 3 Daniel Levine 2005-09-26 14:17:31 UTC

I tried your suggestions.  It appears that the acpi=false option does the 
trick.  The maxcpus=1 does not.  I have 2 Intel Xeon processors with hyper 
threading and probably EM64T.  I am definitely an SMP system.  I didn't 
realize that it's not considered an i686 system anymore.

Thanks for your help,

-Dan

Comment 4 Dave Jones 2005-09-26 19:22:15 UTC

so, if you do the install with acpi disabled, and then run yum update, it'll
grab the latest updates, including a newer kernel. Can you see if that one then
boots without the acpi disabled ?

Comment 5 Daniel Levine 2005-09-26 19:57:18 UTC

Unfortunately, I cannot do what you requested.  The system installed is in a 
secure environment.  However, using our SNARE enabled 2.6.12 kernel, it seems 
like we need the acpi=off still on boot.  Otherwise, nash hangs forever 
(waited over 15 minutes).  Normally, nash hangs for 2 minutes and then 
proceeds for us.

Comment 6 Dave Jones 2005-09-26 21:31:35 UTC

Ok, given the inability to debug this further, I'll close this bug, as you have
the acpi=off workaround.

Thanks.