> That happened to me with 2.4.2-ac28 when I tried using DRM.
> I also got the following messages in syslog.
>
> /var/log/messages.1:Mar 31 12:15:04 joker kernel:
> [drm:r128_do_wait_for_fifo] *ERROR* r128_do_wait_for_fifo failed!
You need to replace down(...->mmap_sem), up(...->mmap_sem) with
> Its a kernel bug if it gets stuck like this. You need to provide more info
> though - what file system, what devices, how much memory. Also ps can give you
> the wait address of a process stuck in 'D' state which is valuable for debug
Let's see if I'm getting this right, processes in D state sh
On Wed, Apr 04, 2001 at 02:13:49PM +0200, christophe barbe wrote:
> The sleep should certainly be interruptible and I that's what I said to the GFS guy.
> But what the reason to increment the load average for each D process ?
>
OK, the Unix history goes something like this. Synchronization was a
On Wed, Apr 04, 2001 at 08:39:19AM +0930, Trevor Nichols wrote:
> > ps -eo pid,stat,pcpu,nwchan,wchan=WIDE-WCHAN-COLUMN -o args
>
> 1230 D 0.0 105cc1 down_write_failed /home/data/mozilla/obj/dist/bin/mozilla-bin
My mysql-server got stuck in down_write_failed today too.
SMP dual PentiumIII s
This problem seems to be related with the recent post from David Howells
<[EMAIL PROTECTED]> with the subject "rw_semaphore bug".
Christophe
On mar, 03 avr 2001 18:40:53 Manfred Spraul wrote:
> > ps xl:
> > F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
> > 040 1000 1230 1 9 0 2432
On mer, 04 avr 2001 17:05:05 Paul Jakma wrote:
> imagine a box with a bunch of processes that do almost nothing but
> call on the kernel to do IO. If you only count the runnable state
> towards load_avg then your load_avg will be very low, even though your
> box is swamped - you are ignoring the w
On Wed, 4 Apr 2001, christophe barbe wrote:
> From me, a POV without technical reasons is not a philosical one
> but more certainly an historical one.
there may be (and indeed probably are) good technical reasons, however
i am not well enough informed to say what they are.
> Process that will b
I've unfortunately no significant Unix culture.
I'm certainly young enough to be excused and by luck Linux shows me the road to the
hacker heaven.
So now I move forward the good direction, trying to understand the POSIX stuff
From me, a POV without technical reasons is not a philosical o
On Wed, 4 Apr 2001, christophe barbe wrote:
> The sleep should certainly be interruptible and I that's what I
> said to the GFS guy. But what the reason to increment the load
> average for each D process ?
from a philosical POV: they are processes that will be runnable as
soon as the kernel retu
> The sleep should certainly be interruptible and I that's what I said to t=
> he GFS guy.
> But what the reason to increment the load average for each D process ?
D indicates short term I/O wait. This is how unix has always computed the
laod average.
-
To unsubscribe from this list: send the li
The sleep should certainly be interruptible and I that's what I said to the GFS guy.
But what the reason to increment the load average for each D process ?
Thanks,
Christophe
On mer, 04 avr 2001 13:15:52 Alan Cox wrote:
> > The file locking use real IO and so when you ask for a lock, if the loc=
> The file locking use real IO and so when you ask for a lock, if the loc=
> k is already owned, you fall in a D state.
That seems odd. They should be using interruptible sleeps so you can interrupt
the task waiting for the lock, surely.
-
To unsubscribe from this list: send the line "unsubscrib
Sorry if I fork a bit the thread but I'm wondering why the load average is incremented
for each D process.
I don't know if the kernel use this information (if yes please let me know).
But some programs like sendmail use this information to sleep when the load is too
high (I believe from 12 for
> Did you compile sysrq into your kernel?
I haven't yet. I'll enable it and see if I can trigger it next time I
reboot again.
> ps -eo pid,stat,pcpu,nwchan,wchan=WIDE-WCHAN-COLUMN -o args
1230 D 0.0 105cc1 down_write_failed /home/data/mozilla/obj/dist/bin/mozilla-bin
Hopefully that help
Trevor Nichols wrote:
> > Its a kernel bug if it gets stuck like this. You need to provide more info
> > though - what file system, what devices, how much memory. Also ps can give you
> > the wait address of a process stuck in 'D' state which is valuable for debug
>
> ps xl:
> F UID PID PP
> ps xl:
> F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
> 040 1000 1230 1 9 0 24320 4 down_w D ? 0:00
> /home/data/mozilla/obj/dist/bin/mozi
>
down_w
Perhaps down_write_failed()? 2.4.3 converted the mmap semaphore to a
rw-sem.
Did you compile sysrq into your kernel? Then
> Its a kernel bug if it gets stuck like this. You need to provide more info
> though - what file system, what devices, how much memory. Also ps can give you
> the wait address of a process stuck in 'D' state which is valuable for debug
System specs:
Pentium 200 MMX
80MB RAM
2 IDE Drives:
SAMSUN
> One last thing, if this turns out to be a non-kernel problem, the
> processes that *do* get stuck, are unkillable - even by root with SIGKILL.
> Is there any way for it to be able to? :) So far I have to reboot each
> time it happens.
Its a kernel bug if it gets stuck like this. You need to pr
domly some processes are going into an uninteruptable sleep and not
> waking up at all.
>
> It's happened to nautilus and today just happened to mozilla also.
> Another common related problem is the load averages go up to n + "normal"
> where n is the number of proces
Hi all,
Since upgrading to the latest stable (2.4.3) kernel, I've noticed that
randomly some processes are going into an uninteruptable sleep and not
waking up at all.
It's happened to nautilus and today just happened to mozilla also.
Another common related problem is the load average
20 matches
Mail list logo
