Hi Monty,

On Tue, 30 Sep 2008, Monty Montgomery wrote:
quoted text
> On Wed, Sep 17, 2008 at 11:05 AM, Geert Uytterhoeven
> <Geert.Uytterhoeven@sonycom.com> wrote:
> >> The problem is I don't think the new behaviour is a regression.
> >> cdparanoia requested O_NONBLOCK ... it's a bit counter to this if we
> >> wait for the drive to become ready.
> 
> O_NONBLOCK has nothing to do with the drive being ready.  It means not
> to wait to open a device locked or in use exclusively by another
> process. It does not affect command processing (at least not the way
> cdparanoia is doing it).  If a drive isn't ready, it returns a sense
> key of 'not ready' and the SGIO layer doesn't filter that in any way.
> SGIO itself never waits or takes any special action on 'not ready', it
> merely passes through the comand termination status.
> 
> Note that 'not ready' is not the same as 'no medium'.  One means the
> drive is digesting a new disc, the other means there is no dics (or
> the tray is open).  Some drives do in fact return 'empty' until a new
> disc is completely loaded after tray close.  These drives are in
> violation of spec (but the alternative is to ignore the empty status
> and retry forever, which means there's no recovering from ejecting a
> disc mid-operation, which was also reported as a bug).  On the other
> hand, I've never come across any ATAPI drive that 100% faithfully
> implements the command spec.  All vendors take *substantial*
> liberties.
> 
> > I confirmed (using strace) that my cdparanoia also opens /dev/scd0 with
> > O_NONBLOCK.
> >
> > After applying the patch below to cdparanoia, the problem goes away.
> >
> > --- cdparanoia-3.10.0+debian/interface/scan_devices.c.orig      2008-05-16 06:25:24.000000000 +0200
> > +++ cdparanoia-3.10.0+debian/interface/scan_devices.c   2008-09-17 16:36:14.000000000 +0200
> > @@ -608,7 +608,7 @@
> >
> >   if(specialized_device) {
> >     if(use_sgio)
> > -      i_fd=open(specialized_device,O_RDWR|O_NONBLOCK);
> > +      i_fd=open(specialized_device,O_RDONLY);
> 
> This change means you can only run one cdparanoia per computer as the
> device autoscan code will now block on an in-use drive.
> Also, you're a few releases behind.  10.0 was misreporting drive
> status due to a stupid bug; god only knows what happened in SGIO as
> the error code never got passed up.  10.2 corrects the problem (as
> well as a few other major bugs).  Current SVN will be 10.3 in a few
> more days.

So I tried the version in Debian unstable...

quoted text
> If the same thing is still happening with 10.2 and the same patch

The same thing happens with cdparanoia-3.10.2+debian.

quoted text
> still fixes it, then I definitely have some head scratching [and
> kernel perusal] to do.

But the patch above doesn't help. Now cdparanoia crashes with a segmentation
fault:

| 0x0ffd5730 in cdda_read_timed () from /usr/lib/libcdda_interface.so.0
| (gdb) bt
| #0  0x0ffd5730 in cdda_read_timed () from /usr/lib/libcdda_interface.so.0
| #1  0x0ffa7624 in i_read_c_block () from /usr/lib/libcdda_paranoia.so.0
| #2  0x0ffa9114 in paranoia_read_limited () from /usr/lib/libcdda_paranoia.so.0
| #3  0x10004da0 in ?? ()
| #4  0x0fd46704 in ?? () from /lib/libc.so.6
| #5  0x0fd468c0 in __libc_start_main () from /lib/libc.so.6
| #6  0x00000000 in ?? ()

due to the `buffer' parameter being NULL.

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village