Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp6339970ybn; Sun, 29 Sep 2019 18:02:51 -0700 (PDT) X-Google-Smtp-Source: APXvYqz4IDAni5QYkPlN0FI6v/a6780g5qdDMFcTk9DYdBzzaZC3cp1VIz4BZSdierIDmK2xVJ+b X-Received: by 2002:a50:d903:: with SMTP id t3mr16556851edj.117.1569805371556; Sun, 29 Sep 2019 18:02:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569805371; cv=none; d=google.com; s=arc-20160816; b=kNxhart2FTltjnd2Oq+pR3/er0/Rfg62LVTmcgeAHxdTfyQlljGLHY5jqr3rGdT/l8 sQSZbP5RiG8+8lEscaiXH1vpcnoFRB9DdMvdiNDhXy0QSsnOG+9+9GfiWJE1G7fp7XHm o+vrVYwRVM4ykFjKurQ3psVAxBFjWr2WY2+Vw1Ry/338Q9QMg6tbANjYhnR+r0e43c2Q EaipFKQAjKJzmTTuCpsoU5E0+GlFT4987qO6tRMpfA/tMFMjR2S8tCvrvGijCz5Sr54M y+hVcufVBfcYsLZNU9D+f30wN4zyrgi7Xm1uYr4dYFZOVmr15SvmSs6WYYmzXHDsy/Xy yUPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date; bh=0QuTKO2szPkxh23m6jCGPwI6LolX3YNYqubI/SwzBMM=; b=JIW/M9l9WmDIDDSco6cUJTbc8TZp9gJ4RB3apa+uPOZfzbYvyUoo4s9+nt/lFXrrmL ZUh9OM8Up2X8esvefHQwB5OGUmE0dSoDes68jTAO6Nger2CLF+AtPf2aRjiv+bQx+X2Z kg6hmtbcYa0OgT4s6OLsNiXvFke/DKgMVTwi01AwxQKx8tt9/D+0LR0ceR8OGi+ZK95N R3e07Wrg1vLW6BkCzvHajUUy8DJ6KXmi9KZ/UiuQJUMPTMpYjCQdGX7hBRiOuO4q9h7z rFKOGXlH5vJwrPzI5wW5ffP/tIxM8+PJd/dJ5a4t8HMOPODvHkvLjEHtXxEag7hfmTyA nEAg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i9si6011826ejy.106.2019.09.29.18.01.53; Sun, 29 Sep 2019 18:02:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729171AbfI3BBu (ORCPT + 99 others); Sun, 29 Sep 2019 21:01:50 -0400 Received: from netrider.rowland.org ([192.131.102.5]:48179 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1728853AbfI3BBu (ORCPT ); Sun, 29 Sep 2019 21:01:50 -0400 Received: (qmail 7255 invoked by uid 500); 29 Sep 2019 21:01:48 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 29 Sep 2019 21:01:48 -0400 Date: Sun, 29 Sep 2019 21:01:48 -0400 (EDT) From: Alan Stern X-X-Sender: stern@netrider.rowland.org To: Piergiorgio Sartor cc: Christoph Hellwig , Jens Axboe , USB list , , Kernel development list Subject: Re: reeze while write on external usb 3.0 hard disk [Bug 204095] In-Reply-To: <20190929201332.GA3099@lazy.lzy> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 29 Sep 2019, Piergiorgio Sartor wrote: > On Wed, Sep 25, 2019 at 02:31:58PM -0400, Alan Stern wrote: > > On Wed, 25 Sep 2019, Piergiorgio Sartor wrote: > > > > > On Mon, Aug 26, 2019 at 07:38:33PM +0200, Piergiorgio Sartor wrote: > > > > On Tue, Aug 20, 2019 at 06:37:22PM +0200, Piergiorgio Sartor wrote: > > > > > On Tue, Aug 20, 2019 at 09:23:26AM +0200, Christoph Hellwig wrote: > > > > > > On Mon, Aug 19, 2019 at 10:14:25AM -0400, Alan Stern wrote: > > > > > > > Let's bring this to the attention of some more people. > > > > > > > > > > > > > > It looks like the bug that was supposed to be fixed by commit > > > > > > > d74ffae8b8dd ("usb-storage: Add a limitation for > > > > > > > blk_queue_max_hw_sectors()"), which is part of 5.2.5, but apparently > > > > > > > the bug still occurs. > > > > > > > > > > > > Piergiorgio, > > > > > > > > > > > > can you dump the content of max_hw_sectors_kb file for your USB storage > > > > > > device and send that to this thread? > > > > > > > > > > Hi all, > > > > > > > > > > for both kernels, 5.1.20 (working) and 5.2.8 (not working), > > > > > the content of /sys/dev/x:y/queue/max_hw_sectors_kb is 512 > > > > > for USB storage devices (2.0 and 3.0). > > > > > > > > > > This is for the PC showing the issue. > > > > > > > > > > In an other PC, which does not show the issus at the moment, > > > > > the values are 120, for USB2.0, and 256, for USB3.0. > > One thing you can try is git bisect from 5.1.20 (or maybe just 5.1.0) > > to 5.2.8. If you can identify a particular commit which caused the > > problem to start, that would help. > > OK, I tried a bisect (2 days compilations...). > Assuming I've done everything correctly (how to > test this? How to remove the guilty patch?), this > was the result: > > 09324d32d2a0843e66652a087da6f77924358e62 is the first bad commit > commit 09324d32d2a0843e66652a087da6f77924358e62 > Author: Christoph Hellwig > Date: Tue May 21 09:01:41 2019 +0200 > > block: force an unlimited segment size on queues with a virt boundary > > We currently fail to update the front/back segment size in the bio when > deciding to allow an otherwise gappy segement to a device with a > virt boundary. The reason why this did not cause problems is that > devices with a virt boundary fundamentally don't use segments as we > know it and thus don't care. Make that assumption formal by forcing > an unlimited segement size in this case. > > Fixes: f6970f83ef79 ("block: don't check if adjacent bvecs in one bio can be mergeable") > Signed-off-by: Christoph Hellwig > Reviewed-by: Ming Lei > Reviewed-by: Hannes Reinecke > Signed-off-by: Jens Axboe > > :040000 040000 57ba04a02f948022c0f6ba24bfa36f3b565b2440 8c925f71ce75042529c001bf244b30565d19ebf3 M block > > What to do now? Here's how to verify that the bisection got a correct result. First, do a git checkout of commit 09324d32d2a0, build the kernel, and make sure that it exhibits the problem. Next, have git write out the contents of that commit in the form of a patch (git show commit-id >patchfile), and revert it (git apply -R patchfile). Build the kernel from that tree, and make sure that it does not exhibit the problem. If it doesn't, you have definitely shown that this commit is the cause (or at least, is _one_ of the causes). Alan Stern