Is anyone else seeing this issue? I'm running into it
on desktop boxes and a laptop running 4.8-RELEASE with
up to date ports collections and various versions of
DRI installed over a ports version of X. I'm also seeing
this under 5.1-RELEASE on the laptop.
Everything works perfectly unless/until I restart the X
server. This appears to be initiated automatically when
running GDM -- ie, GDM starts, you log in using that X
session, you log out and the session stops, GDM starts X
again and displays the login screen.
This seems to happen a bit more than 1/3 of the times I
try it (intentionally or not). It isn't much of a problem
on the laptop as I'm the only user and tend to turn the
machine off when I log out but it is causing all sorts of
issues on the desktops because they are intended to be
used as multi-user (serially and also simultaneously)
systems.
Any ideas? The instability goes away completely with DRI
disabled, but part of the use of these desktops is in the
accelerated OpenGL rendering...
Sean
me too!!! ;) I see this on a laptop running 5.x with an ATI Mobility card. Don't remember the exact model. I havn't found a solution (but havn't really tried because it's the smallest of the problems I have with 5.1 on this laptop)> Is anyone else seeing this issue? I'm running into it > on desktop boxes and a laptop running 4.8-RELEASE with > up to date ports collections and various versions of > DRI installed over a ports version of X. I'm also seeing > this under 5.1-RELEASE on the laptop. > > Everything works perfectly unless/until I restart the X > server. This appears to be initiated automatically when > running GDM -- ie, GDM starts, you log in using that X > session, you log out and the session stops, GDM starts X > again and displays the login screen. > > This seems to happen a bit more than 1/3 of the times I > try it (intentionally or not). It isn't much of a problem > on the laptop as I'm the only user and tend to turn the > machine off when I log out but it is causing all sorts of > issues on the desktops because they are intended to be > used as multi-user (serially and also simultaneously) > systems. > > Any ideas? The instability goes away completely with DRI > disabled, but part of the use of these desktops is in the > accelerated OpenGL rendering... > > Sean > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >
On Tue, Aug 26, 2003 at 12:21:56PM -0500, Sean Welch wrote:> Is anyone else seeing this issue?Yes, I have a Radeon 9100 that does the same thing. In fact, I sent a message to the -current mailing list just a couple of days ago.> I'm running into it on desktop boxes and a laptop running 4.8-RELEASE > with up to date ports collections and various versions of DRI > installed over a ports version of X. I'm also seeing this under > 5.1-RELEASE on the laptop. > > Everything works perfectly unless/until I restart the X server. This > appears to be initiated automatically when running GDM -- ie, GDM > starts, you log in using that X session, you log out and the session > stops, GDM starts X again and displays the login screen. > > This seems to happen a bit more than 1/3 of the times I try it > (intentionally or not). It isn't much of a problem on the laptop as > I'm the only user and tend to turn the machine off when I log out but > it is causing all sorts of issues on the desktops because they are > intended to be used as multi-user (serially and also simultaneously) > systems. > > Any ideas? The instability goes away completely with DRI disabled, > but part of the use of these desktops is in the accelerated OpenGL > rendering...Well, I may have a work around. Try putting the following in the Device section of your XF86Config file: Option "ForcePCIMode" "true" That will slow down your 3D acceleration though. I have been running with this option for about 2 days and have not had a lockup with it yet. I was going to run it for another day or so and contact Eric Anholt about it. See if it works for your machines. That should provide enough corroborating evidence. -- Glenn Johnson USDA, ARS, SRRC Phone: (504) 286-4252 New Orleans, LA 70124 e-mail: gjohnson@srrc.ars.usda.gov
Thanks -- I'll give it a try. I know that in the laptop the
card can be addressed as either a PCI or an AGP card; I don't
think that will work in the desktop. I'll try it anyway...
Sean
-------Original Message-------
From: Glenn Johnson <gjohnson@srrc.ars.usda.gov>
Sent: 08/26/03 02:54 PM
To: Sean_Welch@alum.wofford.org
Subject: Re: Radeon 7500 w/ DRI locking on restart of X
>
> On Tue, Aug 26, 2003 at 12:21:56PM -0500, Sean Welch wrote:
> Is anyone else seeing this issue?
Yes, I have a Radeon 9100 that does the same thing. In fact, I sent a
message to the -current mailing list just a couple of days ago.
> I'm running into it on desktop boxes and a laptop running 4.8-RELEASE
> with up to date ports collections and various versions of DRI
> installed over a ports version of X. I'm also seeing this under
> 5.1-RELEASE on the laptop.
>
> Everything works perfectly unless/until I restart the X server. This
> appears to be initiated automatically when running GDM -- ie, GDM
> starts, you log in using that X session, you log out and the session
> stops, GDM starts X again and displays the login screen.
>
> This seems to happen a bit more than 1/3 of the times I try it
> (intentionally or not). It isn't much of a problem on the laptop as
> I'm the only user and tend to turn the machine off when I log out but
> it is causing all sorts of issues on the desktops because they are
> intended to be used as multi-user (serially and also simultaneously)
> systems.
>
> Any ideas? The instability goes away completely with DRI disabled,
> but part of the use of these desktops is in the accelerated OpenGL
> rendering...
Well, I may have a work around. Try putting the following in the Device
section of your XF86Config file:
Option "ForcePCIMode" "true"
That will slow down your 3D acceleration though. I have been running
with this option for about 2 days and have not had a lockup with it yet.
I was going to run it for another day or so and contact Eric Anholt
about it. See if it works for your machines. That should provide
enough corroborating evidence.
--
Glenn Johnson
USDA, ARS, SRRC Phone: (504) 286-4252
New Orleans, LA 70124 e-mail:
gjohnson@srrc.ars.usda.gov>
I had similar problem with a 7200 and OGL. I solved the problem by turning off some of the options in the X config. On Tue, 26 Aug 2003 12:21:56 -0500 (GMT) Sean Welch <welchsm@earthlink.net> wrote:> Is anyone else seeing this issue? I'm running into it > on desktop boxes and a laptop running 4.8-RELEASE with > up to date ports collections and various versions of > DRI installed over a ports version of X. I'm also seeing > this under 5.1-RELEASE on the laptop. > > Everything works perfectly unless/until I restart the X > server. This appears to be initiated automatically when > running GDM -- ie, GDM starts, you log in using that X > session, you log out and the session stops, GDM starts X > again and displays the login screen. > > This seems to happen a bit more than 1/3 of the times I > try it (intentionally or not). It isn't much of a problem > on the laptop as I'm the only user and tend to turn the > machine off when I log out but it is causing all sorts of > issues on the desktops because they are intended to be > used as multi-user (serially and also simultaneously) > systems. > > Any ideas? The instability goes away completely with DRI > disabled, but part of the use of these desktops is in the > accelerated OpenGL rendering... > > Sean > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
Dear All,
I have been experiencing this problem for a few months and thought is
was related to me upgrading to Gnome2, i.e. when I go to logout out
sometimes the screen just goes black, I am unable to login into the box
from another machine on the network, I am unable to sometimes to power
cycle the machine and end up having to power off the box by pulling out
the power cord. Other times on login out the login screen is displayed,
put parts of it are missing, i.e. the options available. Also when
logging in I occasionally get xsession-errors that returns me to the
login screen, this repeats itself a few times until I get in.
Further to Eric's request here is the output from dmesg | grep -i drm
drm0: <ATI Radeon QW 7500 (AGP)> port 0xc000-0xc0ff mem
0xed000000-0xed00ffff,0xe0000000-0xe7ffffff irq 11 at device 5.0 on pci1
info: [drm] AGP at 0xe8000000 64MB
info: [drm] Initialized radeon 1.1.1 20010405 on minor 0
My XF86Config file has only these lines relating to dri (lines have been
removed to keep this email smallish)
Section "Module"
Load "dri"
Load "drm"
EndSection
Section "DRI"
Mode 0666
EndSection
Section "Device"
Identifier "Card0"
Driver "ati"
VendorName "ATI"
BoardName "Radeon 7500"
BusID "PCI:1:5:0"
Option "AGPMode" "4"
Option "DRI"
EndSection
If you want me to test anything, then let me know.
Regards,
Dave.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20030826/c836a5aa/attachment.bin
I have precisely the same symptoms as what Glenn listed.
I have now tried the forcepcimode option on the laptop and
unfortunately experienced what appears to be the opposite
effect to what Glenn noted. I get a black screen with lots
of disk activity. I can log in remotely (at least that
seemed to work every time) and a top listing shows X taking
up more and more CPU cycles. It seems to be scribbling to
the disk making temporary files as well because eventually
I couldn't edit the XF86Config file any longer -- I was
getting a "no space left on device" error. I ended up
taking out all options short of disabling DRI altogether
and eventually discovered the only way I could run with
DRI switches on and forcepcimode set to true was to unload
the agp module from kernel space. This got it started just
fine but there was no DRI. It seems that X is getting
confused and somehow PCI and AGP modes are duking it out...
Here is a listing of the X modules from ports:
XFree86-4.3.0,1
XFree86-FontServer-4.3.0
XFree86-Server-4.3.0_5
XFree86-clients-4.3.0_1
XFree86-documents-4.3.0
XFree86-font100dpi-4.3.0
XFree86-font75dpi-4.3.0
XFree86-fontCyrillic-4.3.0
XFree86-fontDefaultBitmaps-4.3.0
XFree86-fontEncodings-4.3.0
XFree86-fontScalable-4.3.0
XFree86-libraries-4.3.0_3
Xaw3d-1.5
Xft-2.1_8
This is what I see from 'dmesg | grep drm' :
drm0: <ATI Radeon LW Mobility 7 (AGP)> port 0xcc00-0xccff mem
0xfcff0000-0xfcffffff,0xe0000000-0xe7ffffff irq 11 at device 0.0 on pci1
info: [drm] AGP at 0xe8000000 64MB
info: [drm] Initialized radeon 1.8.0 20020828 on minor 0
Here is the output of 'head /var/log/XFree86.0.log' :
XFree86 Version 4.3.0 (DRI trunk)
Release Date: 27 February 2003
X Protocol Version 11, Revision 0, Release 6.6
Build Operating System: FreeBSD 4.8-RELEASE i386 [ELF]
Build Date: 09 August 2003
Before reporting problems, check http://www.XFree86.Org/
to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
The above was built on 08/03/03 in the evening.
Here is 'uname -a':
FreeBSD NitroPhys.welchsmnet.net 4.8-RELEASE FreeBSD 4.8-RELEASE #1: Thu May 29
11:24:46 CDT 2003
welchsm@NitroPhys.welchsmnet.net:/usr/src/sys/compile/NITROPHYS i386
The kernel is compiled with SSE support.
I have tried turning off all options in the config file and
different AGP modes. I always get the same results.
My 5.1-RELEASE install is just using the X off the install
disc with the kernel module that shipped with it. Same exact
issues.
I believe I saw a commit to DRI CVS a while back that was
supposed to address this very issue (comment said something
about locks on logout with GDM) but it didn't change anything
for me.
Let me know what else you'd like to have in the way of info.
Sean
-------Original Message-------
From: Glenn Johnson <gjohnson@srrc.ars.usda.gov>
Sent: 08/26/03 03:55 PM
To: Eric Anholt <eta@lclark.edu>
Subject: Re: Radeon 7500 w/ DRI locking on restart of X
>
> On Tue, Aug 26, 2003 at 01:27:11PM -0700, Eric Anholt wrote:
> On Tue, 2003-08-26 at 18:05, Vulpes Velox wrote:
>
> > I had similar problem with a 7200 and OGL. I solved the problem by
> > turning off some of the options in the X config.
> >
> > On Tue, 26 Aug 2003 12:21:56 -0500 (GMT) Sean Welch
> > <welchsm@earthlink.net> wrote:
> >
> > > Is anyone else seeing this issue? I'm running into it on
desktop
> > > boxes and a laptop running 4.8-RELEASE with up to date ports
> > > collections and various versions of DRI installed over a ports
> > > version of X. I'm also seeing this under 5.1-RELEASE on the
> > > laptop.
> > >
> > > Everything works perfectly unless/until I restart the X server.
> > > This appears to be initiated automatically when running GDM --
ie,
> > > GDM starts, you log in using that X session, you log out and the
> > > session stops, GDM starts X again and displays the login screen.
> > >
> > > This seems to happen a bit more than 1/3 of the times I try it
> > > (intentionally or not). It isn't much of a problem on the
laptop
> > > as I'm the only user and tend to turn the machine off when I
log
> > > out but it is causing all sorts of issues on the desktops because
> > > they are intended to be used as multi-user (serially and also
> > > simultaneously) systems.
> > >
> > > Any ideas? The instability goes away completely with DRI
> > > disabled, but part of the use of these desktops is in the
> > > accelerated OpenGL rendering...
> > >
> > > Sean
>
> (CC'ed to -current since it's not -stable specific)
>
> This is an example of why people need to send PRs and not just emails.
> I realize now I've seen emails on this before, but I had forgotten
> about them because they seemed isolated and I didn't have them piling
> up in my assigned prs list (things pile up in my mailboxes easily, and
> I don't go back and check very often).
Speaking for myself, I was not sure whether the problem was a BIOS
setting problem, a graphics card problem, a FreeBSD problem, an XFree86
problem, or a configuration problem on my part. Until today, I thought
I was the only one with seeing this. I discovered the "ForcePCIMode"
option as a potential workaround only two days ago and I wanted to
confirm that it did indeed make the problem go away before filing a PR
and sending an e-mail directly to you about the issue. In fact, I was
planning on doing that this evening after a few more tests.
> I've tried to reproduce this with a radeon, by doing startx, C-A-B
> to kill the server, then startx again. The second time, the screen
> displays for a brief moment then goes black. The system isn't hung,
> and I can exit using C-A-B again. Is this what everyone else sees?
Sometimes. At times the Xserver will not start and I can switch to a
console and login. Any further attempts to restart X will lock the
machine up. Other times, the screen just goes black and the machine
is locked up. I can not switch to a console nor ssh in via another
machine. In that case, I have to hit the reset switch. Still other
times, the gdm login screen will appear and look normal, except the
cursor is not blinking and the keyboard and mouse do not respond. I did
not try to ssh into the machine in that state but I would guess that it
would fail.
> Everyone that's experiencing this and is using the DRI, what version
> of the radeon DRM is loaded? (dmesg | grep drm)
I will have to get the dmesg output for you when I get home but it is
the latest version in -current, with -current being up to date as of Aug
25, 2003, about 9:00 PM CDT.
> Is anyone experiencing this without the DRI loaded?
Not me; when I disable DRI the lock ups do not occur.
> The ForcePCIMode workaround is interesting, I'll take a look at what
> could be going on there.
I have had that option in my config file for about two days and have
tested by logging in and out repeatedly. So far, I have not had a lock
up with that option enabled.
--
Glenn Johnson
USDA, ARS, SRRC Phone: (504) 286-4252
New Orleans, LA 70124 e-mail:
gjohnson@srrc.ars.usda.gov>
I sent an earlier message which seems to have disappeared
into the void. I tried the forcepcimode under the 5.1
install on my laptop (RELEASE with upgraded ports tree) and
found that it behaved as you said yours does. I can't get
it to hang no matter what I do now -- though the performance
is a little less than half what it was with the AGP.
I haven't had a chance to try that option on my desktops.
If it works there I'll be mighty happy!
Your other message about the newest version of X having
this fixed is very interesting; I track both XFree86 and
DRI CVS daily. The only problem is that I have nearly
2 GB of programs built on top of X, so that is not nearly
as easy to upgrade... Maybe it is time for me to finally
blow away that install of 4.7-RELEASE and try it out.
Sean
-------Original Message-------
From: Glenn Johnson <gjohnson@srrc.ars.usda.gov>
Sent: 08/26/03 09:14 PM
To: Sean_Welch@alum.wofford.org
Subject: Re: Radeon 7500 w/ DRI locking on restart of X
>
> On Tue, Aug 26, 2003 at 03:31:29PM -0500, Sean Welch wrote:
> I have precisely the same symptoms as what Glenn listed.
>
> I have now tried the forcepcimode option on the laptop and
> unfortunately experienced what appears to be the opposite effect to
> what Glenn noted. I get a black screen with lots of disk activity.
> I can log in remotely (at least that seemed to work every time) and
> a top listing shows X taking up more and more CPU cycles. It seems
> to be scribbling to the disk making temporary files as well because
> eventually I couldn't edit the XF86Config file any longer -- I was
> getting a "no space left on device" error. I ended up taking out
all
> options short of disabling DRI altogether and eventually discovered
> the only way I could run with DRI switches on and forcepcimode set
> to true was to unload the agp module from kernel space. This got it
> started just fine but there was no DRI. It seems that X is getting
> confused and somehow PCI and AGP modes are duking it out...
Does it work on your desktops? I do not have agp in the kernel config.
When X starts it loads both the radeon and agp modules, or maybe the
radeon module is loading the agp module. Either way, both radeon.ko and
agp.ko get loaded up.
Here is some info about my hardware:
- The motherboard is an Abit IS7 (P4c w/865PE chipset)
- The graphics card is an ATI Radeon 9100
Here is the device section of my XF86Config (sans comments):
Section "Device"
Identifier "Card0"
Driver "ati"
VendorName "ATI Technologies Inc"
BoardName "Radeon R200 QM [Radeon 9100]"
BusID "PCI:1:0:0"
Option "DDCMode" "true"
Option "ForcePCIMode" "true"
EndSection
Finally, here are the first few lines of glxinfo:
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
--
Glenn Johnson>