From owner-freebsd-current@FreeBSD.ORG Wed Nov 10 13:51:48 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 78CD916A4CE; Wed, 10 Nov 2004 13:51:48 +0000 (GMT) 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 C871443D55; Wed, 10 Nov 2004 13:51:47 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id iAADphXM037722; Wed, 10 Nov 2004 14:51:45 +0100 (CET) (envelope-from sos@DeepCore.dk) Message-ID: <41921CC4.5010802@DeepCore.dk> Date: Wed, 10 Nov 2004 14:51:00 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.4 cc: Zoltan Frombach cc: freebsd-current@freebsd.org Subject: Re: 5.3-RELEASE: WARNING - WRITE_DMA interrupt timout - what does it mean? 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 Nov 2004 13:51:48 -0000 Robert Watson wrote: > On Wed, 10 Nov 2004, S=F8ren Schmidt wrote: >=20 >=20 >>>I'm still a bit skeptical that the task queue is at fault -- I run my >>>notebook with continuous measurement of the latency to schedule tasks,= >>>generating a warning for any latency > .5 seconds, and the only time I= >>>ever see that sort of latency is during the boot process when ACPI has= >>>scheduled a task to run, but the task queue thread has not yet been >>>allowed to run: >> >>Right, the timeout is 5 secs. I havn't looked into how the taskqueues >>are handled recently, but in case of ATA read/writes it is the >>bio_taskqueue handled by geom thats in use not the catchall ones, does >>your timing cover that as well?=20 >=20 >=20 > Nope -- I had assumed that the suggested task problems in question was = the > use of taskqueue_enqueue() in ata-queue for the timeout, rather than th= e > bio_taskqueue() ata_completed() call. OK, then there is no idea in trying the patch, it wont tell us anything. --=20 -S=F8ren