Re: Swap space deallocation speed. (fwd)
Hi, On Thu, May 03, 2001 at 12:03:39AM -0400, Dave Mielke wrote: > unresponsive. The relevant line in the log, as you can find in the attached > "crash.log" file, appears to be: > > Unable to handle kernel paging request at virtual address 00020024 > Apr 16 11:23:06 dave kernel: esi: 0002 edi: c14ff5d0 ebp: c3e6a6d0 esp: >c142ff30 This looks like a random bit flip in a page table. That's almost always a hardware problem. Stop overclocking if you are doing that; check that the CPU fan is still working, etc. Cheers, Stephen - 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: Swap space deallocation speed. (fwd)
Hi, On Thu, May 03, 2001 at 12:03:39AM -0400, Dave Mielke wrote: unresponsive. The relevant line in the log, as you can find in the attached crash.log file, appears to be: Unable to handle kernel paging request at virtual address 00020024 Apr 16 11:23:06 dave kernel: esi: 0002 edi: c14ff5d0 ebp: c3e6a6d0 esp: c142ff30 This looks like a random bit flip in a page table. That's almost always a hardware problem. Stop overclocking if you are doing that; check that the CPU fan is still working, etc. Cheers, Stephen - 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/
Swap space deallocation speed.
Ever since I've upgraded to the 2.2.17-14 i386 kernel as provided by RedHat, I've had several hard crashes. One allowed "/var/log/messages" to be synced, so I was able to capture those details (which are attached to this message as the file "crash.log"). Once, instead of crashing, the system stayed up but all of the respawn processes in "/etc/inittab" began to respawn to rapidly, I couldn't create a shell process to poke around, and the keyboard eventually became unresponsive. The relevant line in the log, as you can find in the attached "crash.log" file, appears to be: Unable to handle kernel paging request at virtual address 00020024 My guess is that, for whatever reason, I may now be running out of swap space fairly often. If this is true, then either my children have altered their usage habits around the same time that I upgraded the kernel, or something about swap space management has changed between the 2.2.16-3 and 2.2.17-14 kernels. To this end, I've asked my children to be careful about not opening too many windows at the same time, and the system now stays up longer but still, on occasion, without requesting my permission, still goes down hard. I've also been watching the amount of available swap space with the "free" command. It predictably goes down quite quickly when a hog like netscape is started, but, when that same application exits, the available swap space goes back up very slowly. This would seem to make it very easy to inadvertently run out of swap space, i.e. quitting and restarting an application still, without the user realizing it, appears to be a bad thing to do because of the as yet unreclaimed swap space which is still being counted. Do any of you have any ideas? If I'm right about the slow reclamation of the swap space, is there anything I can do, e.g. alter something in "/proc", to speed up swap space reclamation? Thanks. -- Dave Mielke | 2213 Fox Crescent | I believe that the Bible is the Phone: 1-613-726-0014 | Ottawa, Ontario | Word of God. Please contact me EMail: [EMAIL PROTECTED] | Canada K2A 1H7 | if you're concerned about Hell. Apr 16 11:23:06 dave kernel: Unable to handle kernel paging request at virtual address 00020024 Apr 16 11:23:06 dave kernel: current->tss.cr3 = 00101000, %%cr3 = 00101000 Apr 16 11:23:06 dave kernel: *pde = Apr 16 11:23:06 dave kernel: Oops: Apr 16 11:23:06 dave kernel: CPU:0 Apr 16 11:23:06 dave kernel: EIP:0010:[locks_remove_posix+43/140] Apr 16 11:23:06 dave kernel: EFLAGS: 00010206 Apr 16 11:23:06 dave kernel: eax: c3e6a6d0 ebx: c03e5c70 ecx: c3e6a660 edx: c03e5c70 Apr 16 11:23:06 dave kernel: esi: 0002 edi: c14ff5d0 ebp: c3e6a6d0 esp: c142ff30 Apr 16 11:23:06 dave kernel: ds: 0018 es: 0018 ss: 0018 Apr 16 11:23:06 dave kernel: Process ppp-watch (pid: 7528, process nr: 81, stackpage=c142f000) Apr 16 11:23:06 dave kernel: Stack: c14ff5d0 0001 c3e6a6d0 c3e6a660 0001 c011c9a1 0019 0032 Apr 16 11:23:06 dave kernel:c011ca40 bfffc000 c15147c0 0286 c15147c0 1d00 001d Apr 16 11:23:06 dave kernel:bd68 c151483c 1d00 c012768a c03e5c70 c203a280 00100047 0001 Apr 16 11:23:06 dave kernel: Call Trace: [check_pgt_cache+17/24] [clear_page_tables+152/160] [filp_close+70/88] [do_exit+293/624] [sys_exit+14/16] [system_call+52/56] Apr 16 11:23:06 dave kernel: Code: f6 46 24 01 74 49 8b 4c 24 5c 39 4e 14 75 40 8b 4c 24 58 8b
Swap space deallocation speed.
Ever since I've upgraded to the 2.2.17-14 i386 kernel as provided by RedHat, I've had several hard crashes. One allowed /var/log/messages to be synced, so I was able to capture those details (which are attached to this message as the file crash.log). Once, instead of crashing, the system stayed up but all of the respawn processes in /etc/inittab began to respawn to rapidly, I couldn't create a shell process to poke around, and the keyboard eventually became unresponsive. The relevant line in the log, as you can find in the attached crash.log file, appears to be: Unable to handle kernel paging request at virtual address 00020024 My guess is that, for whatever reason, I may now be running out of swap space fairly often. If this is true, then either my children have altered their usage habits around the same time that I upgraded the kernel, or something about swap space management has changed between the 2.2.16-3 and 2.2.17-14 kernels. To this end, I've asked my children to be careful about not opening too many windows at the same time, and the system now stays up longer but still, on occasion, without requesting my permission, still goes down hard. I've also been watching the amount of available swap space with the free command. It predictably goes down quite quickly when a hog like netscape is started, but, when that same application exits, the available swap space goes back up very slowly. This would seem to make it very easy to inadvertently run out of swap space, i.e. quitting and restarting an application still, without the user realizing it, appears to be a bad thing to do because of the as yet unreclaimed swap space which is still being counted. Do any of you have any ideas? If I'm right about the slow reclamation of the swap space, is there anything I can do, e.g. alter something in /proc, to speed up swap space reclamation? Thanks. -- Dave Mielke | 2213 Fox Crescent | I believe that the Bible is the Phone: 1-613-726-0014 | Ottawa, Ontario | Word of God. Please contact me EMail: [EMAIL PROTECTED] | Canada K2A 1H7 | if you're concerned about Hell. Apr 16 11:23:06 dave kernel: Unable to handle kernel paging request at virtual address 00020024 Apr 16 11:23:06 dave kernel: current-tss.cr3 = 00101000, %%cr3 = 00101000 Apr 16 11:23:06 dave kernel: *pde = Apr 16 11:23:06 dave kernel: Oops: Apr 16 11:23:06 dave kernel: CPU:0 Apr 16 11:23:06 dave kernel: EIP:0010:[locks_remove_posix+43/140] Apr 16 11:23:06 dave kernel: EFLAGS: 00010206 Apr 16 11:23:06 dave kernel: eax: c3e6a6d0 ebx: c03e5c70 ecx: c3e6a660 edx: c03e5c70 Apr 16 11:23:06 dave kernel: esi: 0002 edi: c14ff5d0 ebp: c3e6a6d0 esp: c142ff30 Apr 16 11:23:06 dave kernel: ds: 0018 es: 0018 ss: 0018 Apr 16 11:23:06 dave kernel: Process ppp-watch (pid: 7528, process nr: 81, stackpage=c142f000) Apr 16 11:23:06 dave kernel: Stack: c14ff5d0 0001 c3e6a6d0 c3e6a660 0001 c011c9a1 0019 0032 Apr 16 11:23:06 dave kernel:c011ca40 bfffc000 c15147c0 0286 c15147c0 1d00 001d Apr 16 11:23:06 dave kernel:bd68 c151483c 1d00 c012768a c03e5c70 c203a280 00100047 0001 Apr 16 11:23:06 dave kernel: Call Trace: [check_pgt_cache+17/24] [clear_page_tables+152/160] [filp_close+70/88] [do_exit+293/624] [sys_exit+14/16] [system_call+52/56] Apr 16 11:23:06 dave kernel: Code: f6 46 24 01 74 49 8b 4c 24 5c 39 4e 14 75 40 8b 4c 24 58 8b
