From nobody Wed Apr 13 05:56:48 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D42831AF5734 for ; Wed, 13 Apr 2022 05:57:49 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KdX1m754sz3p3q for ; Wed, 13 Apr 2022 05:57:48 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.16.1/8.16.1) with ESMTPS id 23D5vPaY039846 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Apr 2022 05:57:25 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: bsd-lists@bsdforge.com Received: from [10.58.0.11] (dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 23D5uw8t066852 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 13 Apr 2022 12:57:23 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: xhci USB transaction error and subsequent recovery mechanism on Freebsd stable/12 To: Chris , mahesh mv References: <1524993805.98701.1649776236883.ref@mail.yahoo.com> <1524993805.98701.1649776236883@mail.yahoo.com> <5fefe57150f9efab867a775722b9d71b@bsdforge.com> Cc: freebsd-hackers@freebsd.org From: Eugene Grosbein Message-ID: Date: Wed, 13 Apr 2022 12:56:48 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <5fefe57150f9efab867a775722b9d71b@bsdforge.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4KdX1m754sz3p3q X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-0.12 / 15.00]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all]; FREEFALL_USER(0.00)[eugen]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.39)[-0.393]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; NEURAL_SPAM_MEDIUM(0.26)[0.259]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.89)[-0.885]; MLMMJ_DEST(0.00)[freebsd-hackers]; FREEMAIL_TO(0.00)[bsdforge.com,yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 13.04.2022 4:26, Chris wrote: > I just replaced a drive 2 days ago that exhibited the same behavior. I haven't (yet) > checked the replaced drive yet for cause. But what I chose to do was as follows. > Get a new (known dependable) drive. Add it to the system and dump the data on the > failing disk to the new drive. At least you'll have a safe copy of it. > You didn't say how the drive(s) are formatted/laid out. Are you using UFS/GPT or > ZFS? > How you proceed after making a safe copy will depend on how you manage your disks. > UFS/GPT?: simply remove the failing the disk, and change the entry in fdtab(5) to > point to the new disk. > ZFS. It should be enough to simply replace the failing disk with one at least the > size of the failing one and resilver. Similar to ZFS case, it is possible to make the kernel to "resilver" non-ZFS disk by temporary creating non-persistent block-level mirror with "gmirror create" command. It will not create any "labels" on-disk but perform copying of contents similar to "dd" command but in more efficient way: no data transfer from kernel land to user land and back, also it uses MAXPHYS blocks to read/write media efficiently. Also, it would copy partition tables (and bootloaders, if any) of all kinds.