From nobody Mon Feb 07 06:46:02 2022 X-Original-To: freebsd-current@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 C348919B931E for ; Mon, 7 Feb 2022 06:46:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jsc9f2gSwz3Mml for ; Mon, 7 Feb 2022 06:46:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x92c.google.com with SMTP id v5so10156934uam.3 for ; Sun, 06 Feb 2022 22:46:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2oV4X0QOefB3dAsmmBua09BzjfIQeCLRiWYGdLvrJ+o=; b=V7ZqSZgZfvnbwNWe5TUfyVYfKka3EKXuSpGEXm5/ROphp03f3ej/AtSLHKl6S93dHF L5lXkAX5cdXt21gx5sFDhGqigAFqCRGulg3ZaMtH5w+80a8Up0RxkSiJ38M+VdbFMbGL 6xpYULwTzhE/GNdc4DZR+7OwfjwxOOfy/UqlqmcQv0BI/AcfDknO8zGIq5HGVWOXw516 ZneyRTrafkIdRw9rG7xW2Zre7oUnNYAjZKkMUvUY5ldxSdupkkeubMpAucsOuXtzPyxw 6EbNqxG+eoXG1ua5V1KxLjXpqiNzntYllL7RsMF06H34e5i/I+aIx8ymhLR5frIMk78O Nx6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2oV4X0QOefB3dAsmmBua09BzjfIQeCLRiWYGdLvrJ+o=; b=7zXPzxcGD/0jFMVxX++j0wiyFq8dA4tZXPkb2ywHwlQrZzbI11Ymgi4uwb/JAVzUB0 NROwx44BXVztE4O9/pzIn9ECgm0FUvZtOLZNQ3TM62XW9H/JP5QYMpWwU27VM9jFYNfb szpo8ezYG8hsGPlNbQrA/SLTiF6fBnq0CZ4U6cDeC6eqIzE/j2B1pG6pUMVYoBWwrjw7 45W6ULyoCYPh8hIs206tJ890GCm/tC/qGfGLBSQYac1seh1IvakvVjyhcSsnyFg/kqp+ ZSRx3Fa5nOK3sKL0kq97GMHtz3BpEBumV9iNUvZliUklk+hlBWazFQf8l42l4yGrkTDW F/Ng== X-Gm-Message-State: AOAM531dCcZXracSaZS8pI0yKrYRqHtStb4z7mdpWvlyT4eYDCOv/RcE HT0ArilCMcCCuBMayvcj/cMcSrBfBWzQIHcqSk8DIw== X-Google-Smtp-Source: ABdhPJx9OC9rBtsqDwlgsA0W7rmYKJpTucfy4DrLX8kjyfSfqDAU8nXdNInIYaLL6NdCO2kx09j2ejMButOXNdKzMWw= X-Received: by 2002:a67:fc97:: with SMTP id x23mr4307415vsp.68.1644216373738; Sun, 06 Feb 2022 22:46:13 -0800 (PST) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <7e8459e4-d708-7750-402c-cda2adf6199f@freebsd.org> <60ebd011-c2b8-3524-1476-123f11128ffe@freebsd.org> In-Reply-To: From: Warner Losh Date: Sun, 6 Feb 2022 23:46:02 -0700 Message-ID: Subject: Re: USB Disk Stalls on -current To: grarpamp Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000e4180505d767f4a9" X-Rspamd-Queue-Id: 4Jsc9f2gSwz3Mml X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=V7ZqSZgZ; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::92c) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.48 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.48)[-0.481]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::92c:from]; BLOCKLISTDE_FAIL(0.00)[2607:f8b0:4864:20::92c:server fail]; MLMMJ_DEST(0.00)[freebsd-current]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; NEURAL_HAM_SHORT(-1.00)[-0.997]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --000000000000e4180505d767f4a9 Content-Type: text/plain; charset="UTF-8" On Sun, Feb 6, 2022 at 11:32 PM grarpamp 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


=
On Sun, Feb 6, 2022 at 11:32 PM grarp= amp <grarpamp@gmail.com> wr= ote:
> Feb=C2= =A0 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=C2=A0 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): CAM status:= CCB
> request completed with an error
> Feb=C2=A0 6 11:56:43 alice kernel: (da0:umass-sim1:1:0:0): Retrying co= mmand,
> 2 more tries remain

Isn't there mechanism for kernel/cam/driver to issue a
sense request to fetch and print the actual error...
<= br>
We do that, but since this is a timeout, there's no sense to
print (otherwise we'd print the sense he= re). We definitely report
those errors for = things like media error, etc.
=C2=A0 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<= /div>
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
ha= ve been known to glitch out under load (sometimes transparently
s= ometimes not).

Warner

--000000000000e4180505d767f4a9--