Date: Sun, 6 Feb 2022 23:46:02 -0700 From: Warner Losh <imp@bsdimp.com> To: grarpamp <grarpamp@gmail.com> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: USB Disk Stalls on -current Message-ID: <CANCZdfp62bbVNJ=VuD3VaOtPpVLPrMg9jaEha6tw33vfWXRDJA@mail.gmail.com> In-Reply-To: <CAD2Ti2_WP8y9tADUYjH5PykPm8oJyqRjrj-%2Bk_xHU99kFbWNxw@mail.gmail.com> References: <7e8459e4-d708-7750-402c-cda2adf6199f@freebsd.org> <CANCZdfqG-%2B9dfFz-%2BeezZaqbPQN5-mQpw%2B214CkiKC%2B_kmW2ig@mail.gmail.com> <60ebd011-c2b8-3524-1476-123f11128ffe@freebsd.org> <CAD2Ti2_WP8y9tADUYjH5PykPm8oJyqRjrj-%2Bk_xHU99kFbWNxw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000e4180505d767f4a9 Content-Type: text/plain; charset="UTF-8" On Sun, Feb 6, 2022 at 11:32 PM grarpamp <grarpamp@gmail.com> wrote: > > Feb 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): READ(10). CDB: 28 > > 00 36 69 02 6e 00 00 80 00 > > Feb 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): CAM status: CCB > > request completed with an error > > Feb 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): Retrying command, > > 2 more tries remain > > Isn't there mechanism for kernel/cam/driver to issue a > sense request to fetch and print the actual error... > We do that, but since this is a timeout, there's no sense to print (otherwise we'd print the sense here). We definitely report those errors for things like media error, etc. > > assuming, which is fine, that the bus or devices aren't > already locked up, in reset, etc such that a sense > would go unfulfilled or already be cleared. > I'm pretty sure the problem here is that the disks are timing out for some reason. Many USB drives are designed for occasional use, and often have aggressive power saving modes, which are known to hiccup like this. And many USB bridge to SATA chips have been known to glitch out under load (sometimes transparently sometimes not). Warner --000000000000e4180505d767f4a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Sun, Feb 6, 2022 at 11:32 PM grarp= amp <<a href=3D"mailto:grarpamp@gmail.com">grarpamp@gmail.com</a>> wr= ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px= 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Feb=C2= =A0 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): READ(10). CDB: 28<br> > 00 36 69 02 6e 00 00 80 00<br> > Feb=C2=A0 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): CAM status:= CCB<br> > request completed with an error<br> > Feb=C2=A0 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): Retrying co= mmand,<br> > 2 more tries remain<br> <br> Isn't there mechanism for kernel/cam/driver to issue a<br> sense request to fetch and print the actual error...<br></blockquote><div><= br></div>We do that, but since this is a timeout, there's no sense to</= div><div class=3D"gmail_quote">print (otherwise we'd print the sense he= re). We definitely report</div><div class=3D"gmail_quote">those errors for = things like media error, etc.<br></div><div class=3D"gmail_quote">=C2=A0<bl= ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef= t:1px solid rgb(204,204,204);padding-left:1ex"> assuming, which is fine, that the bus or devices aren't<br> already locked up, in reset, etc such that a sense<br> would go unfulfilled or already be cleared.<br></blockquote><div><br></div>= <div>I'm pretty sure the problem here is that the disks are timing out<= /div><div>for some reason. Many USB drives are designed for occasional</div= ><div>use, and often have aggressive power saving modes, which are</div><di= v>known to hiccup like this. And many USB bridge to SATA chips</div><div>ha= ve been known to glitch out under load (sometimes transparently</div><div>s= ometimes not).<br></div><div><br></div><div>Warner</div><div><br></div></di= v></div> --000000000000e4180505d767f4a9--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfp62bbVNJ=VuD3VaOtPpVLPrMg9jaEha6tw33vfWXRDJA>