From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 06:44:25 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2606106564A; Mon, 11 Apr 2011 06:44:25 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id A3D6F8FC18; Mon, 11 Apr 2011 06:44:24 +0000 (UTC) Received: by bwz12 with SMTP id 12so5497436bwz.13 for ; Sun, 10 Apr 2011 23:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=nMN585lCtONI+mcTgwDbhuSTBdHhSt41BK2knSHyINg=; b=WuYn5pV4WYTTFn0P/ryKrDhVsGCyMgajaqFDIcxzCreStmWUtowX+358h9LwDtZ2VV GQ+oxSeuY70NmkWPnBPTIWnhYMJfbNryP/SR8YxTGSn6WmvBVDfQdL8K6LP9O/M4Y7gW A+q5cjLK0GMw9mQ8WKmnT4q/TJagK3h4Wf+1s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=UO7Q1Low/AKnqb2rvZtJ9tPcaVpKk+yhg4SmNaYjI1kdsRyW61AFev7jnhMqI39c+T qLhCZZKMng1GlbKj6mAG+fJx1llkCuD0jT8gRBL6nqYBzBLFs5qrVtSVM1qNiCOEBJWs lhyS9LvwG2+lrJnqP7zlfSI0jpbmMMkXwoQ5o= Received: by 10.204.81.27 with SMTP id v27mr4518536bkk.115.1302504263042; Sun, 10 Apr 2011 23:44:23 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id x6sm3008062bkv.12.2011.04.10.23.44.21 (version=SSLv3 cipher=OTHER); Sun, 10 Apr 2011 23:44:22 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DA2A33B.8010807@FreeBSD.org> Date: Mon, 11 Apr 2011 09:44:11 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Alexander Best References: <20110331223339.GA13682@freebsd.org> <201104010843.47367.jhb@freebsd.org> <20110404204316.GA11367@freebsd.org> <4D9D9917.3030102@FreeBSD.org> <20110410115644.GA55815@freebsd.org> <4DA210D3.5090807@FreeBSD.org> <20110411025646.GA46088@freebsd.org> In-Reply-To: <20110411025646.GA46088@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org Subject: Re: multiple issues with devstat_*(9) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Mon, 11 Apr 2011 06:44:26 -0000 Alexander Best wrote: > On Sun Apr 10 11, Alexander Motin wrote: >> Alexander Best wrote: >>> On Thu Apr 7 11, Alexander Motin wrote: >>>> Assuming that SCSI and IDE in -t option means transport type, and >>>> assuming that we count everything except ATA and SATA as SCSI, I've made >>>> following patch, that should fix issues from the CAM side: >>>> http://people.freebsd.org/~mav/cam.devstat.patch >>> with your patch i get the following output: >>> >>> otaku% iostat -t ide >>> tty ada0 ada1 cpu >>> tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id >>> 6 144 14.21 6 0.09 20.46 40 0.81 2 0 3 0 95 >>> otaku% iostat -t scsi >>> tty cd0 cpu >>> tin tout KB/t tps MB/s us ni sy in id >>> 6 146 2.32 0 0.00 2 0 3 0 95 >>> otaku% iostat -t pass >>> tty pass0 pass1 pass2 cpu >>> tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id >>> 6 147 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 2 0 3 0 95 >>> otaku% iostat -t da >>> tty ada0 ada1 cpu >>> tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id >>> 6 147 14.21 6 0.08 20.46 37 0.75 1 0 3 0 95 >>> otaku% iostat -t cd >>> tty cd0 cpu >>> tin tout KB/t tps MB/s us ni sy in id >>> 7 147 2.32 0 0.00 1 0 3 0 95 >>> otaku% iostat -t other >>> tty cpu >>> tin tout us ni sy in id >>> 7 149 1 0 3 0 95 >>> otaku% iostat -n 100 >>> tty ada0 ada1 cd0 pass0 pass1 pass2 cpu >>> tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id >>> 6 135 14.21 5 0.07 20.44 32 0.64 2.32 0 0.00 0.36 0 0.00 0.36 0 0.00 0.00 0 0.00 1 0 3 0 96 >>> >>> the the remaining issues imho are: >>> >>> 1) ada* and cd* are SATA/ATA devices. so i think they should show up together >>> either under ide *or* scsi. i don't have any *real* scsi devices. >> I've just retested the patch and haven't reproduced your problem: >> %iostat -d >> da0 ada0 da1 cd0 >> KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s >> 0.01 0 0.00 3.27 1 0.00 2.65 1 0.00 0.00 0 0.00 >> %iostat -d -t ide >> da0 ada0 cd0 >> KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s >> 0.01 0 0.00 3.27 1 0.00 0.00 0 0.00 >> %iostat -d -t scsi >> da1 >> KB/t tps MB/s >> 2.65 1 0.00 >> %iostat -d -t pass >> pass0 pass1 pass2 pass3 >> KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s >> 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 >> %iostat -d -t ide,pass >> pass0 pass1 pass2 >> KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s >> 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 >> %iostat -d -t scsi,pass >> pass3 >> KB/t tps MB/s >> 0.00 0 0.00 >> >> da0 is an PATA ATAPI ZIP, da1 - USB floppy, ada0 - SATA HDD, cd0 - PATA >> ATAPI CD-ROM. >> >> Just an idea, aren't you are using legacy ata(4) + atapicam for your >> cd0? atapicam lies that it's buses are SPI (SCSI). > > my cd0 is a pata atapi dvdrom drive and i have the following in my kernel conf: > > device atacore > device ahci > device atajmicron > device atapci > #device atapicd > device atapicam > > device umass > device scbus > device cd > device pass > device da > device random > device pty > device md > > the dmesg entries for cd0 are: > > cam_periph_alloc: attempt to re-allocate valid device cd0 rejected > cdasync: Unable to attach new device due to status 0x6 > cd0 at ata2 bus 0 scbus8 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device > cd0: 3.300MB/s transfers > cd0: cd present [2149024 x 2048 byte records] Aha, that's it. It is atapicam's lie. atapicam is one of a things that will go away during migration to CAM ATA. If you remove `device atapicam`, but add `options ATA_CAM` instead, CAM will manage that bus directly and report it as ATA. -- Alexander Motin