Date: Fri, 19 Aug 2016 14:06:20 +0300 From: Alexander Motin <mav@FreeBSD.org> To: Andriy Gapon <avg@FreeBSD.org>, FreeBSD Current <freebsd-current@FreeBSD.org> Subject: Re: ahci timeout during boot on a particular mobo Message-ID: <2a643c9d-db5b-5cb0-e429-8eadba4fea79@FreeBSD.org> In-Reply-To: <4fed11f6-533d-4ec3-81ea-9d326dcb1f45@FreeBSD.org> References: <4fed11f6-533d-4ec3-81ea-9d326dcb1f45@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2a643c9d-db5b-5cb0-e429-8eadba4fea79>