Re: is dumpon/savecore broken?
On Thu, Jul 22, 1999 at 02:19:37AM +0200, a little birdie told me that Andrzej Bialecki remarked > On Tue, 20 Jul 1999, Matthew Dillon wrote: > > > > You can do it manually from /etc/rc. If it doesn't even get that far, > > you used to be able to specify it in the kernel config but I do not know > > if that is possible any more. > > I remember doing this once or twice from DDB - writing appropriate values > to _dumpdev, as they appeared on running system. > > Of course, the system can be in such state that this could equally well > do more harm than good... :-/ But lemme guess... This won't work with a system that panics before it gets around to probing the harddrives... This is one of my present problems :( -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ FutureSouth Communications |ISPHelp ISP Consulting "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is dumpon/savecore broken?
On Wed, 21 Jul 1999, Matthew D. Fuller wrote: > On Thu, Jul 22, 1999 at 02:19:37AM +0200, a little birdie told me > that Andrzej Bialecki remarked > > On Tue, 20 Jul 1999, Matthew Dillon wrote: > > > > > > You can do it manually from /etc/rc. If it doesn't even get that far, > > > you used to be able to specify it in the kernel config but I do not know > > > if that is possible any more. > > > > I remember doing this once or twice from DDB - writing appropriate values > > to _dumpdev, as they appeared on running system. > > > > Of course, the system can be in such state that this could equally well > > do more harm than good... :-/ > > But lemme guess... > This won't work with a system that panics before it gets around to > probing the harddrives... > > This is one of my present problems :( Then use remote GDB - it works miracles, I can tell you, it's just like debugging any other user space program. See the section in the handbook on that. Andrzej Bialecki // <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is dumpon/savecore broken?
On Tue, 20 Jul 1999, Matthew Dillon wrote: > > :And how do you create dumps from a kernel that hasn't finished booting > :(not gotten to the stage of reading rc.conf)? 'dumps on' in kernel > :config does not seem to do the job. > : > :Nick > > You can do it manually from /etc/rc. If it doesn't even get that far, > you used to be able to specify it in the kernel config but I do not know > if that is possible any more. I remember doing this once or twice from DDB - writing appropriate values to _dumpdev, as they appeared on running system. Of course, the system can be in such state that this could equally well do more harm than good... :-/ Andrzej Bialecki // <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is dumpon/savecore broken?
On Tue, 20 Jul 1999, Poul-Henning Kamp wrote: > >Should I commit a similar workaround for the swap code too? Quite > >simple to do... > > Please so, but I would appreciate if you would do me the favour of > hiding the guts of this monstrosity in kern/kern_conf.c in a function > called dev2budev() ? I did so. I'm working out why this did not fix pstat now... > > -- > Poul-Henning Kamp FreeBSD coreteam member > [EMAIL PROTECTED] "Real hackers run -current on their laptop." > FreeBSD -- It will take a long time before progress goes too far! > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is dumpon/savecore broken?
In message <[EMAIL PROTECTED]>, "Bria n F. Feldman" writes: >On Tue, 20 Jul 1999, Poul-Henning Kamp wrote: > >> In message <[EMAIL PROTECTED]>, "Bria >> n F. Feldman" writes: >> >> >> /ddname = find_dev/s/BLK/CHR/ >> > >> >No, that's wrong. You cannot do buffered-type IO on a cdev. I committed >> >a workaround, and now it works. There's no easy way around this, except >> >possibly making kern.dumpdev a string (makes quite a bit of sense there...) >> >> Indeed. a dev_t should never be exported as such from the kernel >> anymore, in particular not for bdevs. dumps and swap are the two >> offenders left. > >Should I commit a similar workaround for the swap code too? Quite >simple to do... Please so, but I would appreciate if you would do me the favour of hiding the guts of this monstrosity in kern/kern_conf.c in a function called dev2budev() ? -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is dumpon/savecore broken?
On Tue, 20 Jul 1999, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, "Bria > n F. Feldman" writes: > > >>/ddname = find_dev/s/BLK/CHR/ > > > >No, that's wrong. You cannot do buffered-type IO on a cdev. I committed > >a workaround, and now it works. There's no easy way around this, except > >possibly making kern.dumpdev a string (makes quite a bit of sense there...) > > Indeed. a dev_t should never be exported as such from the kernel > anymore, in particular not for bdevs. dumps and swap are the two > offenders left. Should I commit a similar workaround for the swap code too? Quite simple to do... > > -- > Poul-Henning Kamp FreeBSD coreteam member > [EMAIL PROTECTED] "Real hackers run -current on their laptop." > FreeBSD -- It will take a long time before progress goes too far! > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is dumpon/savecore broken?
In message <[EMAIL PROTECTED]>, "Bria n F. Feldman" writes: >> /ddname = find_dev/s/BLK/CHR/ > >No, that's wrong. You cannot do buffered-type IO on a cdev. I committed >a workaround, and now it works. There's no easy way around this, except >possibly making kern.dumpdev a string (makes quite a bit of sense there...) Indeed. a dev_t should never be exported as such from the kernel anymore, in particular not for bdevs. dumps and swap are the two offenders left. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is dumpon/savecore broken?
On Tue, 20 Jul 1999, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, "Steven G. Kar > gl" writes: > > > >During the boot process I see > > > dumpon: crash dumps to /dev/da0s1b (4, 131073) > > checking for core dump...savecore: can't find device 13/131073 > > >It seems that the the major device number is reset from 4 to 13. > > >troutmask:kargl[225] swapinfo > >Device 1K-blocks UsedAvail Capacity Type > >/dev/#B13:0x200015118720 511872 0%Interleaved > > Yes, all dev_t's which make it out of the kernel have cmajor > numbers now. > > Try this change to savecore: > > /ddname = find_dev/s/BLK/CHR/ No, that's wrong. You cannot do buffered-type IO on a cdev. I committed a workaround, and now it works. There's no easy way around this, except possibly making kern.dumpdev a string (makes quite a bit of sense there...) > > > -- > Poul-Henning Kamp FreeBSD coreteam member > [EMAIL PROTECTED] "Real hackers run -current on their laptop." > FreeBSD -- It will take a long time before progress goes too far! > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is dumpon/savecore broken?
On Tue, 20 Jul 1999, Matthew Dillon wrote: > > A crash dump would have to uncopmressed to gdb it. If you have > sufficient space to hold a crash dump, just point /var/crash at that > space. If you compress it right off the bat then someone is going to > have to uncompress it to look at it. savecore saving compressed crash dumps is handy on production machines with lots of memory. I run a bunch of HP/UX boxes that don't have 4 gigs in /var/crash, because they never crash, except of course when they do. It is very useful to be able to save the dump, even if I have to analyze it somewhere else. David Scheidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is dumpon/savecore broken?
:On Tue, 20 Jul 1999, Matthew Dillon wrote: : :> :> * make sure your swap partition is large enough to hold the crash :> dump. If you have 256MB of ram, your swap partition must be :> at least 256MB in size. : :Is there any reason that savecore(8) can't write compressed crashdumps? :(Other than no one haveing ever written the the code, of course.) In :other words, if I wrote this would it get committed? : :David Scheidt A crash dump would have to uncopmressed to gdb it. If you have sufficient space to hold a crash dump, just point /var/crash at that space. If you compress it right off the bat then someone is going to have to uncompress it to look at it. I sometimes compress crash dumps if I want to save them after I'm through gdb'ing them. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is dumpon/savecore broken?
In message <[EMAIL PROTECTED]>, Dav id Scheidt writes: >On Tue, 20 Jul 1999, Matthew Dillon wrote: > >> >> * make sure your swap partition is large enough to hold the crash >> dump. If you have 256MB of ram, your swap partition must be >> at least 256MB in size. > >Is there any reason that savecore(8) can't write compressed crashdumps? >(Other than no one haveing ever written the the code, of course.) In >other words, if I wrote this would it get committed? I'm pretty sure it would. I think the lack of libz has prevented it in the past. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is dumpon/savecore broken?
According to Matthew Dillon: > > :And how do you create dumps from a kernel that hasn't finished booting > :(not gotten to the stage of reading rc.conf)? 'dumps on' in kernel > :config does not seem to do the job. > : > :Nick > > You can do it manually from /etc/rc. If it doesn't even get that far, > you used to be able to specify it in the kernel config but I do not know > if that is possible any more. > I think that is Nick's point. You can no longer specify a dump device in the kernel config file. troutmask:root[203] config TROUTMASK config: line 41: root/dump/swap specifications obsolete On the other hand, you should have kernel.old or a fixit floppy available. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is dumpon/savecore broken?
On Tue, 20 Jul 1999, Matthew Dillon wrote: > > * make sure your swap partition is large enough to hold the crash > dump. If you have 256MB of ram, your swap partition must be > at least 256MB in size. Is there any reason that savecore(8) can't write compressed crashdumps? (Other than no one haveing ever written the the code, of course.) In other words, if I wrote this would it get committed? David Scheidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is dumpon/savecore broken?
:And how do you create dumps from a kernel that hasn't finished booting :(not gotten to the stage of reading rc.conf)? 'dumps on' in kernel :config does not seem to do the job. : :Nick You can do it manually from /etc/rc. If it doesn't even get that far, you used to be able to specify it in the kernel config but I do not know if that is possible any more. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is dumpon/savecore broken?
And how do you create dumps from a kernel that hasn't finished booting (not gotten to the stage of reading rc.conf)? 'dumps on' in kernel config does not seem to do the job. Nick > A checklist for people who want kernel cores: > > * make sure that dumpdev is set to point to your swap partition > in your /etc/rc.conf > > * make sure your swap partition is large enough to hold the crash > dump. If you have 256MB of ram, your swap partition must be > at least 256MB in size. > > * make sure /var/crash has sufficient space to hold the dump > (note: /var/crash *can* be a softlink to a directory in some > other partition if /var does not have sufficient space) > > /var/crash must nominally have sufficient space to hold the crash > dump (a file of the same size as the amount of memory you have), > *and* the kernel image. Normally you give it a lot more space so > you store several crash dumps in it at once. Nick -- e-Mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is dumpon/savecore broken?
According to Matthew Dillon: > :> > dumpon: crash dumps to /dev/da0s1b (4, 131073) > :> > checking for core dump...savecore: can't find device 13/131073 > :> > :> >It seems that the the major device number is reset from 4 to 13. > :> > :> Yes, all dev_t's which make it out of the kernel have cmajor > :> numbers now. > :> > :> Try this change to savecore: > :> > :>/ddname = find_dev/s/BLK/CHR/ > :> > : > :Thanks, Poul. > : > :I forgot to mention that this is after a "make world" and new kernel > :from today (1000 PST). > : > > A checklist for people who want kernel cores: > [Matt's check list deleted which I meet] > /var/crash must nominally have sufficient space to hold the crash > dump (a file of the same size as the amount of memory you have), > *and* the kernel image. Normally you give it a lot more space so > you store several crash dumps in it at once. Matt, AFAICT, the problem is due to the translation of /dev/da0s1b to major and minor numbers. dumpon takes /dev/da0s1b and translates it to (4,131073) in my case. savecore uses sysctl kern.dumpdev to determine the dump device. kern.dumpdev is set to (13,131073). Thus, dumpon uses bmajor and savecore uses cmajor device numbers. I also note that savecore grovels around in /dev/kmem which scares the heck out of me as far as my hacking abilities go ;-) -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is dumpon/savecore broken?
:> > dumpon: crash dumps to /dev/da0s1b (4, 131073) :> > checking for core dump...savecore: can't find device 13/131073 :> :> >It seems that the the major device number is reset from 4 to 13. :> :> Yes, all dev_t's which make it out of the kernel have cmajor :> numbers now. :> :> Try this change to savecore: :> :> /ddname = find_dev/s/BLK/CHR/ :> : :Thanks, Poul. : :I forgot to mention that this is after a "make world" and new kernel :from today (1000 PST). : :-- :Steve A checklist for people who want kernel cores: * make sure that dumpdev is set to point to your swap partition in your /etc/rc.conf * make sure your swap partition is large enough to hold the crash dump. If you have 256MB of ram, your swap partition must be at least 256MB in size. * make sure /var/crash has sufficient space to hold the dump (note: /var/crash *can* be a softlink to a directory in some other partition if /var does not have sufficient space) /var/crash must nominally have sufficient space to hold the crash dump (a file of the same size as the amount of memory you have), *and* the kernel image. Normally you give it a lot more space so you store several crash dumps in it at once. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is dumpon/savecore broken?
According to Poul-Henning Kamp: > In message <[EMAIL PROTECTED]>, "Steven G. Kar > gl" writes: > > > >During the boot process I see > > > dumpon: crash dumps to /dev/da0s1b (4, 131073) > > checking for core dump...savecore: can't find device 13/131073 > > >It seems that the the major device number is reset from 4 to 13. > > Yes, all dev_t's which make it out of the kernel have cmajor > numbers now. > > Try this change to savecore: > > /ddname = find_dev/s/BLK/CHR/ > Thanks, Poul. I forgot to mention that this is after a "make world" and new kernel from today (1000 PST). -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is dumpon/savecore broken?
In message <[EMAIL PROTECTED]>, "Steven G. Kar gl" writes: > >During the boot process I see > dumpon: crash dumps to /dev/da0s1b (4, 131073) > checking for core dump...savecore: can't find device 13/131073 >It seems that the the major device number is reset from 4 to 13. >troutmask:kargl[225] swapinfo >Device 1K-blocks UsedAvail Capacity Type >/dev/#B13:0x200015118720 511872 0%Interleaved Yes, all dev_t's which make it out of the kernel have cmajor numbers now. Try this change to savecore: /ddname = find_dev/s/BLK/CHR/ -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
