From owner-freebsd-stable@FreeBSD.ORG Fri Feb 8 14:23:38 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 4DEE216A469 for ; Fri, 8 Feb 2008 14:23:38 +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 BE4C413C45B for ; Fri, 8 Feb 2008 14:23:36 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (vpn-cl-162-193.rz.uni-karlsruhe.de [141.3.162.193]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 9D234405478; Fri, 8 Feb 2008 15:25:30 +0100 (CET) Message-ID: <47AC65E5.8080604@bsdforen.de> Date: Fri, 08 Feb 2008 15:23:33 +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> <47ABF66E.4040807@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 14:23:38 -0000 Carlos A. M. dos Santos wrote: > On Feb 8, 2008 4:27 AM, Dominic Fandrey wrote: >> 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. > > Yes, it happens in my notebook (HP NX6320). > >> 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 > > Do not put this in rc.conf. It will be executed again each time a > script in /etc/rc.d source rc.conf to obtain the configuration > variables. Hence the check, weather the drive is in PIO mode or not. The way I understand the rc(8) manual page, the same is true for rc.local. > >>> 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. > > I believe that the kernel must handle this transparently when > hw.ata.atapi_dma is set to 1, but I will need to look at the code this > to see what is happening. I think it's the job of the BIOS to set this properly. Many BIOS allow you to choose the mode and FreeBSD obeys the settings made in the BIOS. To me that makes sense. It's a problem of HP that they do not allow to change the setting and have chosen such an ill fit default. Also you cannot just send everything into DMA mode, because all devices can have different capabilities. My preferred solution would be to have device hints for every device to override the BIOS settings.