Date: Thu, 3 Apr 2003 16:13:21 -0600 From: "Welch, Sean M." <WelchSM@nsc-msg01.network.com> To: "'Eric Anholt'" <eta@lclark.edu> Cc: "'freebsd-stable@freebsd.org'" <freebsd-stable@freebsd.org> Subject: RE: Re:agp driver locks up on resume Message-ID: <5B7014A44B89494E830AD32859FBC858010AE665@nsc-msg01.network.com>
next in thread | raw e-mail | index | archive | help
Here's the thing; I never had trouble suspending the console, but I also never tracked stable or current with that r128 card in. I only ran releases with updated ports trees. Last time I ran that card was under 4.6-RELEASE and my experience was that I could suspend on the console or another VT but when I resumed if I tried to switch back to X it would hang (mouse moved, but everything else was borked with CPU on 100%). My solution was what I detailed about running two X servers. I've been running the radeon card since the middle of last summer and now I can't do a suspend to ram at all -- the bios chokes and does a power cycle on resume (guess it doesn't understand the new card as well as it should). I don't have any other side effects and I can still suspend to disk. The suspend changes were only to the radeon driver and they were not merged. I found and tried the diffs; they seemed to work well in that they prevented hangs when switching to a vt while running a DRI app, but I've never been able to test the suspend to ram because of the bios issue. It does not work when resuming from disk -- it displays the behavior I came to expect from the r128 card on resume from ram. By the way, those diffs set up a handler to notice the suspend event and flush the buffer leaving it empty when the machine suspended. The same was done for a switch to a vt to avoid the same sync problem. Sean -----Original Message----- From: Eric Anholt [mailto:eta@lclark.edu] Sent: Thursday, April 03, 2003 3:51 PM To: Welch, Sean M. Cc: 'dgilbert@velocet.ca'; 'freebsd-stable@freebsd.org' Subject: Re: Re:agp driver locks up on resume On Thu, 2003-04-03 at 12:31, Welch, Sean M. wrote: > I'm familiar with this one -- it isn't agp, it is DRI. DRI depends on AGP > so you are disabling both when you disable > AGP. This issue has to do with the DRI module "losing track" of what is > going on in the usage of main memory > (through AGP) when you do a suspend resume -- it gets stuck trying to flush > a buffer... I was initally going to say this too. However, I remember I tried to suspend/resume my laptop in the console with DRM not loaded and still had hangs. I put some printf in the kernel to see if the AGP setup was corrupted by the resume and it didn't look like it (having noticed that linux does a whole re-setup of agp after resume). I didn't ever try without AGP at all I think, and didn't try reconfiguring. Some work has been done on suspend/resume with the DRI. I don't know too much about it, but I think it let you suspend/resume while a 3d client was running. I don't remember if that stuff got merged or not (thinking not). I think suspend/resume is supposed to still work if you're switched away to console. -- Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5B7014A44B89494E830AD32859FBC858010AE665>