From owner-freebsd-current@freebsd.org Fri Aug 19 12:00:20 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63FFBBBF810 for ; Fri, 19 Aug 2016 12:00:20 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 35EE31BEF; Fri, 19 Aug 2016 12:00:19 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA18904; Fri, 19 Aug 2016 15:00:17 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1baiTA-000KkF-VA; Fri, 19 Aug 2016 15:00:16 +0300 Subject: Re: ahci timeout during boot on a particular mobo To: Alexander Motin , FreeBSD Current References: <4fed11f6-533d-4ec3-81ea-9d326dcb1f45@FreeBSD.org> <2a643c9d-db5b-5cb0-e429-8eadba4fea79@FreeBSD.org> From: Andriy Gapon Message-ID: Date: Fri, 19 Aug 2016 14:59:20 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <2a643c9d-db5b-5cb0-e429-8eadba4fea79@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 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, 19 Aug 2016 12:00:20 -0000 On 19/08/2016 14:06, Alexander Motin wrote: > On 19.08.16 11:30, Andriy Gapon wrote: >> So, what's suspicious here is that we discover two AHCI channels on the JMicron >> device and we seem to discover some sort of a device on one of them. But the >> communication with that (phantom?) device times out and that causes a very long >> delay during the boot. > > This fake device is the most interesting part. Marvell AHCI RAID chips > in such way expose RAID management device, but I doubt that JMicron is > so advanced, at least it seems like not implemented properly enough. > >> Is there a way to fix the boot delay? >> >> Searched for JMB361 in the source code, looked at some nearby device entries, >> and - is it as simple as adding AHCI_Q_1CH quick for this device? > > AHCI_Q_1CH quirk was added for early Marvell chips that were ever > dirtier mix of legacy ATA and AHCI, that reported total number of ports > instead of expected AHCI ones. May be JMB361 is also like that, but I > never had those check. JMB362 I have does not have this problem, > reporting two real SATA ports, even though it has one legacy PATA port > also. I don't have strong objections against this quirk. I am not sure > whether it is right solution, but suppose that in couple years nobody > will bother about that hardware at all. > Thank you for the reply! I found this bit of info about JMB361 http://www.clubedohardware.com.br/datasheets/JMB361.pdf and it confirms that the controller has a single SATA port. And JMB362 has two ports http://www.clubedohardware.com.br/datasheets/JMB361.pdf. Maybe the second port on JMB361 has some sort of a SATA-to-IDE adapter and perhaps it's that adapter that gets detected as a phantom device. -- Andriy Gapon