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): RHEL3U5 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 initialization. Actual results: Black screen after monitior probing during graphical install startup. Expected results: Graphical install window will appear. Additional info:
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.
Created attachment 120142 [details] x config file
Created attachment 120143 [details] x log file
Cannot startx in a fully installed system as well (see attached files)
*** Bug 162021 has been marked as a duplicate of this bug. ***
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: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162021#c38 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 circumstances. 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.
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)
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. Setting bug to NEEDINFO_REPORTER.
*** Bug 170647 has been marked as a duplicate of this bug. ***
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.