cdrtools und Cygwin 1.3.18 ff.
Hartmut Welpmann
bekanntlich führt sowohl "cdda2wav -paranoia" als auch "mkisofs |
cdrecord -" unter Cygwin ab Version 1.3.18 zum Einfrieren des
kompletten Systems. Da bisher AFAIK noch keine Lösung des Problems
gefunden wurde, habe ich die aktuellen cdrtools mit
Debug-Informationen kompiliert und mit dem GNU Debugger gdb
untersucht.
Dabei ist mir nach einiger Zeit aufgefallen, dass das Einfrieren immer
in Zusammenhang mit der Änderung der Prozess-Priorität mittels der
Funktionen rt_raisepri() [cdrecord.c] bzw.
switch_to_realtime_priority() [cdda2wav.c] stand. Daraufhin habe ich
eben diese Funktionen testweise selbiger beraubt und die cdrtools neu
kompiliert.
Dadurch sind nicht nur die Systemabstürze bei cdda2wav -paranoia
verschwunden, auch das Pipen von mkisofs nach cdrecord geht jetzt mit
voller Geschwindigkeit [1]! Natürlich kann ich nicht sagen, ob dieser
Patch auch auf anderen Systemen seine Wirkung zeigt, hier mit Cygwin
1.3.22/Windows XP SP1 [2] und Athlon XP 2000+/VIA KT266A funktioniert
es bisher jedenfalls wunderbar.
Meine beiden Patches (über diff -ur erstellt) sind, da ich nicht
weiss, wie, und ob überhaupt, Attachments im Usenet ankommen, im
Klartext am Ende dieses Postings [3 und 4] zu finden. Nochmals sei
darauf hingewiesen, dass ich nicht weiss, welche (möglicherweise
negativen) Auswirkungen sich auf anderen Systemen zeigen - die
Benutzung erfolgt auf eigene Gefahr!
Viele Grüße,
Hartmut
[1] jedenfalls mit 24x, der FIFO-Buffer von cdrecord war
kontinuierlich zu über 95 % gefüllt - eine höhere Geschwindigkeit kann
ich mangels schnellerem Brenner momentan nicht testen.
[2] mit Windows XP-Hotfix Q330909, siehe
http://www.silent-dreams.de/news_april2003_2.html#q811493
[3]
--- cdrecord.org.c 2003-04-29 21:59:14.000000000 +0200
+++ cdrecord.c 2003-05-02 03:29:06.000000000 +0200
@@ -321,8 +321,9 @@
cdr_version,
HOST_CPU, HOST_VENDOR, HOST_OS);
+#define SOURCE_MODIFIED
#ifdef SOURCE_MODIFIED
-#define INSERT_YOUR_EMAIL_ADDRESS_HERE
+#define INSERT_YOUR_EMAIL_ADDRESS_HERE
"hartmut....@gmx.de"
printf("NOTE: this version of cdrecord is an
inofficial (mofified) release of cdrecord\n");
printf(" and thus may have bugs that are not
present in the original version.\n");
printf(" Please send bug reports and support
requests to <%s>.\n", INSERT_YOUR_EMAIL_ADDRESS_HERE);
@@ -3900,20 +3901,7 @@
rt_raisepri(pri)
int pri;
{
- int prios[] = {THREAD_PRIORITY_TIME_CRITICAL,
THREAD_PRIORITY_HIGHEST};
-
- /* set priority class */
- if (SetPriorityClass(GetCurrentProcess(),
REALTIME_PRIORITY_CLASS) == FALSE) {
- errmsgno(EX_BAD, "No realtime priority class
possible.\n");
- return (-1);
- }
-
- /* set thread priority */
- if (pri >= 0 && pri <= 1 &&
SetThreadPriority(GetCurrentThread(), prios[pri]) == FALSE) {
- errmsgno(EX_BAD, "Could not set realtime
priority.\n");
- return (-1);
- }
- return (0);
+ return (1);
}
#else
[4]
--- cdda2wav.org.c 2003-03-31 13:47:33.000000000 +0200
+++ cdda2wav.c 2003-05-02 03:16:54.000000000 +0200
@@ -1003,16 +1003,6 @@
static void
switch_to_realtime_priority()
{
- /* set priority class */
- if (FALSE == SetPriorityClass(GetCurrentProcess(),
REALTIME_PRIORITY_CLASS)) {
- fprintf(stderr, "No realtime priority possible.\n");
- return;
- }
-
- /* set thread priority */
- if (FALSE == SetThreadPriority(GetCurrentThread(),
THREAD_PRIORITY_HIGHEST)) {
- fprintf(stderr, "Could not set realtime priority.\n");
- }
}
#else
static void
--
Hartmut Welpmann
Hartmut Welpmann
bekanntlich führt sowohl "cdda2wav -paranoia" als auch "mkisofs |
cdrecord -" unter Cygwin ab Version 1.3.18 zum Einfrieren des
kompletten Systems. Da bisher AFAIK noch keine Lösung des Problems
gefunden wurde, habe ich die aktuellen cdrtools mit
Debug-Informationen kompiliert und mit dem GNU Debugger gdb
untersucht.
Dabei ist mir nach einiger Zeit aufgefallen, dass das Einfrieren immer
in Zusammenhang mit der Änderung der Prozess-Priorität mittels der
Funktionen rt_raisepri() [cdrecord.c] bzw.
switch_to_realtime_priority() [cdda2wav.c] stand. Daraufhin habe ich
eben diese Funktionen testweise selbiger beraubt und die cdrtools neu
kompiliert.
Dadurch sind nicht nur die Systemabstürze bei cdda2wav -paranoia
verschwunden, auch das Pipen von mkisofs nach cdrecord geht jetzt mit
voller Geschwindigkeit [1]! Natürlich kann ich nicht sagen, ob dieser
Patch auch auf anderen Systemen seine Wirkung zeigt, hier mit Cygwin
1.3.22/Windows XP SP1 [2] und Athlon XP 2000+/VIA KT266A funktioniert
es bisher jedenfalls wunderbar.
Meine beiden Patches (über diff -ur erstellt) sind am Ende dieses
Postings zu finden. Nochmals sei darauf hingewiesen, dass ich nicht
weiss, welche (möglicherweise negativen) Auswirkungen sich auf anderen
Systemen zeigen - die Benutzung erfolgt auf eigene Gefahr!
Viele Grüße,
Hartmut
[1] jedenfalls mit 24x, der FIFO-Buffer von cdrecord war
kontinuierlich zu über 95 % gefüllt - eine höhere Geschwindigkeit kann
ich mangels schnellerem Brenner momentan nicht testen.
[2] mit Windows XP-Hotfix Q330909, siehe
http://www.silent-dreams.de/news_april2003_2.html#q811493
Joerg Schilling
Hartmut Welpmann <hartmut....@gmx.de> wrote:
>Hallo zusammen,
>
>bekanntlich führt sowohl "cdda2wav -paranoia" als auch "mkisofs |
>cdrecord -" unter Cygwin ab Version 1.3.18 zum Einfrieren des
>kompletten Systems. Da bisher AFAIK noch keine Lösung des Problems
>gefunden wurde, habe ich die aktuellen cdrtools mit
>Debug-Informationen kompiliert und mit dem GNU Debugger gdb
>untersucht.
>
>Dabei ist mir nach einiger Zeit aufgefallen, dass das Einfrieren immer
>in Zusammenhang mit der Änderung der Prozess-Priorität mittels der
>Funktionen rt_raisepri() [cdrecord.c] bzw.
>switch_to_realtime_priority() [cdda2wav.c] stand. Daraufhin habe ich
>eben diese Funktionen testweise selbiger beraubt und die cdrtools neu
>kompiliert.
>
>Dadurch sind nicht nur die Systemabstürze bei cdda2wav -paranoia
>verschwunden, auch das Pipen von mkisofs nach cdrecord geht jetzt mit
>voller Geschwindigkeit [1]! Natürlich kann ich nicht sagen, ob dieser
>Patch auch auf anderen Systemen seine Wirkung zeigt, hier mit Cygwin
>1.3.22/Windows XP SP1 [2] und Athlon XP 2000+/VIA KT266A funktioniert
>es bisher jedenfalls wunderbar.
Damit bastelst Du nur an den Symptomen!
Als Ergebnis hast Du eine erheblich höhere Wahrscheinlichkeit für Buffer
underruns. Es ist allgemein bekannt (vielleich nur nicht den RedHat Leuten)
daß es sich um ein durch Cygwin hausgemachtes Problem handelt, denn
alte Cywin Versionen haven nicht dieses Problem.
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schi...@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Hartmut Welpmann
>Hartmut Welpmann <hartmut....@gmx.de> wrote:
>>
>>bekanntlich führt sowohl "cdda2wav -paranoia" als auch "mkisofs |
>>cdrecord -" unter Cygwin ab Version 1.3.18 zum Einfrieren des
>>kompletten Systems. Da bisher AFAIK noch keine Lösung des Problems
>>gefunden wurde, habe ich die aktuellen cdrtools mit
>>Debug-Informationen kompiliert und mit dem GNU Debugger gdb
>>untersucht.
>>
>>Dabei ist mir nach einiger Zeit aufgefallen, dass das Einfrieren immer
>>in Zusammenhang mit der Änderung der Prozess-Priorität mittels der
>>Funktionen rt_raisepri() [cdrecord.c] bzw.
>>switch_to_realtime_priority() [cdda2wav.c] stand. Daraufhin habe ich
>>eben diese Funktionen testweise selbiger beraubt und die cdrtools neu
>>kompiliert.
>>
>>Dadurch sind nicht nur die Systemabstürze bei cdda2wav -paranoia
>>verschwunden, auch das Pipen von mkisofs nach cdrecord geht jetzt mit
>>voller Geschwindigkeit [1]! Natürlich kann ich nicht sagen, ob dieser
>>Patch auch auf anderen Systemen seine Wirkung zeigt, hier mit Cygwin
>>1.3.22/Windows XP SP1 [2] und Athlon XP 2000+/VIA KT266A funktioniert
>>es bisher jedenfalls wunderbar.
>
>Damit bastelst Du nur an den Symptomen!
Das ist klar, das komplette Deaktivieren obiger Funktionen sollte auch
nur ein QAD hack sein, um der Ursache des Problems näher zu kommen.
>Als Ergebnis hast Du eine erheblich höhere Wahrscheinlichkeit für Buffer
>underruns. Es ist allgemein bekannt (vielleich nur nicht den RedHat Leuten)
>daß es sich um ein durch Cygwin hausgemachtes Problem handelt, denn
>alte Cywin Versionen haven nicht dieses Problem.
Das ist auch mir bekannt [1]. Ich habe nun, statt die Funktionen ganz
zu entfernen, lediglich die zu setzende priority class von REALTIME in
HIGH abgeändert. Das funktioniert hier mindestens ebenso gut wie mein
erster Workaround. Offensichtlich bekommt Cygwin unter bestimmten
Bedingungen Probleme, sobald Prozesse mit realtime priority ausgeführt
werden sollen [2].
Es scheint also, dass zur Zeit mehr als high priority für cdrecord
bzw. cdda2wav unter Cygwin nicht drin ist. Spricht also grundsätzlich
etwas dagegen, hier (und nur hier unter Cygwin) das Setzen von
realtime priority zu vermeiden?
Gruß, Hartmut
P.S.: neue Patches siehe unten
[1] siehe <4qn2bvsnd8tdu6pg4...@4ax.com> ;)
[2] und ist offenbar darauf auch gar nicht ausgelegt, siehe
http://sources.redhat.com/ml/cygwin/2002-11/msg01491.html "Cygwin is a
general purpose tool, and internally not quite up to running at
realtime" --Robert Collins
--- cdrecord/cdrecord.org.c 2003-04-29 21:59:14.000000000 +0200
+++ cdrecord/cdrecord.c 2003-05-02 10:16:14.000000000 +0200
@@ -321,8 +321,9 @@
cdr_version,
HOST_CPU, HOST_VENDOR, HOST_OS);
+#define SOURCE_MODIFIED
#ifdef SOURCE_MODIFIED
-#define INSERT_YOUR_EMAIL_ADDRESS_HERE
+#define INSERT_YOUR_EMAIL_ADDRESS_HERE "hartmut....@gmx.de"
printf("NOTE: this version of cdrecord is an inofficial (mofified) release of cdrecord\n");
printf(" and thus may have bugs that are not present in the original version.\n");
printf(" Please send bug reports and support requests to <%s>.\n", INSERT_YOUR_EMAIL_ADDRESS_HERE);
@@ -3903,14 +3904,14 @@
int prios[] = {THREAD_PRIORITY_TIME_CRITICAL, THREAD_PRIORITY_HIGHEST};
/* set priority class */
- if (SetPriorityClass(GetCurrentProcess(), REALTIME_PRIORITY_CLASS) == FALSE) {
- errmsgno(EX_BAD, "No realtime priority class possible.\n");
+ if (SetPriorityClass(GetCurrentProcess(), HIGH_PRIORITY_CLASS) == FALSE) {
+ errmsgno(EX_BAD, "No high priority class possible.\n");
return (-1);
}
/* set thread priority */
if (pri >= 0 && pri <= 1 && SetThreadPriority(GetCurrentThread(), prios[pri]) == FALSE) {
- errmsgno(EX_BAD, "Could not set realtime priority.\n");
+ errmsgno(EX_BAD, "Could not set high priority.\n");
return (-1);
}
return (0);
--- cdda2wav/cdda2wav.org.c 2003-03-31 13:47:33.000000000 +0200
+++ cdda2wav/cdda2wav.c 2003-05-02 10:18:45.000000000 +0200
@@ -1004,14 +1004,14 @@
switch_to_realtime_priority()
{
/* set priority class */
- if (FALSE == SetPriorityClass(GetCurrentProcess(), REALTIME_PRIORITY_CLASS)) {
- fprintf(stderr, "No realtime priority possible.\n");
+ if (FALSE == SetPriorityClass(GetCurrentProcess(), HIGH_PRIORITY_CLASS)) {
+ fprintf(stderr, "No high priority possible.\n");
return;
}
/* set thread priority */
if (FALSE == SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_HIGHEST)) {
- fprintf(stderr, "Could not set realtime priority.\n");
+ fprintf(stderr, "Could not set high priority.\n");
}
}
#else
--
Hartmut Welpmann
Udo Buedel
> bekanntlich führt sowohl "cdda2wav -paranoia" als auch "mkisofs |
> cdrecord -" unter Cygwin ab Version 1.3.18 zum Einfrieren des
> kompletten Systems.
Das Einfrieren kann ich hier nicht nachvollziehen, das hängt vom
verwendeten Rechner ab.
[Änderung der Prozess-Priorität deaktiviert]
> auch das Pipen von mkisofs nach cdrecord geht jetzt mit voller
> Geschwindigkeit [1]!
> [1] jedenfalls mit 24x
Prima, mit der Änderung funktioniert pipen hier auch mit voller
Geschwindigkeit =40x; NT4 und cygwin1.dll 1.3.22.
Gruss Udo
Thomas Plank
> Dadurch sind nicht nur die Systemabstürze bei cdda2wav -paranoia
> verschwunden, auch das Pipen von mkisofs nach cdrecord geht jetzt mit
> voller Geschwindigkeit [1]!
Cool. Bin gerade am Binaries inklusive dieses Patches bauen.
Hat jemand Interesse daran?
> Natürlich kann ich nicht sagen, ob dieser
> Patch auch auf anderen Systemen seine Wirkung zeigt, hier mit Cygwin
> 1.3.22/Windows XP SP1 [2] und Athlon XP 2000+/VIA KT266A funktioniert
> es bisher jedenfalls wunderbar.
Ich werde es testen und mich melden.
> Meine beiden Patches (über diff -ur erstellt) sind am Ende dieses
> Postings zu finden.
Das kannte ich noch gar nicht. Gibt's da eine Möglichkeit das per diff
einzuspielen? Ich hab es jetzt händisch gemacht.
--
und tschüß... Thomas
http://www.sbox.tugraz.at/home/t/tplank
Die neuesten cdrtools (win32-bin; 2.01a11)
und ein Morver-Mirror (1.0.305)
Thomas Plank
> P.S.: neue Patches siehe unten
Jetzt würde mich noch interessieren, wie ich dieses Teil einbaue.
Habe zwar ein bißchen Programmiererfahrung, aber mit Patches etc. noch
nie was zu tun gehabt.
Michael Langner
> Ich habe nun, statt die Funktionen ganz zu entfernen, lediglich
> die zu setzende priority class von REALTIME in HIGH abgeändert.
Ich hoffe es macht dir nix aus, ich habe mal mit dem 2. Patch
kompiliert und die Binaries online gestellt:
<http://www.geoshock.com/cdrtools/files/cdrtools-2.01a12-win32-bin-patched-hw.zip>
Wer das testen will, ohne gcc/cygwin zu installieren kann es mal damit
probieren.
bye,
Michael
Joerg Schilling
Thomas Plank <tpl...@gmx.at> wrote:
>Hartmut Welpmann (hartmut....@gmx.de) wrote:
>
>> P.S.: neue Patches siehe unten
>
>Jetzt würde mich noch interessieren, wie ich dieses Teil einbaue.
>Habe zwar ein bißchen Programmiererfahrung, aber mit Patches etc. noch
>nie was zu tun gehabt.
Du brauchst das Programm "patch" welches um 1980 fuer die Verteilung
der Sourcen des News System entwickelt wurde.... also fast 25 Jahre alt.
Thomas Plank
> Du brauchst das Programm "patch" welches um 1980 fuer die Verteilung
> der Sourcen des News System entwickelt wurde.... also fast 25 Jahre alt.
Danke, gesucht und gefunden. ;-)
Thomas Plank
> Ich werde es testen und mich melden.
So, zu mkisofs | cdrecord bin ich noch nicht gekommen, aber zumindest
cdda2wav habe ich getestet:
Die Abstürze sind tatsächlich verschwunden!
Das Grabben mit dem -paranoia Schalter läuft wieder ordnungsgemäß durch
die Files sind natürlich ok hinterher.
Ich bin begeistert, danke Hartmut, daß du dir die Mühe gemacht hast.
Frederick Page
>>Meine beiden Patches (über diff -ur erstellt) sind am Ende dieses
>>Postings zu finden.
>Das kannte ich noch gar nicht. Gibt's da eine Möglichkeit das per diff
>einzuspielen? Ich hab es jetzt händisch gemacht.
Nicht per diff, aber die erste Zeile von "man patch" sagt:
patch - apply a diff file to an original
Und jetzt ärgere Dich kräftig ;-)
FFPX Frederick
--
Heart Attacks...God's Revenge For Eating His Animal Friends
Michael Langner
[gefixtes cdrecord und cdda2wav]
> Wer das testen will, ohne gcc/cygwin zu installieren kann es mal
> damit probieren.
Normalerweise versuche ich ja zu vermeiden auf mich selbst zu
antworten, aber für ein Supersede isses mir jetzt zu lang her:
Ich kann bestätigen dass der Patch funktioniert, "cdda2wav -paranoia"
mit "realtime" Priorität hat Windows gecrasht, die gepatchte Version
hingegen hat problemlos funktioniert.
Danke Hartmut :).
bye,
Michael
Joerg Hevers
>>> bekanntlich führt sowohl "cdda2wav -paranoia" als auch "mkisofs |
>>> cdrecord -" unter Cygwin ab Version 1.3.18 zum Einfrieren des
>>> kompletten Systems. Da bisher AFAIK noch keine Lösung des Problems
>>> gefunden wurde, habe ich die aktuellen cdrtools mit
>>> Debug-Informationen kompiliert und mit dem GNU Debugger gdb
>>> untersucht.
>>>
>>> Dabei ist mir nach einiger Zeit aufgefallen, dass das Einfrieren immer
>>> in Zusammenhang mit der Änderung der Prozess-Priorität mittels der
>>> Funktionen rt_raisepri() [cdrecord.c] bzw.
>>> switch_to_realtime_priority() [cdda2wav.c] stand. Daraufhin habe ich
>>> eben diese Funktionen testweise selbiger beraubt und die cdrtools neu
>>> kompiliert.
>>>
>>> Dadurch sind nicht nur die Systemabstürze bei cdda2wav -paranoia
>>> verschwunden, auch das Pipen von mkisofs nach cdrecord geht jetzt mit
>>> voller Geschwindigkeit [1]! Natürlich kann ich nicht sagen, ob dieser
>>> Patch auch auf anderen Systemen seine Wirkung zeigt, hier mit Cygwin
>>> 1.3.22/Windows XP SP1 [2] und Athlon XP 2000+/VIA KT266A funktioniert
>>> es bisher jedenfalls wunderbar.
Vielen Dank für Deine Mühe - Du hast sicher vielen Cygwin-Usern, die
cdrecord und cdda2wav nutzen wollen, sehr geholfen!
Ich habe nun auch auf die neueste Cygwin-Version upgedated - und otf-
Brennen geht endlich, wie es soll, mit full-speed und ohne Buffer
Underruns :)
> Es scheint also, dass zur Zeit mehr als high priority für cdrecord
> bzw. cdda2wav unter Cygwin nicht drin ist. Spricht also grundsätzlich
> etwas dagegen, hier (und nur hier unter Cygwin) das Setzen von
> realtime priority zu vermeiden?
Schön, dass wir nun zumindest wissen, woran es liegt. Auch von mir der
Apell an Jörg Schilling, diesen Patch doch (nur für cygwin) in die
offizielle Source mit einfließen zu lassen. Klar liegt der Fehler bei
cygwin, aber darauf zu warten, dass die den irgendwann mal beheben ist
glaube ich nach den bisherigen Erfahrungen nicht sinnvoll.
Insbesondere für cdrecord-ProDVD, wo man selber ja nicht dran
"rumpfuschen" kann, wäre das sicherlich sinnvoll, damit auch damit
mkisofs | cdrecord geht (noch nicht getestet, aber ich befürchte auch
hier die Hänger).
Gruß, Jörg
--
http://www.freedb.org
Die freie Audio-CD Datenbank.
Udo Buedel
[Änderung der Prozess-Priorität deaktiviert]
> Damit bastelst Du nur an den Symptomen!
>
> Als Ergebnis hast Du eine erheblich höhere Wahrscheinlichkeit für
> Buffer underruns.
Unter einem kaputten OS (NT4 cygwin1.dll 1.3.22) stellt sich hier beim
OTF-Brennen ab einer bestimmten Brenngeschwindigkeit ein anderes
Ergebnis dar.
mkisofs cdrecord
Priorität Normal Priorität Echtzeit: buffer läuft leer
Priorität Normal Priorität Normal : buffer bleibt gefüllt
Wenn cdrecord die Daten von einem Image erhält, ist die Echtzeit-
Priorität auch bei NT4 angebracht.
Wäre es denkbar, beim Cygwin OTF-Brennen die Priorität von cdrecord
nicht zu ändern?
Grüsse Udo
Joerg Schilling
Udo Buedel <odul...@web.de> wrote:
>Unter einem kaputten OS (NT4 cygwin1.dll 1.3.22) stellt sich hier beim
>OTF-Brennen ab einer bestimmten Brenngeschwindigkeit ein anderes
>Ergebnis dar.
>
>mkisofs cdrecord
>Priorität Normal Priorität Echtzeit: buffer läuft leer
>Priorität Normal Priorität Normal : buffer bleibt gefüllt
>
>Wenn cdrecord die Daten von einem Image erhält, ist die Echtzeit-
>Priorität auch bei NT4 angebracht.
>
>Wäre es denkbar, beim Cygwin OTF-Brennen die Priorität von cdrecord
>nicht zu ändern?
Daran sieht man, dasz es sich um einen offensichtlichen Bug von Cygwin handelt.
Pipes unter Win32 sind unvollstaendig (nonstandard). Sie enthalten
nicht die automatische Fluszsteuerung. Das ist was Cygwin dazubaut.
Wenn es also bei der Fluszsteuerung hakt, dann haben wir einen Cygwin Bug
der sicherlich nie repariert wird, wenn ich auf die hohe Prioritaet
verzichte.