From owner-freebsd-current@FreeBSD.ORG Wed Mar 10 01:45:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0682116A4CE for ; Wed, 10 Mar 2004 01:45:22 -0800 (PST) Received: from smtp.mho.com (smtp.mho.net [64.58.4.5]) by mx1.FreeBSD.org (Postfix) with SMTP id AC02543D41 for ; Wed, 10 Mar 2004 01:45:21 -0800 (PST) (envelope-from scottl@freebsd.org) Received: (qmail 62291 invoked by uid 1002); 10 Mar 2004 09:45:21 -0000 Received: from unknown (HELO freebsd.org) (64.58.1.252) by smtp.mho.net with SMTP; 10 Mar 2004 09:45:21 -0000 Message-ID: <404EE2ED.3030600@freebsd.org> Date: Wed, 10 Mar 2004 02:42:05 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <39679.1078911516@critter.freebsd.dk> In-Reply-To: <39679.1078911516@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Michael Reifenberger cc: freebsd-current@freebsd.org Subject: Re: got "swap_pager: indefinite wait buffe" under -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2004 09:45:22 -0000 Poul-Henning Kamp wrote: > In message <20040310103020.Y69923@fw.reifenberger.com>, Michael Reifenberger wr > ites: > >>Hi, >>under -current as of yesterday I got during the fixation of an audio CD >>using cdrecord via atapicam the following console message: >> >>swap_pager: indefinite wait buffer: device: ad0s2a, blkno: 34107, size: 16384 >> >>What does that mean? > > > That a disk-I/O request did not complete. > > Likely cause is disk hardware or media error. > > Check for console messages from ata driver. > > You can try to run gstat(8) the leftmost column which shows number > of outstanding I/O requests. > > Actually, this is more likely due to bad error recovery in ATAPI causing all of the other I/O to be held hostage. It's hard to say if this is purely the fault of the ata driver, or if there is a more insideous interaction between ata and GEOM. In any case, you might try using burncd(8) to see if the problem persists. Scott