From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; X11; Linux i686) Opera 7.50 [en] Description of problem: During bootup system hangs. Last message on console is: agpgart: Unsupported Intel chipset (device id: 254c) This is on a machine that ran flawlessly with Fedora 1. This hang is intermittent - sometimes it is permanent and sometimes the kernel continues to boot after a delay of 10 to 20 seconds. (It may be tied to whether the reboot is due to a reset or a power cycle. ) If the system does continue to boot it seems to come up OK and the video system runs fine (I'm assuming the "agpgart" is somehow related to the AGP port) and X fires up fine. The same thing happens if I boot the non-SMP kernel. This is on a Supermicro 6013P-i (X5DPR-iG2+ motherboard), dual 2.4 Xeon's, 512M memory, single 40g IDE drive. Motherboard info at:http: //www.supermicro.com/products/motherboard/Xeon/E7501/X5DPR-iG2+.cfm It has a USB keyboard and USB mouse. There is a possibly related problem - during Anaconda during the Fedora 2 install off of the CDROM the install properly identifies the video chipset and monitor type but then fails to start X for the bitmapped graphical install and falls back to the old character-graphic install. Version-Release number of selected component (if applicable): kernel-2.6.5-1.358smp How reproducible: Always Steps to Reproduce: 1. Boot machine 2. 3. Actual Results: The system hangs about 50% of the time. The other 50% it pauses for several seconds before continuing. Additional info: I don't know if there is any relationship but the machine does not always reboot automatically if it's brought down with the "restart" command. It worked correctly in this regard under Fedora 1.
From the documentation Intel E7501 chipset (using MCH, ICH3-S, P64H2) ATI Rage 64 XL onboard video. AGP looks like a missing table entry. We know 7505 not 7501. Reviewing the code there is a harmless leak on this path (tiny) and on the later error paths where we don't free the bridge allocated at the top of agp_intel_probe. I don't see any reason that would fail. Is there anything in dmesg after the case where it pauses ?
Here's the last parts of dmesg when it hangs (I'm retyping this from notes, so I might introduce typos): Uncompressing Linux... Ok, booting the kernel. ACPI: S3 and PAE do not like each other for now, S3 disabled. audit(1085432160.302:0): initialized agpgart: Unsupported Intel chipset (device id: 254c) And that's all she wrote. When the machine does proceed to boot past these messages they flash by too fast to examine and the dmesg buffer is too small, so they get pushed out of the dmesg fifo and are lost. It looks like the next thing to come out is the kernel version number. There seems to be little rhyme or reason why it goes on or why it hangs - it suggests to me an uninitialized bit in the hardware that comes up in a random state.
dmesg -s 40000 >dmesg.out should get you the whole log. if you can find out what it spits out after the agpgart messages, that might be a clue.
OK, I'll grab the dmesg stuff - since it's long I'll put it up on my web server and include the URL... OK,it's posted at: http://www.cavebear.com/tmp/tmpi/dmesg.txt In the meantime I'm running some additional tests. It seems that there is some kind of interaction with the "rhgb quiet" parameters to the kernel. Those parameters are set when the agpgart hang occurs. When I remove them the agpgart message still happens but the boot proceeds with no apparent delay. By-the-way this system is configured to comes up to init level 3 rather than 5. Later today I plan to lift the disk and put it into an identical hardware platform to make sure that this is not a glitch on one particular machine. I'll post the result of that test later today.
I just swapped the drive from my test machine into another machine that is identical except for the bios level and the third ethernet NIC. The problem moved with the disk. In other words, this bug seems not to be due to a glitch in one particular computer.
is this still occuring with the latest errata kernel ? or the one from people.redhat.com/arjanv/2.6 ? Does booting with the agp=off argument make any difference ? (also if you have 'quiet' in your arguments, remove it, and you may get more info when it hangs).
It seems to have stopped happening, i.e. things got better, a couple of kernel updates ago (I'm now running 2-6.6.1-435.2.3 both smp and uniprocessor). It's somewhat hard for me to do much boot-time testing since I'm still suffering under another boot-time bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125832