Re: port-x68k/51663 (crash dump related bugs in x68k/machdep.c)

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

The following reply was made to PR port-x68k/51663; it has been noted by GNATS.

From: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
To: rokuyama%rk.phys.keio.ac.jp@localhost
Cc: gnats-bugs%NetBSD.org@localhost, tsutsui%ceres.dti.ne.jp@localhost
Subject: Re: port-x68k/51663 (crash dump related bugs in x68k/machdep.c)
Date: Wed, 30 Nov 2016 00:56:45 +0900

 > Let me explain a little more.
 
 Thank you for your explanation. Your analysis is correct.
 
 > cpu_kcore_hdr.un._m68k.ram_segs[i].{start,size} describe start address
 > and size of the i-th segment of physical memory.
  :
 
 I see.  Actually I didn't understand what values ram_segs[] should have,
 and I should have checked cpu_init_kcore_hdr() more carefully
 when I changed mem_exists() for PR/45915:
  http://mail-index.netbsd.org/port-x68k/2013/10/19/msg000039.html
 
 > cpu_kcore_hdr.un._m68k.ram_segs[0] must cover whole the base memory,
 > including areas not registered into the free list of UVM. This is
 > because there are global variables and msgbuf below and above the region
 > managed by UVM.
 
 (BTW, mem_size for ram_segs[0] seems incorrect even before
  my mem_exist() changes..)
 
 > On the other hand, regions in extended memory not managed by UVM can
 > probably be excluded from ram_segs[i] (i >= 1). However, in my patch,
 > such regions are also included for the reasons explained before.
 
 Maybe we should clarify the definitions of the following regions
 in some m68k docs:
 
  a) VM_PHYSMEM_PTR() (formerly vm_physmem[]) registered by
     uvm_page_physload(9)
  b) phys_ram_seg_t ram_segs[] for crashdump
 
 The region a) includes memories that are managed by uvm(9).
 The region b) includes memories that should be accessed
 on gdb "target kvm" debug using crashdump via savecore(8).
 
 The main difference is that b) includes kernel itself and msgbuf
 but a) should not have them.
 
 b) would exclude memory regions that are not managed by kernel
 (for example, PROM reserved area on news68k and sun3x etc.)
 as you mentioned, but IIRC x68k uses whole extended memory regions.
 
 Forthermore, it would be harmless to register unmanaged regions
 into b) (unless the region includes some sensitive data),
 so we don't have to consider it strictly if the port doesn't
 have useful info (variables) about the "unmanaged regions."
 
 (Note news68k PROM excludes its reserved area from "memsize" info)
 
 Your patch seems fine (maybe "size" should be psize_t rather than int).
 I'll commit it after I also confirm it on my x68k.
 
 Thanks,
 
 ---
 Izumi Tsutsui