kern/103455: "swap_pager: indefinite wait buffer" with page file enabled (causes lockups)

Nick Withers nick at nickwithers.com
Tue May 17 14:10:14 UTC 2011


The following reply was made to PR kern/103455; it has been noted by GNATS.

From: Nick Withers <nick at nickwithers.com>
To: "\"Arnaud" =?ISO-8859-1?Q?Mich=E9=22?= <Arnaud.Miche at gmx.net>
Cc: bug-followup at FreeBSD.org
Subject: Re: kern/103455: "swap_pager: indefinite wait buffer" with page
 file enabled (causes lockups)
Date: Tue, 17 May 2011 23:49:30 +1000

 --=-RTr1Boq2URAgd5N7obOO
 Content-Type: text/plain; charset="ISO-8859-1"
 Content-Transfer-Encoding: quoted-printable
 
 On Tue, 2011-05-17 at 11:25 +0200, "Arnaud Mich=E9" wrote:
 > Hi,
 
 (snip)
 
 > When the problem occurs some messages are interlaced with the "swap_pager=
 "=20
 > messages, I give them here:
 >=20
 > ad0: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completi=
 ng=20
 > request directly
 > acd0: WARNING - TEST_UNIT_READY taskqueue timeout - completing request=
 =20
 > directly
 > ad0: WARNING - SETFEATURES SET ENABLE RCACHE taskqueue timeout - completi=
 ng=20
 > request directly
 > ad0: WARNING - SETFEATURES SET ENABLE WCACHE taskqueue timeout - completi=
 ng=20
 > request directly
 > ad0: WARNING - SET_MULTI taskqueue timeout - completing request directly
 > ad0: TIMEOUT - READ_DMA retrying (1 retry left) LBA=3D215821
 > acd0: WARNING - TEST_UNIT_READY freeing taskqueue zombie request
 >=20
 > I don't know if this is a clue but is it not weird to have some messages=
 =20
 > coming from the cdrom drive ?
 
 Not necessarily - for instance I fully expect the following on my
 desktop when I boot: "cd0: Attempt to query device size failed: NOT
 READY, Medium not present - tray closed"... Because there isn't a CD in
 the drive, as the message suggests. Similarly, the far more scary
 sounding "acd0: FAILURE - ATA_IDENTIFY status=3D51<READY,DSC,ERROR>
 error=3D4<ABORTED> LBA=3D0" makes sense to me, as ATA_IDENTIFY's trying to
 identify the media and... There isn't one :-)
 
 That having been said, from what I understand of the "swap_pager:
 indefinite wait buffer: (...)" messages, it's because the swapper
 couldn't get access to the swap within the pre-defined timeout period
 (could well be totally wrong here, but see Kris Kennaway's response here
 http://groups.google.com/group/mailing.freebsd.stable/browse_thread/thread/=
 2e7faeeaca719c52/cdcd4601ce1b90c5). [Please check the URL your mail client'=
 s generated before telling me the link doesn't work, or google "swap_pager:=
  indefinite wait buffer"]). If there's an issue reading / writing to your s=
 wap area[1] such that it takes a long time to read / write from swap then y=
 ou *should* see this message - it's a good thing.
 
 Probably worth bearing in mind that PowerPC is NOT a FreeBSD Tier 1
 platform and don't be too surprised if there are issues there that may
 not be apparent to the vast majority of FreeBSd users. I myself used to
 have some "fun" on that very architecture before DMA was supported.
 
 [1]: Do you actually use a swap *****file*****? I really doubt you do -
 a swap partition ain't the same thing, and hence not really what PR
 kern/103455's about.
 
 Are you actually seeing a lock-up at all? If not, then again this isn't
 really what PR kern/103455's about. If I google "swap_pager: indefinite
 wait buffer", the very first result (well, for me;
 http://www.unixguide.net/freebsd/faq/05.30.shtml) tells you the
 following:
 ____
 
 This means that a process is trying to page memory to disk, and the page
 attempt has hung trying to access the disk for more than 20 seconds. It
 might be caused by bad blocks on the disk drive, disk wiring, cables, or
 any other disk I/O-related hardware. If the drive itself is actually
 bad, you will also see disk errors in /var/log/messages and in the
 output of dmesg. Otherwise, check your cables and connections.
 ____
 
 Not any kind of official source or anything, and does disagree with the
 30 second quote from good Mr. Kennaway's response (linked to earlier)
 but still, is consistent with what I recall from past research on the
 issue... Dodgy cables, etc..
 
 > Have you an idea of where do I debug and search to understand the error ?
 
 A WWW search engine - sorry man :-)
 
 > Many many thanks in advance.
 >=20
 > Arnaud
 --=20
 Nick Withers
 email: nick at nickwithers.com
 Web: http://www.nickwithers.com
 Mobile: +61 414 397 446
 
 --=-RTr1Boq2URAgd5N7obOO
 Content-Type: application/pgp-signature; name="signature.asc"
 Content-Description: This is a digitally signed message part
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.17 (FreeBSD)
 
 iEYEABECAAYFAk3SfOoACgkQ3wcG/Pf4WrhphACdF3O0wV7WylYRG5YIJK8AexpG
 0PsAnRyQXnfYJRyzN6nfcF7luhoV5Opt
 =aya2
 -----END PGP SIGNATURE-----
 
 --=-RTr1Boq2URAgd5N7obOO--
 


More information about the freebsd-bugs mailing list