Bug 139243
| Summary: | HAL tries to read the disk too often, stops eject | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Alan Cox <alan> |
| Component: | hal | Assignee: | John (J5) Palmieri <johnp> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3 | CC: | gajownik, jkeck, mattdm, ralston, sitsofe |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | FC5 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-08-22 18:49:08 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Alan Cox
2004-11-14 12:25:58 UTC
Hi, I agree we should make the user eject the disc, sure. > Perhaps if HAL sees media errors it should stop probing and not > reprobe that device in any way until it sees the device empty ? Well, in order to see if the drive is empty we need to poll the drive I suppose. Perhaps HAL should slow down polling (say, every ten seconds) if errors are encountered. I'm not sure though where hal fails, e.g. whether it's in the fs detection code or in polling the drive; what is the output of 'hald --daemon=no --verbose=yes' when you start up with an empty drive and then insert the broken disc? It might be useful to get a selected strace to see what system calls fails. I want to put some more brains into how hal detects media on optical drives. E.g including whitelists/blacklists (for bug 130649) and checks whether the drive shares an IDE channel with other drives (for bug 138148). Any hints on how to damage an optical disc so I can reproduce this? :-) To get the eject to work I have to slow it down to 45 seconds. Hal fails because it polls the drive, each poll locks the drive, it sees a disk in, it (or something triggered as a result tries to read bits of the disk to identify it). I did it buy burning a DVD+RW and putting in an old drive that cant read them. Strange, I've seen this problem with a DVD+RW too. I had finished burning it and mounted it correctly. However when I told the disk to eject from the desktop (right mouse button eject) the DVD+RW was unmounted but I was told that eject failed with some incorrect parameter. The button on front of the drive did nothing. Going to My Computer and double clicking the CD icon mounted it again but as a regular user I could not get the disk to eject either from GNOME or at the terminal by typing eject. The only way to get the disk out was to become root and then type eject. I got the same warning about parameters but the disk actually came out. Is my experience the same as this bug or is it something different? Comment #3: this sounds like a different bug This sounds related to Bug #138148. (As pointed out by Sitsofe Wheeler in that bug.) Fedora Core 3 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thank you! |