Re: FYI: example "panic: ARM64TODO: reclaim_pv_chunk" on a Pine64+ 2GB with head -r317015 [mkimg okay; "cp -p" generates the bad context]

2017-04-30 Thread Mark Millard
On 2017-Apr-27, at 10:26 PM, Mark Millard wrote: > [As the text does not really follow from the earlier text > I'd sent directly I'm top posting a hypothesis about where > so much active memory came from to be so low in available > memory to get an reclaim_pv_chunk attempt.] > > My hypothesis

Re: FYI: example "panic: ARM64TODO: reclaim_pv_chunk" on a Pine64+ 2GB with head -r317015 [mdconfig -d not effectively releasing memory?]

2017-04-27 Thread Mark Millard
[As the text does not really follow from the earlier text I'd sent directly I'm top posting a hypothesis about where so much active memory came from to be so low in available memory to get an reclaim_pv_chunk attempt.] My hypothesis is that the "mdconfig -d"s from vm_copy_base (from

Re: FYI: example "panic: ARM64TODO: reclaim_pv_chunk" on a Pine64+ 2GB with head -r317015 [another example]

2017-04-27 Thread Mark Millard
[Another example panic. Again no dump. But I have what a top -PCwaopid froze at this time.] On 2017-Apr-27, at 4:22 PM, Mark Millard wrote: > Unfortunately for this FYI the attempt to produce a dump > failed and so all the information that I have is what I > first captured from the console

FYI: example "panic: ARM64TODO: reclaim_pv_chunk" on a Pine64+ 2GB with head -r317015

2017-04-27 Thread Mark Millard
Unfortunately for this FYI the attempt to produce a dump failed and so all the information that I have is what I first captured from the console output: a backtrace. The context was head -r317015 on a Pine64+ 2GB. At the time I was experimenting with trying to build a vm.raw from my own build of