Yes I just get the same problem with RADEON m7p mobility think it'S a problem with wakeup signal.
sergio On Friday 12 April 2002 09:26, K. Petersen wrote: > On Thu, 11 Apr 2002, Jens Owen wrote: > > "K. Petersen" wrote: > > > I have come upon a reproducible lockup on my system when switching from > > > a console virtual terminal to X. It can be produced as follows: > > > > > > Begin X > > > Switch back to a virtual console > > > Switch back to X > > > > Does this cause the problem every time? > > > > Also, just to confirm...you don't have to run even one 3D application in > > order to see this problem? > > The problem does indeed occur every time. After doing some more thorough > investigations and experimenting, I have discovered some revised > information. Here is a more detailed description of what happens. > > When I switch back to X, the X server begins to take 100% of the cpu time. > As reported by top, this is system time, not user. > It is not possible to switch between vc's in this state by using > ctrl-alt-f1, for instance. However, ctrl-alt-del does reboot, so the > keyboard is not completely locked. > From a remote login, it is possible for root to `killall -9 X`. This then > allows switching of vc's again. However, the screen shows a corrupted > version of the X display until mode3 is run. > With the proper display restored, it can be found that vc/7 is not freed > when X is killed. It can be switched to, and has a blinking underscore > unlike the higher unused vc's. > > If I now start X again, there is a slightly different effect. > When X is started, the monitor goes into power saving mode. It is again > impossible to switch virtual consoles, but the keyboard responds to > ctrl-alt-del. > top shows that X is taking 100% of cpu time, but now it is user rather > than system. X can be killed with the -9 option by root. mode3 is > ineffective at restoring the display in this condition, however. > The only way I know of restoring the display at this point is rebooting. > > > So, as described here, no 3d applications are run to cause this, just the > presence of the enabled DRI. Hopefully this new description will be more > insightful than the original. > > > > I hope this has been a reasonably thorough description of the problem, > > > now my hardware and software configuration. > > > > > > Hardware: > > > ATI Radeon 64DDR > > > AMD AthlonMP in SMP configuration > > > AMD 760MP chipset on a Tyan S2460 Motherboard > > > > > > Software: > > > Linux kernel 2.4.18 > > > Latest DRI cvs, with kernel module from the dri > > > > Are you building this yourself? If so, it might be useful to build a > > static X server. I've attached host.def you could place over > > xc/config/cf/host.def to build a static server with just the ati driver. > > I am building this myself. Unfortunately, I didn't recieve the attatched > host.def file. If you could send it again, I'd be more than happy to > rebuild with it, if it will help in diagnosing this. > > > --Kalen > > > _______________________________________________ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
