Bug 2597 - Dual Head broken
Summary: Dual Head broken
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: 6.9.0
Hardware: x86 (IA32) Linux (All)
: high major
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-02-22 21:04 UTC by Tony Howard
Modified: 2009-05-20 05:26 UTC (History)
14 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Log file of secondary monitors failing (search for ATI(1) and ATI(2)) (68.76 KB, text/plain)
2006-03-23 18:15 UTC, greg
no flags Details
Error log with nv card set as primary (35.41 KB, text/x-log)
2006-03-28 05:02 UTC, Jack liu
no flags Details
NVIDIA driver with i810 as primary (17.37 KB, text/plain)
2006-03-28 06:33 UTC, Tony Howard
no flags Details
i810 driver with NVIDIA as primary (18.47 KB, text/plain)
2006-03-28 06:34 UTC, Tony Howard
no flags Details
i810 driver with i810 as primary, works (54.67 KB, text/plain)
2006-03-28 06:35 UTC, Tony Howard
no flags Details
NVIDIA driver with NVIDIA as primary, works (29.55 KB, text/plain)
2006-03-28 06:37 UTC, Tony Howard
no flags Details
i810 primary, using i810 driver (53.30 KB, text/plain)
2006-03-28 08:58 UTC, Jack liu
no flags Details
i810 primary, same depth/resolution, display locks up (53.75 KB, text/plain)
2006-03-29 03:27 UTC, Jack liu
no flags Details
Xorg.0.log from working Fedora Core 4 (62.41 KB, text/plain)
2006-03-29 18:17 UTC, Dr. Tilmann Bubeck
no flags Details
lspci output from working Fedora Core 4 (1.89 KB, text/plain)
2006-03-29 18:18 UTC, Dr. Tilmann Bubeck
no flags Details
lspci -v -n output from working Fedora Core 4 (5.31 KB, text/plain)
2006-03-29 18:18 UTC, Dr. Tilmann Bubeck
no flags Details
Xorg.0.log from broken Fedora Core 5 (67.30 KB, text/plain)
2006-03-29 18:19 UTC, Dr. Tilmann Bubeck
no flags Details
lspci output from broken Fedora Core 5 (1.89 KB, text/plain)
2006-03-29 18:19 UTC, Dr. Tilmann Bubeck
no flags Details
lspci -v -n output from broken Fedora Core 5 (5.41 KB, text/plain)
2006-03-29 18:19 UTC, Dr. Tilmann Bubeck
no flags Details
JasonF, using nv+i810 (39.69 KB, text/plain)
2006-03-30 08:34 UTC, Jason Faulkner
no flags Details
JasonF, using nv+i810 (39.69 KB, text/plain)
2006-03-30 08:36 UTC, Jason Faulkner
no flags Details
J.Adamczewski Xorg.log for 9700/TNT2 combination (164.14 KB, text/plain)
2006-04-05 23:22 UTC, Jonathan Adamczewski
no flags Details
int10 softboot: Option "BiosLocation" "file:pathname" (14.81 KB, patch)
2006-05-02 10:33 UTC, vdb128
no flags Details | Splinter Review
Logfile: X/Linux int10 failure on secondary Permedia (40.52 KB, text/plain)
2007-02-08 13:09 UTC, Peter Missel
no flags Details

Description Tony Howard 2005-02-22 21:04:57 UTC
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.
Comment 1 Alan Hourihane 2006-01-30 20:25:42 UTC
logs have disappeared. Re-open if there's still a problem with X.Org 7.0
Comment 2 Wesley Tanaka 2006-03-12 18:22:56 UTC
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.
Comment 3 greg 2006-03-23 18:07:15 UTC
I seem to have the same problem with different cards. Will attach logs.
Comment 4 greg 2006-03-23 18:15:11 UTC
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
Comment 5 Jason Faulkner 2006-03-25 04:41:10 UTC
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
--------------
Comment 6 Jason Faulkner 2006-03-28 00:41:23 UTC
Adding a CC to alanh per a conversation on IRC with "libv"
Comment 7 Alan Hourihane 2006-03-28 00:44:51 UTC
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 ?
Comment 8 Jack liu 2006-03-28 05:02:15 UTC
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.
Comment 9 Alan Hourihane 2006-03-28 05:12:24 UTC
You really need to set the i810 as primary and post a new log
Comment 10 Tony Howard 2006-03-28 06:33:45 UTC
Created attachment 5091 [details]
NVIDIA driver with i810 as primary

My web storage got deleted, but here is the log from the original problem.
Comment 11 Tony Howard 2006-03-28 06:34:41 UTC
Created attachment 5092 [details]
i810 driver with NVIDIA as primary
Comment 12 Tony Howard 2006-03-28 06:35:16 UTC
Created attachment 5093 [details]
i810 driver with i810 as primary, works
Comment 13 Tony Howard 2006-03-28 06:37:39 UTC
Created attachment 5094 [details]
NVIDIA driver with NVIDIA as primary, works
Comment 14 Alan Hourihane 2006-03-28 06:52:39 UTC
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.
Comment 15 Jack liu 2006-03-28 08:58:38 UTC
Created attachment 5095 [details]
i810 primary, using i810 driver

Screen goes black and locks up.
Comment 16 Alan Hourihane 2006-03-28 17:51:19 UTC
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.
Comment 17 Jack liu 2006-03-29 03:27:23 UTC
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.
Comment 18 Alan Hourihane 2006-03-29 04:00:25 UTC
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.
Comment 19 Alan Hourihane 2006-03-29 04:02:16 UTC
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.
Comment 20 Jack liu 2006-03-29 06:58:57 UTC
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.
Comment 21 Dr. Tilmann Bubeck 2006-03-29 18:17:36 UTC
Created attachment 5116 [details]
Xorg.0.log from working Fedora Core 4
Comment 22 Dr. Tilmann Bubeck 2006-03-29 18:18:16 UTC
Created attachment 5117 [details]
lspci output from working Fedora Core 4
Comment 23 Dr. Tilmann Bubeck 2006-03-29 18:18:42 UTC
Created attachment 5118 [details]
lspci -v -n output from working Fedora Core 4
Comment 24 Dr. Tilmann Bubeck 2006-03-29 18:19:11 UTC
Created attachment 5119 [details]
Xorg.0.log from broken Fedora Core 5
Comment 25 Dr. Tilmann Bubeck 2006-03-29 18:19:36 UTC
Created attachment 5120 [details]
lspci output from broken Fedora Core 5
Comment 26 Dr. Tilmann Bubeck 2006-03-29 18:19:59 UTC
Created attachment 5121 [details]
lspci -v -n output from broken Fedora Core 5
Comment 27 Dr. Tilmann Bubeck 2006-03-29 18:21:05 UTC
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).
Comment 28 Jack liu 2006-03-30 03:02:40 UTC
(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.
Comment 29 Jason Faulkner 2006-03-30 08:34:12 UTC
Created attachment 5124 [details]
JasonF, using nv+i810
Comment 30 Jason Faulkner 2006-03-30 08:36:33 UTC
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.
Comment 31 Jonathan Adamczewski 2006-04-05 23:18:32 UTC
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)
Comment 32 Jonathan Adamczewski 2006-04-05 23:22:18 UTC
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).
Comment 33 Chris Gianelloni 2006-04-11 23:36:27 UTC
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.
Comment 34 Chris Gianelloni 2006-04-12 00:47:02 UTC
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
Comment 35 Andrew Gaffney 2006-04-12 01:08:46 UTC
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)
Comment 36 vdb128 2006-05-02 10:30:37 UTC
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
Comment 37 vdb128 2006-05-02 10:33:45 UTC
Created attachment 5544 [details] [review]
int10 softboot: Option "BiosLocation" "file:pathname"
Comment 38 Jonathan Adamczewski 2006-05-02 15:56:44 UTC
Is this related to (or a duplicate of) bug 6751?
Comment 39 vdb128 2006-05-02 17:34:00 UTC
(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.
Comment 40 Jonathan Adamczewski 2006-05-02 22:52:02 UTC
(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.
Comment 41 Dr. Tilmann Bubeck 2006-05-10 04:05:32 UTC
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.
Comment 42 BuBuaBu 2006-05-21 01:09:36 UTC
(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 ?
Comment 43 Torge Szczepanek 2006-06-13 15:09:29 UTC
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)]




Comment 44 Torge Szczepanek 2006-06-13 15:21:42 UTC
> 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


Comment 45 vdb128 2006-06-13 17:40:02 UTC
(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
Comment 46 Torge Szczepanek 2006-06-14 01:26:10 UTC
(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?
Comment 47 Ashley 2006-06-14 01:59:26 UTC
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
Comment 48 Andrew Gaffney 2006-06-29 18:22:37 UTC
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.
Comment 49 Konstantin L. Metlov 2006-07-04 13:48:42 UTC
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)...
Comment 51 Konstantin L. Metlov 2006-07-15 15:06:14 UTC
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.
Comment 52 Peter Missel 2007-02-08 12:54:47 UTC
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.
Comment 53 Peter Missel 2007-02-08 13:02:01 UTC
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.
Comment 54 Peter Missel 2007-02-08 13:09:08 UTC
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.
Comment 55 Kevin R. Page 2007-02-15 10:16:24 UTC
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
Comment 56 Peter Missel 2007-02-15 16:28:12 UTC
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 ...
Comment 57 Peter Missel 2007-02-16 09:03:29 UTC
It's bug #8369 not 8269, sorry.
Comment 58 Daniel Stone 2007-02-27 01:25:33 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 59 Kevin R. Page 2007-07-11 05:21:58 UTC
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
Comment 60 Peter Missel 2007-07-11 12:03:07 UTC
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.
Comment 61 Kevin R. Page 2007-07-11 16:40:02 UTC
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.
Comment 62 Peter Missel 2007-07-12 11:55:43 UTC
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.
Comment 63 Jerome Glisse 2009-05-20 05:26:30 UTC
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.