Jozef Babjak napsal/wrote, On 04/07/08 06:55:
>> > $ burncd -e -v -f /dev/acd0 -s max blank
>> >
>> > Program nechtel skoncit.
>>
>> Zajimavejsi bylo podivat se na LEDky te vypalovacky. Nevim jaks
>> dlouho
>> cekal, ale treba proste nemela hotovo.
>
> ^-- Mala. Je to know-issue, nechce sa mi to teraz googlit, urcite si
> to vygoogli, kto to potrebuje.
Ne tak uplne. Known issue je popsano tady:
http://www.freebsd.org/cgi/query-pr.cgi?pr=83702
http://www.freebsd.org/cgi/query-pr.cgi?pr=95344
http://www.freebsd.org/cgi/query-pr.cgi?pr=98082
http://www.freebsd.org/cgi/query-pr.cgi?pr=104270
http://www.freebsd.org/cgi/query-pr.cgi?pr=109270
(nenechte se zmast, to vsechno ej tentyz problem v nekolika inkarnacich)
- jenze o tom se ma zato, ze jde o problem vyreseny.
Tohle je pravdepodobne samostatny problem, nanestesti s podobnymi
projevy.
> Udajne sa toto prejavuje v kombinacii s niektorymi mechanikami.
Ano, zatim se mi zda, ze to je chyba ve funkci acd_get_progress
(vnitrne pouziva v ramci aplikacniho ioctl CDRIOCGETPROGRESS), ktera
vraci nulu v pripade, ze jeste neni hotovo nebo velikost media, v
pripade, ze uz hotovo je. Jenze, nektere mechaniky na cistem
nenaformatovanem mediu hlasi velikost vlozeneho media nulovou, takze
funkce vraci i v "hotovem" case cislo shodne s "nehotovym" stavem. Tim
vznika ona nekonecna smycka.
Jen jsem si jeste nenacetl v ATAPI dokumentaci, jestli je "vraceni
nuly" pripustne nebo jde o nestandardni chovani mechaniky. V kazdem
pripade, at uz je chyba v implementaci na strane standardu nebo uvnitr
OS, oprava si vyzada zmeny v teto logice a mozna take v one smycce v
burncd, ktera se mi ted zda take podivna (presneji receni, podivna je
ukoncujici podminka).
Dan
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
