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

Groups > linux.debian.user > #203248

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

Show all headers | View raw

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/210ba1d1724f5c4ed87a2ab1a21ca861a915f734

and a glimpse of the following woes
  http://lkml.iu.edu/hypermail//linux/kernel/0807.0/0287.html
(The culprits already suffered duely. Hehehe.)

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.

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.


Have a nice day :)

Thomas

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