Re: Slow I/O on USB media

[Andrea Vai <andrea.vai@unipv.it>]

Il giorno gio 6 giu 2019 alle ore 16:48 Greg KH
<gregkh@linuxfoundation.org> ha scritto:
>
> On Thu, Jun 06, 2019 at 04:00:52PM +0200, Andrea Vai wrote:
> > Il giorno mer, 05/06/2019 alle 19.39 +0200, Greg KH ha scritto:
> > > On Wed, Jun 05, 2019 at 06:23:58PM +0200, Andrea Vai wrote:
> > > [...]
> > >
> > > > Anyway, I know that I can do all of this in a better way, and will
> > > let
> > > > you know.
> > >
> > > Yes, please do so, your steps above do not show much.
> >
> > 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
>
> We have no idea what is in a random distro kernel, sorry.
>
> So I would start with a kernel.org kernel.  That keeps things at an even
> level, and you are using a "known good" configuration as well.
>
> > 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?
> >
> > I am afraid I am missing something obvious, sorry
>
> As Alan said, 4.20 is older than 4.20.13.
>
> But, is the kernel.org version of 4.20.13 really "good" here?
>
> I would start with Linus's tree and stay away from the stable trees
> for now.  As you end up with odd "leafs" that can confuse 'git bisect'
> and everyone else.
>
> So start with 4.20.0.  Test that.  If it is "good", then great!

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.

Current output of "git bisect log" is

git bisect start
# good: [8fe28cb58bcb235034b64cbbb7550a8a43fd88be] Linux 4.20
git bisect good 8fe28cb58bcb235034b64cbbb7550a8a43fd88be
# bad: [01047631df813f6247185547c3778c80af088a20] Merge tag
'xfs-5.2-fixes-2' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux
git bisect bad 01047631df813f6247185547c3778c80af088a20
# bad: [bcd49c3dd172c38e14faf151adca63c8db4c9557] Merge branch
'x86-cleanups-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad bcd49c3dd172c38e14faf151adca63c8db4c9557
# bad: [fcf010449ebe1db0cb68b2c6410972a782f2bd14] Merge tag
'kgdb-4.21-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/danielt/linux
git bisect bad fcf010449ebe1db0cb68b2c6410972a782f2bd14
# bad: [e0c38a4d1f196a4b17d2eba36afff8f656a4f1de] Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
git bisect bad e0c38a4d1f196a4b17d2eba36afff8f656a4f1de
# bad: [c2f1f3e0e17d94ab0c66d83e669492cb9e9a3698] Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-next
git bisect bad c2f1f3e0e17d94ab0c66d83e669492cb9e9a3698
# bad: [b3cc2bfe7244e848f5e8caa77bbdc72c04abd17c] Merge tag
'i3c/for-4.21' of
git://git.kernel.org/pub/scm/linux/kernel/git/i3c/linux
git bisect bad b3cc2bfe7244e848f5e8caa77bbdc72c04abd17c
# bad: [2ac5e38ea4203852d6e99edd3cf11f044b0a409f] Merge drm/drm-next
into drm-intel-next-queued
git bisect bad 2ac5e38ea4203852d6e99edd3cf11f044b0a409f
# skip: [63ac3328f0d1d37f286e397b14d9596ed09d7ca5] drm/i915: fix
broadwell EU computation
git bisect skip 63ac3328f0d1d37f286e397b14d9596ed09d7ca5
# bad: [ca05359f1e64cf8303ee532e50efe4ab7563d4a9] dma-buf: allow
reserving more than one shared fence slot
git bisect bad ca05359f1e64cf8303ee532e50efe4ab7563d4a9
# bad: [21ebe615c16994f340fe2b6735aad31fd1d0014c] drm: Remove
transitional helpers
git bisect bad 21ebe615c16994f340fe2b6735aad31fd1d0014c
# bad: [a0d4d42cb5854400baa47bf63d9aae65fa9f484e] drm/bochs: Replace
drm_gem_object_unreference_unlocked with put function
git bisect bad a0d4d42cb5854400baa47bf63d9aae65fa9f484e

Many thanks,
Andrea