Messages in this thread |  | | Date | Sun, 24 Sep 2000 00:12:11 -0400 (EDT) | From | Byron Stanoszek <> | Subject | 2.4.0-test9-pre6 shmem problems revisited |
| |
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: bstanoszek@comtime.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |