safemode wrote:
> Mark Hahn wrote:
>
>> this has nothing to do with the linux kernel.
>> X itself does not use shm for anything. apps may use
>> an X extension (XSHM) which uses shm segments to exchange
>> image data without copying through a socket, but that's
>> an extension, not inherent to X.
>>
>> > Ok, compiling using a cvs of X i got a couple hours ago, I'm just
>>
>> > wondering what the average segment number is for SHM on an X
>> session
>> > that has been up for a while .... i'll get back with any sort of
>> info
>> > on if the SHM problem has been solved with this latest CVS or if
>> it
>> > continues to look like a kernel SHM problem. So far though,
>> > 2.4.0-test8-vm3 is handling the problem Quite well as opposed to
>> test9,
>> > which died in 2 hours upon booting ...and it didn't have the added
>>
>> > stress of compiling X.
>> >
>> > -
>>
>
>
> I think it has a lot to do with the kernel, and with X. Since i
> havn't upgraded anything but X (and thus the extensions) ... now it's
> obvious that X is at fault for providing us with a wonderful shared
> memory leak. But, the kernel too, has something to do with it since
> test9 seems to be fairly unstable with it, causing all sorts of weird
> happenings before totally freezing up like test8-vm3 does. This
> problems only manifests in VERY recent X cvs copies so most people
> will not see this problem. The problem i'm wondering about is if the
> Kernel is handling shared memory correctly or if this is entirely X's
> fault.
>
Somehow i cant help but think this is somehow linked to an OOM problem
that has yet to be fixed with the 2.4.0-testX series. It seems
suspiciously like the kernel is killing init when X decides it would be
peachy to gobble up all the ram. i dont know of any way to prove
this though.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
