From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 5 08:00:01 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98DD31065673 for ; Fri, 5 Aug 2011 08:00:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 2512F8FC0A for ; Fri, 5 Aug 2011 08:00:00 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p757xvSV058254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Aug 2011 10:59:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p757xvf0075090; Fri, 5 Aug 2011 10:59:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p757xv17075089; Fri, 5 Aug 2011 10:59:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 5 Aug 2011 10:59:57 +0300 From: Kostik Belousov To: Steven Hartland Message-ID: <20110805075957.GP17489@deviant.kiev.zoral.com.ua> References: <4CAD348034DD463E80C89DD5A0BDD71B@multiplay.co.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MRe2Ouhm04S76NDZ" Content-Disposition: inline In-Reply-To: <4CAD348034DD463E80C89DD5A0BDD71B@multiplay.co.uk> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org Subject: Re: cam / ata timeout limited to 2147 due to overflow bug? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 08:00:01 -0000 --MRe2Ouhm04S76NDZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 05, 2011 at 12:02:19AM +0100, Steven Hartland wrote: > I'm working on adding security methods to camcontrol and have > come up against a strange issue. It seems that the timeout > value for cam, at least on ata (ahci), is limited to less than > 2148 seconds. >=20 > This can be seen by running:- > camcontrol identify ada0 -t 2148 -v > (pass0:ahcich0:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 0= 0=20 > 00 > (pass0:ahcich0:0:0:0): CAM status: Command timeout >=20 > Also seen in /var/log/messages at this time is:- > Aug 4 23:29:51 cfdev kernel: ahcich0: Timeout on slot 24 > Aug 4 23:29:51 cfdev kernel: ahcich0: is 00000000 cs 01000000 ss 0000000= 0=20 > rs 01000000 tfd d0 serr 00000000 >=20 > Dropping the timeout down to 2147 and the command runs fine. >=20 > I've done some digging and it seems like this is implemented via:- > sys/dev/ahci/ahci.c > ahci_execute_transaction(struct ahci_slot *slot) > { > ... > /* Start command execution timeout */ > callout_reset(&slot->timeout, (int)ccb->ccb_h.timeout * hz / 2000, > (timeout_t*)ahci_timeout, slot); >=20 > Now its documented that:- > "Non-positive values of ticks are silently converted to the value 1" >=20 > So I suspect that this is what's happening resulting in an extremely > small timeout instead of a large one. Now I know that passed in value > to the timeout is seconds * 1000 so we should be seeing 2148000 > for ccb->ccb_h.timeout now multiply that by 1000 (hz) and your over > the int wrap point 2147483647. >=20 > So instead of the wrap point being 2147483 seconds (24 days), I suspect > because of the way this is structured its actually 2147 seconds (26mins). >=20 > If this is the case the fix is likely to be something like:- > callout_reset(&slot->timeout, (int)(ccb->ccb_h.timeout * (hz / 2000)), For hz =3D=3D 1000, hz / 2000 =3D=3D 0 according to the C rules, so the result will be 0 always. >=20 > Does this sound reasonable? What I don't understand is why the /2000? >=20 > For reference the reason for wanting a large timeout is that a > secure erase of large media could take many hours so I'm using > the erase time reported by the drive for this, in my case here is > 400 minutes. >=20 > Currently this instantly fails with a Command timeout which is > clearly not right. >=20 > Regards > Steve >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > This e.mail is private and confidential between Multiplay (UK) Ltd. and t= he=20 > person or entity to whom it is addressed. In the event of misdirection, t= he=20 > recipient is prohibited from using, copying, printing or otherwise=20 > disseminating it or any information contained in it.=20 > In the event of misdirection, illegible or incomplete transmission please= =20 > telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" --MRe2Ouhm04S76NDZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk47ovwACgkQC3+MBN1Mb4iaPQCfbbcO3Vu0DEBP7h7umwZoYXW7 ttIAoKgMITHEs0YyuHfeMaYQ08cTc4qX =0hCw -----END PGP SIGNATURE----- --MRe2Ouhm04S76NDZ--