|Summary:||Gforce2 GTS not initializaed by plug/play when secondary video|
|Product:||[Retired] Red Hat Linux||Reporter:||Jon Smirl <jonsmirl>|
|Component:||kernel||Assignee:||Arjan van de Ven <arjanv>|
|Status:||CLOSED DUPLICATE||QA Contact:||David Lawrence <dkl>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2002-11-15 19:40:55 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Jon Smirl 2002-11-15 18:20:40 UTC
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20020922 Description of problem: My primary adapter is a ATI Rage128 PCI. Secondary is Elsa Geforce2 GTS AGP. Rage is only used at boot time. X Windows uses the Geforce2. If the BIOS is set for a PNP OS this configuration will fail. The kernel PNP code does not properly initalize the secondardy Geforce2. Symtom is failure of NVidia kernel module when initializing X. Setting the BIOS to non-PNP OS makes the config work. Win2K works with BIOS on either setting. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Install primary Rage128 2. Install secondard NVidia Geforce2 GTS 3. Set BIOS of PNP OS 4. Boot Linux 5. Config X to use GF2 with NVidia kernel support 6. Start X. 7. X will fail with "unable to initalize hardware" Make GF2 primary adapter or BIOS non-PNP OS and config will work. Actual Results: X will fail with "unable to initalize hardware" Expected Results: X should have started Additional info: /proc/pci when non-PNP OS set in BIOS: PCI devices found: Bus 0, device 0, function 0: Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 2). Master Capable. Latency=8. Prefetchable 32 bit memory at 0xd8000000 [0xdbffffff]. Bus 0, device 1, function 0: PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (rev 0). Master Capable. No bursts. Min Gnt=12. Bus 0, device 7, function 0: ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 34). Bus 0, device 7, function 1: IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 16). Master Capable. Latency=32. I/O at 0x9000 [0x900f]. Bus 0, device 7, function 4: Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 48). IRQ 3. Bus 0, device 8, function 0: Ethernet controller: Lite-On Communications Inc LNE100TX (rev 33). IRQ 10. Master Capable. Latency=32. I/O at 0x9c00 [0x9cff]. Non-prefetchable 32 bit memory at 0xe3004000 [0xe30040ff]. Bus 0, device 15, function 0: Multimedia audio controller: PCI device 1004:0307 (VLSI Technology Inc) (rev 6). IRQ 7. Master Capable. Latency=32. Min Gnt=9.Max Lat=40. I/O at 0xa000 [0xa07f]. I/O at 0xa400 [0xa40f]. I/O at 0xa800 [0xa803]. I/O at 0xac00 [0xac07]. I/O at 0xb000 [0xb03f]. Bus 0, device 15, function 1: Input device controller: PCI device 1004:0308 (VLSI Technology Inc) (rev 0). I/O at 0xb400 [0xb407]. Bus 0, device 17, function 0: VGA compatible controller: ATI Technologies Inc Rage 128 PD/PRO TMDS (rev 0) . IRQ 5. Master Capable. Latency=32. Min Gnt=8. Prefetchable 32 bit memory at 0xdc000000 [0xdfffffff]. I/O at 0xb800 [0xb8ff]. Non-prefetchable 32 bit memory at 0xe3000000 [0xe3003fff]. Bus 0, device 19, function 0: Unknown mass storage controller: Triones Technologies, Inc. HPT366 / HPT370 (rev 3). IRQ 11. Master Capable. Latency=120. Min Gnt=8.Max Lat=8. I/O at 0xbc00 [0xbc07]. I/O at 0xc000 [0xc003]. I/O at 0xc400 [0xc407]. I/O at 0xc800 [0xc803]. I/O at 0xcc00 [0xccff]. Bus 1, device 0, function 0: VGA compatible controller: nVidia Corporation NV15 (GeForce2 Pro) (rev 163). IRQ 5. Master Capable. Latency=248. Min Gnt=5.Max Lat=1. Non-prefetchable 32 bit memory at 0xe1000000 [0xe1ffffff]. Prefetchable 32 bit memory at 0xd0000000 [0xd7ffffff].
Comment 1 Bill Nottingham 2002-11-15 19:37:09 UTC
If X is failing to find the hardware based on BIOS settings, this is an XFree86 or kernel problem, not a kudzu issue.
Comment 2 Arjan van de Ven 2002-11-15 19:40:48 UTC
1) don't set the bios to PNP, that's not supported 2) the binary only nvidia driver is not supported
Comment 3 Mike A. Harris 2002-11-16 03:48:14 UTC
Indeed, Nvidia binary kernel modules are unsupported. Closing as dupe of our dupe catcher. *** This bug has been marked as a duplicate of 73733 ***
Comment 4 Jon Smirl 2002-11-16 04:02:31 UTC
I don't agree that this is a duplicate of problems with the NVidia driver (73733). arjanv was correct when he said don't set PNP OS in the BIOS because it is not supported. Something is wrong with the kernel's PNP assignment of resources at boot time, this is before any NVidia driver code is loaded. Loading the NVidia code just illustrates that the card has not been initializaed properly. I suspect that the ROM BIOS for the video card contains an initialization routine. The kernel's boot time PNP code is not calling this video BIOS code. When the card is the primary video card or non-PNP OS is selected the motherboard BIOS calls the video BIOS to initialize.
Comment 5 Mike A. Harris 2002-11-16 04:22:10 UTC
If this occurs at boot time, then it may be valid. Feel free to reopen if that is the case. Just be sure for any bugs that you report in bugzilla while using Nvidia hardware, that from kernel boot onward, the Nvidia binary kernel modules have never been loaded. Even loading them, then unloading them is enough to corrupt the kernel, and will make your system unsupported.
Comment 6 Jon Smirl 2002-11-16 17:05:50 UTC
arjanv said that PNP OS in the BIOS is not supported. I'd file this bug with the PNP bugs so that when it is decided to support BIOS PNP OS we'll still have the bug report. Right now the kernel tries to do PNP OS support but it doesn't always get it right.
Comment 7 Mike A. Harris 2002-11-17 00:13:28 UTC
No, the kernel does ISA PnP, which is Plug and Play for the ISA bus, not for PCI devices. It is highly unlikely that the kernel will ever support the PnP OS setting in PC BIOS's, largely because there is no real reason for it. Right now you're just grasping at straws to try and guess what the problem is that you are having. That isn't helpful. At any rate, this isn't an XFree86 bug, so I don't need to see it anymore.