Bug 374526

Summary:	eject -T spawns ioctl: Input/output on Mac computers
Product:	[openSUSE] openSUSE 11.0	Reporter:	Martin Szulecki <novell>
Component:	Basesystem	Assignee:	Anna Maresova <anicka>
Status:	RESOLVED FIXED	QA Contact:	E-mail List <qa-bugs>
Severity:	Major
Priority:	P5 - None	CC:	chrubis
Version:	Factory
Target Milestone:	---
Hardware:	All
OS:	openSUSE 11.0
Whiteboard:
Found By:	Beta-Customer	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Attachments:	attempt to fix the bug using CDROM_DRIVE_STATUS strace eject -T # no cd in drive strace eject -T # cd in drive strace eject # cd in drive, being ejected ok strace eject -T # unmounted cd, cd still in drive

Description Martin Szulecki 2008-03-27 18:19:00 UTC

Ejecting the disc using the eject key on Mac computers (Macbook, iMac, ...) causes it to fail with "ioctl: Input/output" (since the drive has no tray I assume). This disables the ability for those users to eject a CD from the drive.

Using eject manually without the -T (tray) option works though.

The whole issue is described here:
https://bugs.launchpad.net/ubuntu/+source/eject/+bug/91873

The very simple patch here fixes this for the Apple line of computers:
http://launchpadlibrarian.net/6772132/eject_for_mac.patch

Comment 1 Anna Maresova 2008-04-23 14:09:43 UTC

I am afraid that while this patch fixes a problem for Apple users, it will break eject for anyone getting EIO because he was trying to eject a device that was plugged off before. It does not look really pretty.

If I understand it right, apple cdroms cannot close on their own, so eject -T cannot work for them. Then the real fix should be making the eject button on Apple computers run "eject" instead of "eject -T", not breaking eject.

Comment 2 Petr Cerny 2008-04-30 13:38:21 UTC

Reassigning to Anna (new eject maintainer).

Comment 3 Tejun Heo 2008-05-15 05:43:06 UTC

Ah, the problem is that the heuristics itself used in ToggleTray.  You cannot expect every drive to behave this way.  There will be almost definitely drives which will behave differently.

More appropriate way to do detect current tray status is to issue TEST_UNIT_READY and look at the sense data.  If tray is open, it should say MEDIUM NOT PRESENT - TRAY OPEN.  In which case, the tray should be closed.  If the device is ready or the sense data is MEDIUM NOT PRESENT - TRAY CLOSED, the tray should be open.

If the device is not ready but the sense data is none of the above two, you can't really tell the current tray status.  In that case, falling back to the original heuristic should work.

Comment 4 Anna Maresova 2008-05-22 16:59:06 UTC

Created attachment 217587 [details]
attempt to fix the bug using CDROM_DRIVE_STATUS

Tejun, can you please take a look at this patch? Looking into the cdrom driver, I think that it does exactly what you propose in quite a neat way. Do you think it is correct?

Comment 5 Tejun Heo 2008-05-23 00:46:53 UTC

Ah.. yeah, indeed.  That's a nice ioctl to use and GET_EVENT_STATUS_NOTIFICATION used from the ioctl is definitely better way to detect this stuff.  The only problem is that for ancient drives it will just report CDS_TRAY_OPEN but I don't really think that will be an issue at this point.  Great.

Comment 6 Anna Maresova 2008-05-23 08:00:31 UTC

I have submitted package with this patch to the factory, I think it will fix it the issue. Please test my fix (either apply this patch or wait for a new package) and if there is something wrong, just reopen.

Comment 7 Martin Szulecki 2008-06-01 20:00:45 UTC

Using eject-2.1.0-114, which apparently has that patch included, I still get the input/output error thus re-opening.

Comment 8 Anna Maresova 2008-06-02 15:09:08 UTC

Weird, because it have worked fine with my Mac. Can you please show me strace?

Comment 9 Martin Szulecki 2008-06-02 15:48:26 UTC

Created attachment 219558 [details]
strace eject -T # no cd in drive

strace output attached for various situations.
I am testing on a Macbook1,1.

Comment 10 Martin Szulecki 2008-06-02 15:49:20 UTC

Created attachment 219559 [details]
strace eject -T # cd in drive

Comment 11 Martin Szulecki 2008-06-02 15:50:30 UTC

Created attachment 219560 [details]
strace eject # cd in drive, being ejected ok

Comment 12 Anna Maresova 2008-06-02 21:02:36 UTC

Can you please show me one more strace? Please umount your CD and run strace on eject -T with CD in drive.

I would like to see it because running eject -T with unmounted CD gives me EIO on any machine I have tried, not only on Apple laptop - it happens because umount is run only before eject, not before eject -T. 

I will fix it anyway, I just want to know whether it will help you.

Comment 13 Martin Szulecki 2008-06-02 22:25:01 UTC

Created attachment 219665 [details]
strace eject -T # unmounted cd, cd still in drive

Yes, that works without any errors.

Comment 14 Anna Maresova 2008-06-03 07:10:32 UTC

Great, thanks a lot. Actually I did not have the right idea of trying to eject mounted CD so I had to wait for your first strace to see what actually happens.

Fix submitted, I hope that we can finally close now. (If not, you already know what to do :-))