Folks, we just tried an install on a Panasonic CF-52 (TOUGHBOOK laptop) using an ATI Radeon X2100. 1) had to install in text mode because X is just black screen. 2) after install startx results in the same situation. (consistency is nice) 3) by default xorg.conf is pointing at vesa instead of an ati driver, so it does not do a PCI scan, it just hangs at a black screen.
after setting the driver to ati, the startx process just gives up because xorg (as the log.ati shows) for some reasons can't find a screen.
BTW, no other monitors plugged in, just the one on the laptop, and when I do plug other monitors in (such as a Dell 1907FPf) it changes nothing.
So is there a way to get 2D on this machine, besides doing http://www.fedorafaq.org/#radeon or figuring out which driver from http://ati.amd.com/support/driver.html (the M71 || Mobility Radeon X2100 is not listed)???
I miss the days of being able to tell X to drop back and punt with a generic VGA (640x480 or 800x600) config.
P.S. is the correct etiquette for this mailing list to: A) have a bunch of text files attached, B) tar and bzip them before attaching, C) make the folks helping you request the ones they want???
On Mon, 2007-10-29 at 18:06 -0500, Todd Denniston wrote:
Folks, we just tried an install on a Panasonic CF-52 (TOUGHBOOK laptop) using an ATI Radeon X2100.
- had to install in text mode because X is just black screen.
- after install startx results in the same situation. (consistency is nice)
- by default xorg.conf is pointing at vesa instead of an ati driver, so it
does not do a PCI scan, it just hangs at a black screen.
The 'ati' driver in F8 does not support R600 chips. You have an R600 chip. It ain't gonna work.
What does the X log look like when you use the vesa driver?
- ajax
Adam Jackson wrote, On 10/30/2007 08:53 AM:
On Mon, 2007-10-29 at 18:06 -0500, Todd Denniston wrote:
Folks, we just tried an install on a Panasonic CF-52 (TOUGHBOOK laptop) using an ATI Radeon X2100.
- had to install in text mode because X is just black screen.
- after install startx results in the same situation. (consistency is nice)
- by default xorg.conf is pointing at vesa instead of an ati driver, so it
does not do a PCI scan, it just hangs at a black screen.
The 'ati' driver in F8 does not support R600 chips. You have an R600 chip. It ain't gonna work.
Care to clue me on how you see it is an R600? No doubt it is, I just don't see how to figure that from the data I have.
What does the X log look like when you use the vesa driver?
The Xorg.0.log (as opposed to the Xorg.0.log.ati) in my first email was a log from the vesa driver, sorry I did not make that clear.
the log just stops at ============= ... (--) using VT number 7
(WW) xf86OpenConsole: setpgid failed: Invalid argument (WW) xf86OpenConsole: setsid failed: Operation not permitted ============= the screen is now black, Ctrl-Alt-F[1-6] fails to be able to switch to a different VT, and even though the command was ran as `startx&sleep 60;reboot` the box has to be hard power cycled 120 seconds later to recover.
In the email originating this thread: xorg.conf.orig and Xorg.0.log go together, vesa driver. xorg.conf and Xorg.0.log.ati go together, ati driver.
BTW, having SELinux on or off does not make a functional difference in xorg working, but I did notice when I ran xorg with SELinux on the following messages appeared in /var/log/messages: setroubleshoot: #012 SELinux is preventing /usr/bin/Xorg (xdm_xserver_t) "use" to /dev/tty1 (local_login_t).#012 For complete SELinux messages. run sealert -l cfd857e5-b182-431b-b9bf-acba1e48c0cc setroubleshoot: #012 SELinux is preventing /usr/bin/Xorg (xdm_xserver_t) "signal" to <Unknown> (unconfined_t).#012 For complete SELinux messages. run sealert -l b56c8443-e433-47c2-aa1a-b3a622cd66e1 setroubleshoot: #012 SELinux is preventing /usr/bin/Xorg (xdm_xserver_t) "getpgid" to <Unknown> (unconfined_t).#012 For complete SELinux messages. run sealert -l d2960006-8d4a-4b08-abe6-9d4f6b780888 I have ran the `sealert -l randnum` commands if you want/need to see the output.
On Tue, 2007-10-30 at 09:41 -0500, Todd Denniston wrote:
Care to clue me on how you see it is an R600? No doubt it is, I just don't see how to figure that from the data I have.
The R600 is the type series, engine, CPU, or whatever that the ATI-2x000 series cards have. Something along those lines. Andrew is the xorg maintainer for Fedora, so I'm sure he can explain that a heck of a lot better.
On Tue, 2007-10-30 at 09:41 -0500, Todd Denniston wrote:
Adam Jackson wrote, On 10/30/2007 08:53 AM:
On Mon, 2007-10-29 at 18:06 -0500, Todd Denniston wrote:
Folks, we just tried an install on a Panasonic CF-52 (TOUGHBOOK laptop) using an ATI Radeon X2100.
- had to install in text mode because X is just black screen.
- after install startx results in the same situation. (consistency is nice)
- by default xorg.conf is pointing at vesa instead of an ati driver, so it
does not do a PCI scan, it just hangs at a black screen.
The 'ati' driver in F8 does not support R600 chips. You have an R600 chip. It ain't gonna work.
Care to clue me on how you see it is an R600? No doubt it is, I just don't see how to figure that from the data I have.
The X2k series are generally R600 chips. It's easier to define support in terms of chip revision than marketing name because some of the marketing names are just lies.
What does the X log look like when you use the vesa driver?
The Xorg.0.log (as opposed to the Xorg.0.log.ati) in my first email was a log from the vesa driver, sorry I did not make that clear.
I missed it, for being too short! Weird. I have no idea why it'd fail there.
BTW, having SELinux on or off does not make a functional difference in xorg working, but I did notice when I ran xorg with SELinux on the following messages appeared in /var/log/messages: setroubleshoot: #012 SELinux is preventing /usr/bin/Xorg (xdm_xserver_t) "use" to /dev/tty1 (local_login_t).#012 For complete SELinux messages. run sealert -l cfd857e5-b182-431b-b9bf-acba1e48c0cc setroubleshoot: #012 SELinux is preventing /usr/bin/Xorg (xdm_xserver_t) "signal" to <Unknown> (unconfined_t).#012 For complete SELinux messages. run sealert -l b56c8443-e433-47c2-aa1a-b3a622cd66e1 setroubleshoot: #012 SELinux is preventing /usr/bin/Xorg (xdm_xserver_t) "getpgid" to <Unknown> (unconfined_t).#012 For complete SELinux messages. run sealert -l d2960006-8d4a-4b08-abe6-9d4f6b780888 I have ran the `sealert -l randnum` commands if you want/need to see the output.
Those should all be allowed actions, but if it still fails with selinux off then I'm stumped. I can't even think of where to begin looking.
Is your /usr/bin/Xorg not suid root for some reason?
- ajax
Adam Jackson wrote, On 10/30/2007 10:10 AM:
On Tue, 2007-10-30 at 09:41 -0500, Todd Denniston wrote:
Adam Jackson wrote, On 10/30/2007 08:53 AM:
On Mon, 2007-10-29 at 18:06 -0500, Todd Denniston wrote:
Folks, we just tried an install on a Panasonic CF-52 (TOUGHBOOK laptop) using an ATI Radeon X2100.
- had to install in text mode because X is just black screen.
- after install startx results in the same situation. (consistency is nice)
- by default xorg.conf is pointing at vesa instead of an ati driver, so it
does not do a PCI scan, it just hangs at a black screen.
The 'ati' driver in F8 does not support R600 chips. You have an R600 chip. It ain't gonna work.
Care to clue me on how you see it is an R600? No doubt it is, I just don't see how to figure that from the data I have.
The X2k series are generally R600 chips. It's easier to define support in terms of chip revision than marketing name because some of the marketing names are just lies.
understood.
What does the X log look like when you use the vesa driver?
The Xorg.0.log (as opposed to the Xorg.0.log.ati) in my first email was a log from the vesa driver, sorry I did not make that clear.
I missed it, for being too short! Weird. I have no idea why it'd fail there.
It might not be... like I said, I have to power cycle after ~120 seconds because it just seems hung, so the log could be getting truncated. The ssh sessions into the machines also stop responding when startx is ran, so I _expect_ either X is going into a tight infinite loop, kills the networking stack and/or it is taking out the kernel, the only system response after startx is that pings return.
[Ping data Before startx: rtt min/avg/max/mdev = 0.052/0.053/0.056/0.009 ms after startx: rtt min/avg/max/mdev = 0.052/0.056/0.065/0.010 ms so clues are running out.]
The attached log is the longest one I got today in vesa mode, I have gotten different lengths from 0Bytes up to the attached one, by running: `sync;startx&sync&sync&sync&sleep 1;sync`
BTW, having SELinux on or off does not make a functional difference in xorg working, but I did notice when I ran xorg with SELinux on the following messages appeared in /var/log/messages: setroubleshoot: #012 SELinux is preventing /usr/bin/Xorg (xdm_xserver_t) "use" to /dev/tty1 (local_login_t).#012
<SNIP>
I have ran the `sealert -l randnum` commands if you want/need to see the output.
Those should all be allowed actions, but if it still fails with selinux off then I'm stumped. I can't even think of where to begin looking.
Fails even with selinux off.
Is your /usr/bin/Xorg not suid root for some reason?
ls -l /usr/bin/Xorg -rws--x--x 1 root root 1912496 2007-09-17 19:54 /usr/bin/Xorg
Todd Denniston wrote, On 10/30/2007 03:39 PM:
Adam Jackson wrote, On 10/30/2007 10:10 AM:
On Tue, 2007-10-30 at 09:41 -0500, Todd Denniston wrote:
Adam Jackson wrote, On 10/30/2007 08:53 AM:
What does the X log look like when you use the vesa driver?
The Xorg.0.log (as opposed to the Xorg.0.log.ati) in my first email was a log from the vesa driver, sorry I did not make that clear.
I missed it, for being too short! Weird. I have no idea why it'd fail there.
It might not be... like I said, I have to power cycle after ~120 seconds because it just seems hung, so the log could be getting truncated. The ssh sessions into the machines also stop responding when startx is ran, so I _expect_ either X is going into a tight infinite loop, kills the networking stack and/or it is taking out the kernel, the only system response after startx is that pings return.
[Ping data Before startx: rtt min/avg/max/mdev = 0.052/0.053/0.056/0.009 ms after startx: rtt min/avg/max/mdev = 0.052/0.056/0.065/0.010 ms so clues are running out.]
The attached log is the longest one I got today in vesa mode, I have gotten different lengths from 0Bytes up to the attached one, by running: `sync;startx&sync&sync&sync&sleep 1;sync`
Also (sorry, forgot to attach it to the last email) after reading several things today including [1] indicating that sometimes the intel chipsets make things interesting, so attached is a lspci that includes all the devices on the PCI bus of the laptop.
[1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02223.html
Adam Jackson wrote, On 10/30/2007 08:53 AM:
On Mon, 2007-10-29 at 18:06 -0500, Todd Denniston wrote:
Folks, we just tried an install on a Panasonic CF-52 (TOUGHBOOK laptop) using an ATI Radeon X2100.
- had to install in text mode because X is just black screen.
- after install startx results in the same situation. (consistency is nice)
- by default xorg.conf is pointing at vesa instead of an ati driver, so it
does not do a PCI scan, it just hangs at a black screen.
The 'ati' driver in F8 does not support R600 chips. You have an R600 chip. It ain't gonna work.
Adam, You did mean that the ati driver that comes with the xorg in the F8 distro would not work, but that the fglrx from livna has a chance to work right????
I just updated the system from F8T3 to the current rawhide set (including the kernel), rebooted and then `yum install kmod-fglrx`. after rebooting again so that the xorg.conf got built by the livna stuff, I did a startx and ... got the same result as the vesa driver, i.e., locked system and black screen. AAAAGGGHH!
And to think with FC5 we can get the things to work, but apparently the guys are building the drivers supplied directly from ATI.
Is there any hope to be had that when you do the disruption[1] there will be some support for the R600 chips?
[1] https://www.redhat.com/archives/fedora-devel-list/2007-October/msg02223.html
On Fri, 2007-11-02 at 17:26 -0500, Todd Denniston wrote:
You did mean that the ati driver that comes with the xorg in the F8 distro would not work, but that the fglrx from livna has a chance to work right????
No it won't.
I just updated the system from F8T3 to the current rawhide set (including the kernel), rebooted and then `yum install kmod-fglrx`. after rebooting again so that the xorg.conf got built by the livna stuff, I did a startx and ... got the same result as the vesa driver, i.e., locked system and black screen. AAAAGGGHH!
The fglrx driver, 8.42.3 I believe, won't work with current F8/rawhide as it doesn't support the 2.6.23 kernel. There should be another release this month that should support it then (don't quote me on this but this is what I have heard).
So you are stuck using the vesa driver, or you can wait and at least try the radeonhd driver as well.
On Fri, 2007-11-02 at 17:26 -0500, Todd Denniston wrote:
Adam Jackson wrote, On 10/30/2007 08:53 AM:
On Mon, 2007-10-29 at 18:06 -0500, Todd Denniston wrote:
Folks, we just tried an install on a Panasonic CF-52 (TOUGHBOOK laptop) using an ATI Radeon X2100.
- had to install in text mode because X is just black screen.
- after install startx results in the same situation. (consistency is nice)
- by default xorg.conf is pointing at vesa instead of an ati driver, so it
does not do a PCI scan, it just hangs at a black screen.
The 'ati' driver in F8 does not support R600 chips. You have an R600 chip. It ain't gonna work.
Adam, You did mean that the ati driver that comes with the xorg in the F8 distro would not work, but that the fglrx from livna has a chance to work right????
I meant that the ati driver would not work.
It's a fair assesment that at any given point in time I never know whether fglrx will or won't work, and that whenever I make statements about what works in Fedora I am not talking about what happens to work this week with a closed source driver. I have a hard enough time fixing the bugs I get in the code I _have_ to worry about bugs in software I'm physically incapable of fixing.
Is there any hope to be had that when you do the disruption[1] there will be some support for the R600 chips?
radeonhd is in rawhide. It may or may not work after the rebase. We'll find out!
- ajax
-
Adam Jackson -
Mike Chambers -
Todd Denniston