Most recent kernel where this bug did not occur: 2.6.12.6 Distribution: Mandriva 2006 Hardware Environment: Two VGA cards one AGP one PCI Software Environment: Xorg-x11-6.9 Problem Description: There are two video cards in my computer, one AGP and one PCI. With kernels up to 2.6.12.6 (both vanilla and Mandriva versions) both cards are usable at the same time. With vanilla kernels 2.6.13.5, 2.6.14.7 and 2.6.15.4 the PCI card does not work. This error message (EE) s3(1): Cannot read V_BIOS is written to /var/log/Xorg.0.log. I changed the PCI card and get the same problem. The problem seems to have been uncovered as a result of an official Mandriva upgrade of xorg from a beta version to 6.9. (It might take a few time consuming reinstallations to be sure, so I am putting it off untill someone says that I really need to do it.) ->lspci 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 651 Host (rev 01) 00:01.0 PCI bridge: Silicon Integrated Systems [SiS] Virtual PCI-to-PCI bridge (AGP) 00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS962 [MuTIOL Media IO] (rev 04) 00:02.1 SMBus: Silicon Integrated Systems [SiS] SiS961/2 SMBus Controller 00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] 00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] Sound Controller (rev a0) 00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f) 00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f) 00:03.2 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f) 00:03.3 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 Controller 00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 00:0b.0 Multimedia video controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder (rev 05) 00:0b.2 Multimedia controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] (rev 05) 00:0d.0 VGA compatible controller: S3 Inc. 86c764/765 [Trio32/64/64V+] 01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev a1) Steps to reproduce: What more do you want to know?
Seems that X can no longer map the trio card's BIOS ROM. Are you sure that the exact same userspace setup worked OK on 2.6.12.6? That changing only the kernel breaks things?
Also, do you have CONFIG_FB_S3TRIO enabled? That might affect it..
Same installation, same lilo "append" parameters (noacpi splash=silent), same /etc/X11/xorg.conf. Different kernels. There is no "CONFIG_FB_S3TRIO" in any of my /usr/src/linux*/.config files, not even the one that works (2.6.12.6). I can not see any way to turn on any TRIO options with "make xconfig". I thought that it was just treated as a generic VGA device. It is very old.
OK, thanks. Let me cc a few guys who might be able to help. It might be a PCI problem? (What happens if you remove the `noacpi'?)
Using 2.6.12.6; if "CONFIG_FB_S3TRIO" is edited into .config then "make xconfig" removes it, as does "make". Commenting out the "append" lines (and re-running lilo) does not change it. I only tested 2.6.12.6 and 2.6.15.4.
One of the drivers is probably not unmapping the BIOS, so the second driver is unable to map its own BIOS. VGA card's BIOS's can only be mapped in a fixed location (0xc000). Does the problem persist if you alter the loading sequence of the drivers, load secondary first, then the primary? What if you comment out "Load int10" in your XF86/Xorg config file and just post the secondary card with vbetool, for example?
How is the loading sequence altered? The PCI cards information now comes first in xorg.conf, but the AGP cards data still comes first in Xorg.0.log. There is no "Load init10" in my xorg.conf. I have installed vbetool. What do you want me to do with it?
Created attachment 7378 [details] xorg.conf I've just shuffled my xorg.conf to look like this, booted into a new kernel and had the PCI card failure.
Created attachment 7379 [details] with kernel 2.6.15.4
That xorg.conf caused a hard lock up during the startup of X twice with the old kernel. I then reverted back to the old "screen" lines at the bottom of xorg.conf and restarted successfully (with the old kernel). I've been having a bit of trouble with hard lockups for a few weeks, but I think that that is an unrelated hardware problem. The failure of the PCI card is *very* consistent with which kernel is booted.
> How is the loading sequence altered? You can modify the X config file and add 2 more serverlayout entries (ie, layout2 for s3 and layout3 for nv) , each with only one screen entries, one with screen1 and the other screen2. Disable xinerama. Then run: startx -- :0 vt07 -layout layout2 startx -- :1 vt08 -layout layout3 Looking at your xorg.conf, I see that the S3 is the secondary card and nvidia is the primary. However, looking at the source code of the S3 driver, it actually uses legacy vga port banging access the hardware. But if the S3 driver is the secondary card, the io ports are actually mapped to the VGA core of the nvidia card rather than the S3 card. This causes the driver initialization of the S3 to fail. (I'm actually surprised that dual display worked before when one of the cards uses legacy port access instead of mmio. This might explain why you sometimes have lockups). Is it possible to change your BIOS settings to make the S3 card the primary display adapter? Most BIOS'es support this. Also, can you post the lspci -vvv and lspci -xxx of the working vs nonworking kernel? Trim the output to show only vga controllers. (Unfortunately vbetool works only for the primary card..., so you can't use it to POST the S3 unless it becomes the primary card)
Extra info: Your X log shows this which I believe is the cause of the failure, rather than the cannot read V_BIOS: (**) s3(0): Chipset: "Trio32/64" (--) s3(0): Framebuffer @ 0xef000000 (--) s3(0): videoRam = 0 Kb The videoRam is probed with this: /* probe videoram */ outb(vgaCRIndex, 0x36); tmp = inb(vgaCRReg); (But the outb is probing nvidia's ports, not the s3 card..., so it gets nothing)
Created attachment 7382 [details] lspci -xxx trimmed for just video cards No change between kernel versions
Created attachment 7383 [details] lspci -vvv (trimmed) for working old kernel
Created attachment 7384 [details] lspci -vvv (trimmed) for broken new kernel
My setup does not like ":1" either with new or old kernels. "startx -- :0 vt07 -layout layout2" and "startx -- :0 vt08 -layout layout3" are both OK, at least with an old kernel. Trying to startx with the PCI S3 on a new kernel failed. The bios does allow me to configure the PCI card as the primary graphics card. (What it would do if PCI was selected and *two* PCI cards were installed I do not know.) Selecting PCI with my current setup made things worse. How much detail do you want? On the plus side I have decided to delay building another new computer for a little while.
Created attachment 7387 [details] Make x86emu compile Can you try this? 1. Get x86emu from http://www.scitechsoft.com/ftp/devel/obsolete/x86emu/x86emu-0.8.tar.gz 2. Apply the attached patch (ugly patch to make x86emu compile) 3. cd scitech/src/v86bios 4. make vbios.vm86 -f makefile.linux 5. Run the created binary, vbios.vm86 This binary will POST both active and inactive cards. Before and after running vbios.vm86, run lspci -vvv. You should see that the regions of the controllers should be enabled, if the POST was successful. Then try to run X. Try with and without Option "NoInt10" in the Device section of your X config. x86emu shares the same code as X's libint10. So using this utility will make our debugging session much easier than compiling X with debugging on. Note: I only tested POSTing my primary adapter since I don't have any secondary adapters.
According to man xorg.conf int10 is the default, adding Option NoInt10 shouldn't change anything. I've had a lot of "fun" with video cards. Removed the PCI S3 and Mandriva went and installed dkms and proprietary nVidia drivers - without asking. (There were still lockups.) Removed the AGP nVidia card and fell back to the on-board SiS "AGP" video. Re-installed the PCI S3 card. Set the bios to make the PCI S3 card the primary. Re-arranged xorg.conf to only use the PCI S3. Eventually I got to use "vbetool vbestate save > vbestate.<kernel ver>.<runlevel>" for 2.6.12.6 and 2.6.15.4 in runlevels 1, 2, 3 and 5. (There were a few more lockups.) Do you still want me to use x86emu? How do I use it? It is not a /patch/ file to be applied to the kernel source tree. Should the entire unpacked directory, /scitech/, be copied to /usr/src/linux/drivers? Leaving it separate gave an error. ->pwd /usr/src/scitech/src/v86bios ->make vbios.vm86 -f makefile.linux makefile.linux:5: *** missing separator. Stop. Some automatic configuration tool is confused about which video card is which. It reads the memory size of the AGP nVidia card (32M) and attributes it to the PCI S3 card, which actually has 1M. This error causes the zero memory line in Xorg.0.log. I have added an explicit "VideoRam 1024" to xorg.conf to fix that problem.
Created attachment 7388 [details] 2.6.12.6 runlevel 1 vbetool vbestate save
Created attachment 7389 [details] 2.6.12.6 runlevel 1 vbetool vbestate save
Created attachment 7390 [details] 2.6.12.6 runlevel 2 vbetool vbestate save
Created attachment 7391 [details] 2.6.12.6 runlevel 3 vbetool vbestate save
Created attachment 7392 [details] 2.6.12.6 runlevel 5 vbetool vbestate save
Created attachment 7393 [details] 2.6.15.4 runlevel 1 vbetool vbestate save
Created attachment 7394 [details] 2.6.15.4 runlevel 2 vbetool vbestate save
Created attachment 7395 [details] 2.6.15.4 runlevel 3 vbetool vbestate save
Created attachment 7396 [details] 2.6.15.4 runlevel 5 vbetool vbestate save
Created attachment 7397 [details] 2.6.12.6 runlevel 1 vbetool vbestate save
Something strange is happening. With the on-board "AGP" SiS and the PCI S3 the zero memory error for the S3 is getting into Xorg.0.log despite the VideoRam 1024 line in xorg.conf. The PCI S3 card is not working with the SiS and an old kernel. I will sleep on this and maybe reinstall the AGP nVidia card in the morning.
More information... Using the on-board "AGP" SiS video and the other PCI S3 card (a 2 Meg Virge) there are similar results. It runs in Xinerama with an old kernel, although there is an odd message in Xorg.0.log, (II) S3VIRGE(1): initializing int10 (II) Truncating PCI BIOS Length to 32768 With the new kernel BOTH screens are blank, with the old error, (II) S3VIRGE(1): initializing int10 (EE) S3VIRGE(1): Cannot read V_BIOS
Is this bug still active? Here is a quote from Changelog-2.6.18 commit 9f125d30487cea72542a84b4835c037163c7f3d5 Author: Arjan van de Ven <arjan@linux.intel.com> Date: Sat Apr 29 10:59:08 2006 +0200 [PATCH] PCI: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access This patch adds an "enable" sysfs attribute to each PCI device. When read it shows the "enabled-ness" of the device, but you can write a "0" into it to disable a device, and a "1" to enable it. This later is needed for X and other cases where userspace wants to enable the BARs on a device (typical example: to run the video bios on a secundary head). Right now X does all this "by hand" via bitbanging, that's just evil. This allows X to no longer do that but to just let the kernel do this. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> CC: Peter Jones <pjones@redhat.com> Acked-by: Dave Airlie <airlied@linux.ie> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> End quote. I can't test it at the moment because of other hardware/BIOS/kernel problems, even assuming that Xorg make use of this new facility.
Any updates on this bug? Was the problem resolved, or testing is still needed? Thanks.
Relevant changes seem to have been make to the kernel and to Xorg. I don't have that motherboard any more, or any AGP board. I do still have both of the PCI video cards mentioned above. I have just done some test installs with two and three PCI video cards. X seemed slow to start, but there were no lockups and I could not find any V_BIOS errors when I grepped /var/log/* . So, I *think* that the problem is fixed, but I don't know for sure. Sorry.