|Summary:||int10 (riva128) lock up|
|Product:||[Fedora] Fedora||Reporter:||Jan "Yenya" Kasprzak <kas>|
|Component:||xorg-x11-server||Assignee:||Adam Jackson <ajax>|
|Status:||CLOSED NEXTRELEASE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||10||CC:||mcepl, wayland, whitney, xgl-maint|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-11-20 16:01:25 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Jan "Yenya" Kasprzak 2008-07-10 10:44:17 UTC
Description of problem: I have a dual-seat setup (two monitors, two keyboards, two mice), and it stopped working after the F7->F9 upgrade. The primary head works OK, but the secondary locks up (probably) while initializing the card via the int10 interface. My hardware is: AMD Athlon 3000+ (32-bit) ATi Radeon 7500 AGP as a primary head Nvidia Riva128 PCI as a secondary head ("nv" driver) Version-Release number of selected component (if applicable): xorg-x11-server-Xorg-188.8.131.525-1.20080701.fc9 xorg-x11-drv-nv-2.1.10-1.fc9 The last lines in /var/log/Xorg.1.log are the following: (II) RIVA128(0): Initializing int10 (II) Attempted to read BIOS 4096KB from /sys/bus/pci/devices/0000:00:13.0/rom: g ot 32KB ... which would normally continue as follows (taken from : (==) RIVA128(0): Depth 15, (--) framebuffer bpp 16 (==) RIVA128(0): RGB weight 555 (==) RIVA128(0): Default visual is TrueColor The secondary X server now loops (eats 100 % CPU time), and cannot be killed by SIGTERM. SIGKILL works, though, so it is probably locked up somewhere in user space. Downgrade to the Fedora 8 version of X server and drivers fixed the problem - with the following packages it works: xorg-x11-server-Xorg-184.108.40.206-46.fc8.i386 xorg-x11-drv-nv-2.1.6-1.fc8.i386 xorg-x11-drv-ati-6.8.0-4.fc8.i386 Additional info: I am filling this under xorg-x11-server because /usr/lib/xorg/modules/libint10.so belongs to the X server package and not the xorg-x11-drv-nv package (altough it _may_ be nv-driver related). I use xdm to start the X servers with the following setup in /etc/X11/xdm/Xservers: :0 local /usr/bin/X :0 vt7 -layout ATI+LGLCD :1 local /usr/bin/X :1 vt7 -layout Riva+PhilipsLCD -sharevts -novtswitch -isolateDevice PCI:00:19:0 I am attaching my xorg.conf file.
Comment 1 Jan "Yenya" Kasprzak 2008-07-10 10:44:17 UTC
Created attachment 311466 [details] My xorg.conf
Comment 2 Matěj Cepl 2008-07-15 16:41:45 UTC
Could we get please /var/log/Xorg.*.log attached as well? Thank you
Comment 3 Wayne Whitney 2008-08-08 18:08:24 UTC
I am having the exact same problem. A dual seat setup that worked fine under Fedora 8 fails after upgrading to Fedora 9. The primary head works OK, but the secondary locks up, with the last line in the Xorg.log "(II) RADEON(0): initializing int10". My hardware: AMD Athlon 64 X2 Dual Core Processor 4200+ ATI Radeon 9200 PRO PCI as primary head ATI Radeon 7000/VE AGP as secondary head Everything works OK with these packages from Fedora 8: xorg-x11-server-Xorg-220.127.116.11-46.fc8.i386 xorg-x11-drv-ati-6.8.0-4.fc8.i386 I tried the xorg-x11-server packages from F9-Beta, F9-Preview, F9, and F9-Updates, all with the same failure. I'll attach an Xorg.log from the working Fedora 8, and from the non-working Fedora 9, for the secondary head card.
Comment 4 Wayne Whitney 2008-08-08 18:11:23 UTC
Created attachment 313824 [details] Xorg.log for working secondary head under Fedora 8
Comment 5 Wayne Whitney 2008-08-08 18:12:00 UTC
Created attachment 313826 [details] Xorg.log for non-working secondary head under Fedora 9
Comment 6 Wayne Whitney 2008-08-08 18:13:24 UTC
Created attachment 313827 [details] Xorg.log for "X -configure" under Fedora 9 Under Fedora 9, "X -configure" hangs up at the same point, when reloading libint10 for the secondary head.
Comment 7 Wayne Whitney 2008-08-08 18:14:42 UTC
Created attachment 313828 [details] xorg.conf from the second reporter
Comment 8 Jan "Yenya" Kasprzak 2008-10-06 13:14:28 UTC
This is not nv related, but int10 related. I have bought a new computer with two PCIe ATi Radeon HD 3xxx cards, and the problem is the same - when starting the X server on a secondary card (with the same Xorg.conf that works on the primary head, except the BusID line is different), it locks up inside the int10 module. With Option "noint10" "yes" it complains that the card has not been POSTed yet (no surprise here). It also has nothing to do with multiseat - the lock-up occurs even when the X server on the not-yet-booted card is the only X server running. Can I somehow boot the secondary card manually? The title of this bug should be changed - it is an int10 problem, not nv problem.
Comment 9 Jan "Yenya" Kasprzak 2008-10-21 21:54:19 UTC
No reaction from Fedora maintainers :-( , so I have tried to forward it upstream: https://bugs.freedesktop.org/show_bug.cgi?id=18160
Comment 10 Tim Nelson 2009-02-04 04:10:43 UTC
Update from upstream; there's a bug fix that overcomes this problem, but at least in my case, I still can't get multiple monitors working. The bug is in the libpciaccess package, which probably means that the component should be changed.
Comment 11 Bug Zapper 2009-06-10 02:01:28 UTC
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 12 Tim Nelson 2009-06-10 07:24:08 UTC
I can confirm that this is still a problem with Fedora 10. Unfortunately I don't appear to have the power to change the version number. Could someone do that?
Comment 13 Bug Zapper 2009-07-14 17:45:32 UTC
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 14 Tim Nelson 2009-07-15 06:01:58 UTC
I can reproduce this in Fedora 10, and I'm expecting Fedora 11 to have the same issue (will install it in a week or two, hopefully). Please reopen, as I said before.
Comment 15 Jan "Yenya" Kasprzak 2009-07-20 07:47:59 UTC
Comment 16 Bug Zapper 2009-11-18 12:36:08 UTC
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 17 Jan "Yenya" Kasprzak 2009-11-18 13:38:13 UTC
To Tim Nelson: please verify whether it still exists in F11 or F12. As for me, I don't have the hardware setup mentioned in the original report anymore, and for the hardware described in comment #8 it worked in F11, except that I got a complete lockup when stopping the X server (as described in detail in the upstream bug). I have not tried F12 yet, but I hope the dual radeon will work with the new KMS kernel and the VGA arbiter device.
Comment 18 Tim Nelson 2009-11-19 02:04:35 UTC
I no longer have that hardware set up on Fedora either. I *do* have a FireMV 2400 which fails for somewhat similar reasons. However, I'm kind of busy at the moment (NaNoWriMo), and may not get around to looking at this until Fedora 13, so close the bug, and I will open a new one if I need it. Oh, and thanks to Redhat for its support of the Xorg developers. :)
Comment 19 Matěj Cepl 2009-11-20 16:01:25 UTC
Thank you for letting us know.