Re: Slow I/O on USB media

From: Greg KH <gregkh@linuxfoundation.org>
To: Andrea Vai <andrea.vai@unipv.it>
Cc: linux-usb@vger.kernel.org, Alan Stern <stern@rowland.harvard.edu>
Subject: Re: Slow I/O on USB media
Date: Mon, 10 Jun 2019 16:38:21 +0200	[thread overview]
Message-ID: <20190610143821.GB30602@kroah.com> (raw)
In-Reply-To: <CAOsYWL2z=Rddvu62DP+QdQOf=4FwygmLrOPS0rJ8Uc+OzLKQvA@mail.gmail.com>

On Sat, Jun 08, 2019 at 11:29:16AM +0200, Andrea Vai wrote:
> Il giorno sab 8 giu 2019 alle ore 09:43 Andrea Vai
> <andrea.vai@unipv.it> ha scritto:
> >
> >[...]
> >
> > Hi,
> >   there is also something else I don't understand.
> > Every time I build a kernel, then after booting it "uname -a" shows
> > something like
> >
> > Linux [...] 4.19.0-rc5+ #12 SMP Sat Jun 8 00:26:42 CEST 2019 x86_64
> > x86_64 x86_64 GNU/Linux
> >
> > where the number after "#" increments by 1 from the previous build.
> >
> > Now I have the same number (#12) after a new build, is it normal?
> > Furthermore, "ls -lrt /boot/v*" shows the last lines to be
> >
> > -rw-r--r--. 1 root root 8648656  8 giu 00.35 /boot/vmlinuz-4.19.0-rc5+.old
> > -rw-r--r--. 1 root root 8648656  8 giu 09.08 /boot/vmlinuz-4.19.0-rc5+
> >
> > and "diff /boot/vmlinuz-4.19.0-rc5+.old /boot/vmlinuz-4.19.0-rc5+"
> > shows they are identical. Why? I expected that each bisect would lead
> > to a different kernel.
> > Assuming that the opposite can happen, does it mean that when I say
> > i.e. "git bisect bad", then build a new kernel and see that is
> > identical to the previous one I can run "git bisect bad" without
> > booting into the new one and even making the test?
> >
> > Another thing I don't understand is that I told 4.20.0 to be good, so
> > I would expect that I don't need to test any older version, but as far
> > as I know 4.19.0-rc5+ is older than 4.20.0, so why is it involved in
> > the bisection?
> >
> > I had to "git bisect skip" one time (the kernel did not boot), but as
> > far as I know I don't think this could be related to my doubts.
> > [...]
> 
> Update:
>   I have concluded the bisection, found that
> "9cb5f4873b993497d462b9406f9a1d8a148e461b is the first bad commit",
> reverted it, and the test still fails (btw, the final kernel file,
> /boot/vmlinuz-4.19.0-rc5+, does not differ from the previous one).
> 
> So, all my doubts above are still there (and growing). What I am doing wrong?

Are you _SURE_ that a 4.20.0 release actually worked properly for you?
Did you build one and do your tests?  Or are you just relying on your
Fedora build still?

that's all I can think of here, sorry.

greg k-h