Bug 6083
Description
Peter D.
2006-02-15 22:07:26 UTC
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. |