Re: bin/51331: cdrom will not mount after first time

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR bin/51331; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: bin/51331: cdrom will not mount after first time
Date: Tue, 12 Jul 2016 15:37:44 +0700

     Date:        Tue, 12 Jul 2016 05:45:01 +0000 (UTC)
     From:        mlelstv%serpens.de@localhost (Michael van Elst)
     Message-ID:  <20160712054501.6DEE87AAAD%mollari.NetBSD.org@localhost>
 
   |  The flag is supposed to be cleared by a UNIT ATTENTION sense which is
   |  supposed to be generated always when the media is changed or a
   |  NOT READY sense which is supposed to be returned for most commands
   |  when no disk is loaded. This is handled by generic code in scsipi_base.c
   |  and atapi_base.c.
 
 Yes, I saw that (the ATAPI) version after I sent my last message ... however
 I also saw that there are cases where the sense info can be sent, and not
 reset the MEDIA_LOADED bit .. the generic sense handler first calls the
 driver specific error handler (if there is one, and there is for the cd
 driver) and if that returns anything other than EJUSTRETURN then the
 generic routine just returns, and does not clear MEDIA_LOADED.
 
 There appear to be 2 sense results which could clear MEDIA_LOADED,
 SKEY_NOT_READY and SKEY_UNIT_ATTENTION - if the second happens, all
 should be OK, but in the SKEY_NOT_READY case, there are several cases
 (filled with magic numbers) in the cd driver that cause it to return
 something other than EJUSTRETURN.
 
 What is actually happening here I have no idea, but from the symptoms
 described, I'd say that something in this area is very likely the cause
 of the problem described.   Perhaps the drive has some odd behaviour
 that needs a quirk to deal with it (wouldn't be the first CD drive that
 deviates from the standards...).
 
 I think I'd just clear the MEDIA_LOADED bit in the case of an eject ioctl
 (where the command is actually sent to the drive - ie: about the same place
 that the previous label is invalidated) in all cases - what harm can it do?
 The intent is clearly to cause the drive to eject the CD, so when it is
 reloaded new info needs to be acquired - if the drive (for some reason)
 refuses the eject, all that would happen is that the label (and other
 init data) would be acquired again (the label needs to be to undo the
 FS_UNUSED settings in any case).
 
 But PC hardware is all voodoo to me, so don't do anything just because I
 think it makes sense....
 
 kre