From owner-freebsd-stable@FreeBSD.ORG Fri Feb 8 20:41:11 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25C5316A420 for ; Fri, 8 Feb 2008 20:41:11 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by mx1.freebsd.org (Postfix) with ESMTP id A9CF113C46B for ; Fri, 8 Feb 2008 20:41:10 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail04.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m18Kf8Ai022559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Feb 2008 07:41:09 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.1) with ESMTP id m18Kf81E087541; Sat, 9 Feb 2008 07:41:08 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m18Kf8gq087540; Sat, 9 Feb 2008 07:41:08 +1100 (EST) (envelope-from peter) Date: Sat, 9 Feb 2008 07:41:08 +1100 From: Peter Jeremy To: "Carlos A. M. dos Santos" Message-ID: <20080208204107.GG4008@server.vk2pj.dyndns.org> References: <47A9F835.1060200@bsdforen.de> <47AA0696.5020109@bsdforen.de> <7872AB6E-21DA-4E2D-93C0-D07CFA3A7E47@mac.com> <47AA0E3E.4020304@bsdforen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+mr2ctTDD1GjnQwB" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7: interrupt eating whole cpu core X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2008 20:41:11 -0000 --+mr2ctTDD1GjnQwB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 08, 2008 at 12:22:38AM -0200, Carlos A. M. dos Santos wrote: >Wow, now I'm *really* surprised. I used to think that putting > > hw.ata.ata_dma=3D"1" > hw.ata.atapi_dma=3D"1" hw.ata.ata_dma has no effect on ATAPI devices. >in /boot/loader.conf would be enough to enable DMA mode. Looking at the code, atapi_dma will enable UDMA modes if the drive supports at least UDMA2 them but ignores WDMA capabilities. This was part of the ATA mkIII update - which is in 6.x but was not MFC'd to 5.x. If you do a verbose boot, you will get a probe line reporting the drive capabilities. Unfortunately, atacontrol only reports 'dma [not] supported' - not what capabilities the drive has. >1. Is this related to using atapicam? No. >2. Should this be considered a bug? Possibly. The relevant commit message doesn't mention the ATAPI DMA changes so it's not clear whether this is an oversight or deliberate. I do recall that there have been problems in the past with ATAPI drives that would advertise DMA capabilities but would misbehave if you used DMA (atapi_dma was disabled by default in 5.x for this reason). I'm not sure if the current code is at effort to avoid this. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --+mr2ctTDD1GjnQwB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHrL5j/opHv/APuIcRAsMpAJ9J6MNX0fu10xG+msFVbb6HPQu2KwCeP30i kw5LNtRaCsy5CvHXyzHeKWo= =Uxbb -----END PGP SIGNATURE----- --+mr2ctTDD1GjnQwB--