From owner-freebsd-current@FreeBSD.ORG Sat Aug 7 11:55:43 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 3EFF216A4CE for ; Sat, 7 Aug 2004 11:55:43 +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 8F2EB43D49 for ; Sat, 7 Aug 2004 11:55:42 +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 i77BtYar014944; Sat, 7 Aug 2004 13:55:39 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <4114C32E.3060202@DeepCore.dk> Date: Sat, 07 Aug 2004 13:55:26 +0200 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: Nate Lawson References: <4113EB2A.7060401@root.org> <41140722.10807@DeepCore.dk> <411415C8.4070600@root.org> In-Reply-To: <411415C8.4070600@root.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: Ceri Davies cc: current@freebsd.org cc: Radek Kozlowski Subject: Re: Panic on boot with today's CURRENT, ata related 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: Sat, 07 Aug 2004 11:55:43 -0000 Nate Lawson wrote: > Søren Schmidt wrote: > >> Nate Lawson wrote: >> >>> I took a quick look at this ATA panic. The exact same one occurs for >>> Ceri. A quick dissassemble shows that the testb is the check for the >>> DMA flag at the very end of ata_generic_transaction(). The bug >>> appears to be that this may be a PIO request (since the DMA check is >>> outside the switch() statement). The fix is to make sure it's a DMA >>> request before dereferencing an element of the DMA struct. Try the >>> attached patch. >> >> >> No, the fix is to make sure there is a valid ch->dma pointer, the >> below is the correct fix. >> >> --- ata-lowlevel.c 5 Aug 2004 21:13:41 -0000 1.41 >> +++ ata-lowlevel.c 6 Aug 2004 22:31:16 -0000 >> @@ -295,7 +295,7 @@ >> } >> >> /* request finish here */ >> - if (ch->dma->flags & ATA_DMA_LOADED) >> + if (ch->dma && ch->dma->flags & ATA_DMA_LOADED) >> ch->dma->unload(ch); >> return ATA_OP_FINISHED; >> } > > > Thanks. Under what circumstances is a request generated with ATA_R_DMA > set in the flags but where the channel's dma struct has not been allocated? It should not happen on normal and correct use, but since drivers are responsible for setting the flags, there is potential for error situations, and we want to catch those as well instead of panic'ing. Better safe than sorry as they say... -Søren