From owner-freebsd-current@FreeBSD.ORG Wed Jul 20 20:36:21 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 8ADAA10657AA; Wed, 20 Jul 2011 20:36:21 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from zimbra.averesystems.com (75-149-8-245-Pennsylvania.hfc.comcastbusiness.net [75.149.8.245]) by mx1.freebsd.org (Postfix) with ESMTP id 468568FC0C; Wed, 20 Jul 2011 20:36:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.averesystems.com (Postfix) with ESMTP id E22D28BC020; Wed, 20 Jul 2011 16:38:53 -0400 (EDT) X-Virus-Scanned: amavisd-new at averesystems.com Received: from zimbra.averesystems.com ([127.0.0.1]) by localhost (zimbra.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mEYwwxTmSWw; Wed, 20 Jul 2011 16:38:47 -0400 (EDT) Received: from [10.0.128.215] (fw.arriad.com [10.0.0.16]) by zimbra.averesystems.com (Postfix) with ESMTPSA id 05E9F8BC003; Wed, 20 Jul 2011 16:38:46 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Andrew Boyer In-Reply-To: <1DB50624F8348F48840F2E2CF6040A9D019060D246@orsmsx508.amr.corp.intel.com> Date: Wed, 20 Jul 2011 16:36:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1FCD1BDB-626E-41C7-BDC6-0FCAA56E7C76@averesystems.com> References: <1DB50624F8348F48840F2E2CF6040A9D019060D246@orsmsx508.amr.corp.intel.com> To: "Vogel, Jack" X-Mailer: Apple Mail (2.1084) Cc: "mav@freebsd.org" , "freebsd-current@freebsd.org" 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:36:21 -0000 Thank you for looking into it! I would really like to get Alexander's = feedback before it gets committed. -Andrew 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? >=20 > Jack >=20 >=20 > -----Original Message----- > From: Andrew Boyer [mailto:aboyer@averesystems.com]=20 > 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 >=20 > 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=3D0x01018f card=3D0x060d15d9 = chip=3D0x3a208086 rev=3D0x00 hdr=3D0x00 >> atapci1@pci0:0:31:5: class=3D0x010185 card=3D0x060d15d9 = chip=3D0x3a268086 rev=3D0x00 hdr=3D0x00 >=20 >> atapci0: port = 0xbff0-0xbff7,0xbf7c-0xbf7f,0xbfe0-0xbfe7,0xbef4-0xbef7,0xbfa0-0xbfaf,0xbf= 60-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=3D0x00 >> ata2: p0: SATA connect timeout status=3D00000000 >> ata2: p1: SATA connect timeout status=3D00000000 >> 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=3D0x08 >> ata3: p0: SATA connect timeout status=3D00000000 >> ata3: p1: SATA connect time=3D0ms status=3D00000123 >> ata3: reset tp1 mask=3D03 ostat0=3D7f ostat1=3D50 >> ata3: stat0=3D0x7f err=3D0x00 lsb=3D0xff msb=3D0xff >> ata3: stat1=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 >> ata3: reset tp2 stat0=3D7f stat1=3D50 devices=3D0x2 >> ata3: [MPSAFE] >> ata3: [ITHREAD] >=20 >=20 > 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. >=20 > 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. =20 >=20 > Thank you, > Andrew >=20 -------------------------------------------------- Andrew Boyer aboyer@averesystems.com