linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrea Vai <andrea.vai@unipv.it>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org, stern@rowland.harvard.edu
Subject: Re: Slow I/O on USB media
Date: Wed, 05 Jun 2019 18:23:58 +0200	[thread overview]
Message-ID: <463fb315f901783543c3bd5284523912c3c31080.camel@unipv.it> (raw)
In-Reply-To: <0c2adde7154b0a6c8b2ad7fc5258916731b78775.camel@unipv.it>

Hi,
Il giorno mer, 05/06/2019 alle 16.55 +0200, Greg KH ha scritto:
> On Wed, Jun 05, 2019 at 09:36:04AM +0200, Andrea Vai wrote:
> > Hi,
> > Il giorno mar, 04/06/2019 alle 07.43 +0200, Greg KH ha scritto:
> > > On Mon, Jun 03, 2019 at 01:13:48PM +0200, Andrea Vai wrote:
> > > > Il giorno gio, 30/05/2019 alle 06.25 -0700, Greg KH ha
> scritto:
> > > > > [...]
> > > > Hi,
> > > > 
> > > > > Any chance you can use 'git bisect' to find the offending
> > > commit?
> > > > Yes, I am doing it as I managed to build the kernel from
> source
> > > 
> > > Great!  What did you find?
> > 
> > # first bad commit: [534903d60376b4989b76ec445630aa10f2bc3043]
> > drm/atomic: Use explicit old crtc state in
> > drm_atomic_add_affected_planes()
> > 
> > By the way, as I am not expert, is there a way to double-check
> that I
> > bisected correctly? (such as, e.g., test with the version before
> this
> > one, and then with this commit applied?)
> 
> How exactly are you "testing" this?
> 
> I would recommend a script that does something like:
>       mount the disk somewhere
>       copy a big file to it
>       unmount the disk
> 
> testing how long the whole process takes, especially the 'unmount'
> is
> important.  Are you doing that?

Well, not exactly, and thank you for pointing me out. I am doing the
job in two ways, from the DE (when I am located at the PC), or in an
ssh session when I am away. In ssh I manually mount the media, then
run

touch begin
date
<cp command>
date
touch end

so I get the time kept looking at the output of "date", or at the date
of the begin/end files. I understand that if I don't unmount the media
I cannot be sure all data has been written, but if the cp command is
still not finished after 20, 30 minutes then I can tag the commit as
"bad". Since I obtained one "good" behavior only (1-2 minutes) among
10+ tests, I took for sure it was a"good" commit, and I may have made
a mistake there (because I am not sure I actually unmounted the
media).

If I use the DE (where the media is mounted automatically) I used to
"eject" the media after the copy finished, and took note of the time
used until the media was correctly "ejected" (and, so, unmounted).

Anyway, I know that I can do all of this in a better way, and will let
you know.

> 
> Also, you should probably just boot into text mode for this, most
> graphical DEs like to auto-mount disks these days.

Thank you for clarifying. As said above, actually I think I have took
care of it, but I can do another bisect by turning off the automount
feature of USB media in my DE, and mount/unmount only by command line.

First of all, I will try to revert the commit, and see what happens.
If the test fails, I will run another bisect.

Thank you for your patience,
Best regards
Andrea


  parent reply	other threads:[~2019-06-05 16:24 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 [this message]
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
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=463fb315f901783543c3bd5284523912c3c31080.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).