Date: Sat, 26 Jul 2008 19:04:05 -0300 From: "Carlos A. M. dos Santos" <unixmania@gmail.com> To: Volker <volker@vwsoft.com> Cc: FreeBSD Stable <freebsd-stable@freebsd.org>, bug-followup@freebsd.org Subject: Re: bin/123693: Workaround for burncd: ioctl(CDIOCEJECT): Input/output error Message-ID: <e71790db0807261504h7f7f8f46i6e239d5b94ca1082@mail.gmail.com> In-Reply-To: <e71790db0805252121l4847f290ia500abf10407d858@mail.gmail.com> References: <482F31E7.7080000@vwsoft.com> <e71790db0805190527q3fbc49c2tb088cc1b29a284a3@mail.gmail.com> <e71790db0805252121l4847f290ia500abf10407d858@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, May 26, 2008 at 1:21 AM, Carlos A. M. dos Santos <unixmania@gmail.com> wrote: > On Mon, May 19, 2008 at 9:27 AM, Carlos A. M. dos Santos > <unixmania@gmail.com> wrote: >> On Sat, May 17, 2008 at 4:28 PM, Volker <volker@vwsoft.com> wrote: >>> Carlos, >>> >>> IMHO it's better to explicitly check for ioctl returning EBUSY and 5 >>> seconds may not fit every situation. >>> >>> Volker >> >> Ok, I will attempt the approach of checking for EBUSY. > > I found that ioctl(fd, CDIOCEJECT) returns EIO, not EBUSY, so it seems > that there is no better solution. I was able to improve the delays, > however (see attachmet). Now they grow exponentially, limited to 31 > seconds (1 + 2 + 4 + 8 + 16). This is better than flooding the CD > drive with one eject request per second. Any update on this issue? I'd suggest you to at least close the PR if the proposed patch is not acceptable. I must admit that it is only a tricky workaround, not a masterpiece, so I will not feel offended. :-) -- If you think things can't get worse it's probably only because you lack sufficient imagination.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e71790db0807261504h7f7f8f46i6e239d5b94ca1082>