From owner-freebsd-stable@FreeBSD.ORG Fri Feb 8 06:28:01 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 1DA8516A417 for ; Fri, 8 Feb 2008 06:28:01 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id D025D13C447 for ; Fri, 8 Feb 2008 06:28:00 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (nat-wh-1.rz.uni-karlsruhe.de [129.13.72.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 960D0405D18; Fri, 8 Feb 2008 07:27:59 +0100 (CET) Message-ID: <47ABF66E.4040807@bsdforen.de> Date: Fri, 08 Feb 2008 07:27:58 +0100 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.9 (X11/20080205) MIME-Version: 1.0 To: "Carlos A. M. dos Santos" References: <47A9F835.1060200@bsdforen.de> <47AA0696.5020109@bsdforen.de> <7872AB6E-21DA-4E2D-93C0-D07CFA3A7E47@mac.com> <47AA0E3E.4020304@bsdforen.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 06:28:01 -0000 Carlos A. M. dos Santos wrote: > On Feb 6, 2008 5:45 PM, Dominic Fandrey wrote: >> Chuck Swiger wrote: >>> Hi, Dominic-- >>> >>> On Feb 6, 2008, at 11:12 AM, Dominic Fandrey wrote: >>>>> behaviour has changed. This is an HP 6510b GR695EA#ABD, if anyone >>>>> thinks it might be helpful, I can supply you with a dmesg and the >>>>> output of pciconf -lv. >>>> The problem remains with fresh sources: >>>> >>>> PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND >>>> 12 root 1 171 ki31 0K 16K RUN 0 22:04 97.85% >>>> idle: cpu0 >>>> 37 root 1 -64 - 0K 16K CPU1 1 2:35 96.00% >>>> irq14: ata0 >>>> 11 root 1 171 ki31 0K 16K RUN 1 19:32 6.40% >>>> idle: cpu1 >>>> >>>> The rip is done by k3b, so the drive is accessed through the cam >>>> interface. >>> What are the values being reported by "sysctl hw.ata"? If you're going >>> to be burning CD/DVDs, you really want to make sure hw.ata.atapi_dma is on. >> I cannot believe it was so trivial. The sysctl looks all right. >> >> # sysctl hw.ata 0 /root >> hw.ata.wc: 1 >> hw.ata.atapi_dma: 1 >> hw.ata.ata_dma: 1 >> >> But further research revealed: >> # atacontrol mode acd0 0 /root >> current mode = PIO4 >> >> # atacontrol mode acd0 udma33 0 /root >> >> changed the load dramatically: >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND >> 12 root 1 171 ki31 0K 16K RUN 0 52:54 100.00% idle: cpu0 >> 11 root 1 171 ki31 0K 16K CPU1 1 23:36 94.29% idle: cpu1 >> 1087 kamikaze 3 -8 0 133M 36168K physrd 1 1:09 3.17% k3b >> 37 root 1 -64 - 0K 16K WAIT 1 30:10 0.00% irq14: ata0 >> >> >> Thank you very much! I used to think that UDMA33 was the default for >> CD-/DVD-Rom drives. I suppose I should review the BIOS settings or change >> something in the hints file. > > Wow, now I'm *really* surprised. I used to think that putting > > hw.ata.ata_dma="1" > hw.ata.atapi_dma="1" > > in /boot/loader.conf would be enough to enable DMA mode. In fact I'm > pretty sure it used to be in previous versions of FreeBSD. I created a > /etc/rc.local containing > > #!/bin/sh - > atacontrol mode acd0 udma33 > Did you check weather you are affected, before you applied your solution? Only one machine is affected. I put the following into my rc.conf: # Set mode for CD/DVD drive. /sbin/atacontrol mode acd0 2>&1 | /usr/bin/grep PIO > /dev/null 2>&1 \ && /sbin/atacontrol mode acd0 UDMA33 > Two questions, now: > > 1. Is this related to using atapicam? Not for me. > 2. Should this be considered a bug? Yes, but not in FreeBSD. It's a bug in the BIOS of my Notebook. This is a guess, not certainty.