linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrea Vai <andrea.vai@unipv.it>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg KH <gregkh@linuxfoundation.org>, linux-usb@vger.kernel.org
Subject: Re: Slow I/O on USB media
Date: Mon, 01 Jul 2019 19:52:22 +0200	[thread overview]
Message-ID: <3e7662d1391346dd11a903e66e7a8936ca83dba9.camel@unipv.it> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1906171259500.1738-100000@iolanthe.rowland.org>

Il giorno lun, 17/06/2019 alle 13.28 -0400, Alan Stern ha scritto:
> On Mon, 17 Jun 2019, Andrea Vai wrote:
> 
> > Il giorno lun, 17/06/2019 alle 12.14 -0400, Alan Stern ha scritto:
> > > On Mon, 17 Jun 2019, Andrea Vai wrote:
> > > 
> > > > [...]
> > > > 
> > > > That happened ALL times, so I never encountered a kernel that
> made
> > > me
> > > > say "git bisect good".
> > > 
> > > Really?  That strongly suggests that the 4.20 kernel also should
> > > have
> > > been marked bad.  Did you really test it exactly the same way as
> all
> > > the others?  That is, did you go through the entire procedure
> > > starting
> > > with "git checkout v4.20", then running the build script, then
> the
> > > reboot and "uname -a", and then the test script?
> > 
> > well, honestly, no, because (sigh) I didn't know the "git
> checkout"
> > command, sorry. I started with building 4.20 from the source
> > downloaded with
> > 
> >  wget 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/snapshot/linux-4.20.tar.gz
> > 
> > , then said "git bisect good v4.20".
> > 
> > Is this different from "git checkout v4.20"? I hope it is, so we
> have
> > found the mistake I have done.
> 
> In theory the results should be exactly the same.  But it doesn't
> hurt 
> to check.
> 
> > > Compare the mainstream 4.20 kernel with the Fedora 4.20.13
> kernel.  
> > > Also, maybe compare the mainstream 4.20.13 with Fedora's
> 4.20.13.
> > 
> > Sorry, what do you mean here by "compare"? And what is the
> > "mainstream"? If the mainstream is the one I got with wget, and if
> > "compare" means "see if they behave differently", so I have
> already
> > done it and they are both "good".
> 
> I was trying to point out that there may be a significant difference
> between 4.20 and 4.20.13.  But if you say 4.20 behaves well, this 
> doesn't matter.
> 
> At any rate, you are some commits you could try (beginning with
> "git 
> checkout <commit>" and then running your scripts):
> 
>         c76cd634eb5b
>         b1669432b355
>         507413a5f88a
>         a52fb43a5faa
>         38fabca18fc4
>         fc2fd5f0f1aa
> 
> These are all between 4.20 and 5.0-rc1.

Hi,
  these were all "good".

Then I ran another bisect (the sixth (!), more carefully, starting
from

git bisect good c76cd634eb5b
git bisect bad 241e39004581

), and it seems to give some consistent result.

I found that:

f664a3cc17b7d0a2bc3b3ab96181e1029b0ec0e6 is the first bad commit
commit f664a3cc17b7d0a2bc3b3ab96181e1029b0ec0e6
Author: Jens Axboe <axboe@kernel.dk>
Date:   Thu Nov 1 16:36:27 2018 -0600

    scsi: kill off the legacy IO path
    
    This removes the legacy (non-mq) IO path for SCSI.
    
    Cc: linux-scsi@vger.kernel.org
    Acked-by: Himanshu Madhani <himanshu.madhani@cavium.com>
    Reviewed-by: Hannes Reinecke <hare@suse.com>
    Tested-by: Ming Lei <ming.lei@redhat.com>
    Reviewed-by: Omar Sandoval <osandov@fb.com>
    Acked-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>

:040000 040000 312373927bae1c6fd1da40ded2c12dfa5e4de71c 4eccbd2c84bf83cb2eb72a81514d59ebf12866b7 M	Documentation
:040000 040000 98de24b4fe20b82095f53f56c9193c5537d70ed0 8e2092780100205ae1c3723a598a89794a50677f M	drivers
:040000 040000 fbc10c84d3eb6b7933598018319f96767ee3a0f3 2523940c2819e8adb32758f5093e477da481ca65 M	include

I reverted it and the test succeeded.
Then I made a double check: "git clone" again; git checkout
3a7ea2c483a53fc89e336f69c6ee1d7defe00811 (the last good), and the test
succeded. Then git checkout f664a3cc17b7d0a2bc3b3ab96181e1029b0ec0e6
(the first bad) and the test failed; then reverted it and the test
succeded again.

Does it make sense?

Thanks,
Andrea


  reply	other threads:[~2019-07-01 17:52 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-30 13:18 Slow I/O on USB media Andrea Vai
2019-05-30 13:25 ` Greg KH
2019-06-03 11:13   ` Andrea Vai
2019-06-04  5:43     ` Greg KH
2019-06-04  7:26       ` Andrea Vai
2019-06-05  7:36       ` Andrea Vai
2019-06-05 14:26         ` Alan Stern
2019-06-05 15:46           ` Andrea Vai
2019-06-05 16:11             ` Alan Stern
2019-06-05 14:55         ` Greg KH
     [not found]           ` <0c2adde7154b0a6c8b2ad7fc5258916731b78775.camel@unipv.it>
2019-06-05 16:23             ` Andrea Vai
2019-06-05 17:39               ` Greg KH
2019-06-06  8:41                 ` Andrea Vai
2019-06-06  9:03                 ` Andrea Vai
2019-06-06 14:00                 ` Andrea Vai
2019-06-06 14:30                   ` Alan Stern
2019-06-06 14:47                   ` Greg KH
2019-06-07  7:59                     ` Andrea Vai
2019-06-08  7:43                     ` Andrea Vai
2019-06-08  9:29                       ` Andrea Vai
2019-06-10 14:38                         ` Greg KH
2019-06-11  6:48                           ` Andrea Vai
2019-06-10 14:40                         ` Alan Stern
2019-06-10 14:55                           ` Andrea Vai
2019-06-10 16:20                             ` Alan Stern
2019-06-17 15:52                           ` Andrea Vai
2019-06-17 16:14                             ` Alan Stern
2019-06-17 16:34                               ` Andrea Vai
2019-06-17 17:28                                 ` Alan Stern
2019-07-01 17:52                                   ` Andrea Vai [this message]
2019-07-01 18:57                                     ` Alan Stern
2019-06-10 14:37                       ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3e7662d1391346dd11a903e66e7a8936ca83dba9.camel@unipv.it \
    --to=andrea.vai@unipv.it \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).