Bug 167846 - FC4 Installer spews infinite of "release_dev read/write wait queue active!"
FC4 Installer spews infinite of "release_dev read/write wait queue active!"
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-08 16:27 EDT by Daniel Levine
Modified: 2015-01-04 17:21 EST (History)
3 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Daniel Levine 2005-09-08 16:27:31 EDT
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 10:00:08 EDT
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-23 21:21:08 EDT
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 10:17:31 EDT
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 15:22:15 EDT
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 15:57:18 EDT
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 17:31:35 EDT
Ok, given the inability to debug this further, I'll close this bug, as you have
the acpi=off workaround.

Thanks.

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