From: Alan Stern <stern@rowland.harvard.edu>
To: Andrea Vai <andrea.vai@unipv.it>
Cc: Greg KH <gregkh@linuxfoundation.org>, <linux-usb@vger.kernel.org>
Subject: Re: Slow I/O on USB media
Date: Thu, 6 Jun 2019 10:30:47 -0400 (EDT) [thread overview]
Message-ID: <Pine.LNX.4.44L0.1906061025540.1641-100000@iolanthe.rowland.org> (raw)
In-Reply-To: <b159e1518b670d4b0126c7671c30c8c3cb8fffbc.camel@unipv.it>
On Thu, 6 Jun 2019, Andrea Vai wrote:
> Here I am with another question.
> What I have done so far:
>
> - booted with the last kernel I know to be working (4.20.13-
> 200.fc29.x86_64, installed from Fedora repos), checked that test runs
> fine (2min to copy)
> - marked "git bisect good v4.20.13"
> - built the latest stable version:
> - git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> - cp -v /boot/config-$(uname -r) .config
> - make -j4 && make modules_install && make install && grub2-mkconfig -o /boot/grub2/grub.cfg
> - grubby --set-default /boot/vmlinuz-5.2.0-rc3 (the last regular file listed in "ls -lrt /boot/v*")
> - rebooted with kernel 5.2.0-rc3, ran the test, took 49min to copy
> (!), thus marked "git bisect bad"
> - built again, and it turns out to be 4.20.0 (why is it earlier than
> 4.20.13?), rebooted with 4.20.0, ran the test and it took more than 15
> minutes so I killed the cp process, and marked it BAD, and obtained:
>
> The merge base 8fe28cb58bcb235034b64cbbb7550a8a43fd88be is bad.
> This means the bug has been fixed between
> 8fe28cb58bcb235034b64cbbb7550a8a43fd88be and
> [0f7c162c1df596e0bba04c26fc9cc497983bf32b].
>
> The output of "git bisect log" is:
>
> git bisect start
> # good: [0f7c162c1df596e0bba04c26fc9cc497983bf32b] Linux 4.20.13
> git bisect good 0f7c162c1df596e0bba04c26fc9cc497983bf32b
> # bad: [f2c7c76c5d0a443053e94adb9f0918fa2fb85c3a] Linux 5.2-rc3
> git bisect bad f2c7c76c5d0a443053e94adb9f0918fa2fb85c3a
> # bad: [8fe28cb58bcb235034b64cbbb7550a8a43fd88be] Linux 4.20
> git bisect bad 8fe28cb58bcb235034b64cbbb7550a8a43fd88be
>
> I can understand that the bug was present before 4.20.13 (is that
> reasonable?), but how can I tell bisect to start at 4.20.13, which I
> know for sure to be working, and not from 4.20.0, which I actually
> don't care about?
So what you got was a meaningless result. Bisection works by assuming
assuming that it's looking for a commit that introduced a problem. If
the earliest commit you test already has the problem (and 4.20.0 is
earlier than 4.20.13) then bisection won't do anything.
In your case it looks like something added between 4.20.0 and 4.20.13
caused the problem to go away! You can still use bisection to find the
commit which did that, but the idea is a little unintuitive.
Start out by telling git that 4.20.0 is "good" and 4.20.13 is "bad".
Then test the intermediate commits as you have been doing, and say that
the commit is "good" if the copy takes a long time and "bad" if the
copy takes a short time. That should help to find the first commit
which caused the problem to go away. (Assuming that the problem is
caused by the kernel and not by something else...)
Alan Stern
next prev parent reply other threads:[~2019-06-06 14:30 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 [this message]
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
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=Pine.LNX.4.44L0.1906061025540.1641-100000@iolanthe.rowland.org \
--to=stern@rowland.harvard.edu \
--cc=andrea.vai@unipv.it \
--cc=gregkh@linuxfoundation.org \
--cc=linux-usb@vger.kernel.org \
/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).