Re: 2.6.19-rc6-mm2 is ok (2.6.19-rc1-mm1+ memory problem)
Michael Raskin wrote: I have a strange problem with 2.6.19-rc-mm kernels. After I load X, I notice that memory is marked used at rate of tens of KB/s. Then it Tried 2.6.19-rc6-mm2. Now the problem is gone. Sometimes memory is getting maked used as before, but when the loss reaches a few MB's it is all freed. After 3 hours of X+all those scripts that cause leak + ThunderBird I can still shut down everything except a few processes and have only 50MB used. Script that demonstrated leak is now working without problems and without eating memory. Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-rc6-mm2 is ok (2.6.19-rc1-mm1+ memory problem)
Michael Raskin wrote: I have a strange problem with 2.6.19-rc-mm kernels. After I load X, I notice that memory is marked used at rate of tens of KB/s. Then it Tried 2.6.19-rc6-mm2. Now the problem is gone. Sometimes memory is getting maked used as before, but when the loss reaches a few MB's it is all freed. After 3 hours of X+all those scripts that cause leak + ThunderBird I can still shut down everything except a few processes and have only 50MB used. Script that demonstrated leak is now working without problems and without eating memory. Thanks. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NTP time sync
Joakim Tjernlund wrote: Is that the way it is supposed to be? How do I create a static /dev/rtcN in my /dev directory if the major number isn't fixed? Maybe I am just missing something, feel free to correct me :) udev ;) the concept of static numbers is quite old... Yes it is old, but is the old way unsupported now? I have an embedded target which is using the old static /dev directory, do I need to make it udev aware to use newer features like the rtc subsystem? Really you do not have to make it udev aware, it is enough to make it sysfs aware. You will be done by reading /sys/class/misc/rtc/dev on initialization and replacing /dev/rtcN with device with the address read. If you have configuration static enough, I guess you can even create it once and for life of current setup with current kernel. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NTP time sync
Joakim Tjernlund wrote: Is that the way it is supposed to be? How do I create a static /dev/rtcN in my /dev directory if the major number isn't fixed? Maybe I am just missing something, feel free to correct me :) udev ;) the concept of static numbers is quite old... Yes it is old, but is the old way unsupported now? I have an embedded target which is using the old static /dev directory, do I need to make it udev aware to use newer features like the rtc subsystem? Really you do not have to make it udev aware, it is enough to make it sysfs aware. You will be done by reading /sys/class/misc/rtc/dev on initialization and replacing /dev/rtcN with device with the address read. If you have configuration static enough, I guess you can even create it once and for life of current setup with current kernel. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-rc1-mm1+ memory problem
Andrew Morton wrote: 89361 times: Page allocated via order 0, mask 0x280d2 [0xc0159f31] __handle_mm_fault+1809 [0xc011318a] do_page_fault+314 [0xc04111c4] error_code+116 Can be anything. But if I understand anything, this memory is used because someone has requested a page that is swapped out. So the memory must be used, but not reflected in meminfo, and not by a process? What you should do is to cause the system to free as many pages as possible before looking ad /proc/page_owner. For example, build `usemem' from http://www.zip.com.au/~akpm/linux/patches/stuff/ext3-tools.tar.gz, run usemem -m N (where N is the number of megabytes which the machine has) a couple of times. Then check /proc/meminfo, and look to see which pages are left over in /proc/page_owner. Well, I was too lazy to get this utility, used my own to allocate and fill enough memory as to go some 50MB to deep swap (Did I understand correctly what usemem does?). Top 3 did not change, except for exact numbers. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-rc1-mm1+ memory problem
Andrew Morton wrote: 89361 times: Page allocated via order 0, mask 0x280d2 [0xc0159f31] __handle_mm_fault+1809 [0xc011318a] do_page_fault+314 [0xc04111c4] error_code+116 Can be anything. But if I understand anything, this memory is used because someone has requested a page that is swapped out. So the memory must be used, but not reflected in meminfo, and not by a process? What you should do is to cause the system to free as many pages as possible before looking ad /proc/page_owner. For example, build `usemem' from http://www.zip.com.au/~akpm/linux/patches/stuff/ext3-tools.tar.gz, run usemem -m N (where N is the number of megabytes which the machine has) a couple of times. Then check /proc/meminfo, and look to see which pages are left over in /proc/page_owner. Well, I was too lazy to get this utility, used my own to allocate and fill enough memory as to go some 50MB to deep swap (Did I understand correctly what usemem does?). Top 3 did not change, except for exact numbers. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
