Bug 85738

Summary: Installed kernel(s) boot but with no video nor initlevel-3 login except using rescue mode
Product: [Retired] Red Hat Linux Reporter: Michael P Moran <vampm>
Component: kernelAssignee: Arjan van de Ven <arjanv>
Status: CLOSED WONTFIX QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.2   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-09-30 15:40:36 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Contents of log messages for rescue and stock kernels and also lspci of machine none

Description Michael P Moran 2003-03-06 18:37:35 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.7 [en] (Win95; I)

Description of problem:
Virgin installation (no other OS on machine) proceeds normally, including all setup dialogs and internal probings of hardware. Both 
Monitor (AOC Spectrum Dlr7a) and video card (generic AOpen GeForce 2 MX 64M AGP) are detected and Xwindows is configured. 
Bootup option is set to runlevel 3 on an ASUS A7M266D dual Athlon 1800+ MOBO with the 760MPX chipset. However, after 
installation is completed, booting either SMP or UP kernel results in a blank console screen and no ability to login (even if typing in the 
dark). Ctl-Alt-Del DOES cause reboot, and using
rescue-kernel from installation media works correctly allowing verification from log files that bootup DID actually occur. Issue was 
reported to installatiion support channel (service report #228953), but after a week of email ping-pong where the following was 
attempted:
    1. combinations of boot options nousb,noathlon,apm=off,mem=nopentium
    2. BIOS shutdown of DPMS services
    3. Attempts to reconfigure XFree86 to a lower resolution (which I did despite questioning why Xwindows would
make any difference)
    4. Disabling DMA for the harddisk, and alterring the initscripts to not start apmd in runlevels 345
NONE of which made any difference to the problem.
    5 Using my own discretion I also tried using the vga=ask boot option which at least produced the mode menu onscreen - which 
resulted in  the first time I had seen ANYTHING beyond the GRUB bootscreen.

On my own, google turned up an article from the Linux Gazette describing EXACTLY the same problem, but alas their solution led to 
a bad BIOS setting (PCI .vs. AGP as primary VGA card) - which is untrue in my case. However it alluded to perhaps needing to 
compare kernel configs as the next logical step to solve the problem. Based on that, I attempted to rebuild the kernel using the SMP 
config that was supplied in the kernel source package (2.4.7-10SMP).
This also failed -- HOWEVER I noticed that there was also a (2.4.7-10BOOT) config present and tried a rebuild with that (based on 
the notion that the rescue kernel had always worked). This WORKED correctly, allowing me to view the bootup and subsequently 
login. However I am now unsure of just what is actually configured into my machine. Notably, my parallel port is not functioning, nor 
is my new kernel SMP-aware; but it is at least a start.

Is there something inherently different in accessing the video card in a kernel configured for installation versus one that is 
configured 
for general use 

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

How reproducible:
Always

Steps to Reproduce:
1. Simply boot the stock installed kernel from the GRUB screen
2.
3.
    

Actual Results:  Grub boot screen is cleared, and remains dark.
However, monitor remains 'on' (i.e. not standby, nor loss of signal).
Console fails to show any acknowledgement of switching between virtual consoles, nor does it accept blind keyboard entry of valid 
login sequences.

Expected Results:  Messages pertaining to the bootup should have been displayed.
Ultimately, a login prompt should have been produced on each virtual console.

Additional info:

Due to the relative ages of the 7.2 release and the newness of the 760MPX chipset many of the onboard devices are reported in the 
log as "unknown" including bridges and IO chips. However given that BOTH the rescue and stock kernels agree on how little they 
"know" about the devices I tend to think of this as somewhat inconsequential to the problem at hand; but I am no kernel hacker (yet) 
so my opinion may not count for much on this point.

Comment 1 Michael P Moran 2003-03-06 18:41:47 UTC
Created attachment 90498 [details]
Contents of log messages for rescue and stock kernels and also lspci of machine

Comment 2 Alan Cox 2003-06-08 20:12:44 UTC
760MPX is known to work but you require - BIOS > = 1007 (or 1004 with MP set to
MP 1.1), and a PS/2 mouse installed if the system is the ASUS.


Comment 3 Bugzilla owner 2004-09-30 15:40:36 UTC
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/