Bug 128633

I now have a similar issue:

FC2 x86_64 installed just fine on this machine, with
kernel-2.6.5-1.358.  I upgraded to the latest kernel-2.6.8-1.521, and
everything worked.

I then completely wiped out all partitions, and re-installed with a
software RAID-1 configuration.  Again, the installation was flawless,
and the system booted just fine.

However, when I installed kernel-2.6.7-1.494.2.2 or
kernel-2.6.8-1.521, I experienced the problem described in this bug. 
I could still boot kernel-2.6.5-1.358, but the later kernels just hang
in the grub screen as described earlier in the bug. 

Hardware:

ASUS KV8 Delux SE
AMD64 3200+
1GB RAM (ECC)
RAID-1 using two Maxtor 80GB drives

/proc/mdstat:

Personalities : [raid1]
md1 : active raid1 hdg2[1] hda2[0]
      2047488 blocks [2/2] [UU]
       
md2 : active raid1 hdg3[1] hda3[0]
      76027136 blocks [2/2] [UU]
       
md0 : active raid1 hdg1[1] hda1[0]
      102144 blocks [2/2] [UU]
       
unused devices: <none>

lspci:

00:00.0 Host bridge: VIA Technologies, Inc. VT8385 [K8T800 AGP] Host
Bridge (rev 01)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800
South]
00:07.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host
Controller (rev 80)
00:08.0 RAID bus controller: Promise Technology, Inc. PDC20378
(SATA150 TX) (rev 02)
00:0a.0 Ethernet controller: Marvell Yukon Gigabit Ethernet
10/100/1000Base-T Adapter (rev 13)
00:0c.0 Unknown mass storage controller: Promise Technology, Inc.
20262 (rev 01)00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA
VT6420 SATA RAID Controller (rev 80)
00:0f.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 81)
00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 81)
00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 81)
00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 81)
00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [K8T800
South]
00:11.5 Multimedia audio controller: VIA Technologies, Inc.
VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge
01:00.0 VGA compatible controller: nVidia Corporation NV31 [GeForce FX
5600XT] (rev a1)

/proc/ide/via:
----------VIA BusMastering IDE Configuration----------------
Driver Version:                     3.38
South Bridge:                       VIA vt8237
Revision:                           ISA 0x0 IDE 0x6
Highest DMA rate:                   UDMA133
BM-DMA base:                        0xfc00
PCI clock:                          33.3MHz
Master Read  Cycle IRDY:            0ws
Master Write Cycle IRDY:            0ws
BM IDE Status Register Read Retry:  yes
Max DRDY Pulse Width:               No limit
-----------------------Primary IDE-------Secondary IDE------
Read DMA FIFO flush:          yes                 yes
End Sector FIFO flush:         no                  no
Prefetch Buffer:              yes                 yes
Post Write Buffer:            yes                 yes
Enabled:                      yes                 yes
Simplex only:                  no                  no
Cable Type:                   80w                 80w
-------------------drive0----drive1----drive2----drive3-----
Transfer Mode:       UDMA       PIO      UDMA       PIO
Address Setup:      120ns     120ns     120ns     120ns
Cmd Active:          90ns      90ns      90ns      90ns
Cmd Recovery:        30ns      30ns      30ns      30ns
Data Active:         90ns     330ns      90ns     330ns
Data Recovery:       30ns     270ns      30ns     270ns
Cycle Time:          15ns     600ns      60ns     600ns
Transfer Rate:  133.3MB/s   3.3MB/s  33.3MB/s   3.3MB/s

/proc/ide/pdc202xx:
 
                                Ultra66 Chipset.
------------------------------- General Status
---------------------------------Burst Mode                          
: enabled
Host Mode                            : Normal
Bus Clocking                         : 33 PCI Internal
IO pad select                        : 6 mA
Status Polling Period                : 9
Interrupt Check Status Polling Delay : 8
--------------- Primary Channel ---------------- Secondary Channel
-------------                enabled                          enabled
66 Clocking     disabled                         disabled
           Mode PCI                         Mode PCI
                FIFO Empty                       FIFO Empty
--------------- drive0 --------- drive1 -------- drive0 ----------
drive1 ------DMA enabled:    no               no              yes    
          no
DMA Mode:       NOTSET           NOTSET          UDMA 4            NOTSET
PIO Mode:       NOTSET            NOTSET           PIO 4            NOTSET

/proc/ide/hda/model:
MAXTOR 6L080J4

/proc/ide/hdc/model:
_NEC DV-5500A

/proc/ide/hde/model:
CD-RW BCE5224IM

/proc/ide/hdg/model:
MAXTOR 6L080J4

/etc/grub.conf:

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this
file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/md2
#          initrd /initrd-version.img
#boot=/dev/hda
default=0
timeout=10
splashimage=(hd0,0)/grub/splash.xpm.gz
password --md5 $1$lmtwMRB/$CuaPgOjCkm/uxQIZKFNlO/
title Fedora Core (2.6.5-1.358)
        root (hd0,0)
        kernel /vmlinuz-2.6.5-1.358 ro root=/dev/md2
        initrd /initrd-2.6.5-1.358.img

I've made some progress on this, and come up with a workaround.  Since
the system booted OK on the same kernel without RAID-1, I shutdown and
disconnected hdg (the second drive in the RAID-1 with hda).

The system booted on the new kernel, no problem.  I shutdown again,
and swapped hdg and hdc (a DVD player).  The two hard drives were now
on hda and hdc.  Again, the system booted no problem.  I updated
/etc/raidtab, raidhotadd'ed the hdc partitions, waited for the RAID-1
devices to sync, then shutdown and rebooted.  The system came up fine,
and the RAID-1 arrays on the two drives were all correctly detected
and mounted.

It now appears that the drives in the array have to be BIOS accessible
in order to boot the array (hdg was not, in the original
configuration).  This strikes me as strange, since hda is BIOS
accessible, has the grub bootloader on it, and grub boots (hd0,0). 
Once the kernel gets control, it can access the drive, and previous
kernels had no trouble booting on this configuration.  The original
configuration was preferable, because it split the RAID-1 drives
across two different controllers.  A controller failure will now cause
both drives to fail, defeating some of the benefit of a RAID-1
configuration.

Apparently, the way the kernel handles IDE drives has changed in the
2.6.7 and 2.6.8 kernels, and not for the better.

I am also having this problem.

I upgraded from FC1 to FC2 and I cannot boot any 2.6.X kernels.  i had
to install the latest 2.4 kernel for FC1 just to be able to use my system.

They all stop at the same point described in the bug.

My devices are as follows:

/hda = Windows 98 SE
/hdb = Fedora Core
/hdc = cd/dvd burner (ide-scsi emulation)
/hdd = none
/hde = 80 gig drive on an IDE expansion card.

If you need any more info on my system, please let me know.

any better with the 2.6.10 updates ?

Good timing.  :-)

I had recently reconfigured back to the configuration I previously had (comment
#1), but I'm now using FC3 with the 2.6.10-1.760_FC3 kernel.  It's working fine
for me now.

My issue was solved by removing the QUIET option from grub.conf in FC3 (I've
upgraded since I added my name to this list).

I guess my issue was really with RHGB in that it doesn't actually tell you not
to worry and that the system is booting.  On systems like mine, booting could
take a minute or two, which does a pretty good imitation of freezing when you
don't get notified by the system.

Fedora Core 2 has now reached end of life, and no further updates will be
provided by Red Hat.  The Fedora legacy project will be producing further kernel
updates for security problems only.

If this bug has not been fixed in the latest Fedora Core 2 update kernel, please
try to reproduce it under Fedora Core 3, and reopen if necessary, changing the
product version accordingly.

Thank you.