I have the same problem with FC1, FC2test1, FC2test2, FC2test3 and
FC2. The last working version is Redhat 9b.
The text you are looking for is attached in the picture. Sorry, but I
have no second computer so I can't save this output via a serial cable.
My hardware configuration:
Pentium II 450
Intel BX440
Mitsumi 2801T CD Writer
#119293 seems to be a similar bug.

Okay, borrowing a clue from Oliver Dittmer, I just robbed a CD drive
from another machine, and install now proceeds past the place where it
panicked before. Does pause for several seconds at the running
/sbin/loader stage, I suppose that's normal.
I loaded RH 7.3 using the original drive, so the drive is more-or-less
functional. It had trouble reading glibc-common (which is part of my
motivation in moving up to Fedora). So the original CD drive may be
marginal.

Am having same problem on a (slow) IBM 300 GL (300MHz Pentium II),
INTEL 440 LX/EX chipset, 64MB memory, FX320X, CDRom.
Note the CDRom driver and timer interrupt in the traceback.
What's the chance that this is due to the CDRom driver race
fixed by a patch from Jens Axoe in kernel 2.6.7?
Possibly related bugs 115458 and 129832.

From a first glance it seems hwgroup->handler is wrong . The sequence
in the trace appears to be a mix of two sets of traces (ie some is
stack noise).
ide_timer_expiry -> cdrom_timer_expiry -> ??
then ide_timer_expiry clls
ide_do_request->start_request->ide_do_rw_cdrom ->
cdrom_start_packet_command(..,cdrom_start_read_confirmation)
and fires up a new command
That imples that on ide_timer_expiry entry
hwgroup->handler is set hwgroup->drive is valid
so a command timed out (which is fine by itself)
hwgroup->expiry would be cdrom_timer_expiry and for all commands on
the install which will return 0 for all the cases used by the
installer and thus fall through to generic handling and eventually
potential (and apparently actually) to the 'it's dead, issue new
command' case
At that point we bug in ide_execute_command because the current
command isnt in fact dead, so someone somewhere on the error path did
the wrong thing and appears to have issued a command in the error
handling path before we execute a new command

Very interesting. Unfortunately, I don't have a Fedora Core 3
CD handy right now. So I used a FC3-Test1 which I had handy.
(The problem originally occurred with the FC2 install CD.)
With hdc=ide-scsi (CDRom is on hdc), I no longer get a panic.
I used
linux mediacheck hdc=ide-scsi
I got the language prompt, etc. from the installer. But it
finally said that it could not locate the install CD on "any
of the CD drives" when I select a "install from local CD".

Used the Fedora Core 2 CD that successfully installed other machines
and first showed the CDRom problem on the problem machine.
Boot machine with CDRom in drive.
In booting, it spins up the CD drive for a few seconds loads, I think
you call it the "preboot environment", and spins down the CD.
I type "linux mediacheck"
CD drive spins up for about 10 seconds, and the standard boot messages
fly by on the "alt-F1" console. "alt-F2" doesn't change the display.
"alt-F3" and "alt-F4" show two different sets of messages.
CD drive spins down.
About 20 seconds later CD drive spins up for about 5 seconds then
down again.
About one minute later the panic message appears.
After the panic message, the machine is dead and can't switch
consoles.
Before that, I switched among the consoles actively.
All of the messages appear to be progress messages with no obvious
errors logged.
Alt-F1 shows the sequence of boot messages starting at the first
5 second spinup of the CD and ends ends with
"running/sbin/loader" just after the CD spin down
lasting for 20 seconds
Alt-F3 shows a sequence of progress messages about probing,
module loading, etc. during the 20 second CD spin
down. It then shows "trying to mount cd device hdc"
coincident with the second spin up (after the 20
seconds, before the one minute delay to the panic)
Alt=F3 shows a different sequence of messages, ending with
messages about the ehternet card (e100: eth0: eth100_probe:)
I also tried this with a "vga=773" on the boot line. This gives
me a smaller font and I can even check the messages right before
the panic. Basically, the "running /sbin/loader" and "trying
to mount" and "e100" messages are the last before the panic.
Fedora core 1, which runs fine on the machine identifies the
CDRom drive as
hdc: FX320S, ATAPI CD/DVD-ROM drive
...
hdc: attached ide-cdrom driver
hdc: ATAPI 32X CD-ROM drive, 256kB Cache, DMA
in dmesg.

The same thing seemed to be happening to me today.
At the start of the installation I did:
linux ide=nodma
Everything worked fine after that. I have some funky no name CD-ROM drive in my
system. And an old Intel motherboard (last BIOS update was 1999).

The incorrect request blanking bug was fixed in update kernel and also in RHEL4
gold after SGI pinned it down. The ide=nodma workaround suggested is a good
solution until a kernel update is done.
The actual bug occurs when a CD command is retried.

1. System hangs while executing /sbin/loader in FC4 also.
2. Sometimes just before the first screen starts up in GUI installation mode,
the monitor went into undesirable format (unreadable too...coz it shows numerous
vertical lines with numerous colours), then the system hangs thereafter. This is
also in FC4.

[This comment added as part of a mass-update to all open FC4 kernel bugs]
FC4 has now transitioned to the Fedora legacy project, which will continue to
release security related updates for the kernel. As this bug is not security
related, it is unlikely to be fixed in an update for FC4, and has been migrated
to FC5.
Please retest with Fedora Core 5.
Thank you.

A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.
Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.
This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.
Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.
In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed. See bug 207474 for further details.
If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.
If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.
Thank you.

Note

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