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>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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 [-- Attachment #2 --] <div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 6, 2022 at 11:32 PM grarpamp <<a href="mailto:grarpamp@gmail.com">grarpamp@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Feb 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 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): CAM status: CCB<br> > request completed with an error<br> > Feb 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): Retrying command,<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="gmail_quote">print (otherwise we'd print the sense here). We definitely report</div><div class="gmail_quote">those errors for things like media error, etc.<br></div><div class="gmail_quote"> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left: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><div>known to hiccup like this. And many USB bridge to SATA chips</div><div>have been known to glitch out under load (sometimes transparently</div><div>sometimes not).<br></div><div><br></div><div>Warner</div><div><br></div></div></div>help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfp62bbVNJ=VuD3VaOtPpVLPrMg9jaEha6tw33vfWXRDJA>