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
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
Latency Timer: Enabled
Large Disk Access Mode: Other (not DOS)
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
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):
desc: "Cyrix Corporation|PCI Master"
desc: "Cyrix Corporation|5510 [Grappa]"
desc: "3Com Corporation|3c905 100BaseTX [Boomerang]"
desc: "Generic PS/2 Mouse"
desc: "WDC WD102AA"
Those messages are from before it even gets to userland, so it can't
be a kudzu problem. Assigning to kernel.
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.
Created attachment 22292 [details]
Graphical mode installation boot messages
Created attachment 22293 [details]
Non-graphical installation boot message - core set
Created attachment 22294 [details]
Non-graphical installation boot message - 1st variation
Created attachment 22295 [details]
Non-graphical installation boot message - 2nd variation
Created attachment 22296 [details]
Non-graphical installation boot message - 3rd variation
Created attachment 22297 [details]
Non-graphical installation boot message - 4th variation
[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.
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.
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
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.
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
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
floppy0: reschedule timeout lock fdc0
I'll spare you the unproductive attempts.
I finally got past the floppy detection routine with:
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
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
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
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
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.
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/