From owner-freebsd-current@FreeBSD.ORG Wed May 12 08:54:15 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 1098316A4CF; Wed, 12 May 2004 08:54:15 -0700 (PDT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 851DD43D41; Wed, 12 May 2004 08:54:13 -0700 (PDT) (envelope-from sos@DeepCore.dk) Received: from DeepCore.dk (sos.deepcore.dk [194.192.25.130]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i4CFs608035647; Wed, 12 May 2004 17:54:11 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <40A2489E.4030008@DeepCore.dk> Date: Wed, 12 May 2004 17:54:06 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.5 (X11/20040329) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <20040512145212.62e7db1e@it.buh.cameradicommercio.ro> <40A2387E.1050208@DeepCore.dk> <40A23FEE.3020109@DeepCore.dk> <40A24605.7030908@freebsd.org> In-Reply-To: <40A24605.7030908@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-mail-scanned: by DeepCore Virus & Spam killer v1.4 cc: "Bjoern A. Zeeb" cc: freebsd-current@freebsd.org Subject: Re: ad0: WARNING - WRITE_DMA interrupt was seen but timeout fired LBA=21267353 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, 12 May 2004 15:54:15 -0000 Scott Long wrote: > Taskqueues work just fine for other drivers. I can't see anything > obviously wrong with your use of the taskqueue (other than what we have > talked about before), though you also use bio_taskqueue(). Looking in > there, it has two additional mutexes that get locked when run. Maybe > there is an LOR or other such problem that is causing the stall. > Running with WITNESS might reveal something. You might also just plain > be missing the interrupt from the drive,, but that is harder to > determine. Well using the bio_taskqueue has made the problem go away on those few situations where I could provoke it, so that is actually a help. I see no LOR's or anything else from witness. I dont miss the interrupt, if you look at the code you will se that I have got the interrupt, read status from the device etc, but its the simple return via the biodone etc thats put on the taskqueue that doesn't get called in time for the timeout to fire... Now the timeout is 5 secs so on a busy machine our lemming syncer can get the disksystem so busy that the first one appears because of that. -- -Søren