Builworld stalls on rpi2 [various processes stuck in pfault and vmwait with 1996M Free Swap listed by top]

bob prohaska fbsd at www.zefox.net
Sat Jan 13 02:43:50 UTC 2018


On Fri, Jan 12, 2018 at 05:53:03PM -0800, Mark Millard wrote:
> 
> On 2018-Jan-12, at 4:54 PM, bob prohaska <fbsd at www.zefox.net> wrote:
> 
> > 
> > The machine still answers ping. Typing escape control-b does not
> > bring up a debugger, did the keysequence change? Power cycling seems
> > to be the only way out.
> 
> With or without:
> 
> options         ALT_BREAK_TO_DEBUGGER
> 
> For with: <CR>~^B (with <CR> being <return>
> and ^ being <control>) is an alternate with
> this.
> 

The line 
options         ALT_BREAK_TO_DEBUGGER
does not appear in the GENERIC kernel, but
neither does the ue identifier for ethernet.
I thought perhaps both were included from
elsewhere. Maybe not. I'll add it.




> I've see the smsc0 messages before but I'm
> not up to -r327664+ yet. This has been with
> a non-debug kernel running.
> 
> I've had building large ports get into such states,
> especially while at least one large link operation
> was active with other fairly large processes,
> as I remember.
> 
> Note all the pfault and vmwait lines. It looks like
> -r327316 and -r327468 did not happen to avoid this.
> It looks like the paging/swaping has gotten stuck
> in some way. How tied that might be to smsc0
> messages, I've no clue.
> 
> You might get through by using -j3 or -j2 or -j1 which
> likely would use less process space at once (worst case)
> than -j4 happened to.
> 
> Of course there are other time consequences as you
> approach -j1 (or no explicit -j for the buildworld
> at all).
> 
> 
> 
I'd rather not slow things down, but slow is better than
crashed....

8-)

Thanks for writing!

bob prohaska



More information about the freebsd-arm mailing list