# [solved] CDs brennen mit Kernel 2.6.9 geht überhaupt nicht

## mrsteven

Hallo!

Langsam regt es mich ziemlich auf, ich will endlich mal wieder vernünftig brennen können (Kernel 2.6.8 hatte ja Probleme mit Audio-CDs), aber nix ist:

Als normaler User klappt es gar nicht, egal ob cdrecord das suid-Bit gesetzt hat oder nicht. Die Berechtigungen stimmen auch, also mein Standarduser darf auf das Device lesend und schreibend zugreifen. Trotzdem bricht cdrecord mit einer Fehlermeldung ab. Eine Suche im Internet ergab, dass der direkte Zugriff auf die CD-Brenner-Hardware für normale User aus Sicherheitsgründen gesperrt wurde. So weit so gut, aber mit Set-UID sollte es ja eigentlich trotzdem gehen. Eigentlich ein klarer Bug...

Als root gibt es ständig Buffer Underruns, obwohl der cdrecord-Prozess eigentlich mit erhöhter Priorität läuft und der Rechner sonst gar nix zu tun hat (kein cronjob, keine Useraktivität). Der Laufwerkspuffer leert sich einfach langsam, bis irgendwann nix mehr drin ist.

Hier die entsprechende Fehlermeldung zu 2.

```

cdrecord: No write mode specified.

cdrecord: Asuming -tao mode.

cdrecord: Future versions of cdrecord may have different drive dependent defaults.

cdrecord: Continuing in 5 seconds...

Cdrecord-Clone 2.01 (i686-pc-linux-gnu) Copyright (C) 1995-2004 Jörg Schilling

cdrecord: Warning: Running on Linux-2.6.9

cdrecord: There are unsettled issues with Linux-2.5 and newer.

cdrecord: If you have unexpected problems, please try Linux-2.4 or Solaris.

cdrecord: Warning: Linux-2.6.8 introduced incompatible interface changes.

cdrecord: Warning: SCSI transport does no longer work for suid root programs.

cdrecord: Warning: if cdrecord fails, try to run it from a root account.

TOC Type: 0 = CD-DA

scsidev: 'ATAPI:0,0,0'

devname: 'ATAPI'

scsibus: 0 target: 0 lun: 0

Warning: Using ATA Packet interface.

Warning: The related Linux kernel interface code seems to be unmaintained.

Warning: There is absolutely NO DMA, operations thus are slow.

Using libscg version 'schily-0.8'.

SCSI buffer size: 64512

atapi: 1

Device type    : Removable CD-ROM

Version        : 0

Response Format: 2

Capabilities   :

Vendor_info    : 'TOSHIBA '

Identifikation : 'DVD-ROM SD-R2512'

Revision       : '1720'

Device seems to be: Generic mmc2 DVD-ROM.

Current: 0x0009

Profile: 0x0010

Profile: 0x0008

Profile: 0x0009 (current)

Profile: 0x000A

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/R96R

Drive buf size : 1791936 = 1749 KB

FIFO size      : 26214400 = 25600 KB

Track 01: audio   32 MB (03:10.74) no preemp pad

Track 02: audio   23 MB (02:18.55) no preemp pad

Track 03: audio   18 MB (01:52.09) no preemp pad

Track 04: audio   44 MB (04:25.95) no preemp pad

Track 05: audio   25 MB (02:32.37) no preemp pad

Track 06: audio   57 MB (05:44.00) no preemp pad

Track 07: audio   41 MB (04:09.18) no preemp pad

Track 08: audio   35 MB (03:31.51) no preemp pad

Track 09: audio   42 MB (04:15.47) no preemp pad

Track 10: audio   19 MB (01:57.81) no preemp pad

Track 11: audio   38 MB (03:51.00) no preemp pad

Track 12: audio   33 MB (03:20.64) no preemp pad

Track 13: audio   28 MB (02:49.95) no preemp pad

Track 14: audio   40 MB (03:58.96) no preemp pad

Track 15: audio   41 MB (04:05.16) no preemp pad

Track 16: audio   54 MB (05:24.91) no preemp pad

Track 17: audio   33 MB (03:18.61) no preemp pad

Track 18: audio   20 MB (02:01.99) no preemp pad

Track 19: audio   58 MB (05:46.20) no preemp pad

Track 20: audio   32 MB (03:15.68) no preemp pad

Track 21: audio   28 MB (02:48.28) no preemp pad

Track 22: audio   42 MB (04:13.31) no preemp pad

Total size:      803 MB (79:34.58) = 358094 sectors

Lout start:      803 MB (79:36/44) = 358094 sectors

Current Secsize: 2048

ATIP info from disk:

  Indicated writing power: 6

  Is not unrestricted

  Is not erasable

  Disk sub type: Medium Type C, low Beta category (C-) (6)

  ATIP start of lead in:  -11231 (97:32/19)

  ATIP start of lead out: 359846 (79:59/71)

Disk type:    Short strategy type (Phthalocyanine or similar)

Manuf. index: 27

Manufacturer: Prodisc Technology Inc.

Blocks total: 359846 Blocks current: 359846 Blocks remaining: 1752

Starting to write CD/DVD at speed 24 in real TAO 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.

Performing OPC...

Starting new track at sector: 0

Track 01:   32 of   32 MB written (fifo 100%) [buf  95%]   8.1x.

WARNING: padding up to secsize.

Track 01: Total bytes read/written: 33647804/33650064 (14307 sectors).

Starting new track at sector: 14459

Track 02:   23 of   23 MB written (fifo 100%) [buf  95%]   8.4x.

WARNING: padding up to secsize.

Track 02: Total bytes read/written: 24441020/24441984 (10392 sectors).

Starting new track at sector: 25003

Track 03:   18 of   18 MB written (fifo 100%) [buf  95%]   8.1x.

WARNING: padding up to secsize.

Track 03: Total bytes read/written: 19773116/19773264 (8407 sectors).

Starting new track at sector: 33562

Track 04:   44 of   44 MB written (fifo 100%) [buf  95%]   8.5x.

WARNING: padding up to secsize.

Track 04: Total bytes read/written: 46914236/46915344 (19947 sectors).

Starting new track at sector: 53661

Track 05:   25 of   25 MB written (fifo 100%) [buf  95%]   8.4x.

WARNING: padding up to secsize.

Track 05: Total bytes read/written: 26878652/26878656 (11428 sectors).

Starting new track at sector: 65241

Track 06:   57 of   57 MB written (fifo 100%) [buf  95%]   8.1x.

WARNING: padding up to secsize.

Track 06: Total bytes read/written: 60682940/60683952 (25801 sectors).

Starting new track at sector: 91194

Track 07:   41 of   41 MB written (fifo 100%) [buf  95%]  12.5x.

WARNING: padding up to secsize.

Track 07: Total bytes read/written: 43955900/43956528 (18689 sectors).

Starting new track at sector: 110035

Track 08:   35 of   35 MB written (fifo 100%) [buf  94%]  12.5x.

WARNING: padding up to secsize.

Track 08: Total bytes read/written: 37311164/37312128 (15864 sectors).

Starting new track at sector: 126051

Track 09:   42 of   42 MB written (fifo 100%) [buf  95%]  12.1x.

WARNING: padding up to secsize.

Track 09: Total bytes read/written: 45066428/45066672 (19161 sectors).

Starting new track at sector: 145364

Track 10:   19 of   19 MB written (fifo 100%) [buf  95%]  12.6x.

WARNING: padding up to secsize.

Track 10: Total bytes read/written: 20782268/20782272 (8836 sectors).

Starting new track at sector: 154352

Track 11:   38 of   38 MB written (fifo 100%) [buf  95%]  12.1x.

WARNING: padding up to secsize.

Track 11: Total bytes read/written: 40748732/40750752 (17326 sectors).

Starting new track at sector: 171830

Track 12:   33 of   33 MB written (fifo 100%) [buf  95%]  12.5x.

WARNING: padding up to secsize.

Track 12: Total bytes read/written: 35394236/35395248 (15049 sectors).

Starting new track at sector: 187031

Track 13:   28 of   28 MB written (fifo 100%) [buf  95%]  12.1x.

WARNING: padding up to secsize.

Track 13: Total bytes read/written: 29979836/29980944 (12747 sectors).

Starting new track at sector: 199930

Track 14:   40 of   40 MB written (fifo 100%) [buf  95%]  12.2x.

WARNING: padding up to secsize.

Track 14: Total bytes read/written: 42154172/42154896 (17923 sectors).

Starting new track at sector: 218005

Track 15:   41 of   41 MB written (fifo 100%) [buf  25%]  15.4x.

WARNING: padding up to secsize.

Track 15: Total bytes read/written: 43246268/43248576 (18388 sectors).

Starting new track at sector: 236545

Track 16:   18 of   54 MB written (fifo 100%) [buf  10%]  15.2x.cdrecord: Input/output error. write_g1: scsi sendcmd: no error

CDB:  2A 00 00 03 BC E9 00 00 1B 00

status: 0x2 (CHECK CONDITION)

Sense Bytes: 70 00 03 00 00 00 00 0A 00 00 00 00 0C 00 00 00 00 00

Sense Key: 0x3 Medium Error, Segment 0

Sense Code: 0x0C Qual 0x00 (write error) Fru 0x0

Sense flags: Blk 0 (not valid)

cmd finished after 1.527s timeout 40s

write track data: error after 19813248 bytes

cdrecord: A write error occured.

cdrecord: Please properly read the error message above.

Writing  time:  376.654s

Average write speed  12.7x.

Min drive buffer fill was 10%

Fixating...

Fixating time:   28.772s

cdrecord: fifo had 9395 puts and 8997 gets.

cdrecord: fifo was 0 times empty and 8831 times full, min fill was 96%.

```

Auffällig sind vor allem Track 15 u. 16. Warum wird der Puffer auf einmal leer? Die DMA-Meldung hatte ich mit dem 2.6.7er auch schon, aber da ging es trotzdem. Falls es daran liegen sollte: Wie schalte ich es für den Brenner an (UDMA für die HDD geht) ? Die Kerneloption "enable DMA only for disks" ist aus.

----------

## boris64

gleiche probleme irgendwie hier, wobei ich wieder bei meiner standardfrage wäre:

kennt den niemand hier eine alternative zu den cdrtools?

bei mir versagt übrigens dauernd cdrdao (wegen angeblichen "buffer underrun"),

und dabei will ich doch nur die gentoo-livecd mit integriertem wm brennen.

----------

## mrsteven

 *borisdigital wrote:*   

> kennt den niemand hier eine alternative zu den cdrtools?

 

Meinst du, das liegt an den cdrtools und nicht am Kernel? Ich kann mich nicht erinnern, solche Probleme mit dem 2.6.7 gehabt zu haben, kann aber auch an den neuen cdrtools-2.01 liegen.

----------

## piewie

In de.comp.hardware.brenner liest man von Jörg Schilling dazu folgendes:

 *Quote:*   

> Kurz vor dem Kern 2.6.8 wurde bemerkt, daß in dem ioctl() der zum Versenden von 
> 
> SCSI Kommandos unter Linux verwendet wird ein typischer Anfängerfehler bei der 
> 
> Implementierung gemacht wurde.
> ...

 Last edited by piewie on Fri Oct 22, 2004 9:20 pm; edited 1 time in total

----------

## Nope

Hallo!

ich bin ein wenig verwirrt. 

 *mrsteven wrote:*   

> 
> 
> [*]Als root gibt es ständig Buffer Underruns, obwohl der cdrecord-Prozess eigentlich mit erhöhter Priorität läuft und der Rechner sonst gar nix zu tun hat (kein cronjob, keine Useraktivität). Der Laufwerkspuffer leert sich einfach langsam, bis irgendwann nix mehr drin ist.
> 
> ```
> ...

 

Warum schaltest Du BurnFree nicht ein? Oder habe ich was verpast oder nicht begriffen? 

Nope

----------

## boris64

@mrsteven

tja, ich fürchte, da ist wohl was dran (siehe auch den post von "piewie").

ehrlich gesagt wünsche ich mir nur, dass ich wieder vernünftig brennen kann.

wenn es eine funktionierende alternative zu den cdrtools gäbe, würde ich 

einfach irgendwie "umsteigen" wollen.

eine art "kernelupdate"-sperre (weil es ja scheinbar mit >2.6.7 nicht mehr so ganz klappen will)

kommt dagegen nicht wirklich in frage.

greetz  :Wink: 

----------

## ralph

@piewie:

Kann es sein, dass wir den von dir zitierten Erguss dem zu recht so beliebten Autor von cdrecord, Herrn Schilling verdanken?

----------

## piewie

 *Quote:*   

> @piewie:
> 
> Kann es sein, dass wir den von dir zitierten Erguss dem zu recht so beliebten Autor von cdrecord, Herrn Schilling verdanken?

 

Das ist richtig. Wer könnte auch besser etwas zu diesem Thema sagen? Werde den Autor mal der Vollständigkeit halber noch hinzufügen.

----------

## mrsteven

 *Nope wrote:*   

> 
> 
> Warum schaltest Du BurnFree nicht ein? Oder habe ich was verpast oder nicht begriffen? 
> 
> Nope

 

Es handelt sich hier um eine Audio-CD. Bei denen bringt BurnFree meines wissens nichts.

----------

## hoschi

 *piewie wrote:*   

>  *Quote:*   @piewie:
> 
> Kann es sein, dass wir den von dir zitierten Erguss dem zu recht so beliebten Autor von cdrecord, Herrn Schilling verdanken? 
> 
> Das ist richtig. Wer könnte auch besser etwas zu diesem Thema sagen? Werde den Autor mal der Vollständigkeit halber noch hinzufügen.

 

hmmmmm, irgend was sagt mir dass dieser autor zu recht allgemein als volltrottel gilt?!

http://www.heise.de/newsticker/result.xhtml?url=/newsticker/meldung/50307&words=cdrecord%20Cdrecord

----------

## Pylon

 *mrsteven wrote:*   

> 
> 
> Es handelt sich hier um eine Audio-CD. Bei denen bringt BurnFree meines wissens nichts.

 

Audio-CDs machen -- laut den Bugreports, die ich derzeit kriege -- sowieso Probleme.  Ich konnte es bisher noch nicht verifizieren.

Hab vorhin mal eine Daten-CD unter 2.6.9 gebrannt.  Keine Probleme.  Auf jeden Fall schon mal besser als mit 2.6.8*.  Aber immer noch bleibt CD- und DVD-Brennen unter Linux eine Qual.  Problem ist schlicht, dass es nichn viel Auswahl gibt.  Und dieses eine Tool, welches fuer CD-Brennen bestimmt ist, kann noch nichtmals DVD brennen.  Dazu soll man sich eine binaere Version installieren, die nur auf Solaris und i586-linux aktuell ist.  Das macht natuerlich Spass, wenn der DVD-Brenner in einem PowerPC sitzt.

Andere Loesungen wie die dvd+rw-tools oder dvdrtools sehe ich momentan als Frickel-Loesungen an.  Sie erfuellen ihren Zweck, bis es mal eine ordentliche Abloesung gibt.  Doch ich glaub, da koennen wir noch eine Weile warten.  Manchmal moechte ich einfach nur  aufgrund der verfahrenen Situation kotzen.

----------

## amne

 *hoschi wrote:*   

> 
> 
> hmmmmm, irgend was sagt mir dass dieser autor zu recht allgemein als volltrottel gilt?!
> 
> 

 

Umstrittene Persönlichkeit, die fragwürdige Aktionen setzt ja, das Wort Volltrottel möchte ich aber bitte dennoch nicht mehr hier im Forum lesen.

----------

## piewie

@hoschi

Wo ist Dein Problem? Wenn eine Anwendung über Jahre hinweg zuverlässig funktioniert hat, dann sind das die cdrtools. Hättest Du den Artikel gelesen, auf den Du verwiesen hast. dann wüßtest Du, daß eben dieses Programm auf 30 Betriebssysten läuft. Ein VI wäre dazu sicher nicht in der Lage. 

Wenn es unter irgendwelchen Distributionen zu Problemen mit den cdrtools kommt, dann lautet der erste Tip: "Nimm die original Sourcen". 

Wenn cdrtools mal irgenwelche Macken haben, dann sind es garantiert von SuSE oder Mandrake gepachte Versionen. 

Diese zur Mode gewordenen Beschimpfungen gegen Jörg Schilling sind grundsätzlich immer nur beleidigend und entbehren jeden sachlichen Bezuges. Symptome werden kollektiv beschrien, statt Ursachen zu beseitigen Statt mal Stellung zu nehmen, verstummen Entwickler wie Jens Axboe ganz plötzlich. Da hat sich doch tatsächlich ein kompetenter Entwickler herausgenommen den Ansatz vom großen Linus zu kritisieren. 

Ein Hinweis auf fehlerhafte Implementationen im linux kernel halte ich für durchaus legitim. Ich an seiner Stelle würde linux schon gar nicht mehr berücksichtigen. Dieses Gezeter würde ich mir gar nicht geben über so viele Jahre. Dann müssen die Leute eben sehen, wie sie ihre CDs brennen.

Und bevor jetzt die üblichen Beschimpfungen ansetzen, verwendet Eure Energie doch auf die Erstellung eines Brennprogramms. Schlagt Euch doch mal mit den Eigenschaften der SCSI- und ATAPI Schnittstelle herum. Und sollte am Schluß wirklich ein funktionierendes Programm herauskommen, dann drücke ich dem Entwickler auch die Daumen, daß es nach dem nächsten kernel-update noch funktioniert.

----------

## Polynomial-C

Hi,

habe vorgestern ebenfalls die Erfahrung gemacht, daß das Brennen seit Kernel 2.6.8 faktisch nicht mehr möglich ist (zumindest für Audio-CDs). Das Zitat, das piewie gepostet hat, kenne ich. Leider kenne ich auch den flamewar, der auf lkml damals losgetreten wurde und der mehr oder weniger daran schuld ist, daß diese "Sperre" bestimmter SCSI-Kommandos in den Kernel eingeflossen ist. Leider muß ich dem Author von den cdrtools hier ausnahmsweise (mich schüttelt und würgt es alleine bei dem Gedanken) Recht geben. Die einfachste Lösung hat sich Linus da wirklich nicht einfallen lassen und das Ganze dann noch als security-fix hinzustellen is schon recht unverfroren. Naja, soweit ich gehört habe, soll man mit den gentoo-dev sources auch als user noch brennen können. Jetzt muß ich nur noch etwas Vertrauen in die gentoo-dev sources fassen :-/

@piewie: Jetzt reg' dich nicht auf. Jörg Schilling is ein schwieriger Umgang das ist allgemein bekannt. Das soll nicht heißen, daß er nicht ein guter coder is (die cdrtools sind wohl seine beste Reputation), aber er ist auch nicht besser wie so mancher Kernelcoder. Ich persönlich halte ihn für einen äußerst unsymphatischen Menschen und diese Erfahrung kommt nicht nur vom Lesen in de.comp.hardware.brenner oder lkml. 

Ein recht stark frustrierter

Poly

----------

## ralph

Ich weiß ja, dass ich damit angefangen habe (es fällt mir halt einfach schwer, Äusserungen von Herrn Schilling unkommentiert stehen zu lassen, ich gebe es ja zu), aber ich finde trotzdem, dass dies hier nicht der richtige Ort ist um mal wieder über Herrn Schilling zu diskutieren.

Entschuldigung also dafür, dass ich mal wieder meinen Mund nicht halten konnte, verbunden mit der Bitte doch einfach nur das Problem und mögliche Lösungen zu diskutieren.

----------

## Polynomial-C

@ralph: Hast Recht. Hilft kein bissel irgendwelche Probleme zu lösen. Möchte mich hiermit für meine Flamerei im vorigen Post entschuldigen.

Leider ist das Problem sehr frustrierend, da es so aussieht, als ob weder von der Seite der Kernelcoder noch von der Seite des cdrtools Authors irgendeine Verbesserung dieser Situation zu erwarten ist.

Die leidtragenden sind wie immer die Anwender :-/

Poly

----------

## ralph

@Polynomial-C: Du solltest wirklich versuchen, zu den gentoo-dev-sources Vertrauen zu fassen. Jedenfalls mit dem 2.6.8er Kernel funktioniert bei mir das Brennen ohne Probleme.

----------

## Polynomial-C

Hi,

 *ralph wrote:*   

> @Polynomial-C: Du solltest wirklich versuchen, zu den gentoo-dev-sources Vertrauen zu fassen. Jedenfalls mit dem 2.6.8er Kernel funktioniert bei mir das Brennen ohne Probleme.

 

Du meinst die vanilla-2.6.8 sources? Genau mit denen habe ich mir ca. 10 Rohlinge verbrannt, bis ich dahintergestiegen bin, daß das Brennen zumindest von Audio-CDs eben mit vanilla kernel >= 2.6.8 nicht geht.

[edit]

Okay, überlest dieses Posting. Hatte die Empfehlung von ralph total mißverstanden (kommt davon, wenn man gleich nach dem Aufstehen im Gentoo-Forum lospostet  :Smile: )

[/edit]

Poly

----------

## ralph

Hm, also jetzt muss ich doch glatt überlegen, ob ich in letzter Zeit vielleicht keine Audio CDs gebrannt habe. Es kann also sein, dass mir das Problem einfach nicht aufgefallen ist. Das Brennen von Daten CDs klappt bei mir aber wunderbar und zwar mit der 2.6.8er Reihe der folgenden sourcen:

http://packages.gentoo.org/search/?sstring=gentoo-dev-sources

----------

## Polynomial-C

Hi,

 *ralph wrote:*   

> Das Brennen von Daten CDs klappt bei mir aber wunderbar und zwar mit der 2.6.8er Reihe der folgenden sourcen:
> 
> http://packages.gentoo.org/search/?sstring=gentoo-dev-sources

 

Daten CDs sind relativ unproblematisch. Aber verweist du mit deinem Link oben nicht genau auf jene gentoo-dev-sources, in denen die Änderungen am SG_IO Interface wieder auf den Stand von vor vanilla-2.6.8 gebracht werden? Ich selber benutze die development-sources (= vanilla-2.6 sources) und da wird ja nix weiter reingepatcht...

Poly

----------

## ralph

Wenn es darum geht, was da genau in dieser Beziehung gepatcht wurde, da bin ich ehrlich gesagt überfragt. Ich kann dir halt nur aus eigener Erfahrung berichten, dass ich mit diesen sourcen bisher keine Probleme mit dem Brennen hatte. Versuchs doch einfach mal.

----------

## UTgamer

Ich hatte mich vor einiger Zeit (seit Jahren) auch bereits mit dem Thema beschäftigt gehabt, 

aber mangels installiertem 2.6.x Kernels nicht nachvollziehen könne, doch auch mit dem 

2.4.x Kernel sind da Welten zwischen.

Der oben genannte Heise Beitrag sowie einige andere Beiträge älteren Datums, machten auch mir klar, 

das es nur mit den original Sourcen besser klappt als mit denen der Distributionen.

Auch in Gentoo sind dort große Unterschiede. Hatte bereits hier 

https://forums.gentoo.org/viewtopic.php?p=1652665#1652665 die Originale empfohlen.

----------

## mrsteven

 *ralph wrote:*   

> Wenn es darum geht, was da genau in dieser Beziehung gepatcht wurde, da bin ich ehrlich gesagt überfragt. Ich kann dir halt nur aus eigener Erfahrung berichten, dass ich mit diesen sourcen bisher keine Probleme mit dem Brennen hatte. Versuchs doch einfach mal.

 

Ich habe gerade noch mal nachgeschaut: Es ging irgendwie darum, dass ein böswilliger unpriveligierter User, wenn er Lesezugriff auf den Brenner hat, dessen Firmware überschreiben konnte, da keine Filterung der SCSI-Kommandos durchgeführt wurde. Diese Filterung wurde eingebaut, sie ist aber ein wenig zu streng, weshalb das Brennen nicht funktioniert. Der Patch, der unter anderem in den gentoo-dev-sources enthalten ist, setzt diese Filterung außer Kraft, so weit ich weiß, er öffnet also auch ein Sicherheitsloch. Es sollte denke ich funktionieren, wenn cdrecord mit gesetztem suid-Flag seine root-Privilegien zum Brennen behalten würde, was es aber scheinbar nicht tut.

Zu den Buffer-Underruns ist mir gerade eingefallen, dass mir das schon einmal mit dem Kernel 2.6.8.1 passiert ist, und zwar beim kompletten Löschen einer CD-RW. Da hat sich cdrecord allerdings aufgehängt, man musste es mit kill beenden. Das System blieb aber ansonsten stabil.

----------

## Polynomial-C

Hi,

 *mrsteven wrote:*   

> Zu den Buffer-Underruns ist mir gerade eingefallen, dass mir das schon einmal mit dem Kernel 2.6.8.1 passiert ist, und zwar beim kompletten Löschen einer CD-RW. Da hat sich cdrecord allerdings aufgehängt, man musste es mit kill beenden. Das System blieb aber ansonsten stabil.

 

Joah, das sys zerbröselt nicht, aber dafür hast du bei Audio-CDs halt geschrottete CD-Rs.

Mich regt diese Filterung bestimmter SG_IO Kommandos im Kernel halt auf, da selbst Linus zugibt, daß das keine gute Lösung ist, da diese Filterliste

a) niemals vollständig sein kann

b) Einige SG_IO Kommandos nur in bestimmten Einzelfällen schädlich sein können

c) Einige userspace apps (wie die cdrtools) nicht mehr (oder nur eingeschränkt) ohne root-Rechte funktionieren.

Leider wird das Ganze noch dadurch verschlimmert, daß in den neusten cdrtools die DMA-Geschwindigkeit automatisch(?) abgefragt wird, was nur über ein gefiltertes SG_IO Kommando möglich ist.

@ralph wede die gentoo-dev-sources mal auf einem Rechner testen. Aber ein gutes Gefühl hab' ich bei der Sache nicht...

Poly

----------

## Erdie

Bei mir funktioniert mit gentoo-dev-sources > 2.6.7 kein Klonen von CDs, auch nicht als root. Ohne root Rechte geht das Daten DVD Brennen nicht (auf gentoo-dev-sources- 2.6.9-r4. Mit Rootrechten muß ich das DVD Brennen noch testen. Auf jeden Fall ist die Sache so verstrickt, daß ich zum Brennen immer auf gentoo-dev-sources-2.6.7-r14 runtergehe. Leider gibt es bei diesen Sourcen Probleme an anderen Stellen, so daß ich nicht glücklich bin mit 2.6.7

Grüße

Erdie

----------

## mrsteven

Habe das Problem inzwischen mit dieser Anleitung lösen können.

Bei mir hat es geholfen, das Laufwerk mittels dev=/dev/hdc zu übergeben (vorher war es dev=ATAPI_irgendwas).

----------

## linpacman

Hallo

Ich habe zur Zeit die gentoo-dev-sources 2.6.7 laufen und würde diese gerne auf 2.6.10 updaten. Sind die ganzen Brenner Probleme, mit k3b als User brennen etc. dort behoben oder sollte ich besser noch bei 2.6.7 bleiben?

----------

## piewie

Habe vor zwei Tagen meinen lange genutzeten 2.6.7-love5 gegen den 2.6.11-rc1-nitro0 augewechselt (wegen frequency scaling). Habe die Gruppe burning angelegt. Die user reingepackt (cdrom, cdrw aktivieren), cdrecord mit einem chown root:burning versehen. CD-RW löschen und brennen war ok. Audio-Cds habe ich noch nicht probiert. DVD-RAM macht übrigens auch keine Probleme. Ach ja, ein- ausloggen nicht vergessen oder könnte ein source /etc/profile auch genügen?

----------

## psyqil

http://www.ussg.iu.edu/hypermail/linux/kernel/0501.2/0450.html

Jemand Lust zu testen?

----------

## Polynomial-C

Hi,

 *psyqil wrote:*   

> http://www.ussg.iu.edu/hypermail/linux/kernel/0501.2/0450.html
> 
> Jemand Lust zu testen?

 

heh, gerade eben habe ich in einem andeen Thread geschrieben, daß dieser patch wichtig für Kernel-2.6.10 ist, um mehr als eine DVD/CD als user brennen zu können.

Ich benutze den patch seit einigen Tagen und habe keine Probleme mehr, CDs als user mit Kernel-2.6.10-ac10 zu brennen  :Smile: 

Poly

----------

