Bug 123960 - (AGP? INTEL) Hang during bootup with "agpgard: Unsupported Intel chipset" message
(AGP? INTEL) Hang during bootup with "agpgard: Unsupported Intel chipset" mes...
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2004-05-21 21:26 EDT by Karl Auerbach
Modified: 2015-01-04 17:06 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-25 20:34:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Karl Auerbach 2004-05-21 21:26:44 EDT
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:
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):

How reproducible:

Steps to Reproduce:
1. Boot machine

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.
Comment 1 Alan Cox 2004-05-22 11:02:45 EDT
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 ?

Comment 2 Karl Auerbach 2004-05-24 17:04:14 EDT
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.

Comment 3 Dave Jones 2004-05-25 08:27:59 EDT
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.
Comment 4 Karl Auerbach 2004-05-25 19:18:12 EDT
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:

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.
Comment 5 Karl Auerbach 2004-05-25 21:53:07 EDT
I just swapped the drive from my test machine into another machine 
that is identical except for the bios level and the third ethernet 

The problem moved with the disk.  In other words, this bug seems not 
to be due to a glitch in one particular computer.
Comment 6 Dave Jones 2004-07-12 17:00:26 EDT
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).
Comment 7 Karl Auerbach 2004-07-13 17:14:50 EDT
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

It's somewhat hard for me to do much boot-time testing since I'm still
suffering under another boot-time bug

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