Re: Does FreeBSD support sparse kernel crash dumps?
In the last episode (Apr 07), Peter Wemm said: On Friday 07 April 2006 04:01 pm, Paul Marciano wrote: Do you compress the data stream at all (e.g. gzip)? No, but it could be done in theory.. if you were willing to set aside some memory for the compression algorithm to use. Or just do some sort of simple compression (run length encoding?) The problem is that the dump code cannot allocate memory after the machine has crashed. It has to be able to run as isolated from the rest of the kernel as possible in order to give a true snapshot of the undisturbed state. This is pretty easy since zlib lets you pass in your own malloc/free functions. It's sufficient to pre-malloc (or simply statically declare) a 128k block of memory, then dole it out with a simple function that returns high_water+=asked_for_size until you get a request that would push highwater over 128k. A patch that does this for 5.* on x86 only is at http://www.allantgroup.com/FreeBSD/crashdump_compress.diff . -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Does FreeBSD support sparse kernel crash dumps?
Hello. I read a while back about someone working on supporting sparse kernel crash dumps (dumping only the active kernel pages to the dump device as opposed to all physical memory - for machines where the phys mem is greater than the dump dev space.) Does anyone know the status of that project? Was it committed, or are there plans to commit it? Thanks, Paul. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Does FreeBSD support sparse kernel crash dumps?
On Friday 07 April 2006 12:47 pm, Paul Marciano wrote: Hello. I read a while back about someone working on supporting sparse kernel crash dumps (dumping only the active kernel pages to the dump device as opposed to all physical memory - for machines where the phys mem is greater than the dump dev space.) Does anyone know the status of that project? Was it committed, or are there plans to commit it? I have a working prototype as of last night. There should be something committable in the next week or two. When I boot my 2GB machine and force a crash dump from single user mode, the fully debuggable vmcore file is in the 40-50MB range. A busy machine with 12GB ram took about 150MB to dump. There are still some things to work out. It was written for the amd64 kernel, but can be ported to i386. -Peter ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Does FreeBSD support sparse kernel crash dumps?
--- Peter Wemm [EMAIL PROTECTED] wrote: On Friday 07 April 2006 12:47 pm, Paul Marciano wrote: Hello. I read a while back about someone working on supporting sparse kernel crash dumps (dumping only the active kernel pages to the dump device as opposed to all physical memory - for machines where the phys mem is greater than the dump dev space.) Does anyone know the status of that project? Was it committed, or are there plans to commit it? I have a working prototype as of last night. There should be something committable in the next week or two. When I boot my 2GB machine and force a crash dump from single user mode, the fully debuggable vmcore file is in the 40-50MB range. A busy machine with 12GB ram took about 150MB to dump. There are still some things to work out. It was written for the amd64 kernel, but can be ported to i386. -Peter That's very timely news Peter. Do you think your code is easily back-portable to 5.4? Are the changes limited to dump_machdep.c or otherwise not dependent on a great deal of -current updates? Do you compress the data stream at all (e.g. gzip)? I have a specific need on a CompactFlash based system. I have a 256MB IDE mode card on a machine with 512MB physical memory. I can probably commit 128MB of the card as a dumpdev but I can't go beyond that. Good luck with it. Regards, Paul. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Does FreeBSD support sparse kernel crash dumps?
On Friday 07 April 2006 04:01 pm, Paul Marciano wrote: --- Peter Wemm [EMAIL PROTECTED] wrote: On Friday 07 April 2006 12:47 pm, Paul Marciano wrote: Hello. I read a while back about someone working on supporting sparse kernel crash dumps (dumping only the active kernel pages to the dump device as opposed to all physical memory - for machines where the phys mem is greater than the dump dev space.) Does anyone know the status of that project? Was it committed, or are there plans to commit it? I have a working prototype as of last night. There should be something committable in the next week or two. When I boot my 2GB machine and force a crash dump from single user mode, the fully debuggable vmcore file is in the 40-50MB range. A busy machine with 12GB ram took about 150MB to dump. There are still some things to work out. It was written for the amd64 kernel, but can be ported to i386. -Peter That's very timely news Peter. Do you think your code is easily back-portable to 5.4? Are the changes limited to dump_machdep.c or otherwise not dependent on a great deal of -current updates? My WIP is relative to 6.x. It will port forwards to current fairly easily, and will port to i386 trivially. The code would be simpler on i386 because direct map data doesn't exist there. But on the other hand, i386 has to deal with PAE mode and the dump code would be significantly impacted by PAE mode Changes are mostly in sys/amd64/amd64/dump_machdep.c (a rewrite actually), an 8 line addition to sys/vm/vm_page.c and some trivial patches to some other MD pmap files. libkvm is affected as a complete rewrite of lib/libkvm/kvm_amd64.c. (Porting libkvm changes to i386 will be easy and relatively immune to PAE kernel effects). Do you compress the data stream at all (e.g. gzip)? No, but it could be done in theory.. if you were willing to set aside some memory for the compression algorithm to use. Or just do some sort of simple compression (run length encoding?) The problem is that the dump code cannot allocate memory after the machine has crashed. It has to be able to run as isolated from the rest of the kernel as possible in order to give a true snapshot of the undisturbed state. I have a specific need on a CompactFlash based system. I have a 256MB IDE mode card on a machine with 512MB physical memory. I can probably commit 128MB of the card as a dumpdev but I can't go beyond that. I truely do not know what to expect. Without compression, check the difference between sysctl vm.kvm_free and vm.kvm_size to know how much an uncompressed minidump would take. I don't recall if those are on 5.4 or not (the code for those sysctl's would backport from pmap.c really easily). Good luck with it. Regards, Paul. -Peter ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
