I'm trying to get X working with 2 video cards - the builtin graphics (Intel 845G chipset) using the i810 driver, and a pci Nvidia GeForce4 MX 4000 using the Nvidia 6629 driver. I'm using kernel 2.6.10, X.org 6.8.1. When I boot the machine, the BIOS has an option to select whether the primary graphics should be AGP or PCI. When I set it to AGP, I can start X on the Intel graphics, but when I try the Nvidia, the X server crashes. When I set the primary graphics device to PCI, X will start on the Nvidia card, but I get these errors when I try to start it on the Intel: (EE) I810(0): Cannot read V_BIOS (EE) I810(0): VBE initialization failed. I've tried running both X servers separately, and together - same results. I've also tried the NoInt10 option for the i810 driver, but it still won't start. I think X is always querying the BIOS for information about the video card, and the BIOS returns info for whatever card is set as the primary, regardless of which one X is set to use. Here are the config files I'm using: X only on i810: http://home.nc.rr.com/webstorage/xorg.conf.intel X only on nvidia: http://home.nc.rr.com/webstorage/xorg.conf.nvidia.monitor X on both: http://home.nc.rr.com/webstorage/xorg.conf.multihead Here are the logs from when I try to start the X server: X on i810, bios set to AGP, works: http://home.nc.rr.com/webstorage/Xorg.0.log.i810oni810b X on i810, bios set to PCI, X won't start: http://home.nc.rr.com/webstorage/Xorg.0.log.i810onnvb X on nvidia, bios set to AGP, X crashes: http://home.nc.rr.com/webstorage/Xorg.0.log.nvoni810b X on nvidia, bios set to PCI, works: http://home.nc.rr.com/webstorage/Xorg.0.log.nvonnvb I also tried the vesa driver, but it says that it can't find a device matching the device id I put in the config file.
logs have disappeared. Re-open if there's still a problem with X.Org 7.0
I am experiencing what sounds like exactly the same symptoms with an onboard intel 865 (also uses the i810 driver) and a "Sigma Designs REALmagic/2D" PCI card, which the video bios reports is a S3 775 and the internet reports is a Trio64V2/DX. When the BIOS sets the PCI card as the primary display, I get: (EE) I810(0): Cannot read V_BIOS and (EE) I810(0): VBE initialization failed in the Xorg logs.
I seem to have the same problem with different cards. Will attach logs.
Created attachment 5026 [details] Log file of secondary monitors failing (search for ATI(1) and ATI(2)) This log file shows how X now seems to be refusing to initialize non-primary graphics cards. A major regression from 6.8. The relevant portion is: (==) ATI(1): Chipset: "ati". (**) ATI(1): Depth 15, (--) framebuffer bpp 16 (**) ATI(1): Option "tv_out" (**) ATI(1): Option "tv_standard" "NTSC" (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Reloading /usr/X11R6/lib/modules/linux/libint10.so (EE) ATI(1): Cannot read V_BIOS (WW) ATI(1): Unable to initialise int10 interface. (EE) ATI(1): Adapter has not been initialised. (==) ATI(2): Chipset: "ati". (**) ATI(2): Depth 16, (--) framebuffer bpp 16 (**) ATI(2): Option "tv_out" (**) ATI(2): Option "tv_standard" "NTSC" (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Reloading /usr/X11R6/lib/modules/linux/libint10.so (EE) ATI(2): Cannot read V_BIOS (WW) ATI(2): Unable to initialise int10 interface. (EE) ATI(2): Adapter has not been initialised. (II) UnloadModule: "ati" (II) UnloadModule: "int10" (II) UnloadModule: "atimisc" (II) UnloadModule: "ati" (II) UnloadModule: "int10" (II) UnloadModule: "atimisc" (II) Unloading /usr/X11R6/lib/modules/drivers/atimisc_drv.so
I can confirm this bug on an i810 chipset working with nvidia geforce mx 4000 pci card. Here is my log. ------------- (**) I810(1): Depth 24, (--) framebuffer bpp 32 (==) I810(1): RGB weight 888 (==) I810(1): Default visual is TrueColor (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Reloading /usr/lib/xorg/modules/libint10.so (II) I810(1): initializing int10 (EE) I810(1): Cannot read V_BIOS (EE) I810(1): VBE initialization failed. (II) UnloadModule: "i810" ------------------ And the xorg.conf ----------------- Section "Device" Identifier "nv" Driver "nv" BusID "PCI:1:0:0" EndSection Section "Monitor" Identifier "DELL E176FP" Option "DPMS" EndSection Section "Device" Identifier "intel" Driver "i810" BusID "PCI:0:2:0" EndSection Section "Monitor" Identifier "dell15" Option "DPMS" EndSection Section "Screen" Identifier "nv" Device "nv" Monitor "DELL E176FP" DefaultDepth 24 SubSection "Display" Depth 16 Modes "1280x1024" "1152x864" "1024x768" "800x600" "720 x400" "640x480" EndSubSection SubSection "Display" Depth 24 Modes "1280x1024" "1152x864" "1024x768" "800x600" "720 x400" "640x480" EndSubSection EndSection Section "Screen" Identifier "i800" Device "intel" Monitor "dell15" DefaultDepth 24 SubSection "Display" Depth 24 Modes "1024x768" EndSubSection EndSection Section "ServerLayout" Option "Xinerama" "On" Identifier "Default Layout" Screen 0 "nv" 0 0 Screen 1 "i800" RightOf "nv" InputDevice "Generic Keyboard" InputDevice "Configured Mouse" EndSection --------------
Adding a CC to alanh per a conversation on IRC with "libv"
Jason - you need to add a full log, and also have you just tried the i810 driver on it's own without the nv driver ?
Created attachment 5090 [details] Error log with nv card set as primary This is the log if the nvidia card is set as primary. If I set the onboard i810 as primary, then the V_BIOS error will be associated with the nv driver instead of the int10 (vesa driver). Both cards are using the same IRQ (I can't change it. It's forced by the system bios). If I try to start X using the i810 driver instead of vesa, X will lockup. Using vesa will allow the primary (nv) to start but the onboard card remains inactive.
You really need to set the i810 as primary and post a new log
Created attachment 5091 [details] NVIDIA driver with i810 as primary My web storage got deleted, but here is the log from the original problem.
Created attachment 5092 [details] i810 driver with NVIDIA as primary
Created attachment 5093 [details] i810 driver with i810 as primary, works
Created attachment 5094 [details] NVIDIA driver with NVIDIA as primary, works
Looks like you are suffering from a problem in bug #5443. Try that. But you'll need to compile from source. Also, you might want to try upgrading to 6.8.2 at the very least as well.
Created attachment 5095 [details] i810 primary, using i810 driver Screen goes black and locks up.
Check your logfile ... This is the error... PanoramiX error: Incompatible screens. Root window depths differ That means you are trying to enable xinerama but you are running different depths. Make them the same depth.
Created attachment 5104 [details] i810 primary, same depth/resolution, display locks up FYI, my fc4 install which used xorg 6.8 (I believe) worked fine. This appears to be a 7.0 problem. If I use the i810 driver, the screen goes crazy. If I use the vesa driver, the screen goes black and locks up.
You were using 6.8.1 earlier in this report which you've said didn't work, now you've upgraded to 7.0.0 and it's still not working. So if you've got a setup with 6.8.2 and it's working, then you need to start diagnosing things a little yourself as I dont have a similar setup to debug this, as from what the log is now saying with 7.0.0 the server has fully initialized. So dig into the source and see if you can do some debugging. Sorry I can't more definitively.
One thing I will add though is that you might want to try adding Option "noaccel" to each of the NV and i810 driver sections to see if that helps.
It no longer freezes but if the i810 is set as the primary display, the secondary screen will remain black. If the nv is set as primary, then the i810 will show a corrupted display.
Created attachment 5116 [details] Xorg.0.log from working Fedora Core 4
Created attachment 5117 [details] lspci output from working Fedora Core 4
Created attachment 5118 [details] lspci -v -n output from working Fedora Core 4
Created attachment 5119 [details] Xorg.0.log from broken Fedora Core 5
Created attachment 5120 [details] lspci output from broken Fedora Core 5
Created attachment 5121 [details] lspci -v -n output from broken Fedora Core 5
Comment on attachment 5116 [details] Xorg.0.log from working Fedora Core 4 I can confirm the exact same behaviour as reported in the original post with: * nVidia Corporation NV34 [GeForce FX 5200] as AGP * ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] as PCI The card which is selected as the primary display in the BIOS works. The other one not. My machine is dual boot with Fedora Core 4 and 5. Running FC4 with Xorg 6.8.2 runs on both monitors on the exact same hardware without any problems. After updating to FC5 with Xorg 7.0.0 brings the described problems. I first attach the logs from the working FC4 (Xorg.0.log, lspci, lspc -v -n) and then the logs from the broken FC5 (Xorg.0.log, lspci, lspci -v -n).
(In reply to comment #18) > You were using 6.8.1 earlier in this report which you've said didn't work, now > you've upgraded to 7.0.0 and it's still not working. > > So if you've got a setup with 6.8.2 and it's working, then you need to start > diagnosing things a little yourself as I dont have a similar setup to debug > this, as from what the log is now saying with 7.0.0 the server has fully > initialized. > > So dig into the source and see if you can do some debugging. Sorry I can't more > definitively. I think you have mistaken me for the original poster. My fc4 installation worked fine in dualhead mode with my hardware. xorg7 in fc5 only lets the primary display work but not both.
Created attachment 5124 [details] JasonF, using nv+i810
Created attachment 5125 [details] JasonF, using nv+i810 Here are my scenarios: i810 alone: Works nv alone: Works nv+i810: Primary always works, Secondary always stays black I attached a log, if it's not the right one, just let me know. Thanks.
Gentoo, xorg-7 AGP card is Radeon 9700 Pro All in Wonder, using either radeon (6.5.7.3) or fglrx(8.23.7) driver. With TNT2 with nv(1.0.2.0) driver in PCI : (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Reloading /usr/lib/xorg/modules/libint10.so (II) NV(1): Initializing int10 Requesting insufficient memory window!: start: 0xc0000000 end: 0xc1ffffff size 0xc5010000 Requesting insufficient memory window!: start: 0xc4000000 end: 0xc5ffffff size 0xc5010000 Requesting insufficient memory window!: start: 0xc0000000 end: 0xc1ffffff size 0xc5010000 Requesting insufficient memory window!: start: 0xc4000000 end: 0xc5ffffff size 0xc5010000 Requesting insufficient memory window!: start: 0xc0000000 end: 0xc1ffffff size 0xc5010000 Requesting insufficient memory window!: start: 0xc4000000 end: 0xc5ffffff size 0xc5010000 (EE) NV(1): Cannot read V_BIOS 2nd screen (attached to TNT2) stays black. System locks up. (Full log will be attached) With Mach64 VT4 with ati(6.5.7.3) driver in PCI : (II) LoadModule: "int10" (II) Reloading /usr/lib/xorg/modules/libint10.so (II) ATI(0): Initializing int10 (EE) ATI(0): Cannot read V_BIOS 2nd screen (attached to Mach64) stays black. System does not lock. (Don't have full log handy)
Created attachment 5203 [details] J.Adamczewski Xorg.log for 9700/TNT2 combination Log for AGP9700ProAIW/PCITNT2 combination. Second screen had no signal, mouse could be moved from primary to secondary, kde startup progress happened, system locked hard (no remote connection).
I am getting the same symptoms as people here. I was running 6.8.2 on Gentoo Linux. After upgrading to 7.0, my secondary and tertiary screens no longer start up. I get Cannot read V_BIOS for both my secondary and tertiary cards. Setting the system for only 1 card works, provided the card is set as primary in the BIOS. I did not change my xorg.conf in any way from the working configuration used with 6.8.2 and 3 screens. I can provide any information necessary, but it looks like you have pretty much everything I do already from previous posters.
Here's an IRC log from discussing this bug between a couple of Gentoo developers. I'm just pasting it here in hopes that some of the information helps. <wolf31o2|mobile> but plasmaroo has a working config using newer nvidia cards <plasmaroo> Yeah, it's weird. <plasmaroo> Since I'd expect these cards to need BIOS bootup as well <plasmaroo> But I get BIOS thing on them when X boots them <plasmaroo> +no <agaffney> it may only happen when the cards are different <plasmaroo> These cards are all different <agaffney> I don't see any same-card configs on that bug <agaffney> ah <plasmaroo> All three of them :) <agaffney> *how* different? <agaffney> do they all use the same driver? <wolf31o2|mobile> they're all nvidia, right? <plasmaroo> Yes <wolf31o2|mobile> yeah <wolf31o2|mobile> mine use 2 drivers <plasmaroo> Yeah... just different silicon <plasmaroo> I can try booting one of them with nv if you want <agaffney> wouldn't hurt to try <plasmaroo> But that also works fine AFAICR <wolf31o2|mobile> please try and let us know... I'll put it in the bug <wolf31o2|mobile> heh <agaffney> we luv you long time <plasmaroo> Hm, that was ... interesting <plasmaroo> I think it might have been a good idea to kill X first before running a new X :P <plasmaroo> So... it worked <plasmaroo> But! <plasmaroo> NV(1): Cannot read V_BIOS <wolf31o2|mobile> but it still works? <plasmaroo> Yeah <wolf31o2|mobile> what cards do you have again? <plasmaroo> plasmaroo # lspci | grep nvidia -i <plasmaroo> 01:00.0 VGA compatible controller: nVidia Corporation NV15DDR [GeForce2 Ti] (rev a4) <plasmaroo> 02:0c.0 VGA compatible controller: nVidia Corporation NV18 [GeForce4 MX 4000 AGP 8x] (rev c1) <plasmaroo> 02:0e.0 VGA compatible controller: nVidia Corporation NV18 [GeForce4 MX 4000 AGP 8x] (rev c1) <plasmaroo> The last two are different cards with different silicon
That may have been premature: 10:03 <@plasmaroo> Also, it doesn't give me that BIOS error when I don't have X running and cold boot 10:03 <@plasmaroo> (And also works) 10:04 <+agaffney> even with nvidia and nv? 10:04 <@plasmaroo> Yup 10:05 <+agaffney> hmm 10:06 <+agaffney> so, it was possible the other running X session that caused the V_BIOS errors last time? 10:06 <@plasmaroo> Yes, that's right. 10:06 <@plasmaroo> Because it prolly locked onto the BIOS 10:06 <@plasmaroo> If I kill that and start fresh it doesn't give me the error (and still works)
Here is another approach for a similar problem. The ATI 9250 card I try to softboot has a V_BIOS rom which is not accessible unless booted by the system bios at power on. A solution is to boot with the 9250 primary and to write the rom image to a file by copying it from the OS /sys/devices/pci0000:00/ ... /rom system file or by using dd if=/dev/mem of=/root/r9250.bio bs=65536 skip=12 count=1 to make a copy from legacy ISA space. This file now serves as a substitute when the 9250 is set as secondary. Then, I extended the int10 module as to allow the user to specify the V_BIOS location through a statement like Option "BiosLocation" "primary:0xC0000" Option "BiosLocation" "pci:1:0:0" Option "BiosLocation" "file:/root/r9250.bio" given in the screen section which refers to the r9250 device. The soft boot works with the image file but, alas, never returns. The ATI V_BIOS causes a screaming interrupt through the IO_APIC which is not handled and thus waits forever. Nevertheless, this patch might be useful if someone is trying something similar. Inclusion in the distributed code should be OK since the extension is backward compatible. The 3 options above where verified for primary and secondary card. The proposed patch furthermore removes duplicated code by reorganizing the primary/secondary if-then-else tree. lspci: 01:00.0 Class 0300: 1002:5b60 Subsystem: 17af:201e 01:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)] (prog-if 00 [VGA]) Subsystem: Hightech Information System Ltd.: Unknown device 201e Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at 80000000 (32-bit, prefetchable) [size=128M] I/O ports at 3000 [size=256] Memory at 98210000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at 98220000 [disabled] [size=128K] Capabilities: [50] Power Management version 2 Capabilities: [58] #10 [0001] Capabilities: [80] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable 05:01.0 Class 0300: 1002:5960 (rev 01) Subsystem: 174b:0250 05:01.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01) (prog-if 00 [VGA]) Subsystem: PC Partner Limited: Unknown device 0250 Flags: medium devsel, IRQ 17 Memory at 90000000 (32-bit, prefetchable) [disabled] [size=128M] I/O ports at 1100 [disabled] [size=256] Memory at 98010000 (32-bit, non-prefetchable) [disabled] [size=64K] Expansion ROM at fffe0000 [disabled] [size=128K] Capabilities: [50] Power Management version 2 ** plain boot with x300 primary, softboot of r9250 ** May 1 01:31:55 reddwarf kernel: irq 9: nobody cared (try booting with the "irqp oll" option) May 1 01:31:55 reddwarf kernel: [<c0138e14>] __report_bad_irq+0x2a/0x8d May 1 01:31:55 reddwarf kernel: [<c0138844>] handle_IRQ_event+0x39/0x6d May 1 01:31:55 reddwarf kernel: [<c0138f2f>] note_interrupt+0x9e/0xf7 May 1 01:31:55 reddwarf kernel: [<c013892b>] __do_IRQ+0xb3/0xc0 May 1 01:31:55 reddwarf kernel: [<c0105291>] do_IRQ+0x19/0x24 May 1 01:31:55 reddwarf kernel: [<c01037de>] common_interrupt+0x1a/0x20 May 1 01:31:55 reddwarf kernel: [<c0114047>] sys_vm86old+0x7b/0xda May 1 01:31:55 reddwarf kernel: [<c0102e11>] syscall_call+0x7/0xb May 1 01:31:55 reddwarf kernel: handlers: May 1 01:31:55 reddwarf kernel: [<c02605c1>] (acpi_irq+0x0/0x16) May 1 01:31:55 reddwarf kernel: Disabling IRQ #9 ** boot with pci=routeirq and x300 primary, softboot of r9250 ** May 2 01:19:18 reddwarf kernel: irq 9: nobody cared (try booting with the "irqp oll" option) May 2 01:19:18 reddwarf kernel: [<c0138e14>] __report_bad_irq+0x2a/0x8d May 2 01:19:18 reddwarf kernel: [<c0138844>] handle_IRQ_event+0x39/0x6d May 2 01:19:18 reddwarf kernel: [<c0138f2f>] note_interrupt+0x9e/0xf7 May 2 01:19:18 reddwarf kernel: [<c013892b>] __do_IRQ+0xb3/0xc0 May 2 01:19:18 reddwarf kernel: [<c0105291>] do_IRQ+0x19/0x24 May 2 01:19:18 reddwarf kernel: [<c01037de>] common_interrupt+0x1a/0x20 May 2 01:19:18 reddwarf kernel: [<c0113eff>] save_v86_state+0xe7/0x12e May 2 01:19:18 reddwarf kernel: [<c01146af>] handle_vm86_fault+0xac/0x7db May 2 01:19:18 reddwarf kernel: [<c0103213>] irq_entries_start+0x2cf/0x880 May 2 01:19:18 reddwarf kernel: [<c01037de>] common_interrupt+0x1a/0x20 May 2 01:19:18 reddwarf kernel: [<c010499b>] do_general_protection+0x19b/0x1af May 2 01:19:18 reddwarf kernel: [<c0277001>] acpi_hw_low_level_read+0xc5/0xd1 May 2 01:19:18 reddwarf kernel: [<c0244678>] copy_from_user+0x4c/0x84 May 2 01:19:18 reddwarf kernel: [<c0104800>] do_general_protection+0x0/0x1af May 2 01:19:18 reddwarf kernel: [<c01038cb>] error_code+0x4f/0x54 May 2 01:19:18 reddwarf kernel: [<c0102e11>] syscall_call+0x7/0xb May 2 01:19:18 reddwarf kernel: handlers: May 2 01:19:18 reddwarf kernel: [<c02605c1>] (acpi_irq+0x0/0x16) May 2 01:19:18 reddwarf kernel: Disabling IRQ #9 log file: http://picaros.org/xorg/Xorg.r9250s.halt patch: http://picaros.org/xorg/int10biosloc.diff xorg.conf: http://picaros.org/xorg/xorg.conf
Created attachment 5544 [details] [review] int10 softboot: Option "BiosLocation" "file:pathname"
Is this related to (or a duplicate of) bug 6751?
(In reply to comment #38) > Is this related to (or a duplicate of) bug 6751? This patch allows for a manual workaround. It loads the rom image from any user specified file which is more general since the sysfs rom is not always available. In my setup, I can't get anything from the Radeon 9250 rom if it isn't POSTed primary, nor via direct access in handlePciBIOS() and neither via the linux kernel. POST leaves rom_addr=0xfffe0000 which pciBusAddrToHostAddr() duly returns, whatever I poke in with setpci(8). (The tests I commented out to get this far are not in the patch.) And yes, it is related. Specifying the Linux sysfs path like e.g. Option "BiosLocation" "/sys/devices/pci.. / ... /rom" does basically the same thing as the patch for bug 6751. But I think this patch is useful as such -- a manual last resort override for very special circumstances. Also, this extension does not come at the cost of more lines of code since it cleans up the primary/secondary if-then-else tree. It was rigourously tested. Please take a look if it makes some sense for your setup.
(In reply to comment #39) > (In reply to comment #38) > > Is this related to (or a duplicate of) bug 6751? > This patch allows for a manual workaround. > ... > And yes, it is related. Sorry, my question was a more general one regarding this entire bug :) > Please take a look if it makes some sense for your setup. To be honest, I'm very impressed by your approach/patch. If I get a chance, I'll give it a try.
I can confirm, that "my" bug mentioned in comment #27 is fixed by applying the patch mentioned in bug #6751. AFAIK this patch is already applied to the TRUNK of xorg so that further releases include them. And yes, I do think, that the patch attached to comment #37 is more general and therefore "better". However, I wanted to test the "standard" xorg which (unfortunately) does not use the mentioned patch.
(In reply to comment #36) > > A solution is to boot with the 9250 primary and to write the rom image to > a file by copying it from the OS > > /sys/devices/pci0000:00/ ... /rom > > system file or by using > > dd if=/dev/mem of=/root/r9250.bio bs=65536 skip=12 count=1 > I boot with my radeon 9250 as primary and try as : cp /sys/bus/pci/devices/0000\:03\:0a.0/rom /root/r9250.bio but, it doesn't work : "cp: lecture de `/sys/bus/pci/devices/0000:03:0a.0/rom': Argument invalide" So wath is the good command ?
Hi! > I boot with my radeon 9250 as primary and try as : > cp /sys/bus/pci/devices/0000\:03\:0a.0/rom /root/r9250.bio > but, it doesn't work : "cp: lecture de `/sys/bus/pci/devices/0000:03:0a.0/rom': > Argument invalide" I am having the same Problem. I cannot extract the rom image from sysfs. Using the dd command works, but I cannot get a working dual head setup, as the system now freezes earlier. I am using Dapper and patched the corresponding source packages and rebuilt them. My setup is two PCI-E Ati X-300 cards lspci |grep VGA 0000:01:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)] 0000:03:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)]
> I am having the same Problem. I cannot extract the rom image from sysfs. Using > the dd command works, but I cannot get a working dual head setup, as the system Using the dd extracted rom image initializes the second head, but when I compare this to the initialization when using the older kernel, it looks a little bit different. old kernel: one can see a serial number in the upper left corner new kernel+patched xorg: one can see a little bit shifted serial number and other characters. My guess is that the extracted rom image isn't correct. It looks like: 00000000: 20 07 20 07 20 07 20 07 20 07 20 07 55 aa 68 e9 . . . . . .U.h. 00000010: 29 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 )............... 00000020: 00 00 00 00 78 01 00 00 00 00 49 42 4d 7a 00 00 ....x.....IBMz.. 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 20 37 36 31 ............ 761 00000040: 32 39 35 35 32 30 00 00 00 00 00 00 3f 3f 00 00 295520......??.. 00000050: 00 00 00 00 0a 01 00 00 00 00 00 00 32 30 30 34 ............2004 00000060: 2f 30 38 2f 31 34 20 31 30 3a 31 34 00 00 00 00 /08/14 10:14.... 00000070: e9 f6 13 00 e9 ae 1f 00 00 00 00 00 00 80 00 77 ...............w 00000080: 00 c0 4b 17 50 04 00 00 00 00 00 00 0d 0a 50 2f ..K.P.........P/ 00000090: 4e 31 31 33 2d 50 43 34 35 30 33 2d 30 32 0d 0a N113-PC4503-02.. 000000a0: 00 28 43 29 20 31 39 38 38 2d 32 30 30 33 2c 20 .(C) 1988-2003, 000000b0: 41 54 49 20 54 65 63 68 6e 6f 6c 6f 67 69 65 73 ATI Technologies 000000c0: 20 49 6e 63 2e 20 42 4b 2d 41 54 49 20 56 45 52 Inc. BK-ATI VER 000000d0: 30 30 38 2e 30 31 35 2e 31 32 30 2e 30 30 30 00 008.015.120.000. 000000e0: 20 68 79 70 63 34 35 30 33 2e 30 32 20 76 36 31 hypc4503.02 v61 000000f0: 31 20 00 56 33 38 30 50 43 49 45 44 47 44 31 55 1 .V380PCIEDGD1U 00000100: 4e 00 00 4f 45 4d 20 56 45 52 2e 30 30 30 2e 30 N..OEM VER.000.0 [...] P/N113-PC4503-02 is the mentioned serial number appearing, when the head is initialized. /sys/devices/pci0000:00/0000:00:0e.0/0000:01:00.0# cat rom > /tmp/test.rom cat: rom: Invalid argument
(In reply to comment #44) Your rom image is shifted by 12 bytes. Its signature 55 aa is at offset 12. This can be corrected through dd if=/root/x300old.bio of=/root/x300.bio bs=1 skip=12 count=53248 where the size count comes from 0x68*0x200. Make sure to boot with the kernel parameter pci=routeirq and that an IRQ is allocated for the secondary card. Check lspci -v Flags: fast devsel, IRQ 16. A good image looks like 00000000 55 aa 68 e9 57 07 00 00 00 00 00 00 00 00 00 00 UªhéW........... 00000010 00 00 00 00 00 00 00 00 a4 01 00 00 00 00 49 42 ........¤.....IB 00000020 4d 56 00 00 00 00 00 00 00 00 00 00 00 00 00 00 MV.............. 00000030 20 37 36 31 32 39 35 35 32 30 00 00 00 00 00 00 761295520...... 00000040 3f 3f 00 00 00 00 00 00 36 01 00 00 00 00 00 00 ??......6....... 00000050 32 30 30 34 2f 30 37 2f 32 30 20 31 35 3a 35 39 2004/07/20 15:59 00000060 00 00 00 00 e9 36 14 00 e9 ee 1f 00 00 00 00 00 ....é6..éî...... 00000070 00 80 00 77 00 c0 af 17 1e 20 00 00 00 00 00 00 ...w.À¯.. ...... 00000080 0d 0a 31 31 33 2d 48 59 53 37 45 48 30 31 2d 30 ..113-HYS7EH01-0 00000090 30 52 2d 48 54 20 52 58 33 30 30 53 45 20 31 32 0R-HT RX300SE 12 000000a0 38 4d 5c 36 34 42 20 43 52 54 5c 54 56 5c 44 56 8M\64B CRT\TV\DV 000000b0 49 2d 49 20 32 30 30 4d 5c 33 32 35 45 0d 0a 00 I-I 200M\325E... 000000c0 28 43 29 20 31 39 38 38 2d 32 30 30 33 2c 20 41 (C) 1988-2003, A 000000d0 54 49 20 54 65 63 68 6e 6f 6c 6f 67 69 65 73 20 TI Technologies 000000e0 49 6e 63 2e 20 42 4b 2d 41 54 49 20 56 45 52 30 Inc. BK-ATI VER0 000000f0 30 38 2e 30 31 35 2e 31 31 35 2e 30 30 30 00 20 08.015.115.000. 00000100 68 79 73 37 65 68 30 31 2e 30 30 72 20 76 36 31 hys7eh01.00r v61 00000110 31 20 00 56 33 38 30 50 43 49 45 44 47 44 31 55 1 .V380PCIEDGD1U 00000120 4e 00 00 4f 45 4d 20 56 45 52 2e 30 30 30 2e 30 N..OEM VER.000.0 00000130 30 30 00 90 6c 00 08 a0 08 0f 73 00 6c 00 6f 20 00..l.. ..s.l.o
(In reply to comment #45) > dd if=/root/x300old.bio of=/root/x300.bio bs=1 skip=12 count=53248 Ok. Rom image looks now fine. > where the size count comes from 0x68*0x200. Make sure to boot with the > kernel parameter pci=routeirq and that an IRQ is allocated for the > secondary card. Check lspci -v Flags: fast devsel, IRQ 16. A good > image looks like I checked whether the second card has a irq and also added the pci=routeirq parameter. When I start X the second head doesn't get initialized and on the left side I can see a blinking cursor in the top left corner. There is no Xorg.log created. Any ideas?
Hi vdb128, I followed the instructions above, made the ATI primary display and used dd to grab the BIOS, which looks like this: 00000000 55 AA 40 EB 7B FF 4F 00 00 00 00 00 00 00 00 00 U.@.{.O......... 00000010 00 00 00 00 00 00 00 00 8C 01 00 00 00 00 49 42 ..............IB 00000020 4D 00 34 7B 00 72 4F 00 00 00 00 00 00 00 00 00 M.4{.rO......... 00000030 20 37 36 31 32 39 35 35 32 30 FF FF A5 90 8C 93 761295520...... 00000040 33 3F 00 60 00 00 00 00 08 01 02 10 08 00 00 00 3?.`............ 00000050 32 30 30 30 2F 30 37 2F 31 38 20 30 30 3A 33 30 2000/07/18 00:30 00000060 00 00 00 00 E9 3C 50 00 E9 31 50 00 E9 A8 13 00 .....<P..1P..... 00000070 E9 A5 13 FF FF 00 00 00 A4 01 FF FF A5 90 8C 93 ................ 00000080 CB 90 90 0D 0A 41 54 49 20 52 41 47 45 20 53 44 .....ATI RAGE SD 00000090 52 41 4D 20 42 49 4F 53 20 50 2F 4E 20 31 31 33 RAM BIOS P/N 113 000000A0 2D 37 32 33 30 31 2D 31 30 30 20 0D 0A 00 28 43 -72301-100 ...(C 000000B0 29 20 31 39 38 38 2D 31 39 39 39 2C 20 41 54 49 ) 1988-1999, ATI 000000C0 20 54 65 63 68 6E 6F 6C 6F 67 69 65 73 20 49 6E Technologies In 000000D0 63 2E 42 4B 34 2E 33 2E 30 34 2F 34 2E 33 32 38 c.BK4.3.04/4.328 000000E0 20 78 6C 37 32 33 2E 30 31 20 6D 6C 76 36 31 31 xl723.01 mlv611 000000F0 20 00 4D 41 43 48 36 34 47 52 50 43 49 4D 54 53 .MACH64GRPCIMTS 00000100 44 55 4E 38 00 00 4A 00 00 A0 04 1C EC 02 00 00 DUN8..J......... ... I then rebooted and changed my i815 back to primary display, making the Mach64 secondary. I applied the patch and specified the new BiosLocation option for the Mach64, but it still will not initialize (here's the relevant portion of Xorg.0.log). I then confirmed the Mach64 had an IRQ, and rebooted with the pci=routeirq kernel option: (**) ATI(0): Option "BiosLocation" "file:/root/mach64.bios" (II) ATI(0): Read 32 kB V_BIOS from file:/root/mach64.bios (II) Loading sub module "ddc" (II) LoadModule: "ddc" (II) Reloading /usr/lib/xorg/modules/libddc.so (II) Loading sub module "vbe" (II) LoadModule: "vbe" (II) Reloading /usr/lib/xorg/modules/libvbe.so (II) ATI(0): VESA BIOS not detected (EE) ATI(0): Adapter has not been initialised. It seems as if the bios that is loaded is not recognised by the ATI driver for some reason. Any suggestions? I did have dualhead working in this setup with the X.org CVS, which I compiled and installed in my home directory... but that was not a good solution for me :-) Thanks
A slightly modified version of the patch from https://bugs.freedesktop.org/show_bug.cgi?id=6751 applied to 6.9 fixes this problem for me.
The patch in bug #6751 (as packaged by Gentoo) did not help me. I have the same problem in X11 r7.0 with combination: nVidia Corporation NV34 [GeForce FX 5200] rev 161 (AGP, primary) ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] rev 0 (PCI, secondary) Had to revert back to r6.8. Could it be that some of the newly introduced code in X has primary card hardwired somewhere ? So that it reads BIOS from a wrong (primary) card (while initializing the secondary one)...
This should fix https://bugzilla.novell.com/attachment.cgi?id=86821 from https://bugzilla.novell.com/show_bug.cgi?id=171453&x=0&y=0
Some additional experimental input and workaround. I played some more with Gentoo's xorg-server-1.0.2-r7, containing the patch from bug 6751. First, I have managed to install it in one go, after shutting down the previously working multi-seat under 6.8.2 without reboot. To my surprise both cards (I have described my configuration in comment #49) worked fine individually and also started up fine under control of KDM (with the PCI card's X-server locking system hard on shutdown). After reboot the second server stopped working, logging the usual: Requesting insufficient memory window!: start: 0xe8000000 end: 0xefffffff size 0xf0040000 Requesting insufficient memory window!: start: 0xf0000000 end: 0xf1ffffff size 0xf0040000 Requesting insufficient memory window!: start: 0xe8000000 end: 0xefffffff size 0xf0040000 Requesting insufficient memory window!: start: 0xf0000000 end: 0xf1ffffff size 0xf0040000 Requesting insufficient memory window!: start: 0xe8000000 end: 0xefffffff size 0xf0040000 Requesting insufficient memory window!: start: 0xf0000000 end: 0xf1ffffff size 0xf0040000 (EE) RADEON(0): Cannot read V_BIOS Then I've tried to read the BIOS of the PCI card manually (to try the other patch from this bug). Poking in sysfs/.../rom resulted in a file full of 0xFF. I've decided that it is because the PCI card was not selected as primary in BIOS, selected it and reboot. The sysfs/.../rom was still 0xFF, but, to my surprise, the KDM was able to start both X servers, and the whole setup runs flawlessly (after fixing evdev xkb) till now (I have rebooted and switched the computer on/off several times already). So, my suggestion is to try to play with the primary card in BIOS, it helped in my case.
As a system BIOS writer by profession, I can shed a couple of lights here. Let's start with a few bits of generic wisdom. To get a VGA chip to run as secondary, you'll need to have access to its VBIOS somehow, and (!) the chip must be fully programmable through its PCI-style register set, in other words, without the use of legacy VGA I/O registers. The latter limitation can hardly be worked around - other than running the limited chip as primary and hoping that the other one(s) are multi-VGA capable by design. Getting to the VBIOS of a non-primary VGA chip is mostly prevented by two things: * The chip doesn't physically have a BIOS ROM on. This is always the case for chipset-integrated VGA units, and common with discrete chips down on the mainboard. * Some system BIOSes do not assign resources to any but the primary VGA chip. This is an actual BIOS bug, and leaves the OS with little chance to get it fired up after the fact - particularly if the VGA chip resides on a bridged PCI bus. The former case can be alleviated by having the system BIOS fire the ROMless chip up as primary - if it gives you the choice. A popular fix with Windows drivers is to bring the VBIOS as a file - as suggested here - but usually VBIOS images are configured to match the board design, so that loading a generic VBIOS will often fail rather miserably. Extracting the particular board's VBIOS image from the main BIOS ROM is a task the end user won't get done easily. Now, what if we /did/ get the VBIOS image but still can't start it? As of pre-7.2 x.org, I'm currently seeing a lot of messages like "Attempted to read 64KB VBIOS but got only 32KB" in Xorg.log.X files on Linux systems, including my server box here (ATI Rage XL as primary, Permedia 2v as secondary). This points to a potential int10 problem: int10 seems to assume that it can read as much data from the ROM area as the size of the PCI ROM BAR suggests. However, this is most commonly not the case. Actual ROM images are almost always shorter than the ROM decode window, and the Linux sysfs reflects that (returning only as much data as the length field in the ROM header declares). It appears that int10 then does nothing, leaving the secondary VGA chip once again un-initialized and the driver clueless. Finally, in case all of the above has worked, the secondary VBIOS gets started, but still doesn't manage to fire up the chip, you are probably looking at a case of a VGA chip that depends on access to its legacy VGA register set - or a VBIOS that has been written under the assumption that it may do that.
And now, my own complaint: Although my system's BIOS gives it all the resources correctly, the VBIOS is accessible and the chip by design capable of running as secondary, X can't fire it up for what I interpret as the aforementioned int10 problem. I'll upload a logfile in a minute.
Created attachment 8638 [details] Logfile: X/Linux int10 failure on secondary Permedia Note: The X server fires up despite the int10 failure, but the display is full of noise and garbage - exactly as has been described here, http://bugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=226973 a long time ago for an entirely different architecture.
To share my similar experiences: using FC6 (X 7.1.1, xorg-x11-drv-ati-6.6.3-1.fc6, xorg-x11-server-Xorg-1.1.1-47.5.fc6). These include the patch in bug 6751, which doesn't solve my problem. Hardware: Intel D945GTP motherboard (updated to latest BIOS) PCIe GeForce 7600GS (using nv driver) PCI Radeon 9200 Pro / rv280 (using radeon driver) Whichever graphics card isn't set as the primary card in the motherboard BIOS (i.e. the "secondary" card) fails to work - in each case hardware detection fails, though in different ways. The failing card will work when set as the primary, and vice versa. In both cases I see the "Cannot read V_BIOS" for whichever card is secondary. Copying the Radeon V_BIOS from memory to file while it's primary works (though not through /sys), then using the patch in comment 37 (minor hack to make it fit) and loading the VBIOS from file when the Radeon is secondary works. More details at: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227851
Kevin, vdb128, being able to load a VBIOS from file is a really neat extension. However, the VBIOS you pick up by reading from 0xC0000 isn't /really/ what's needed. The image you see there is only the runtime part, initialized during POST, marked as such, and with the pure POST init part already jettisoned. With a graphics card that (inherently) brings a physical ROM, doing this shouldn't ever be needed (provided int10 and libpciaccess do their job right, see bug #9920 and bug #8269). VBIOS from file is a neat trick for mainboard- or even chipset-integrated VGA units that /don't/ bring their own physical ROM - but to get int10 to softboot this /correctly/, you'll need the virgin ROM image file, not the runtime-ized one from 0xC0000. The "right" VBIOS image resides in the main system ROM, either compressed or - rarely - uncompressed; the system ROM itself is at the very top of the 32-bit address space. Getting to the VBIOS image embedded therein requires proprietary knowledge about how the particular BIOS brand organizes the binaries. Not easy (except if you're a BIOS engineer ;)) at all ...
It's bug #8369 not 8269, sorry.
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Just to note that this if still afflicting xserver 1.3 on Fedora 7 [1]. It looks like Fedora might be carrying some VBIOS patches - which don't fix this - but do prevent the patches in comment 37 from applying. What's the outlook on the "right" fix to this? If it's long term, could the VBIOS from file workaround be applied? Without this one can't use a second graphics card as a second head! [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227851
Kevin, like I tried to outline above, the VBIOS-from-file thing is just helping to mask the original problem - non-working VBIOS retrieval from ROM during 2nd card softboot. Part of the problem are some system BIOSes that ignore all but the 1st VGA completely - not only not enabling them (which a BIOS can't do), but also not giving them any resources. Even with one VGA unit being mainboard-integrated without a physical ROM to read from, the system BIOS can un-snafu the situation by initialising this onboard VGA as primary boot output, and letting the OS fire up the other(s). I'm a system BIOS engineer, and I've coded solutions to both of the above. The rest is the softboot process in X itself. But seeing how long this bug and related ones haven't seen improvements or even generated any kind of interest from the respective maintainers, I wouldn't hold my breath.
Peter, Yes - thanks for your explanations. I realise the load-from-file hack isn't the right solution (or even the "right" VBIOS), however it has worked in many cases (e.g. mine!) and therefore is surely better than nothing? I don't see how it would create any problems for those who don't pass in the option.
I fully agree that the VBIOS-from-file option is harmless for everyone, and useful for some. I could use it well in a problem case I have here, where the add-on card doesn't do secondary due to another X bug, and the onboard one doesn't because there's no physical BIOS ROM. How to retrieve the virgin VBIOS file is a secondary problem ... so if you need a vote for VBIOS-from-file, you have mine.
Dual-head should work properly with recent xserver + randr 1.2 and recent xf86-video-ati reopen if it's not the case for you.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.