From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 20:45:11 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 B5A88106566C for ; Wed, 20 Jul 2011 20:45:11 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3C80C8FC0C for ; Wed, 20 Jul 2011 20:45:10 +0000 (UTC) Received: by ewy1 with SMTP id 1so1135510ewy.13 for ; Wed, 20 Jul 2011 13:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ABRP3gBuN8H9gDEQCAUm2wg1xQhQ+KSBH5VN8PydL4o=; b=SNbIJckbeeBLcfPCyEvmjXm4FuKzT1PnvWxV18V279TK8e8Q7nVSziWqgD/kFB5qSH CMupUeAn+JA/rvGTiuP8YQovtfySmg63S5f6t6yUPt5mASMkdZwAfNhe6DE1UjPL9Tww 7/1/xlJWVoophHMmV8c63TvwJaxwITAzOABx8= Received: by 10.204.7.201 with SMTP id e9mr2607544bke.126.1311194709921; Wed, 20 Jul 2011 13:45:09 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id q1sm4063244faa.1.2011.07.20.13.45.08 (version=SSLv3 cipher=OTHER); Wed, 20 Jul 2011 13:45:08 -0700 (PDT) Sender: Alexander Motin Message-ID: <4E273E46.5070507@FreeBSD.org> Date: Wed, 20 Jul 2011 23:44:54 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110310 Thunderbird/3.1.9 MIME-Version: 1.0 To: Andrew Boyer References: <1DB50624F8348F48840F2E2CF6040A9D019060D246@orsmsx508.amr.corp.intel.com> <1FCD1BDB-626E-41C7-BDC6-0FCAA56E7C76@averesystems.com> In-Reply-To: <1FCD1BDB-626E-41C7-BDC6-0FCAA56E7C76@averesystems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" , "Vogel, Jack" Subject: Re: [patch] Intel SATA controller hiccups, locking 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: Wed, 20 Jul 2011 20:45:11 -0000 On 20.07.2011 23:36, Andrew Boyer wrote: > Thank you for looking into it! I would really like to get Alexander's feedback before it gets committed. Generally it looks good, but I would tune few minor places. I'll look on it closer tomorrow. Thank you. > On Jul 20, 2011, at 4:18 PM, Vogel, Jack wrote: > >> Ran it by the chipset contact internally and he said go for it, you need me to check it in Andrew? >> >> -----Original Message----- >> From: Andrew Boyer [mailto:aboyer@averesystems.com] >> Sent: Wednesday, July 20, 2011 7:45 AM >> To: mav@freebsd.org >> Cc: freebsd-current@freebsd.org; Vogel, Jack >> Subject: [patch] Intel SATA controller hiccups, locking >> >> Hello Alexander, >> I am using the latest ata driver from stable/8 on a system with an Intel ICH10 controller. ATA_CAM and ATA_STATIC_ID are both off. There is one drive connected to port 3. SATA is set to Enhanced / IDE mode (not AHCI) in the BIOS. >>> atapci0@pci0:0:31:2: class=0x01018f card=0x060d15d9 chip=0x3a208086 rev=0x00 hdr=0x00 >>> atapci1@pci0:0:31:5: class=0x010185 card=0x060d15d9 chip=0x3a268086 rev=0x00 hdr=0x00 >> >>> atapci0: port 0xbff0-0xbff7,0xbf7c-0xbf7f,0xbfe0-0xbfe7,0xbef4-0xbef7,0xbfa0-0xbfaf,0xbf60-0xbf6f irq 19 at device 31.2 on pci0 >>> atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xbfa0 >>> atapci0: [MPSAFE] >>> atapci0: [ITHREAD] >>> atapci0: Reserved 0x10 bytes for rid 0x24 type 4 at 0xbf60 >>> ata2: on atapci0 >>> atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0xbff0 >>> atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbf7c >>> ata2: SATA reset: ports status=0x00 >>> ata2: p0: SATA connect timeout status=00000000 >>> ata2: p1: SATA connect timeout status=00000000 >>> ata2: [MPSAFE] >>> ata2: [ITHREAD] >>> ata3: on atapci0 >>> atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xbfe0 >>> atapci0: Reserved 0x4 bytes for rid 0x1c type 4 at 0xbef4 >>> ata3: SATA reset: ports status=0x08 >>> ata3: p0: SATA connect timeout status=00000000 >>> ata3: p1: SATA connect time=0ms status=00000123 >>> ata3: reset tp1 mask=03 ostat0=7f ostat1=50 >>> ata3: stat0=0x7f err=0x00 lsb=0xff msb=0xff >>> ata3: stat1=0x50 err=0x01 lsb=0x00 msb=0x00 >>> ata3: reset tp2 stat0=7f stat1=50 devices=0x2 >>> ata3: [MPSAFE] >>> ata3: [ITHREAD] >> >> >> When under heavy load, the 'atacontrol mode ad0' command sometimes fails to determine the SATA speed; the drive appears to be missing. I think the root cause is that chipsets/ata-intel.c does not do any locking on the ata_intel_sata_sidpr_* routines. The (write address register) + (access data register) model isn't safe without locking because two channels share the registers. The ata_intel_sata_cscr_* routines have the same problem. >> >> Adding a mutex to a structure stored in ctlr->chipset_data makes the hiccups go away; see the attached patch. Please advise if this is something you would like to fix. -- Alexander Motin