Soren Schmidt wrote:
FYI, this is still an issue:
s = ioctl(fd, CDIOCCLOSE, 0)
IOError: [Errno 16] Device busy
Hmm, if the call to do the close fails there isn't much I can do...
I can't reproduce the problem on any of the dozens of ATAPI CDROM's
I have in the closet, so if you want to get f
It seems Lars Eggert wrote:
> Lars Eggert wrote:
> > Soren Schmidt wrote:
> >
> >>> Is there any other patch I can try? I've just confirmed that this bug
> >>> still exists with today's kernel.
> >>
> >> I cant reproduce the no matter what I try, sorry...
> >
> > Would remote access to the machi
Lars Eggert wrote:
Soren Schmidt wrote:
Is there any other patch I can try? I've just confirmed that this bug
still exists with today's kernel.
I cant reproduce the no matter what I try, sorry...
Would remote access to the machine in question help you?
FYI, this is still an issue:
s = ioctl(
Soren Schmidt wrote:
Is there any other patch I can try? I've just confirmed that this bug
still exists with today's kernel.
I cant reproduce the no matter what I try, sorry...
Would remote access to the machine in question help you?
Lars
--
Lars Eggert <[EMAIL PROTECTED]> USC Informati
It seems Lars Eggert wrote:
> Bruce Evans wrote:
> > On Thu, 30 Oct 2003, Soren Schmidt wrote:
> >>
> >>Anyhow if you loose the test for error in atapi-cd.c::acd_tray in the
> >>close case, does it work then ? Problem is that the call to read toc
> >>might fail early, but its worth a shot..
>
> I
Bruce Evans wrote:
On Thu, 30 Oct 2003, Soren Schmidt wrote:
Anyhow if you loose the test for error in atapi-cd.c::acd_tray in the
close case, does it work then ? Problem is that the call to read toc
might fail early, but its worth a shot..
I tried this, but it didn't change anything. (See my mail
On Thu, 30 Oct 2003, Soren Schmidt wrote:
> It seems Lars Eggert wrote:
> > > I've already committed a solution that works on all the drives I
> > > could test on (some of which failed before), if this still
> > > fails for you I'd like a more detailed description of what
> > > exactly goes wrong.
Soren Schmidt wrote:
Anyhow if you loose the test for error in atapi-cd.c::acd_tray in the
close case, does it work then ?
If you mean as below, no, that didn't help:
Index: atapi-cd.c
===
RCS file: /home/ncvs/src/sys/dev/ata/atapi-cd
V čt, 30. 10. 2003 v 20:43, Lars Eggert píše:
> >>FYI, the issue is still present with yesterday's -current. Will Pav
> >>Lucistnik's patch be committed soon?
> >
> > I've already committed a solution that works on all the drives I
> > could test on (some of which failed before), if this still
It seems Lars Eggert wrote:
> > I've already committed a solution that works on all the drives I
> > could test on (some of which failed before), if this still
> > fails for you I'd like a more detailed description of what
> > exactly goes wrong...
>
> I must have missed that commit message, sor
On 30-Oct-2003 Lars Eggert wrote:
> Soren Schmidt wrote:
>> It seems Lars Eggert wrote:
>>
>>>FYI, the issue is still present with yesterday's -current. Will Pav
>>>Lucistnik's patch be committed soon?
>>
>> I've already committed a solution that works on all the drives I
>> could test on (som
Soren Schmidt wrote:
It seems Lars Eggert wrote:
FYI, the issue is still present with yesterday's -current. Will Pav
Lucistnik's patch be committed soon?
I've already committed a solution that works on all the drives I
could test on (some of which failed before), if this still
fails for you I'd
It seems Lars Eggert wrote:
> FYI, the issue is still present with yesterday's -current. Will Pav
> Lucistnik's patch be committed soon?
I've already committed a solution that works on all the drives I
could test on (some of which failed before), if this still
fails for you I'd like a more deta
Soren Schmidt wrote:
It seems Pav Lucistnik wrote:
This patch works for me. Any chance to get it committed?
I'll look at it...
FYI, the issue is still present with yesterday's -current. Will Pav
Lucistnik's patch be committed soon?
Lars
--
Lars Eggert <[EMAIL PROTECTED]> USC Informatio
It seems Pav Lucistnik wrote:
>
> This patch works for me. Any chance to get it committed?
I'll look at it...
-Søren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL P
On Sun, 14 Sep 2003, Pav Lucistnik wrote:
> V so, 06. 09. 2003 v 21:41, Bruce Evans pí¹e:
> > On Sat, 6 Sep 2003, Pav Lucistnik wrote:
> >
> > > after recent ATAng changes, cdcontrol close stopped working
> > > with my CD-ROM drive. It used to close the tray. It works with -f
> > > /dev/cd0 but no
V so, 06. 09. 2003 v 21:41, Bruce Evans píše:
> On Sat, 6 Sep 2003, Pav Lucistnik wrote:
>
> > after recent ATAng changes, cdcontrol close stopped working
> > with my CD-ROM drive. It used to close the tray. It works with -f
> > /dev/cd0 but not with /dev/acd0. cdcontrol eject still works fine.
>
On Sat, 6 Sep 2003, Pav Lucistnik wrote:
> after recent ATAng changes, cdcontrol close stopped working
> with my CD-ROM drive. It used to close the tray. It works with -f
> /dev/cd0 but not with /dev/acd0. cdcontrol eject still works fine.
I use the following fix:
%%%
Index: atapi-cd.c
=
Hi,
after recent ATAng changes, cdcontrol close stopped working
with my CD-ROM drive. It used to close the tray. It works with -f
/dev/cd0 but not with /dev/acd0. cdcontrol eject still works fine.
Relevant dmesg parts:
atapci0: port 0xfc00-0xfc0f at device 17.1 on pci0
ata0: at 0x1f0 irq 14 on
19 matches
Mail list logo
