Re: enabling kernel dump options in GENERIC

On Fri, May 18, 2018 at 06:14:50AM -0700, Mark Millard wrote:
> On 2018-May-17, at 11:17 PM, Mark Johnston <markj at FreeBSD.org> wrote:
> 
> > On Thu, May 17, 2018 at 08:58:16PM -0700, Mark Millard wrote:
> >> Mark Johnston markj at FreeBSD.org wrote on
> >> Thu May 17 17:24:19 UTC 2018 :
> >> 
> >>> Over the past couple of years, a number of kernel dump features have
> >>> been added: encryption, compression and dumping to a remote host
> >>> (netdump). These features are currently all omitted from GENERIC.
> >>> 
> >>> . . .
> >>> Therefore, I'd like to propose enabling these features by default
> >>> on i386, amd64, arm64, powerpc(64) and sparc64 so that they're available
> >>> out of the box in 12.0.
> >>> . . .
> >> 
> >> Bugzilla 214598 (from late 2016) was about
> >> dump for TARGET_ARCH=powerpc64 builds getting
> >> failures like:
> >> 
> >> KDB: enter: manual escape to debugger
> >> [ thread pid 12 tid 10018 ]
> >> Stopped at       .kdb_enter+0x70:       ori r0, r0, 0x0
> >> db> dump
> >> Dumping 9 MB (3 chunks)
> >>  chunk 0: 10MB (2510 pages) ... ok
> >>  chunk 1: 1MB (24 pages) ... ok
> >>  chunk 2: 1MB (2 pages)panic: vm_fault: fault on nofault entry, addr: c000000000022000
> >> 
> >> (A 32-bit powerpc build on the same machine worked
> >> fine for dumping.)
> >> 
> >> I just tried it with head -r333594 and I got something
> >> similar. (Old and new mention routines with _bus_dma_map_
> >> in the names near the trap in the call stack. I've not
> >> done a detailed comparison.)
> > 
> > What is the call stack?
> 
> I'll have to induce the failure, take a picture of
> the screen that results, and hand type in the
> material for the fairly modern backtrace (-r333594).
> I will not be able to do this until later today.
> 
> The bugzilla report has the old backtrace. I did not
> quote all the material from that report in the above.
> So there is something to compare against once I
> supply a modern one.

My apologies, I missed the fact that the backtrace was included in that
PR. Since the problem still occurs and apparently manifests with a
similar backtrace, it wouldn't be useful to retest. I'm afraid I don't
have any suggestions on how to make progress here. Given that the new
options give only a small increase in the kernel size, I'm still
inclined to enable them on powerpc64 for consistency with other
architectures.

> Also: in about a week I'll lose access to the PowerMacs
> for an unknown period of time (weeks? months?).
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
> 
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "[email protected]"