On Sun, 24 Sep 2000, Daniel Stone wrote:
> > 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.
>
> The problem is most definitely NOT X as I experienced the exact same
> problems and reported it to l-k yesterday; and my box has no trace of X on
> it. gcc and grep take it down though.
I have been running 2.4.0-test9-pre2 for some time now and have not experienced
any deadlock or shared memory problem, except for one instance.
Any time I do a 'hdparm -tT /dev/hda', it really screws up all the memory
segments in the kernel. A subsequent 'df' or 'w' will print either garbage or
'no data in /etc/wtmp' file, etc. So it really looks like the cache is being
messed with. I don't think it affects programs whose ram is already in
userspace.
This problem I've noticed has existed in 2.4.0-test7 and on through to
test9-pre2. I do not know if pre6 has the same problem, but I suspect it does.
I'm using hdparm 1.6, and at quick glance of the code, it does use shared
memory to do its timing runs from the disk. This leads me to believe shm is
very buggy, and perhaps Rik van Riel's latest patches have just brought the
bug into the spotlight, analogous to how the test8 patches uncovered the
truncate problem.
Linus, I think you should hold off a little before removing Rik's VM patches
from the kernel, and let the Linux community spend more time tracking down this
problem.
Regards,
Byron
--
Byron Stanoszek Ph: (330) 644-3059
Systems Programmer Fax: (330) 644-8110
Commercial Timesharing Inc. Email: [EMAIL PROTECTED]
-
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/
