From nobody Wed Apr 13 05:14:57 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 F22CF1B0BDDA for ; Wed, 13 Apr 2022 05:15:07 +0000 (UTC) (envelope-from maheshm_v@yahoo.com) Received: from sonic302-1.consmr.mail.bf2.yahoo.com (sonic302-1.consmr.mail.bf2.yahoo.com [74.6.135.40]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KdW4V5V2rz3hdn for ; Wed, 13 Apr 2022 05:15:06 +0000 (UTC) (envelope-from maheshm_v@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649826900; bh=KR48Lycv5Ps+6ssQTSXtwlN5JF1TrDkoFMrbUlhw3oI=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=kQZeDmyGXvzr9SnAux5yvRlqYGFXlq7dj3z1Iz85BysTGfyebEVpVvGYMZCwAmRkYIJ7zJ/oLlFp6xhwIw8qFDIFVIvNQ0z0lkq8+56LbUEkRn+trwG0Cg2O8e7n6FTpGeRanHoVRagPY3tfUmiSN5nvfBDEPljG64TGEuGSp7lFu+JnbSBtbanea9afHH4rfAf7hXH7SjXMt0aIHDP+QewnuVZKaJ11b4dlhUwVdU3vG38N7Y+GotqPEzqIqicegVNdgRvMMxnNsZN3qp7aHzAOe6Cpu6qvXNfsVvnJxg+/Qg5F7cNLuc7uIA7U0gEv8PSgoVyI5xCgEPXVQOxBjg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649826900; bh=VlU0aQ7C6gsS/4Gl8m9kVIYBr1tLTPA8YnJAq4BkNIn=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=YkjRprSB6XNb+SUzDbQt8Qt0klXHdi3MjtdmLsi7ERzgBl3uNtxHJ0zCZw8BUt5UwOs607V1VXR9DdO1WmHSfnSY1ZhBL/gVPO/GnRoawO9r4SnFRjafnigwZaJrUoyDUEl5T6Zo45uFCke2ppY64U5dwpWvUu27hJTiC9wJJvd7SZCbccwPltbnMT4hxMWQoUyxV8GFuNoFqXhNvF+B5XcApNmBu3xA35ycP4CJWpnssvn/2oZn8PQCKM3++KlFL//KRc49iFYrdBnSHFdC0ZwUYHkglrdoAZw6SOQzVBuBVEaXN9rOoFKSNv3Pvn1C62iAhHi5v4Vr1yC8KN/jxw== X-YMail-OSG: Z7J2WXUVM1nwi6ctlthX7zRSQAj71W.JlvQDU7dP2Hp3P8cUgDawfm3NF1FhKXH FShZ8CAf6T.AzFOBFgJwsLsfr1p.i1sD0SWTAQ8JGuWCjvtcg48C6q9JNcxRbYkERaO2xvljVqmM 6xWAHSyDH0JivMVtv3INwWHbCWYgBhVG0Uqm9utqOBpUbSvsHjJtpN_w7c2mvqG5.5bV4QgAxAJU Q0M2oojcq.UbhrqdtSZEAgEok.C6NlqAnrVTfWfBa47emhCX9lwgsjbXajNmNaLT.1TqIPJpIOTE wpBAGaOwNuwWcYXFrvBpfss2FbRxGB2IL2Ij55Vp.FJg8EZAA7Da4YQAZfwDe7nu8bUZwGQPSuTy WoNIkMF8t7kDJfGSmOKL5EXAylT4I2AuR6bJi5JomaUuxZWuddecNIGaFZdzUTHkpZ6BblBA4oRv 0ETm8Y97aODFilLiKh6yr2s3QEmanYmHEaoVykW53w2hbdKkb3S9xvbTqfy_rVR97zitZ.Phqr65 iJFT7Q_PQ7z15Ys3YanVolWt3MP337jUgCpRSzlgA2dBycJddrJFzoUSEudDvTS1.bWX.qxL.kdj z5du7avnGqycFqBLola6_Valh7VBMWjGFY9mPuB6eEUEwxl.Y1_tE_I7jJ2a9qiO9eOLCxSlcMcc mfSRMhc7LS5FR3zjMMHJso06nfetOiP5Z6htI2M8N7i.N_fnvV6JbRWbg_TN2t2_WrsZyS8osOOV dnF1kySi2xjIYk1h4FVkkGZn4vZxhe1q9.tN3i_muzmg0rO7OW5s8w4sdbqP4UqDFdF7B9GvCd7e GI82Jf.htfKSH38Dt1yitYbkkddhPaN_voQ6u.NHVk9SM02N2LLy5z6z0ctlgZv_9gkzhQ.4zF1y WzhdqTHcp_6OaU5TirVGiKowTOshHyuL5d1UoAx1FCiKRcNuEize6FlgptqOwtZfVpldnqf7_OXx srhIp2NCyDT9Mz122qTZldt6kAlmFAhqaRyzLP_9.2akSPuvdipSIIa1zu2K892W3jdalDOqP3pl 6dm4cAP4u6BtSZQ4uassGnkVlBbnHGUQM4yfRAP.86hCRBduu2F6bN1Ku13JFETlW47aWpjXmqxK dP.dt6AKicP3V4v957mPbKiiRwPNcfIBZt6mwHEgPl6lv8Uk5wrF0ycmuYXPhXsnCe6jFUtaZV7q AkGGHzpWiAs.Df2x.DLApaLWZFaWiNRdBSKIuYoaGmAuZ84l.vxMdIxU5n1icDFtZh79c2hOPTcI Up95zyTwVWnaLNnVw8qA0MthM2MIypyTGn.hqUdgz2tdQrfb6hg.o1vxR2HK0clJe1pIKmXDyv5b ooMIKFlVMQGk2cIgEyhrBZ4xROwFShbAayz1K1Z768g.6.IAtrAaamVBQnWxBz5NPwVOufQ_v6VK nrh6oMnZjiwgDp0cXBCkVG3cUPkZtoAa0kUHnSnsbvPX9tORXl7D5lxP.UKW6Y7cLTQKkMQyGngd .0vC7hIvHOsc31W0xLtZRii0GaLgVzVTlE_BQShqUw4CzcFvEDKsn8nDux30K0naRxO5wXQO09Ev L_PGHKrlmpMBmSNTLXeg5c0uM8QdfsyDH7zCT941Rp_95_VsTbIgvBfAXhg1bofYqHFuok.VnTM3 N_9CeO1ECem1IYbFXqU.MtFcYtxdYxPV87V.HnDFEM8DlrrYlfkLB1MJ9x4bnILTV4GpYs1O1diN EPijZJIUazUUsxC.oIMC2ridqOTetjrGEG904pOPsYSAzPN85WgejAIoiZP5FbwINb89nXEL2ie5 IkPgxOPlIlwOFd.MW74OrxHCaMlnXLf68V5e.UY9dFYSkize8VNHxGK7OE2Q8Uzoqnx1UEkZQbaZ yvZbe71cTTnEw4J3_6ZT5.7gy86jKEGLRtmk3GvyXxAogH5j8ZkZ8DHjCUkPCczMVjuGlEQBjo7D SxNRyffgKTgmaxRQXa78H_Ec4zC3CdNn1Ep6FTlomZWkuU5flAyUW394jW1fKxHhn3QO0zeuvz2O DhQMOlR4QWyYj.AQxp4dAgAGfnRmvb4PObNZ1jx72UTznHHUduPf6aRMsVeBEWamgsbYRKZYKaXW LmOJuW4eS_Nmponp4m1kMydt8rBEOsO5ppnmS3289E3xSWp_2w3mJ9hONoYauIiCTO_hEQfkRz6Y TBzWFOJsSRv1CL46oxrnJUH29dlRtmM_ifoNkDOiUW81RBBQsJp_czrNQ4QMl.z97jjOdZqLH5kg dEX4zV55RBQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Wed, 13 Apr 2022 05:15:00 +0000 Date: Wed, 13 Apr 2022 05:14:57 +0000 (UTC) From: mahesh mv To: Chris Cc: "freebsd-hackers@freebsd.org" Message-ID: <1601830847.251013.1649826897803@mail.yahoo.com> In-Reply-To: <5fefe57150f9efab867a775722b9d71b@bsdforge.com> References: <1524993805.98701.1649776236883.ref@mail.yahoo.com> <1524993805.98701.1649776236883@mail.yahoo.com> <5fefe57150f9efab867a775722b9d71b@bsdforge.com> Subject: Re: xhci USB transaction error and subsequent recovery mechanism on Freebsd stable/12 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 Content-Type: multipart/alternative; boundary="----=_Part_251012_182260728.1649826897801" X-Mailer: WebService/1.1.20001 YMailNorrin X-Rspamd-Queue-Id: 4KdW4V5V2rz3hdn X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=kQZeDmyG; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of maheshm_v@yahoo.com designates 74.6.135.40 as permitted sender) smtp.mailfrom=maheshm_v@yahoo.com X-Spamd-Result: default: False [-3.99 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.99)[-0.990]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:26101, ipnet:74.6.128.0/21, country:US]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[74.6.135.40:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RWL_MAILSPIKE_POSSIBLE(0.00)[74.6.135.40:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N ------=_Part_251012_182260728.1649826897801 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Thank you for the inputs. The drive is formatted as GPT with an ESP/UFS par= titions. Thanks,Mahesh On Wednesday, 13 April 2022, 02:57:45 GMT+5:30, Chris wrote: =20 =20 On 2022-04-12 08:10, mahesh mv wrote: > Hi all, >=20 > =C2=A0 >=20 > Need you help regarding an urgent issue where we are observing an issue w= ith > Freebsd stable/12. The DATA0/DATA1 are out of sync with respect to EP and= =20 > the > system experiences the >=20 > READ(10) errors. The READ(10) error recovers with in couple of retries mo= st=20 > of the > times but few cases we have observed that the read retries gets exhausted= =20 > and > =C2=A0system moves >=20 > to unusable state (continuous g_vfs_done() errors) . We are using Junos b= ut=20 > the > xhci driver etc.. are all pristine stable 12 drivers no Juniper specific= =20 > changes. > =C2=A0This issue was never observed with Linux kernel 5.4.2 on the same H= W. > =C2=A0Errors Seen on console >=20 > =C2=A0 >=20 > (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 28 cf 28 00 00 40 00 >=20 > (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error >=20 > (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain >=20 > (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 28 cf 28 00 00 40 00 >=20 > (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error >=20 > (da0:umass-sim0:0:0:0): Retrying command, 2 more tries remain >=20 > FreeBSD/arm (Amnesiac) (ttyu0) >=20 > login: >=20 > I can share the USB traces taken at the USB device if required. > Thanks,Mahesh I just replaced a drive 2 days ago that exhibited the same behavior. I=20 haven't (yet) checked the replaced drive yet for cause. But what I chose to do was as=20 follows. Get a new (known dependable) drive. Add it to the system and dump the data = on=20 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/G= PT=20 or ZFS? How you proceed after making a safe copy will depend on how you manage your= =20 disks. UFS/GPT?: simply remove the failing the disk, and change the entry in=20 fdtab(5) to point to the new disk. ZFS. It should be enough to simply replace the failing disk with one at lea= st=20 the size of the failing one and resilver. HTH --Chris =20 ------=_Part_251012_182260728.1649826897801 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Thank = you for the inputs. The drive is formatted as GPT with an ESP/UFS partition= s.

Thanks,
Ma= hesh


=20
=20
On Wednesday, 13 April 2022, 02:57:45 GMT+5:30, Chris &= lt;bsd-lists@bsdforge.com> wrote:


On 2022-04-12 08:10, mahesh mv wrote:=
> Hi all,
>
&= gt;  
>
> Need you help reg= arding an urgent issue where we are observing an issue with
> Freebsd stable/12. The DATA0/DATA1 are out of sync with respect to = EP and
> the
> system experience= s the
>
> READ(10) errors. The R= EAD(10) error recovers with in couple of retries most
&g= t; of the
> times but few cases we have observed that = the read retries gets exhausted
> and
>  system moves
>
> t= o unusable state (continuous g_vfs_done() errors) . We are using Junos but =
> the
> xhci driver etc.. are al= l pristine stable 12 drivers no Juniper specific
> ch= anges.
>  This issue was never observed with Linu= x kernel 5.4.2 on the same HW.
>  Errors Seen on = console
>
>  
>
> (da0:umass-sim0:0:0:0): READ(10). CDB: 28= 00 00 28 cf 28 00 00 40 00
>
> = (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
>
> (da0:umass-sim0:0:0:0): Retryin= g command, 3 more tries remain
>
&g= t; (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 28 cf 28 00 00 40 00
>
> (da0:umass-sim0:0:0:0): CAM sta= tus: CCB request completed with an error
>
> (da0:umass-sim0:0:0:0): Retrying command, 2 more tries remai= n
>
> FreeBSD/arm (Amnesiac) (tt= yu0)
>
> login:
>
> I can share the USB traces taken at the USB = device if required.
> Thanks,Mahesh
= I just replaced a drive 2 days ago that exhibited the same behavior. I
haven't (yet)
checked the replaced drive y= et 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.
Yo= u didn't say how the drive(s) are formatted/laid out. Are you using UFS/GPT=
or
ZFS?
How you pro= ceed 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 si= mply replace the failing disk with one at least

the

size of the failing one and resilver.

HTH

--Chris

=
------=_Part_251012_182260728.1649826897801--