Bug 170628 - RHEL3U5 System "hangs" when starting the xserver with vesa driver on 64 bit
Summary: RHEL3U5 System "hangs" when starting the xserver with vesa driver on 64 bit
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: XFree86   
(Show other bugs)
Version: 3.0
Hardware: x86_64 Linux
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: David Lawrence
: 162021 170647 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2005-10-13 13:46 UTC by jon chaplick
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-05-02 10:27:23 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
x config file (3.08 KB, text/plain)
2005-10-18 20:35 UTC, jon chaplick
no flags Details
x log file (93.63 KB, text/plain)
2005-10-18 20:35 UTC, jon chaplick
no flags Details

Description jon chaplick 2005-10-13 13:46:47 UTC
Description of problem:

During install with an ATI V5100 (R423) the vesa driver gets blocked during the
int10 vesa 0x4F01 call in VESASetMode. 

Version-Release number of selected component (if applicable):


How reproducible:

Boot from the install CD. 
Proceed until graphical install. 
System gets stuck in a mode set/query int10 call in PreInit stage of driver

Actual results:

Black screen after monitior probing during graphical install startup.

Expected results:

Graphical install window will appear.

Additional info:

Comment 1 Mike A. Harris 2005-10-18 20:22:32 UTC
Thanks for the report.  For diagnostic purposes, please try a text
mode installation, by booting with "linux text", and then run
"system-config-display --reconfig" once the installation is complete
and you've rebooted.

Booting into the installed OS, are you able to start the X server with
startx, or gdm afterward?  Please attach your X server log file, config
file, and a sysreport to the bug report as individual file attachments
using the link below.

Thanks in advance.

Comment 2 jon chaplick 2005-10-18 20:35:29 UTC
Created attachment 120142 [details]
x config file

Comment 3 jon chaplick 2005-10-18 20:35:56 UTC
Created attachment 120143 [details]
x log file

Comment 4 jon chaplick 2005-10-18 20:36:38 UTC
Cannot startx in a fully installed system as well (see attached files)

Comment 5 Mike A. Harris 2005-10-20 23:00:39 UTC
*** Bug 162021 has been marked as a duplicate of this bug. ***

Comment 6 Mike A. Harris 2005-10-20 23:12:02 UTC
Bug #162021 was the IT escalated bug tracking this issue previously.

The cause of this problem is not currently known/understood, so QA has
NACK'd this bug for RHEL3-U7 in:


The RHEL3-U7 devel ACK freeze is tomorrow, and since this is already NACK
by QA, it is unlikely to be addressed in the U7 timeframe without exceptional

However, if ATI can narrow down the exact problem which is causing this,
or provide us with a 100% reproduceable test case that can be reproduced
at Red Hat, there may be time yet to investigate a fix, however we can't
make any promises at this point.

U7 may be the final 'support' release of RHEL3, so it is possible that the
problem may never be addressed if it can't be diagnosed in time to make the
U7 cut.

Comment 7 Mike A. Harris 2005-10-20 23:13:48 UTC
The following items from the log file appear odd, and may provide clues, as
they seem to merge 2 unrelated 32bit values into one 64bit value:

	[14] -1	0	0x3001d8300000 - 0x3001d830ffff (0x10000) MX[B](B)
	[15] -1	0	0xd8300004d0000000 - 0xd8300004d7ffffff (0x8000000) MX[B](B)

Comment 8 Mike A. Harris 2005-10-20 23:16:46 UTC
Later, these values seem to cause an invalid memory allocation:

(WW) ****INVALID MEM ALLOCATION**** b: 0xd8300004d0000000 e:
0xd8300004d7ffffff correcting
(II) window:
	[0] -1	0	0xd0000000 - 0xd80fffff (0x8100000) MX[B]
(II) resSize:
(II) window fixed:
	[0] -1	0	0xd0000000 - 0xd80fffff (0x8100000) MX[B]
(WW) ****INVALID MEM ALLOCATION**** b: 0x3001d8300000 e: 0x3001d830ffff correcting

As we are unable to reproduce the problem internally in order to debug,
we ask if ATI can diagnose/debug the issue further as they seem to be
able to readily reproduce the problem.

Thanks in advance.


Comment 9 Mike A. Harris 2005-10-31 13:39:57 UTC
*** Bug 170647 has been marked as a duplicate of this bug. ***

Comment 11 Mike A. Harris 2006-05-02 10:27:23 UTC
No information has been provided on this issue for quite some time now, and
we do not have this hardware available to directly diagnose the issue.

Users experiencing this problem should try using the kernel framebuffer
driver as a possible workaround, or try RHEL-4 to see if the problem
exists there.

Closing report as INSUFFICIENT_DATA, as we are unable to reproduce this
problem on available hardware.

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