Bug 45611 - Installation hangs booting from RH 7.1 CDROM or floppy image
Summary: Installation hangs booting from RH 7.1 CDROM or floppy image
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-06-23 20:00 UTC by Calvin Webster
Modified: 2008-08-01 16:22 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-30 15:39:02 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Graphical mode installation boot messages (2.60 KB, text/plain)
2001-06-30 16:39 UTC, Calvin Webster
no flags Details
Non-graphical installation boot message - core set (1.27 KB, text/plain)
2001-06-30 16:41 UTC, Calvin Webster
no flags Details
Non-graphical installation boot message - 1st variation (1.32 KB, text/plain)
2001-06-30 16:42 UTC, Calvin Webster
no flags Details
Non-graphical installation boot message - 2nd variation (1.52 KB, text/plain)
2001-06-30 16:43 UTC, Calvin Webster
no flags Details
Non-graphical installation boot message - 3rd variation (1.34 KB, text/plain)
2001-06-30 16:44 UTC, Calvin Webster
no flags Details
Non-graphical installation boot message - 4th variation (1.31 KB, text/plain)
2001-06-30 16:45 UTC, Calvin Webster
no flags Details

Description Calvin Webster 2001-06-23 20:00:45 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)

Description of problem:
CDROM and Floppy boot to install screen okay.

Choosing "graphical" install boots up to message:
    "Floppy drive(s): fd0 is 1.44M"
then hangs idefinitely.

Choosing any other install option boots only to message:
    "Checking 'hlt' instruction..."
then hangs idefinitely.

Changing any BIOS settings only changes the point at which "other" install 
options stop before hanging. "graphical" install _always_ stops at message 
above and hangs.

System currently has RH 6.2 installed and running without problems.

RH 7.0 installation succeeds without hanging or errors.

System Hardware & BIOS:

PowerSpec 2000 (Cyrix GX 200)
Disk:	10GB UltraATA WDC WD102AA
CD:	24X LiteOn LTN242F

BIOS: PhoenixBIOS 4.05:
	BIOS VER:	1559871016
	VSA Ver:	1559870528
	VID Ver:	1319870818

		Type: AUTO:	8455 Mb
		Cyl:		16383
		Hd:		16
		Sec/Trk:	63
		Write Precomp:	none
		Multi-sec xfer:	16 sectors
		LBA Mode Ctrl:	Enabled
		32 bit I/O:	Disabled
		Xfer mode:	Fast PIO 4
		Type: Auto:	CD

	P&P OS:		Disabled
	Integ Snd:	Disabled

	Slot 1:
		BusMaster:	Enabled
		Latency Timer:	Enabled
		Timeout:	0040
	Slot 2:
		BusMaster:	Enabled

	Large Disk Access Mode:	Other (not DOS)

How reproducible:

Steps to Reproduce:
1. Insert installation CDROM or Diskette
2. Power up machine
3. Select boot option (graphical, lowres, nofb, expert)

Actual Results:  "graphical" install boots to the point where 
message "Floppy drive(s): fd0 is 1.44M" is displayed. It never progresses 
beyond this point.

All other install modes hang after the message "Checking 'hlt' 
instruction..." is displayed.

When installing RH 7.0 (doesn't hang) the boot messages that follow are:

"FDC 0 is a post 1991 82077"
(a bunch of "md" (raid) detection messages)
other normal startup messages

Additional info:

Since "graphical" install gets further than other options, I examined 
messages prior to hang. A curious message which appears in each boot:

    "Working around Cyrix MediaGX virtual DMA bugs."

Is there an alternate boot image I can use?
Sounds like something in the generic boot image is causing the hang-up.

Whatever it is, it differs between the 7.0 and 7.1 distributions.

I have a Dell PowerEdge 2200 with RH 7.0 on it. If I install 7.1 can I 
build a boot kernel that will work on my Cyrix GX 200 machine? Can I just 
replace the boot image on CD or Floppy with one built on the PowerEdge? 
I'd really like all my machines to be running the same version.

Here are the contents of the /etc/hwconf (RH 6.2):

class: OTHER
bus: PCI
detached: 0
driver: unknown
desc: "Cyrix Corporation|PCI Master"
vendorId: 1078
deviceId: 0001
pciType: 1
class: OTHER
bus: PCI
detached: 0
driver: unknown
desc: "Cyrix Corporation|5510 [Grappa]"
vendorId: 1078
deviceId: 0000
pciType: 1
class: NETWORK
bus: PCI
detached: 0
device: eth
driver: 3c59x
desc: "3Com Corporation|3c905 100BaseTX [Boomerang]"
vendorId: 10b7
deviceId: 9050
pciType: 1
class: MOUSE
bus: PSAUX
detached: 0
device: psaux
driver: genericps/2
desc: "Generic PS/2 Mouse"
class: CDROM
bus: IDE
detached: 0
device: hdc
driver: ignore
desc: "LTN242F"
class: HD
bus: IDE
detached: 0
device: hda
driver: ignore
desc: "WDC WD102AA"
physical: 16383/16/63
logical: 19885/16/63

Comment 1 Bill Nottingham 2001-06-24 05:14:52 UTC
Those messages are from before it even gets to userland, so it can't
be a kudzu problem. Assigning to kernel.

Comment 2 Arjan van de Ven 2001-06-25 06:40:20 UTC
Could you try passing "no_hlt" or "no-hlt" to the installer commandline ?
This should prevent the use of the "hlt" instruction which seems to hang 
on your machine.

Comment 3 Calvin Webster 2001-06-30 16:39:12 UTC
Created attachment 22292 [details]
Graphical mode installation boot messages

Comment 4 Calvin Webster 2001-06-30 16:41:35 UTC
Created attachment 22293 [details]
Non-graphical installation boot message - core set

Comment 5 Calvin Webster 2001-06-30 16:42:58 UTC
Created attachment 22294 [details]
Non-graphical installation boot message - 1st variation

Comment 6 Calvin Webster 2001-06-30 16:43:51 UTC
Created attachment 22295 [details]
Non-graphical installation boot message - 2nd variation

Comment 7 Calvin Webster 2001-06-30 16:44:47 UTC
Created attachment 22296 [details]
Non-graphical installation boot message - 3rd variation

Comment 8 Calvin Webster 2001-06-30 16:45:37 UTC
Created attachment 22297 [details]
Non-graphical installation boot message - 4th variation

Comment 9 Calvin Webster 2001-06-30 16:46:42 UTC
                        [In answer to your reply]

"Checking for 'hlt' instruction... OK."
"Checking for 'hlt' instruction... disabled"

Typing "linux no-hlt" (accepting default graphical mode) at the installation 
screen turns off this check but still hangs after floppy message.

Typing "linux no-hlt [<any_non-graphic_mode>]" also disables the check 
for 'hlt', but never enters the designated mode. Install always boots graphical 
mode when passing options. It's as though "linux" can only accept one argument. 
I tried several variations to be sure (linux no-hlt expert, linux no_hlt 
expert, linux no-hlt=true expert, linux "no-hlt expert", etc), never succeeding 
in entering a non-graphical mode.

The "kernel" help screen <F4> is somewhat contradictory in its description, 
giving the format for passing options to the kernel as "linux <options>", with 
a note that the user can enter a different installation mode after the option
(s). If this were true, then the format should be "linux <options> 
[<install_mode>]". In practice, the this doesn't work as described.

                            [My Observations]

During the graphical installation boot, the 'hlt' instruction check comes well 
before the floppy drive identification, where it hangs.

Since this _always_ passes in graphical mode, it doesn't seem likely that 'hlt' 
instruction is the primary cause but, more likely, a symptom only present in 
non-graphical installs. I did some more testing, repeating the install boot 10 
times for each mode. Since I couldn't figure out how to pass kernel options 
(i.e. "no-hlt") for modes other than graphical, I could only give the install 

It seemed with non-graphical installation modes that, judging by the messages 
displayed, it appears to stop at random places, albeit more often at the 'hlt' 
instruction check. However, because there were often duplicate messages 
displayed in place of expected ones, it may be that it is still stopping at 
the 'hlt' check but just not displaying it properly. The attached 
file "RH71_non-grph_Inst-boot_msgs_base.txt" contains what I think are the 
actual messages resulting from boot processes in each non-graphical 

After repeating installation attempts 10 times for each mode, I discovered that 
each non-graphical mode booted with the same set of variations in messages 
displayed. These variations are contained in the numbered, "non-grph" 
attachments. In other words, taking into account duplicate messages overwriting 
actual ones, it seems reasonable to postulate that all installation modes may 
be booting the same way and stopping at the same point. For some reason, 
however, duplicate messages unpredictably overwrite actual ones. I still have a 
problem accepting that the primary problem is the 'hlt' instruction check, 

The most reliable symptoms are seen in the graphical installation boot. 
Graphical installs _always_ boot past the 'hlt'instruction check, regardless 
of whether it is disabled, and _always_ stop at the floppy identification.

                             [Attachment Notes]

Attachments represent boot message variations common to each installation mode.

The last "zone" message contains non-alpha-numeric characters (garbage).

Variations in "Kernel command line:" for each mode:

    "expert" always appears before "initrd=initrd.img "
    "lowres" always appears following "lang= "
    "nofb" always appears following "devfs=nomount"

Graphical install passes check of 'hlt' instruction.

Graphical install hangs at same point every time, even when check of 'hlt' 
instruction is disabled.

                                 [Questions & Comments]

Is it possible that these hang-ups are caused by the radically different way in 
which Cyrix MediaGX processors manage memory transfers? 

One of the boot messages says: "Working around Cyrix MediaGX virtual DMA bugs." 
Could there be more of these "bugs" that we are dealing with?

I could not connect to www.cyrix.com to check it out (out of business? VIA 
takeover?), but found information on the PowerSpec site which I used to track 
down what I think is the chip producer.

National Semiconductor apparently makes the "Geode" (GX) integrated circuit and 
its companion XpressGraphics and XpressAudio chips. The Geode processor IC 
contains an x86 core, graphics accelerator, display controller, SDRAM 
controller for graphics and system DMA without L2 cache, and a PCI host 
controller supporting 3 bus masters. That's a lot for one chip to do but it 
seems the biggest difference is how it manages memory transfers for these 

Since the graphical mode _always_ hangs at the floppy identification and the 
non-graphical modes _never_ get past the 'hlt' instruction check, at least part 
of the solution may be found in the difference between the way graphical and 
non-graphical modes are initialized.

Has no one else had these type of problems with the Cyrix GX based machines?

(Sorry I didn't reply earlier. I had to resolve a monitor hardware problem 
before continuing.)

Comment 10 Alan Cox 2001-07-01 19:49:38 UTC
The NatSemi Geode is the new name for the Cyrix MediaGX - they bought that bit
when VIA took the rest and killed it

As far as the DMA bug - it works around a problem where the BIOS magic that
fakes half the hardware has broken SB emulation. (Its not so much a lot of chip
as a lot of magic). 7.1 works on my 5520 and 5530 boxes but the 5510 is very old
and may have other bugs.

Try floppy=nodma,nofifo,slow

That should stress their floppy emulation a lot less.

floppy=debug might also be interesting. Of course it may be dying after the fdc
init but before the next printk

Comment 11 Calvin Webster 2001-07-02 13:29:20 UTC
Tried: "linux floppy=nodma,nofifo,slow"

    Still hangs at same place

Tried: "linux floppy=debug"

    Displays one more message after "Floppy drive(s): fd0 is 1.44M" before 
hanging again:

floppy0: reschedule timeout lock fdc0

Comment 12 Calvin Webster 2001-07-13 19:57:28 UTC
I'll spare you the unproductive attempts.
I finally got past the floppy detection routine with:

    linux floppy=nodma

After trying several combinations I found that, for some reason, I cannot 
supply multiple arguments to "floppy=" using commas. I had to give 
multiple "floppy=" statements. The "nofifo" and "slow" floppy boot options had 
no effect.

It would appear that we are dealing with either a DMA memory management or 
interrupt issue here since installation still fails after passing the floppy 
identification routine.

Now install gets as far as the graphical install screen and sometimes even 
through the first few configuration panels. It will eventually bomb, though, 
causing an "install exited abnormally" error message followed by a shutdown. 

If I select "expert" mode (following the kernel options) I am presented with 
selection menus for driver disk, language, keyboard, and installation method 
options on blue background. Then "anaconda" runs and the installation mode 
returns to graphical display. These results are inconsistent. The installation 
always fails at some random point during graphical (X-Win) selection screens. 
Failure always indicates "install exited abnormally". Sometimes I get 
the "Install exited abnormally -- received signal 11" error followed by a 
kernel panic.

Selecting "nofb" mode reverts to the simple (blue background) installation and 
proceeds much farther. In this mode I always get through the selection screens, 
but it fails either during "Formatting (filesystem)", "Transferring install 
image to hard drive..." or at some point during the actual installation of 
packages. Failure is apparently random and always results in a kernel panic. 
Selecting the X-Window packages bombs the installation very quickly (apparently 
while looking for the display adapter). The "nofb" method always contains the 
error messages:

    Kernel panic: Aiee, killing interrupt handler!
    In interrupt handler - not syncing

Several attempts resulted in failures during "mke2fs", "anaconda", 
and "bdflush", all with the above common failure messages. I recorded all 
values from the first dump, but only the process and error messages for 
subsequent panics. Let me know if you need the stack traces and such.

Should I open another bug report since we aren't hanging during boot?

If you don't think this problem can be resolved, I may have to rever to RH 7.0.


Comment 13 Bugzilla owner 2004-09-30 15:39:02 UTC
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

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