[freebsd]burncd

krishtaf

делаю так:

# burncd -v -f /dev/acd0 blank

после этого появляется:

blanking CD, please wait..
и по окончанию процесса стирания управление обратно в shell не возвращается(ну и само собой нельзя понять закончилось ли стирание или нет):

# burncd -v -f /dev/acd0 blank
blanking CD, please wait..

P.S.

uname -v:
FreeBSD 5.3-STABLE Thu Feb 10 01:29:57 MSK 2005

eee1

если просто burncd -f /dev/acd0 blank?

krishtaf

однохуйственно

eee1

хмм, у меня burncd в -CURRENT и -STABLE (cvsup 11/02) работает без проблемы.
ЗЫ. в /var/log/messages нет сообщения?

krishtaf

процесс burncd переходит в состояние nanslp
видимо burncd не получает результат от сидюка и засыпает.
Что можно и нужно подкрутить в дровах ?

eee1

попробуй через cdrecord. что пишет?

krishtaf

По ходу баг в софте (видимо до сих пор не пофиксили)
Вот что нашел:

Hello,
I have a problem when blanking a CD-RW (I think the problem first
appeared when I started using ATAng but I am not sure). System is:
FreeBSD bsd 5.2-BETA FreeBSD 5.2-BETA Sat Dec 6 11:15:34 EET 2003
root at bsd:/usr/obj/usr/src/sys/CUSTOM i386

My CD-R/RW device is a TEAC CD-W524E:
acd1: <CD-W524E/1.0A> CDRW drive at ata1 as slave
acd1: read 6890KB/s (6890KB/s) write 4134KB/s (4134KB/s 1404KB buffer, UDMA33
acd1: Reads: CDR, CDRW, CDDA stream, packet
acd1: Writes: CDR, CDRW, test write, burnproof
acd1: Audio: play, 256 volume levels
acd1: Mechanism: ejectable tray, unlocked
acd1: Medium: no/blank disc
The command I use to blank a CD-RW disc is:
# burncd -f /dev/acd1 -s 10 blank
The problem is that the "blanking CD, please wait.." message is printed,
the CD-RW is blanked succesfully, but burncd never returns.
After a little searching it seems that the program cannot get out of the
while loop at line 198 of src/usr.sbin/burncd/burncd.c:
while (1) {
sleep(1);
if (ioctl(fd, CDRIOCGETPROGRESS, &pct) == -1)
err(EX_IOERR,"ioctl(CDRIOGETPROGRESS)");
if (pct > 0 && !quiet)
fprintf(stderr,
"%sing CD - %d %% done \r",
blank == CDR_B_ALL ?
"eras" : "blank", pct);
if (pct == 100 || (pct == 0 && last > 90
break;
last = pct;
}
The pct variable is always 0, even after the blanking of the CD-RW is
finished (according to the device's LEDs so the program falls into an
infinite loop.
Of course, hitting ^C exits burncd...
Does anyone else has this problem? Is it specific to my CD-R/RW device?
Thanks

и продолжение:

On Tue, Dec 09, 2003 at 09:08:00PM +0100, Soren Schmidt wrote:
> It seems Lefteris Chatzibarbas wrote:
> > > I'm seeing this too. What's odd is that my cd drive is reporting back
> > > incorrect sense information; the valid bit is not set, the asc/ascq is
> > > suspect (4/8 and the sense key specific data is all 0. Since other
> > > fields in the sense data are reasonable, it's not as if no sense data is
> > > being returned at all. So it looks like the CDRIOGETPROGRESS ioctl
> > > handler is doing the right thing, but the cd drive is not. Maybe the
> > > driver is doing something wrong when it issues the erase command, but
> > > I can't convince myself that that is likely.
> >
> > The attached patch seems to correct the problem (at least for me). It
> > is similar to what was done in revision 1.137 of sys/dev/ata/atapi-cd.c
> > (this has been changed since revision 1.138).
>
> Uh oh, that code breaks on lots of newer drives, especially DVD writers
> and drives of SONY origin. There was a reason that code was removed
I guess those DVD writers do not return EBUSY, and burncd returns before
the drive has finished blanking?
Are CD-R(W) drives, like my TEAC CD-W524E, buggy, not returning correct
sense information (progress)? Or is it a -maybe hard to find- software
bug?
Should I file a PR?
Thanks a lot for answering any of these questions...
PS. I added the atapicam driver to the kernel, and I now use cdrecord
for the job...

krishtaf

придется cdrecord использовать

krishtaf

мда, cdrecord рулит

hoha32

ага, makeisofs | cdrecord - рулит, не помню, можно ли пайпить в burncd.

krishtaf

можно

krishtaf

в чем удобство burncd перед cdrecord - в том что не нужно делать лишних телодвижений: ставить порт, компилить ядро и т.п.
а так конечно пох.

hoha32

Более того, афаик, покуда не появилось atapicam - другой альтернативы и не было

krishtaf

во во
а давно в ядро включили ?

hoha32

с 4.8-STABLE, по-моему, в CURRENT была наверное пораньше. два с половиной года назад ещё точно не было.