Bug 167846 - FC4 Installer spews infinite of "release_dev read/write wait queue active!"
Summary: FC4 Installer spews infinite of "release_dev read/write wait queue active!"
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: 4
Hardware: x86_64 Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-09-08 20:27 UTC by Daniel Levine
Modified: 2015-01-04 22:21 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-26 21:31:35 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

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:

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,


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.


Note You need to log in before you can comment on or make changes to this bug.