Am Donnerstag, 2. September 2004 23:45 schrieben Sie:
On Thu, Sep 02, 2004 at 07:34:36PM +0200, Manfred Eifler wrote:
Lothar, vielen Dank. Ich habe allerdings vergeblich den 95-ziger Kernel gesucht. SuSE hat ihn von den Servern genommen. Werde dann wohl den von der
dummerweise hab ich das '95er Kernel rpm vor ein paar Tagen gelöscht, könnte dir allerdings ein komplettes /boot incl '95er Kernel schicken.
Vielen Dank für das Angebot, es ist aber nicht mehr nötig. Ich hatte gestern den Originalkernel der SuSE9.1 wieder installiert. Leider habe ich auch bei diesem die Brennabbrüche bei den Daten-CD's auf meine CDRW's (Brenngeschwindigkeit 4-fach). Folglich kann es nicht am Kernel liegen, so dass ich den 108-ter wieder installiert habe. Aber irgendein Upate ist dran schuld. Es hatte (auch) mit SuSE9.1 problemlos funktioniert. :-(( -- Gruß Manfred
Am Samstag, 4. September 2004 13:12 schrieb Manfred Eifler:
Vielen Dank für das Angebot, es ist aber nicht mehr nötig. Ich hatte gestern den Originalkernel der SuSE9.1 wieder installiert. Leider habe ich auch bei diesem die Brennabbrüche bei den Daten-CD's auf meine CDRW's (Brenngeschwindigkeit 4-fach). Folglich kann es nicht am Kernel liegen, so dass ich den 108-ter wieder installiert habe.
Aber irgendein Upate ist dran schuld. Es hatte (auch) mit SuSE9.1 problemlos funktioniert. :-((
Ich brenne mit 2.6.5-7.108-default und _gefühlsmäßig_ wird der Puffer leerer. Vorher war der minimal bei 80-90% bei 4x DVD und nun schaffe ich um die 30% mit 2x DVD, wenn ich _aufpasse_ was ich mache. hdparm -i /dev/hda UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 hdparm -i /dev/hdb UDMA modes: udma0 udma1 *udma2 hdparm -i /dev/hdc Model=HL-DT-ST DVDRAM GSA-4040B, FwRev=A301 UDMA modes: udma0 udma1 *udma2 hdparm -i /dev/hdd UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 Es ist also überall DMA aktiviert. Die Brennquelle ist auf /dev/hda und somit wird ein anderer IDE-Kanal vom Brenner benutzt. Früher konnte ich parallel auf der HD kopieren und ein updatedb machte auch keine Probleme bzgl. Buffer-Underrun und nun muss ich schon sehr aufpassen. Wenn ich mir die während des Brennvorgangs gewünschten Programme, wie KMail, KNode, OO etc. vorher öffne, dann kann man weiterarbeiten, wenn man sich überlegt was man tut und somit ist es für mich erträglich. Ein Brennen dauert ja nicht so lange. Die Frage ist, ob da Teile des 2.6.8 bereits gepatcht wurden und damit DMA wieder "kaputter" wurde. Unter 2.6.8 gibt es ja bekanntermassen Probleme, wenn man nicht als root brennt. Al
Am Samstag, 4. September 2004 13:40 schrieb Al Bogner:
Am Samstag, 4. September 2004 13:12 schrieb Manfred Eifler:
Vielen Dank für das Angebot, es ist aber nicht mehr nötig. Ich hatte gestern den Originalkernel der SuSE9.1 wieder installiert. Leider habe ich auch bei diesem die Brennabbrüche bei den Daten-CD's auf meine CDRW's (Brenngeschwindigkeit 4-fach). Folglich kann es nicht am Kernel liegen, so dass ich den 108-ter wieder installiert habe.
Aber irgendein Upate ist dran schuld. Es hatte (auch) mit SuSE9.1 problemlos funktioniert. :-((
Ich brenne mit 2.6.5-7.108-default und _gefühlsmäßig_ wird der Puffer leerer. Vorher war der minimal bei 80-90% bei 4x DVD und nun schaffe ich um die 30% mit 2x DVD, wenn ich _aufpasse_ was ich mache.
Hab gestern auf meiner Tochter ihrem Rechner eine Musik-CD gebrannt (Model=Hewlett-Packard CD-Writer Plus 8100). Der brennt normalerweise 4-fach. Die Geschwindigkeit wurde auf 2-fach runtergesetzt und der Puffer war gerade mal zwischen ca. 2 und 4 % gefüllt. Der DMA ist auch eingeschalten. Verstehe ich auch nicht. Zumindest hat er aber den Brennvorgang durchgezogen. Bei meinem Brenner (Model=LITE-ON LTR-48246K) ist der Puffer voll. Ich glaube nicht, dass es mit DMA etwas zu tun hat.
Früher konnte ich parallel auf der HD kopieren und ein updatedb machte auch keine Probleme bzgl. Buffer-Underrun und nun muss ich schon sehr aufpassen. Wenn ich mir die während des Brennvorgangs gewünschten Programme, wie KMail, KNode, OO etc. vorher öffne, dann kann man weiterarbeiten, wenn man sich überlegt was man tut und somit ist es für mich erträglich. Ein Brennen dauert ja nicht so lange.
Kann ich ich nur bestätigen.
Die Frage ist, ob da Teile des 2.6.8 bereits gepatcht wurden und damit DMA wieder "kaputter" wurde. Unter 2.6.8 gibt es ja bekanntermassen Probleme, wenn man nicht als root brennt.
Ich weiß nicht. Ich habe alles mögliche versucht mit: chmod 4711 /usr/bin/cdr... und chmod 0755 /usr/bin/cdr..., mit allen drei Programmen. Es hat nichts gebracht. Bei meinem Brennvorgang ist der Puffer immer voll. Er wird nur einfach irgendwann abgebrochen. Gestern habe ich ca. 5 CDRW-s probiert. Eine konnte ich voll brennen, alle anderen nicht. Es ist einfach nur zum k... . (Entschuldigung) -- Gruß Manfred
Am Samstag, 4. September 2004 14:10 schrieb Manfred Eifler:
Am Samstag, 4. September 2004 13:40 schrieb Al Bogner:
Am Samstag, 4. September 2004 13:12 schrieb Manfred Eifler:
Vielen Dank für das Angebot, es ist aber nicht mehr nötig. Ich hatte gestern den Originalkernel der SuSE9.1 wieder installiert. Leider habe ich auch bei diesem die Brennabbrüche bei den Daten-CD's auf meine CDRW's (Brenngeschwindigkeit 4-fach). Folglich kann es nicht am Kernel liegen, so dass ich den 108-ter wieder installiert habe.
Aber irgendein Upate ist dran schuld. Es hatte (auch) mit SuSE9.1 problemlos funktioniert. :-((
Ich habe es nun auf einem anderen Rechner probiert, der alle Updates bis auf den Kernel hat und Kernel 2.6.5-7.95 verwendet. Zusammenfassung: Average write speed 8.0x. Min drive buffer fill was 99% fifo was 0 times empty and 12555 times full, min fill was 99%. Wenn da nicht der Kernel Schuld ist ... Details: gebrannt wurde auf eine Lidl/Octron CD-RW mit einem MSI-Brenner. Cdrecord ist von den aktuellen Sourcen selbst kompiliert. /opt/schily/bin/cdrecord: Warning: Running on Linux-2.6.5-7.95-default /opt/schily/bin/cdrecord: There are unsettled issues with Linux-2.5 and newer. /opt/schily/bin/cdrecord: If you have unexpected problems, please try Linux-2.4 or Solaris. scsidev: 'ATA:1,0,0' devname: 'ATA' scsibus: 1 target: 0 lun: 0 Warning: Using badly designed ATAPI via /dev/hd* interface. Linux sg driver version: 3.5.27 SCSI buffer size: 64512 Cdrecord-Clone 2.01a38 (i686-pc-linux-gnu) Copyright (C) 1995-2004 J�g Schilling TOC Type: 1 = CD-ROM Using libscg version 'schily-0.8'. Driveropts: 'burnfree' atapi: -1 Device type : Removable CD-ROM Version : 0 Response Format: 1 Vendor_info : 'ATAPI ' Identifikation : 'CD-RW 48XMax ' Revision : '180D' Device seems to be: Generic mmc CD-RW. Current: 0x000A Profile: 0x0008 Profile: 0x0009 Profile: 0x000A (current) Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). Driver flags : MMC-3 SWABAUDIO BURNFREE Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R Drive buf size : 1658880 = 1620 KB Drive DMA Speed: 23122 kB/s 131x CD 16x DVD FIFO size : 33554432 = 32768 KB Encoding speed : 297x (22230 sectors/s) for libedc from Heiko Ei�eldt Track 01: data 663 MB padsize: 30 KB Total size: 762 MB (75:30.66) = 339800 sectors Lout start: 762 MB (75:32/50) = 339800 sectors Current Secsize: 2048 ATIP info from disk: Indicated writing power: 2 Reference speed: 6 Is not unrestricted Is erasable Disk sub type: High speed Rewritable (CAV) media (1) ATIP start of lead in: -12900 (97:10/00) ATIP start of lead out: 359849 (79:59/74) 1T speed low: 4 1T speed high: 10 2T speed low: 4 2T speed high: 0 (reserved val 6) power mult factor: 1 5 recommended erase/write power: 5 A1 values: 24 1A D8 A2 values: 26 B2 48 Disk type: unknown dye (reserved id code) Manuf. index: -1 Manufacturer: unknown (not in table) Manufacturer is unknown because of the orange forum embargo. As the orange forum likes to get money for recent information, it may be that this media does not use illegal manufacturer coding. Blocks total: 359849 Blocks current: 359849 Blocks remaining: 20049 Starting to write CD/DVD at speed 8 in real RAW/RAW96R mode for single session. Last chance to quit, starting real write 0 seconds. Operation starts. Waiting for reader process to fill input buffer ... input buffer ready. BURN-Free is OFF. Turning BURN-Free on Performing OPC... /opt/schily/bin/cdrecord: WARNING: Drive returns wrong startsec (0) using -12900 from ATIP Writing lead-in at sector -12900 Lead-in write time: 27.520s Writing pregap for track 1 at -150 Starting new track at sector: 0 Track 01: 793 of 793 MB written (fifo 100%) [buf 99%] 8.0x. Track 01: writing 35 KB of pad data. Track 01: Total bytes read/written: 831793680/831830400 (339800 sectors). Writing time: 594.150s Average write speed 8.0x. Min drive buffer fill was 99% Writing Leadout... Fixating... Fixating time: 13.146s /opt/schily/bin/cdrecord: fifo had 13069 puts and 13069 gets. /opt/schily/bin/cdrecord: fifo was 0 times empty and 12555 times full, min fill was 99%. Al
Am Samstag, 4. September 2004 16:53 schrieb Al Bogner:
Am Samstag, 4. September 2004 14:10 schrieb Manfred Eifler:
Am Samstag, 4. September 2004 13:40 schrieb Al Bogner:
Am Samstag, 4. September 2004 13:12 schrieb Manfred Eifler:
Vielen Dank für das Angebot, es ist aber nicht mehr nötig. Ich hatte gestern den Originalkernel der SuSE9.1 wieder installiert. Leider habe ich auch bei diesem die Brennabbrüche bei den Daten-CD's auf meine CDRW's (Brenngeschwindigkeit 4-fach). Folglich kann es nicht am Kernel liegen, so dass ich den 108-ter wieder installiert habe.
Aber irgendein Upate ist dran schuld. Es hatte (auch) mit SuSE9.1 problemlos funktioniert. :-((
Ich habe es nun auf einem anderen Rechner probiert, der alle Updates bis auf den Kernel hat und Kernel 2.6.5-7.95 verwendet.
Zusammenfassung: Average write speed 8.0x. Min drive buffer fill was 99% fifo was 0 times empty and 12555 times full, min fill was 99%.
Wenn da nicht der Kernel Schuld ist ...
Ich hab jetzt auf eine CDR probiert (Simulation), auch mit verschiedenen Geschwindigkeiten. Ebenfalls keine Probleme. Sowohl Daten, als auch Audio. Voller Puffer und voll gebrannt. CDRW rein ---> aus nach irgendwo über 50 %. Alles mit Kernel 2.6.5-7.108 Überlegungen: 1. Die CDRW's waren schon mal gebrannt. Wenn ich diese "komplett" löschen will, bekomme ich nach langer Zeit die Meldung, dass sie nicht gelöscht werden können, was sie aber sind. "Schnell" löschen macht keine Probleme. Kann das die Ursache sein, dass sie nicht "komplett" gelöscht werden (können)? Und warum. Medium- oder Softwarefehler? Leider habe ich keine jungfräuliche CDRW mehr zu Hause um bei so einer probieren zu können. 2. Die CDRW's sind mit Zweckfom-CD-Aufkleber versehen. Kann das die Ursache sein? -- Gruß Manfred
Am Samstag, 4. September 2004 17:52 schrieb Manfred Eifler:
1. Die CDRW's waren schon mal gebrannt. Wenn ich diese "komplett" löschen will, bekomme ich nach langer Zeit die Meldung, dass sie nicht gelöscht werden können, was sie aber sind. "Schnell" löschen macht keine Probleme. Kann das die Ursache sein, dass sie nicht "komplett" gelöscht werden (können)? Und warum. Medium- oder Softwarefehler? Leider habe ich keine jungfräuliche CDRW mehr zu Hause um bei so einer probieren zu können.
Probier mal cdrdao. Der Brenner mit dem "guten Test" ist auch mit cdrecord zum Löschen nicht glücklich, will meist schnell gelöschte Rohlinge nicht, funktioniert aber sehr gut mit von cdrdao voll gelöschten. Der selbe Rohling in einem anderen Brenner funktioniert mit cdrecord problemlos. Eventuell haben wir beide unterschiedliche Probleme. Al
Am Samstag, 4. September 2004 18:05 schrieb Al Bogner:
Am Samstag, 4. September 2004 17:52 schrieb Manfred Eifler:
1. Die CDRW's waren schon mal gebrannt. Wenn ich diese "komplett" löschen will, bekomme ich nach langer Zeit die Meldung, dass sie nicht gelöscht werden können, was sie aber sind. "Schnell" löschen macht keine Probleme. Kann das die Ursache sein, dass sie nicht "komplett" gelöscht werden (können)? Und warum. Medium- oder Softwarefehler? Leider habe ich keine jungfräuliche CDRW mehr zu Hause um bei so einer probieren zu können.
Probier mal cdrdao. Der Brenner mit dem "guten Test" ist auch mit cdrecord zum Löschen nicht glücklich, will meist schnell gelöschte Rohlinge nicht, funktioniert aber sehr gut mit von cdrdao voll gelöschten. Der selbe Rohling in einem anderen Brenner funktioniert mit cdrecord problemlos.
Danke, ist aber mit cdrdao genau das Gleiche. -- Gruß Manfred
participants (2)
-
Al Bogner
-
Manfred Eifler