Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #203260

Re: About /dev/sr impatience with automatic tray loading

Show all headers | View raw

On Monday 10 December 2018 15:02:44 Thomas Schmitt wrote:

> Hi,
>
> Gene Heskett wrote:
> > Perhaps that patch could be reverted,
>
> It had its legitimate intentions, 10 years ago.
> See
>
>  
> https://github.com/torvalds/linux/commit/210ba1d1724f5c4ed87a2ab1a21ca
>861a915f734
>
> and a glimpse of the following woes
>   http://lkml.iu.edu/hypermail//linux/kernel/0807.0/0287.html
> (The culprits already suffered duely. Hehehe.)

And rather than fix it, walked away.
>
> The decisive change is not easy to spot. It's the loss of the function
>
>     static int test_unit_ready(Scsi_CD *cd)
>
> with the line
>
>     return sr_do_ioctl(cd, &cgc);
>
> sr_do_ioctl() has a waiting loop that eats "still undecided" replies
> and retries at most 10 times. It still exists in the current kernel
>
>  
> https://github.com/torvalds/linux/blob/master/drivers/scsi/sr_ioctl.c
>
> where in line 223 ff. we can see the old timeout of 20 seconds
>
>         if (!cgc->quiet)
>                 sr_printk(KERN_INFO, cd,
>                           "CDROM not ready yet.\n");
>         if (retries++ < 10) {
>                 /* sleep 2 sec and try again */
>                 ssleep(2);
>                 goto retry;
>         } else {
>                 /* 20 secs are enough? */
>                 err = -ENOMEDIUM;
>                 break;
>         }
>
> The replacement for test_unit_ready() is a call to
> scsi_test_unit_ready() which does not call a function with retry loop.
>
> For the purpose of sr_drive_status(), the loop is really
> inappropriate. This function shall obtain the drive status and not
> wait until the status of the medium is decided.
>
> Regrettably the subsequent correction attempts never reached the
> doings of drivers/cdrom/cdrom.c function open_for_data(). By the
> original change it lost its loop and never got a new one.
>
> My fix proposal is to create a function with such a loop and to let
> open_for_data() use it instead of the call of cdo->drive_status(),
> which actually is sr_drive_status().
> Currently this call is in line 1068 of
>
>   https://github.com/torvalds/linux/blob/master/drivers/cdrom/cdrom.c
>
> > and the timeout made say 2 minutes,
> > by which time the drive should be able to make up its mind
>
> 30 seconds seems to be enough for all normal situations. My longest
> experiment result with various drives and media was 18 seconds.
> One would have to convince the hypothetical committer why 120 is
> needed.
>
I expect you have a better understanding than I do.  What I will say is 
if you fix it, there will be flowery words written by several, and a 
hand cooler offered if you show up at my place thirsty.

> But before commit comes the test and before test comes the recent
> kernel on real iron. I only have code for now and feel fewly talented
> for the missing steps.
>
> > That I think we can all agree is a PITA.
>
> Oh. I know some more such dumplings.
>
So do I, Thomas, but this is supposedly a polite list. :)
>
> Have a nice day :)
>
> Thomas



-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

About /dev/sr impatience with automatic tray loading "Thomas Schmitt" <scdbackup@gmx.net> - 2018-12-10 15:00 +0100
  Re: About /dev/sr impatience with automatic tray loading Gene Heskett <gheskett@shentel.net> - 2018-12-10 16:00 +0100
    Re: About /dev/sr impatience with automatic tray loading "Thomas Schmitt" <scdbackup@gmx.net> - 2018-12-10 18:50 +0100
      Re: About /dev/sr impatience with automatic tray loading Gene Heskett <gheskett@shentel.net> - 2018-12-10 20:00 +0100
        Re: About /dev/sr impatience with automatic tray loading "Thomas Schmitt" <scdbackup@gmx.net> - 2018-12-10 21:10 +0100
          Re: About /dev/sr impatience with automatic tray loading Gene Heskett <gheskett@shentel.net> - 2018-12-11 01:20 +0100
            Re: About /dev/sr impatience with automatic tray loading "Thomas Schmitt" <scdbackup@gmx.net> - 2018-12-11 12:40 +0100
              Re: About /dev/sr impatience with automatic tray loading Gene Heskett <gheskett@shentel.net> - 2018-12-11 18:00 +0100
                Re: About /dev/sr impatience with automatic tray loading "Thomas Schmitt" <scdbackup@gmx.net> - 2018-12-11 18:30 +0100
                Re: About /dev/sr impatience with automatic tray loading Greg Wooledge <wooledg@eeg.ccf.org> - 2018-12-11 18:40 +0100
                Re: About /dev/sr impatience with automatic tray loading Tony van der Hoff <lists@vanderhoff.org> - 2018-12-11 18:50 +0100
                Re: About /dev/sr impatience with automatic tray loading John Hasler <jhasler@newsguy.com> - 2018-12-11 20:50 +0100
                Re: About /dev/sr impatience with automatic tray loading Gene Heskett <gheskett@shentel.net> - 2018-12-11 20:30 +0100
          Re: About /dev/sr impatience with automatic tray loading mick crane <mick.crane@gmail.com> - 2018-12-11 13:40 +0100
            Re: About /dev/sr impatience with automatic tray loading Dan Ritter <dsr@randomstring.org> - 2018-12-11 15:50 +0100
              Re: About /dev/sr impatience with automatic tray loading Erik Christiansen <dvalin@internode.on.net> - 2018-12-12 01:10 +0100
                Re: About /dev/sr impatience with automatic tray loading Dan Ritter <dsr@randomstring.org> - 2018-12-12 12:30 +0100
                Re: About /dev/sr impatience with automatic tray loading David Wright <deblis@lionunicorn.co.uk> - 2018-12-12 21:20 +0100

csiph-web