From owner-freebsd-stable@freebsd.org Tue Feb 25 15:04:17 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 88DC425DC59 for ; Tue, 25 Feb 2020 15:04:17 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.70]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48RhzN2XgNz4Krh for ; Tue, 25 Feb 2020 15:04:16 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from pmather-dld-1.lib.vt.edu (pmather-dld-1.lib.vt.edu [128.173.51.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 453A9AD9C; Tue, 25 Feb 2020 10:04:07 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: Running FreeBSD on M.2 SSD From: Paul Mather In-Reply-To: <0936F546-2839-4190-88A1-A7D2BADBB210@digsys.bg> Date: Tue, 25 Feb 2020 10:04:07 -0500 Cc: Mario Olofo , Mark Millard via freebsd-stable Content-Transfer-Encoding: quoted-printable Message-Id: <1D2EB492-F287-40B3-A52C-C1A464C7C3C3@gromit.dlib.vt.edu> References: <202002250115.01P1F9KX090465@mail.karels.net> <188F34DA-192C-4D44-96B5-18A7DAE8EC67@digsys.bg> <6028c786-8610-01d9-818e-6f69a2fe9645@ingresso.co.uk> <0936F546-2839-4190-88A1-A7D2BADBB210@digsys.bg> To: Daniel Kalchev X-Mailer: Apple Mail (2.3445.104.11) X-Rspamd-Queue-Id: 48RhzN2XgNz4Krh X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=vt.edu (policy=none); spf=none (mx1.freebsd.org: domain of paul@gromit.dlib.vt.edu has no SPF policy when checking 128.173.49.70) smtp.mailfrom=paul@gromit.dlib.vt.edu X-Spamd-Result: default: False [-2.01 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[vt.edu : No valid SPF, No valid DKIM,none]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; IP_SCORE(-0.52)[ip: (-1.31), ipnet: 128.173.0.0/16(-0.65), asn: 1312(-0.58), country: US(-0.05)]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.992,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1312, ipnet:128.173.0.0/16, country:US]; FREEMAIL_CC(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 15:04:17 -0000 On Feb 25, 2020, at 9:03 AM, Daniel Kalchev wrote: > FreeBSD does not technically have driver for different disks. People = asked whether it is an NVMe device or SATA device, because those = interfaces have different drivers. >=20 > But for FreeBSD, an mechanical SATA, hybrid SATA or SSD SATA will use = exactly the same SATA driver. It depends on the chipset. >=20 > It is possible however, that the timing between the drive and the SATA = controller might be different and that is causing the problem. In a similar vein, I had an old MacBook Pro 2011 model. Its SATA = chipset would negotiate SATA III speeds but any disk I/O at that speed = would soon lead to widespread data corruption. SATA II drives and = slower would be fine: no corruption. The funny thing was that this wasn't an issue when I used earlier = versions of macOS: the problem only seemed to manifest when I "upgraded" = to Mojave (IIRC). I surmised that maybe at that time period, whatever = quirks or workarounds in the earlier OS versions no longer applied, and = so whatever had caused the SATA III replacement drive to work (e.g., by = force-negotiating at the slower speed) no longer did. :-( So, maybe a quirk/workaround that is in Linux and Windows but not in = FreeBSD for you hardware *might* be a possibility? Cheers, Paul.