Date: Thu, 07 Jan 2016 09:12:50 -0700 From: Ian Lepore <ian@freebsd.org> To: Mark Millard <markmi@dsl-only.net>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: FYI: various 11.0-CURRENT -r293227 (and older) hangs on arm (rpi2): a description of sorts Message-ID: <1452183170.1215.4.camel@freebsd.org> In-Reply-To: <E0379BE9-308A-4219-A8AE-A5FFE828BA93@dsl-only.net> References: <E0379BE9-308A-4219-A8AE-A5FFE828BA93@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2016-01-07 at 02:19 -0800, Mark Millard wrote: > I've had various hangs when the rpi2 was busy over longish periods, > both debug buildkernel/buildworld builds of the arm and non-debug > variants. No log files or console messages produced. > > I've not had any analogous issues with powerpc64 (PowerMac G5) or > with amd64 (Virtual Box used on Mac OS X). > > I've finally discovered that if I have, say, top running on the rpi2 > serial console that top continues to update its display so long as I > leave it alone during the hang. (Otherwise it hangs too.) So I > finally have a little window for seeing some of what is happening. > > An example top display showed after the hang: > > Mem: 764M Active 12M Inact 141M Wired 98M Buf 8k free > Swap: 2048M Total 29M Used 2019 Free 1% in use > > (Yep: Just 8K free Mem.) > That's not a problem. > The unusual STATEs for processes seemed to be (for the specific > hang): > > STATE COMMANDs > pfault [ld] [ld] /usr/sbin/syslogd > vmwait [ld] [md0] [kernel] > wswbuf [pagedaemon] > > Those same 3 states seem to always be involved. Some of the processes > vary from one hang to the next: the prior hang had build/genautoma , > /usr/sbin/moused , and /usr/sbin/ntpd instead of 3 [ld]'s. > > /usr/sbin/syslogd, [md0], [kernel], and [pagedaemon] and their states > do not seem to vary (so far). > > Everything is backed up waiting for slow sdcard IO. You can get an amd64 system with many cores and gigabytes of ram into the same state with an sdcard (or any other storage device that takes literally seconds for any individual IO to complete). All the available buffers get queued up to the one slow device, then you can't do anything that requires IO (even launch tools to try to figure out what's going on). -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1452183170.1215.4.camel>