An update on this problem:
First, I'm up to date on the latest kernel and X window
packages. Again, I'm using the standard Fedora Radeon
driver with all the default options. I'm also using the standard
Gnome interface.
Here's the strange thing I'm seeing. I don't know if this
is just coinciden
On Tue, Jul 8, 2008 at 7:15 AM, Thomas Kappelmueller
<[EMAIL PROTECTED]> wrote:
> I completely solved this problem by doing this:
> "yum install xorg-x11-drv-radeonhd"
I can't use the radeonhd driver because it doesn't support or
detect my card. The radeonhd only detects R5xx/R6xx based
cards, so
Hello!
I completely solved this problem by doing this:
"yum install xorg-x11-drv-radeonhd"
and changing the /etx/X11/xorg.conf file:
From:
Section "Device"
Identifier "Videocard0"
Driver "radeon"
EndSection
To:
Section "Device"
Identifier "Videocard0"
Driv
...
Option "AccelMethod" "EXA"
Well, it was a nice theory while it lasted, but unfortunately it
didn't last that long. I had another hang this morning when moving a
Windows window (in a RDP window connected to a MS box).
I'll keep working on it!
Same section, but using
Option "DRI"
Steve Dowe wrote:
I think I have the answer (below).
...
Option "AccelMethod" "EXA"
Well, it was a nice theory while it lasted, but unfortunately it didn't
last that long. I had another hang this morning when moving a Windows
window (in a RDP window connected to a MS box).
I'll keep wo
I think I have the answer (below).
Deron Meranda wrote:
On Tue, Jul 1, 2008 at 3:59 PM, Steve Dowe <[EMAIL PROTECTED]> wrote:
http://shaver.off.net/diary/2008/05/25/fsyncers-and-curveballs/
Good link, but I think it is entirely unrelated to this.
Sorry, I misunderstood the reas
On Tue, Jul 1, 2008 at 3:59 PM, Steve Dowe <[EMAIL PROTECTED]> wrote:
> I became aware of the firefox buffer memory flushing issue when running FF
> 3.0b5. However, it seems to behave itself very well now on my box, using
> FF3.0. Here is a link which I found useful in understanding that issue
>
Deron Meranda wrote:
Steve, your observed Xorg behavior certainly sounds very much like mine.
It is quite frustrating.
It certainly is - I normally have to hard reset my machine once or twice
a day, on average. Sounds like you do at least this?
I've been trying to minimize my use of Fir
Steve, your observed Xorg behavior certainly sounds very much like mine.
It is quite frustrating.
I've been trying to minimize my use of Firefox (painful) and shutting
the app down when I'm not using it; and so far that seems to have
greatly reduced (but not eliminated) the frequency of my hanging
The cause of this problem on my system seems to be when dragging
(resizing) a window. X then seems to hang, the pointer gets jumpy
I should also have added that the mouse cursor image "sticks" to the
diagonal arrow - it doesn't become the normal arrow/pointer again.
I have just booted up i
I have this problem too.
Deron Meranda wrote:
Okay, so Xorg ran away last night ...
it should have been a completely idle unused system.
Anyway, concerning the Xorg driver module, this is a brand new
install of F9 (not an upgrade). All the software is part of the base F9
repo; nothing 3rd par
Okay, so Xorg ran away last night while the system was totally idle and
not being used at all. So I guess the scrollbar theory could be suspect.
There was a screensaver running (just the "cosmos" image slideshow,
no moving graphics); and I left firefox up, which had a gmail window
running so it wo
i will stop bugging you for a while after this one.
g wrote:
anyway, getting a little peeved, i did a google-linux-advanced search
for [ "Xorg" AND "100%" ] and got
69,300 English pages for "Xorg" AND "100%". (0.28 seconds)
i then added 'cpu' for
24,200 English pages for "Xorg" AND "100%"
g wrote:
> xorg group may be you best hope. how to reach them is another story. all
> that is up on internet, last i checked, is a wiki, and it is not much.
>
like maybe, they are aware.
i just went back to see what faqs might say about 100%. nothing, but they did
give driver recommendations
Deron Meranda wrote:
No, there's no difference. These are all equivalent (on Linux):
kill -15 pid
kill -TERM pid
kill -s 15 pid
kill -s TERM pid
i am old unix head and have always used numbers. never tried names,
or numbers less than '-7' or great than '-15'.
i just did a quick look
On Wed, Jun 25, 2008 at 3:44 PM, g <[EMAIL PROTECTED]> wrote:
>> I also tried kills in the following order:
>>
>> kill -TERM (-15)
>> kill -SEGV (-11)
>> kill -KILL (-9)
>
> this is not same as what i was showing you above. use numbers, not words.
> type it as "kill -15 'pid#'" and use '-7' if
Deron Meranda wrote:
"kill -15 'pid#'" to kill it. if '-15' fails, use '-7'.
I did the ps thing. Only one Xorg process was running.
should be just 1.
I also tried kills in the following order:
kill -TERM (-15)
kill -SEGV (-11)
kill -KILL (-9)
this is not same as what i was showi
On Wed, Jun 25, 2008 at 2:55 PM, g <[EMAIL PROTECTED]> wrote:
> Deron Meranda wrote:
>
>>
>> the Xorg process (gdb would hang). And also the Xorg process
>> was not killable. Finally I tried kill -KILL on it, and it sort
>> of got half-killed.
>
> use 'ps -el|grep X' to find 'X', Xorg process, t
Deron Meranda wrote:
the Xorg process (gdb would hang). And also the Xorg process
was not killable. Finally I tried kill -KILL on it, and it sort
of got half-killed.
use 'ps -el|grep X' to find 'X', Xorg process, then
"kill -15 'pid#'" to kill it. if '-15' fails, use '-7'.
--
tc,hago.
g
On Tue, Jun 24, 2008 at 3:49 PM, Alan Cox <[EMAIL PROTECTED]> wrote:
> Once you've done that run it for a bit and see if it seems to be
> gradually eating through swap. The overcommit test will probably work
> sanely as well with 1GB+ of swap 8)
Bad news. The system is still periodically "hanging
On Wed, Jun 25, 2008 at 9:16 AM, Aaron Konstam <[EMAIL PROTECTED]> wrote:
>> I'm running with almost 14GB of swap space...
>>
> Runnin with 14GB of swap semms an obscene waste of space. When you run
> free how much of it is actually used?
Yes, for this machine its overkill, but I don't mind. But
On Tue, 2008-06-24 at 16:21 -0400, Deron Meranda wrote:
> On Tue, Jun 24, 2008 at 3:49 PM, Alan Cox <[EMAIL PROTECTED]> wrote:
> > O> > I wonder if LUKS + swap might be the first suspect
> >> I'm going to try to resize things and get my swap back up
> >> to 32 GB. A little tricky due to LUKS being
>> I have reinstalled Fedora 9 (not an upgrade) onto a system that used
>> to run F7 fine (except for a new video card, see below).
>>
>> Now I am seeing intermittent system hangs or lockups; probably about
>> 2 or 3 per day. This happens most often if I'm scrolling a page in
>> Firefox with the
On Tue, Jun 24, 2008 at 3:49 PM, Alan Cox <[EMAIL PROTECTED]> wrote:
> O> > I wonder if LUKS + swap might be the first suspect
>> I'm going to try to resize things and get my swap back up
>> to 32 GB. A little tricky due to LUKS being in the mix, but
>> I should be able to do it.
>
> Once you've d
O> > I wonder if LUKS + swap might be the first suspect
>
> Well, I looked a little closer and it may be my fault. The LVM
> I have swap in was only 32 MB in size, not the 32 GB I had
> intended! So my swap is way smaller than my physical memory.
>
> Would that excessively small swap space size
On Tue, Jun 24, 2008 at 1:11 PM, Alan Cox <[EMAIL PROTECTED]> wrote:
>> When the system hangs, the mouse cursor will continue to move, but
>> it is very jumpy and sluggish. But otherwise the system is completely
>> unresponsive (not just slow).
>
> That sounds like it suddenly ran out of memory.
>
> When the system hangs, the mouse cursor will continue to move, but it
> is very jumpy
> and sluggish. But otherwise the system is completely unresponsive
> (not just slow).
That sounds like it suddenly ran out of memory.
Try
echo "2" >/proc/sys/vm/overcommit_memory
echo "80" >
I have reinstalled Fedora 9 (not an upgrade) onto a system that used
to run F7 fine
(except for a new video card, see below).
Now I am seeing intermittent system hangs or lockups; probably about 2
or 3 per day.
This happens most often if I'm scrolling a page in Firefox with the
mouse wheel, but
it
28 matches
Mail list logo