Bug 2597

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.