Current method of dumping a processor?

Willem Jan Withagen wjw at
Tue Aug 17 08:36:31 PDT 2004

From: "Greg 'groggy' Lehey" <grog at>
To: "Radek Kozlowski" <radek at>
> On Friday, 13 August 2004 at  1:07:41 +0200, Radek Kozlowski wrote:
> > On Fri, Aug 13, 2004 at 07:28:59AM +0930, Greg 'groggy' Lehey wrote:
> >> I've tried it on kernels built in January, May and yesterday.  In each
> >> case, I did:
> >>
> >>   dumpon /dev/ad0s2b
> >>
> >> (for appropriate values of ad0s2b).  All kernels include ddb.  I
> >> entered the debugger with ctrl-alt-esc and entered "panic".  The
> >> kernel from January dumps just fine.  The kernels from May and August
> >> hang.
> >>
> >> Am I doing something wrong?  Has something else changed?  Does anybody
> >> else have this problem?
> >
> > I also had this problem back in June when I was trying to get a crash
> > dump, but nobody replied (see
> >
> > I then learnt that I can use call doadump in ddb and have been using
> > that since then.
> Thanks.  Yes, this seems to work.  Are we agreed that it's a bug that
> the 'panic' command just hangs?

This was a problem on amd64 with large amounts of memory due to 32bit overflow
until I fixed it in a very crude way (after good suggestions where to look) and
after a short while it got really fixed in an upper layer by someone who knew
what he was doing.

But that was when even 'call doadump' did not even work. So if call doadump does
work for you big chance it is in the boot() code before it calls doadump. Since
that is more or less what panic calls.

Since then I've not seen kernels where this problem returned. BTW I'm running
amd64 with dual processor.


More information about the freebsd-current mailing list