Red Hat Bugzilla – Bug 128633
Kernel freezes system hard right after grub selection
Last modified: 2015-01-04 17:08:11 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET
Description of problem:
This was a redhat 9 machine, upgraded to fedora core 2 by CDROM.
Upgrade process went flawlessly. When done, and rebooting for the
first time, I get the grub menu, select the only kernel choice
(2.6.5), and then am presented with this screen:
Filesystem type is ext2, partition type 0xfd
kernel /vmlinuz-2.6.5-1.358 ro root=/dev/md0
[Linux-bzImage, setup=0x1400, size=0x125fcd]
And that's it. Machine frozen completely. I have to hard reset it.
Now, I can boot from cdrom just fine, and go into recovery mode, and
get into the system from there. Everything otherwise seems to run
and looks good. Except that I cannot boot from the drive(s)?
I also tried upgrading kernel to 2.6.6-1.435.2.3, no change. Also
reinstalled grub, no change. Tried acpi=off, no change.
Version-Release number of selected component (if applicable):
kernel 2.6.5-1.358 & kernel 2.6.6-1.435.2.3
Hardware of machine in question:
Generic Intel VX chipset motherboard
SiI680 PCI ide controller
Two Maxtor 6E040L0's
Software RAID-1 (md1 is /boot, md0 is /, md2 is /var)
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
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.
ASUS KV8 Delux SE
1GB RAM (ECC)
RAID-1 using two Maxtor 80GB drives
Personalities : [raid1]
md1 : active raid1 hdg2 hda2
2047488 blocks [2/2] [UU]
md2 : active raid1 hdg3 hda3
76027136 blocks [2/2] [UU]
md0 : active raid1 hdg1 hda1
102144 blocks [2/2] [UU]
unused devices: <none>
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
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
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)
----------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
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
------------------------------- General Status
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
DMA Mode: NOTSET NOTSET UDMA 4 NOTSET
PIO Mode: NOTSET NOTSET PIO 4 NOTSET
# grub.conf generated by anaconda
# Note that you do not have to rerun grub after making changes to this
# 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
password --md5 $1$lmtwMRB/$CuaPgOjCkm/uxQIZKFNlO/
title Fedora Core (2.6.5-1.358)
kernel /vmlinuz-2.6.5-1.358 ro root=/dev/md2
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
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
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.