From owner-freebsd-current@FreeBSD.ORG Fri Jan 29 20:07:14 2010 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 227C51065670 for ; Fri, 29 Jan 2010 20:07:14 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 9ED918FC15 for ; Fri, 29 Jan 2010 20:07:13 +0000 (UTC) Received: by fxm27 with SMTP id 27so690451fxm.3 for ; Fri, 29 Jan 2010 12:07:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received: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=r6A/lih7SlgyuO8sMFuxAy8mTWEb0DCSbAnsyp0fGuA=; b=vr/4tRtd1ZbBgn8Ud6nhydgFr9yAGlea5Pjd2AO9gXNJGdonUyyKXVS0PmT1Y/brCW mEzNzJa9m8G1v8o8j90aF4KWBQKMlfiwkHNUOtaXeimYfM8F2XgdbF3X+LSrsr+IDpUw R+03IX6s2LqYz6y1d1HOXsFKN87OnU8FJZ/9o= 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=l8ImtGTEdJn1Y69MiDBaYxIJx7VlcuHn95m2nEWz3o104bvPbJrRlEQP2T1FTErR5Y Xpj1xamwBUHjAyFVzFn1sI8UyVPOmRzsfr6bX7/ht/+ANGdcy2/+90raJdnjjbAEg910 XFY/0dewrCKXV2fMY6Ra9W3gFBzuNtPlCLAbE= Received: by 10.102.222.7 with SMTP id u7mr726461mug.1.1264795632457; Fri, 29 Jan 2010 12:07:12 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id j10sm7056781mue.0.2010.01.29.12.07.11 (version=SSLv3 cipher=RC4-MD5); Fri, 29 Jan 2010 12:07:11 -0800 (PST) Sender: Alexander Motin Message-ID: <4B633FED.3030103@FreeBSD.org> Date: Fri, 29 Jan 2010 22:07:09 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Juergen Lock References: <4B55D9D4.1000008@FreeBSD.org> <4B61C688.2050609@FreeBSD.org> <4B61CCB6.4040005@FreeBSD.org> <4B62C97F.7080000@FreeBSD.org> <4B62EDFB.1060103@icyb.net.ua> <201001291949.o0TJnCAa013981@triton8.kn-bremen.de> In-Reply-To: <201001291949.o0TJnCAa013981@triton8.kn-bremen.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Andriy Gapon , Yamagi Burmeister Subject: Re: Pack of CAM improvements 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: Fri, 29 Jan 2010 20:07:14 -0000 Juergen Lock wrote: > Ok while we are talking about ahci(4) on IXP700... Can anyone reproduce > the `test unit ready' bug on one of those? Since I saw no reply to > my post, > http://docs.freebsd.org/cgi/mid.cgi?201001231407.o0NE7l8j002620 > maybe the bug is controller-specific? How to reproduce: just try > camcontrol tur adaX > or > cdrecord -scanbus > or (at least I think this is the same issue) start xfburn without hal > running, then watch for the bus to hang at the next disk access. > (Also leaving the disk led on solid here.) With the previous patch, > http://people.freebsd.org/~mav/cam-ata.20100119.patch > (haven't tested the latest one yet) at least it now seems to recover > after some timeout, leaving this in dmesg: (sorry I didn't notice > when I first tried, guess I didn't wait long enough...) It is controller specific. Intel and NVidia controllers just return error immediately, as they should, and continue operation. ATI IXP700 - doesn't: > ahcich2: Timeout on slot 20 > ahcich2: is 04000000 cs 00100000 ss 00100000 rs 00100000 tfd 451 serr 00400000 > ahcich2: AHCI reset... > ahcich2: hardware reset ... > ahcich2: SATA connect time=0ms status=00000123 > ahcich2: ready wait time=11ms > ahcich2: AHCI reset done: device found > (ada1:ahcich2:0:0:0): Command timed out > (ada1:ahcich2:0:0:0): Retrying Command But after command timeout channel should reset and continue operation. I've tried to handle this situation, but haven't found a good way. But it is possible to just avoid this situation. As soon as CAM will any way need to tell SIM ATAPI CDB length supported by device, it will be easy for SIM to not send ATAPI commands to ATA devices. I am going to do it, as soon as more important things will stabilize. -- Alexander Motin