|
Bugzilla – Full Text Bug Listing |
| Summary: | yast2 doesn't wait long enough after media change | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.0 | Reporter: | Tejun Heo <teheo> |
| Component: | Kernel | Assignee: | Matthias Koenig <mkoenig> |
| Status: | RESOLVED FIXED | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | coolo, jreidinger, jsuchome, lslezak |
| Version: | Beta 2 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | y2logs.tar.gz | ||
|
Description
Tejun Heo
2008-05-14 11:41:34 UTC
This is something for the Media backend or HAL, DBUS..?? Jano? Can you please provide log? Is save_y2logs afterward enough? maybe, if logged message doesn't been overwritten by latter commands. (it depends on allowed size of your logs). So attach it and if it doesn't contain it I say. Created attachment 216146 [details]
y2logs.tar.gz
Here's the y2log. If the log doesn't have what's needed, please lemme know. I'll try to reproduce the problem.
I looks like bug is not in libzypp, because mount is called correctly, but immediately return medium not found (which is not expected if CD is allready inserted). Reassign to mount maintainer. Waiting for drive readiness has never been mount's responsibility. There's related issue being discussed in bug #390934. I'll cc you there. Thanks. Yes, mount returns medium not found because the syscall mount(2) returns ENOMEDIUM. It is not the responsibility of the mount program to wait for a medium it does not even know about. *** Bug 395130 has been marked as a duplicate of this bug. *** The bug is far from invalid, and it is a regression from 10.3 where the media were properly read even if it took some more time. If this is not responsibility of mount, then it is responsibility of whatever that handles the syscall and reassigned, not closed as invalid. Who should take over? Ok, you are right. This has worked on 10.3.
The difference seems to be that on 10.3 the open call for the CD device blocks until the device could be read.
While on 11.0 the open call itself also returns ENOMEDIUM:
open("/dev/sr0", O_RDONLY) = -1 ENOMEDIUM (No medium found)
So this has changed on the kernel side, not sure if this was intentional.
Okay, the difference is from the addition of cdrom_get_media_event() call to both sr_drive_status() and ide_cdrom_drive_status(). Previously, the cdrom driver can't differentiate between tray closed w/ no media and tray open and always returned tray open, which triggers close and retry in the open logic which probably have delayed things enough to get the media recognized. Now the cdrom driver can discern between tray closed w/o media and device not ready for other reasons and returns -ENOMEDIUM on the former. This is all good and dandy but the problem seems that some drives report no media right after the tray is closed but it hasn't properly detected the media yet. It seems the only way to work around the problem is via sensible retries (e.g. try three times 5 secs apart) and I don't think we can add that type of retry logic into cdrom open path. Please note that the previous logic wasn't water proof. Some drives can take longer to recognize the media is there and could have failed the in-kernel retry too. Also, reading the media can take quite some time and during that period the drive reports media present but device not ready. The driver will retry the command (e.g. READ TOC for open) five times but all of them can fail w/ EMEDIUMTYPE. I think adding userland retries is necessary, at least for now. Please take a look at the following bug which deals with the same problem in live cd. Maybe the workaround can be shared? https://bugzilla.novell.com/show_bug.cgi?id=390934 Ok, thanks for explanation. I will add some retry logic to userland mount. Fixed in STABLE. |