Date: Fri, 08 Jan 2016 21:43:27 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 206048] 11.0-CURRENT -r293227 (and others) arm (rpi2/BeagleBone Black): swapfile usage hangs; swap partition works Message-ID: <bug-206048-7@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206048 Bug ID: 206048 Summary: 11.0-CURRENT -r293227 (and others) arm (rpi2/BeagleBone Black): swapfile usage hangs; swap partition works Product: Base System Version: 11.0-CURRENT Hardware: arm OS: Any Status: New Severity: Affects Some People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: markmi@dsl-only.net Description for my rpi2 based context: Using a swap partion on the sdcard o= r on an extern SSD both work fine (recently discovered). But using a fast extern= al SSD for the root file system with a /swapfile0 would eventually hang when normal root-file-system IO was mixed with /swapfile0 IO, such as using gcc49 (from pkg install) to build something like devel/gcc5 (ports). This has been going on since I started with arm but only recently did I manage to get any evidence about the hangs and find a configuration that avoids them. I've al= so had hangs during svnlite status and svnlite diff and other things that woul= d do lots of file activity. Evidence from a rpi2 context taken from various hangs while using /swapfile= 0 as the swap space: Note: a process such as top or gstat running over the serial console connec= tion continues to update its display so long as it is not disturbed. I was also = able to get into ddb. These were my limited window into seeing the following evidence about the hangs when /swapfile0 was the swap-space. 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 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 sometimes looked normal for its state. [md0], [kernel], and [pagedaemon] and their states did not vary from one ha= ng to the next. After a hang and waiting an hour+: "gstat -cod" showed exactly one non-zero figure in its grid: L(q) for "md0" showed a 4. After a hang ddb's "ps" showed (my presentation order and formating): [pagedaemon] had wmesg wswbuf0 and state D [swapper] had wmesg vmwait and state D [md0] had wmesg vmwait and state DL [usb]'s threads: [usb0] had wmesg - and state D (all 5 such lines) [smsc0] had wmesg - and state D "show pageq" listed: pq_free 2 pq_cache 0 dom 0 page_cnt 234761 free 2 pq_act 164873 pq_inact 18563 pass 2 "show freepages" listed only one non-zero "NUMBER POOL 0": ORDER (SIZE) NUMBER POOL 0 01 (000008k) 000001 (gstat and those last two are from Ian Lepore's suggestions for what to look at. But he was not sure either. Hans Petter Selasky had asked about usb process/thread related information.) Non-RPI2 notes/summaries from others: Ian Lepore reported similar symptoms but I'm unsure of the swapfile vs. swap partition status for his context(s). (He was attributing problems to slow IO devices when he wrote of having similar symptoms.) I expect that Ian has ot= her arm systems involved than rpi2 and BeagleBone Black but I do not know the details, other than he mentioned arm64 examples. Paul Mather reported that for BeagleBone Black ( https://lists.freebsd.org/pipermail/freebsd-arm/2016-January/013015.html ): This meshes with recent experience I have been having with CURRENT on a BeagleBone Black. I use a swapfile on the SD card (which also hosts all th= e OS file systems) and the system would regularly lock up, with GEOM complaining= on the console about I/O errors to the mmcsd0 device. In the past, too, I have experienced panics (on all my arm systems) when the system attempts to page in from swap. For now, on the BeagleBone Black, I have attached an external USB hard drive and am using a swap partition on there to see if it "solves" the swap probl= em.=20 The good news is that it hasn't locked up so far. (Usually, the nightly periodic jobs are enough to provoke the problem.) --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-206048-7>