CDs kopieren/DAE mit ATAPI über ide-scsi
Hallo, die meisten Probleme hab ich inzwischen einigermaßen in den Griff bekommen. Aber mein größtes ist Folgendes (ich habe einigermaßen Ahnung, und bin echt bald am Verzweifeln, dass ich deswegen noch auf Windoof angewiesen bin): - CDs mit cdrecord bzw. cdrdao kopieren bzw. Audio-Daten auslesen zwingt das _ganze_ System nach wenigen Sekunden in die Knie. Daten über z. B. ISO-9660 lesen macht keine Probleme, Brennen(!) auch nicht. Ich habe eigentlich eine andere Konfiguration, aber es passiert auch am Onboard-IDE Kanal als Secondary Master, ob nun im PIO oder UDMA Modus. IDE-Brenner als ide-scsi. Ich habe das Problem bisher reproduziert an VIA KT133A Boards und welche mit SiS-Chipsätzen, mit diversen Brennern. Es könnte an einigen Brennern liegen, an den Mainboards bzw. deren Chipsätzen oder eben auch an der Kombination. Unter der 8.x hatte ich immer _unlösbare_ Probleme damit, auch Standard-Kernel 2.4.19/20 halfen nichts. Ich habe den VIA-KT133A-Chipsatz und einen Plextor 241040TA IDE-Brenner, SuSE 8.2 mit 2.4.20er Kernel. - Hat jemand beide Komponenten und kann CDs kopieren oder Audiodaten lesen? (Ich _habe_ tatsächlich schon mal so etwas wie einen Patch bekommen, aber nach Durchsicht kann ich nicht verstehen, wieso das gerade in meinem Fall helfen soll. Ich möchte unbedingt mehr Meinungen) Gruß, Ré
René Matthäi schrieb:
[...] Ich habe den VIA-KT133A-Chipsatz und einen Plextor 241040TA IDE-Brenner, SuSE 8.2 mit 2.4.20er Kernel.
- Hat jemand beide Komponenten und kann CDs kopieren oder Audiodaten lesen?
Ich habe ein Asus A7V133A mit VIA KT133A Chipsatz, SuSE 8.2 mit Kernel 2.4.20, und einen Plextor-Brenner, allerdings einen 161040TA IDE-Brenner. Normalerweise lese ich CDs ueber das DVD-Laufwerk aus, aber - ich habe es gerade probiert - auch ueber den Plextor-Brenner geht das einwandfrei. Ich kann Deine Probleme hier nicht nachvollziehen. Die Brenner sollten eigentlich sehr aehnlich sein. Was verstehst Du eigentlich darunter, dass "das System in die Knie geht"? Gruesse, Thomson -- Thomas Hertweck, Dipl.-Geophys., GPI Universitaet Karlsruhe === First they ignore you, then they laugh at you, then === === they fight you, then you win. (M. Ghandi) ===
Hi, Thomas Hertweck schrieb:
René Matthäi schrieb:
[...] Ich habe den VIA-KT133A-Chipsatz und einen Plextor 241040TA IDE-Brenner, SuSE 8.2 mit 2.4.20er Kernel.
- Hat jemand beide Komponenten und kann CDs kopieren oder Audiodaten lesen?
Ich habe ein Asus A7V133A mit VIA KT133A Chipsatz, SuSE 8.2 mit Kernel 2.4.20, und einen Plextor-Brenner, allerdings einen 161040TA IDE-Brenner. Normalerweise lese ich CDs ueber das DVD-Laufwerk aus, aber - ich habe es gerade probiert - auch ueber den Plextor-Brenner geht das einwandfrei. Ich kann Deine Probleme hier nicht nachvollziehen. Die Brenner sollten eigentlich sehr aehnlich sein.
Mit "Auslesen" meinst Du Audio-Extraktion bzw. "raw" lesen, nicht mounten und kopieren, oder? Dann ist das ja ein ziemliches Ding, und ich weiß echt nicht mehr, was los ist. Ich hatte vergessen zu sagen, dass das gleiche Problem mit meinem Pioneer DVD besteht. Hat also nix mit dem Brenner allein zu tun.
Was verstehst Du eigentlich darunter, dass "das System in die Knie geht"?
Maus fängt an zu ruckeln, bis sie sich schließlich fast nicht mehr bewegt. Man muss schnell abbrechen, sonst dauert es ziemlich lange, bis er wieder reagiert. Aber auch Musikausgabe etc. - ALLES ruckelt mit, hakelt. Ist was auf tieferer Ebene, ps zeigt keinen besonders Resourcen fressenden Prozess an. Ist, soviel konnte ich aus frühreren Diskussionen entnehmen, etwas auf Interrupt-Ebene. Wie gesagt, ich hab mal alles abgehangen und Knoppix vom einen ATAPI-Laufwerk gebootet, dann mit dem anderen versucht zu kopieren. Gleiches Problem :-( Bei meinen beiden Mitbewohnern auch, bei nem anderen Kumpel nicht so. Hier ist was im Argen. Ré
René Matthäi schrieb:
Thomas Hertweck schrieb:
René Matthäi schrieb:
[...] Ich habe den VIA-KT133A-Chipsatz und einen Plextor 241040TA IDE-Brenner, SuSE 8.2 mit 2.4.20er Kernel.
- Hat jemand beide Komponenten und kann CDs kopieren oder Audiodaten lesen?
Ich habe ein Asus A7V133A mit VIA KT133A Chipsatz, SuSE 8.2 mit Kernel 2.4.20, und einen Plextor-Brenner, allerdings einen 161040TA IDE-Brenner. Normalerweise lese ich CDs ueber das DVD-Laufwerk aus, aber - ich habe es gerade probiert - auch ueber den Plextor-Brenner geht das einwandfrei. Ich kann Deine Probleme hier nicht nachvollziehen. Die Brenner sollten eigentlich sehr aehnlich sein.
Mit "Auslesen" meinst Du Audio-Extraktion bzw. "raw" lesen, nicht mounten und kopieren, oder? Dann ist das ja ein ziemliches Ding, und ich weiß echt nicht mehr, was los ist.
Ja klar, ich meinte schon das Auslesen mittels cdrdao oder aehnlichen Programmen. Ist hier kein Problem.
Ich hatte vergessen zu sagen, dass das gleiche Problem mit meinem Pioneer DVD besteht. Hat also nix mit dem Brenner allein zu tun.
Hehe, ich habe hier auch ein Pioneer, ein DVD 106. Das ist eigentlich mein bevorzugtes Laufwerk zum Auslesen. Auch hier treten, wie oben schon angedeutet, keine Probleme auf. Ich kann nebenher ganz normal weiter arbeiten. Das Laufwerk laeuft auch unter ide-scsi Emulation.
Was verstehst Du eigentlich darunter, dass "das System in die Knie geht"?
Maus fängt an zu ruckeln, bis sie sich schließlich fast nicht mehr bewegt. Man muss schnell abbrechen, sonst dauert es ziemlich lange, bis er wieder reagiert. Aber auch Musikausgabe etc. - ALLES ruckelt mit, hakelt. Ist was auf tieferer Ebene, ps zeigt keinen besonders Resourcen fressenden Prozess an. Ist, soviel konnte ich aus frühreren Diskussionen entnehmen, etwas auf Interrupt-Ebene.
Haengt denn das Laufwerk, von dem gelesen wird, und die Fest- platte, auf die geschrieben wird, am gleichen IDE-Kanal? Das ist dann natuerlich nicht ideal. Aber trotz allem sind das recht seltsame Symptome, die Dein Rechner da hat - das habe ich hier wahrlich nicht. Also, es scheint nicht unbedingt am Chipsatz oder Kernel etc. zu liegen, was ja auch der Knoppix- Test zeigt. Hast Du mal die BIOS-Optionen ueberprueft? Oder sonstwie die Hardware ueberprueft (Kabel, etc.)? Scheint mir ehrlich gesagt auch eher ein Hardware- oder Interrupt- oder BIOS-Problem zu sein. Liefert "cat /proc/interrupts" irgend- einen Hinweis? Gibt es irgendwo in /var/log/messages oder warn Hinweise? CU, Th. -- Thomas Hertweck, Dipl.-Geophys., GPI Universitaet Karlsruhe === First they ignore you, then they laugh at you, then === === they fight you, then you win. (M. Ghandi) ===
Thomas Hertweck schrieb:
Haengt denn das Laufwerk, von dem gelesen wird, und die Fest- platte, auf die geschrieben wird, am gleichen IDE-Kanal? Das ist dann natuerlich nicht ideal. Aber trotz allem sind das recht seltsame Symptome, die Dein Rechner da hat - das habe ich hier wahrlich nicht. Also, es scheint nicht unbedingt am Chipsatz oder Kernel etc. zu liegen, was ja auch der Knoppix- Test zeigt. Hast Du mal die BIOS-Optionen ueberprueft? Oder sonstwie die Hardware ueberprueft (Kabel, etc.)? Scheint mir ehrlich gesagt auch eher ein Hardware- oder Interrupt- oder BIOS-Problem zu sein. Liefert "cat /proc/interrupts" irgend- einen Hinweis? Gibt es irgendwo in /var/log/messages oder warn Hinweise?
Unter Knoppix hab ich in (physischen) RAM-Speicher geschrieben. Was soll an den BIOS-Optionen nicht stimmen etc. Unter Windoof und ganz früher liefs doch auch. in /var/log/messages so etwas: Apr 8 04:11:08 linux kernel: ide-scsi: hdg: unsupported command in request queue (0) Apr 8 04:11:08 linux kernel: end_request: I/O error, dev 22:00 (hdg), sector 64 Apr 8 04:11:08 linux kernel: lost async page write due to I/O error on 22:00 re:~> cat /proc/interrupts CPU0 0: 3391145 XT-PIC timer 1: 28118 XT-PIC keyboard 2: 0 XT-PIC cascade 5: 2156094 XT-PIC eth0, Ensoniq AudioPCI 8: 2 XT-PIC rtc 9: 3172131 XT-PIC nvidia 10: 38947 XT-PIC ide2, ide3, usb-uhci, usb-uhci 11: 14 XT-PIC aic7xxx 12: 634259 XT-PIC PS/2 Mouse 14: 84154 XT-PIC ide0 15: 42 XT-PIC ide1 NMI: 0 LOC: 3391019 ERR: 1249 MIS: 0 Ré
René Matthäi schrieb:
[...] Unter Knoppix hab ich in (physischen) RAM-Speicher geschrieben. Was soll an den BIOS-Optionen nicht stimmen etc. Unter Windoof und ganz früher liefs doch auch.
1. Dass es unter Windows laeuft, heisst nichts. Windows scheint weniger anfaellig auf kaputte Hardware zu sein als Linux. Das sind zumindest meine Erfahrungen. 2. Es gibt schon einige BIOS-Optionen, die relevant sein koennen. Aber wenn Du da nichts geaendert hast, dann sollte es nicht daran liegen.
in /var/log/messages so etwas:
Apr 8 04:11:08 linux kernel: ide-scsi: hdg: unsupported command in request queue (0) Apr 8 04:11:08 linux kernel: end_request: I/O error, dev 22:00 (hdg), sector 64 Apr 8 04:11:08 linux kernel: lost async page write due to I/O error on 22:00
Hmm, damit kann ich nicht so viel anfangen. Jedenfalls habe ich nicht solche Meldungen. Mal ganz bloed gefragt: das ist nicht zufaellig ein onboard Highpoint Chip, an dem der Brenner sitzt? hdg deutet ja da- rauf hin, dass es um den zweiten IDE Controller geht. IIRC will naemlich der Chip nur Festplatten, aber keine CD-Lauf- werke... Musst Du mal genau im Handbuch Deines MBs suchen. Hast Du denn die Laufwerke mal an den internen IDE-Kanaelen getestet?
re:~> cat /proc/interrupts CPU0 0: 3391145 XT-PIC timer 1: 28118 XT-PIC keyboard 2: 0 XT-PIC cascade 5: 2156094 XT-PIC eth0, Ensoniq AudioPCI 8: 2 XT-PIC rtc 9: 3172131 XT-PIC nvidia 10: 38947 XT-PIC ide2, ide3, usb-uhci, usb-uhci
Der zweite IDE-Controller teilt sich einen IRQ mit USB. Das ist natuerlich auch nicht ideal! Gruesse, Thomson -- Thomas Hertweck, Dipl.-Geophys., GPI Universitaet Karlsruhe === First they ignore you, then they laugh at you, then === === they fight you, then you win. (M. Ghandi) ===
Hi, Thomas Hertweck schrieb:
René Matthäi schrieb:
in /var/log/messages so etwas:
Apr 8 04:11:08 linux kernel: ide-scsi: hdg: unsupported command in request queue (0) Apr 8 04:11:08 linux kernel: end_request: I/O error, dev 22:00 (hdg), sector 64 Apr 8 04:11:08 linux kernel: lost async page write due to I/O error on 22:00
Hmm, damit kann ich nicht so viel anfangen. Jedenfalls habe ich nicht solche Meldungen.
Hat die sonst jemand bzw. kennt sie?
Mal ganz bloed gefragt: das ist nicht zufaellig ein onboard Highpoint Chip, an dem der Brenner sitzt? hdg deutet ja da- rauf hin, dass es um den zweiten IDE Controller geht. IIRC will naemlich der Chip nur Festplatten, aber keine CD-Lauf- werke... Musst Du mal genau im Handbuch Deines MBs suchen. Hast Du denn die Laufwerke mal an den internen IDE-Kanaelen getestet?
Ich habe die ganzen Tests schon auch mit dem Brenner am Onboard-Kanal getestet, schon klar. Ich dachte lange Zeit auch, dass es was mit dem Promise zu tun hat. "Leider" ist dem nicht so.
re:~> cat /proc/interrupts CPU0 0: 3391145 XT-PIC timer 1: 28118 XT-PIC keyboard 2: 0 XT-PIC cascade 5: 2156094 XT-PIC eth0, Ensoniq AudioPCI 8: 2 XT-PIC rtc 9: 3172131 XT-PIC nvidia 10: 38947 XT-PIC ide2, ide3, usb-uhci, usb-uhci
Der zweite IDE-Controller teilt sich einen IRQ mit USB. Das ist natuerlich auch nicht ideal!
Tja, da sollte ich gar nicht erst meine `cat /proc/ioports` herzeigen... - Aber wie soll ich das ändern? _Früher_ war alles wunderbar (8.1), seit der 8.2 werden die Interrupts und Ports haarsträubend zugewiesen. Zum Beispiel gibt es einen anscheinend (unter SuSE 8.2) unlösbaren Konflikt zwischen meiner SCSI-Karte und dem Onboard-Soundchip. Deswegen benutze ich jetzt eine Extra-Soundkarte! Wie zum Henker ändert man an der Zuweisung der IO-Ports bzw. der Interrupts was? (insbes. ohne anderen Kernel) Ich habe alle meine PCI-Karten mal getauscht und dabei auf shared/unshared geachtet: Es hat NICHTS gebracht. So viel zu diesen shared/unshared-MB-Weisheiten... AUSSERDEM gings ja früher und unter Windoof auch. Naja. Ich bin echt bald mit meinem Latein am Ende. Hätte ich grade Geld, würde ich mir einen anderen Rechner etc. kaufen :-) Denn Zeit (und Fähigkeiten), mich bis in die Kernel-Alpträume zu hacken, hab ich eigentlich nicht... Und gäbe es einfache bis mittelschwere Lösungen zu finden, wären sie vermutlich gefunden. Das deprimiert mich echt, wo ich doch so stolz war, ganz auf Linux zu setzen (naja, es gibt bei mir noch ein "echtes" Win98 und ein XP unter vmware sowie wine und crossover :-))) Gruß, Ré
René Matthäi schrieb:
[IRQ Verteilung]
Tja, da sollte ich gar nicht erst meine `cat /proc/ioports` herzeigen... - Aber wie soll ich das ändern? _Früher_ war alles wunderbar (8.1), seit der 8.2 werden die Interrupts und Ports haarsträubend zugewiesen.
Tja, APIC laesst vermutlich gruessen :-)
[...] Wie zum Henker ändert man an der Zuweisung der IO-Ports bzw. der Interrupts was? (insbes. ohne anderen Kernel) Ich habe alle meine PCI-Karten mal getauscht und dabei auf shared/unshared geachtet: Es hat NICHTS gebracht. So viel zu diesen shared/unshared-MB-Weisheiten...
Bei mir hat das schon mehrmals geholfen. Prinzipiell ist das nicht ganz so einfach, mit dem Aendern der Ressourcen... Manchmal hilft das Umstecken von Karten, manchmal kann man Boot-Parameter oder Module-Optionen ueber- geben, manchmal kann man im BIOS was drehen, ich denke, ein generelles Rezept, das zum Erfolg fuehrt, gibt es hier nicht. Gruesse, Thomson -- Thomas Hertweck, Dipl.-Geophys., GPI Universitaet Karlsruhe === First they ignore you, then they laugh at you, then === === they fight you, then you win. (M. Ghandi) ===
Hi, Thomas Hertweck schrieb:
Prinzipiell ist das nicht ganz so einfach, mit dem Aendern der Ressourcen... Manchmal hilft das Umstecken von Karten, manchmal kann man Boot-Parameter oder Module-Optionen ueber- geben, manchmal kann man im BIOS was drehen, ich denke, ein generelles Rezept, das zum Erfolg fuehrt, gibt es hier nicht.
Du meinst, Du hättest für PCI-Karten per Kernelparameter Resourcen (IRQ/IOPorts) zugewiesen...? Ré
René Matthäi schrieb:
Thomas Hertweck schrieb:
Prinzipiell ist das nicht ganz so einfach, mit dem Aendern der Ressourcen... Manchmal hilft das Umstecken von Karten, manchmal kann man Boot-Parameter oder Module-Optionen ueber- geben, manchmal kann man im BIOS was drehen, ich denke, ein generelles Rezept, das zum Erfolg fuehrt, gibt es hier nicht.
Du meinst, Du hättest für PCI-Karten per Kernelparameter Resourcen (IRQ/IOPorts) zugewiesen...?
Noe, muss ich ja nicht, bei mir geht ja alles. Weiss auch nicht, ob das ueberhaupt direkt geht, oder nur ueber den Umweg des BIOS. Siehe dazu /usr/src/linux/Documentation/kernel-parameters.txt (sorry fuer die etwas laengeren Zeilen): pci=option[,option...] [PCI] various PCI subsystem options: biosirq [IA-32] Use PCI BIOS calls to get the interrupt routing table. These calls are known to be buggy on several machines and they hang the machine when used, but on other computers it's the only way to get the interrupt routing table. Try this option if the kernel is unable to allocate IRQs or discover secondary PCI buses on your motherboard. [...] irqmask=0xMMMM [IA-32] Set a bit mask of IRQs allowed to be assigned automatically to PCI devices. You can make the kernel exclude IRQs of your ISA cards this way. Ich habe z.B. fuer den Parallelport einen speziellen IRQ geregelt, und es muesste auch fuer IDE gehen, laut obiger Doku: ide?= [HW] (E)IDE subsystem : config (iomem/irq), tuning or debugging (serialize,reset,no{dma,tune,probe}) or chipset specific parameters. Gruesse, Thomson -- Thomas Hertweck, Dipl.-Geophys., GPI Universitaet Karlsruhe === First they ignore you, then they laugh at you, then === === they fight you, then you win. (M. Ghandi) ===
* René Matthäi textete am 27.04.03:
in /var/log/messages so etwas:
Apr 8 04:11:08 linux kernel: ide-scsi: hdg: unsupported command in request queue (0) Apr 8 04:11:08 linux kernel: end_request: I/O error, dev 22:00 (hdg), sector 64 Apr 8 04:11:08 linux kernel: lost async page write due to I/O error on 22:00
Und du wunderst dich, wenn dein System nicht das macht, was du von ihm willst? Dein System hängt insofern, als daß es laufend versucht, auf dein Laufwerk zuzugreifen und von dort mit Verzögerung eine Fehlermeldung erhält. Bis die Fehlermeldung eintrudelt, wartet das System. Ich bin mir sicher, daß deine /var/log/messages heftig vollgemüllt ist mit diesen Meldungen. Mit ide-scsi habe ich nichts am Hut, aber du mußt die Ursache dieser Meldungen abstellen, dann sollte es auch mit dem Brennen klappen. cu flo -- Nö, im Gegensatz zu dir trolle ich nicht in dat.lexx rum. Wenigstens hab ich deine sinnlosen Ergüsse dort samt M-ID gespeichert und kann sie bei Gelegenheit gegen dich verwenden. Und darauf kannst du dich verlassen. [Steffen Hillner in daf]
Hi, Florian Gross schrieb:
* René Matthäi textete am 27.04.03:
in /var/log/messages so etwas:
Apr 8 04:11:08 linux kernel: ide-scsi: hdg: unsupported command in request queue (0) Apr 8 04:11:08 linux kernel: end_request: I/O error, dev 22:00 (hdg), sector 64 Apr 8 04:11:08 linux kernel: lost async page write due to I/O error on 22:00
Und du wunderst dich, wenn dein System nicht das macht, was du von ihm willst?
Dein System hängt insofern, als daß es laufend versucht, auf dein Laufwerk zuzugreifen und von dort mit Verzögerung eine Fehlermeldung erhält. Bis die Fehlermeldung eintrudelt, wartet das System. Ich bin mir sicher, daß deine /var/log/messages heftig vollgemüllt ist mit diesen Meldungen.
Dafür, dass ich einige Sekunden warte, bis ich abbreche und der Rechner, bis _er_ abbricht, stehen auf einem Haufen recht wenige von diesen Fehlerausgaben (vielleicht max. 50?). Wahrscheinlich ist jede Fehlerausgabe schon eine "Sammelklage" bzw. mit einem Timeout verbunden.
Mit ide-scsi habe ich nichts am Hut, aber du mußt die Ursache dieser Meldungen abstellen, dann sollte es auch mit dem Brennen klappen.
'tschuldigung, aber das versuche ich seit _geraumer_ Weile mit allen möglichen Ideen. Das Einzige, was ich noch nicht versucht habe, ist, einen 2.5.x Kernel zu benutzen. Aber: MUSS das sein...! Es könnte sich wirklich um "special" ATAPI-Kommandos handeln. Nur warum das bei meinem System auftritt, ist mir schleierhaft. Ré
Hallo, * René Matthäi textete am 28.04.03:
Florian Gross schrieb:
* René Matthäi textete am 27.04.03:
in /var/log/messages so etwas:
Apr 8 04:11:08 linux kernel: ide-scsi: hdg: unsupported command in request queue (0) Apr 8 04:11:08 linux kernel: end_request: I/O error, dev 22:00 (hdg), sector 64 Apr 8 04:11:08 linux kernel: lost async page write due to I/O error on 22:00
Und du wunderst dich, wenn dein System nicht das macht, was du von ihm willst?
Dein System hängt insofern, als daß es laufend versucht, auf dein Laufwerk zuzugreifen und von dort mit Verzögerung eine Fehlermeldung erhält. Bis die Fehlermeldung eintrudelt, wartet das System. Ich bin mir sicher, daß deine /var/log/messages heftig vollgemüllt ist mit diesen Meldungen.
Dafür, dass ich einige Sekunden warte, bis ich abbreche und der Rechner, bis _er_ abbricht, stehen auf einem Haufen recht wenige von diesen Fehlerausgaben (vielleicht max. 50?). Wahrscheinlich ist jede Fehlerausgabe schon eine "Sammelklage" bzw. mit einem Timeout verbunden.
Wenn sich bei mir Festplattenprobleme gezeigt hatten, brauchten die Meldungen auch jedesmal recht lang, bevor sie in der messages auftauchten. Kann schon sein, daß das verzögert wird. Oder es steht vielleicht auch was in der Art "Last Message received X times" drin.
Mit ide-scsi habe ich nichts am Hut, aber du mußt die Ursache dieser Meldungen abstellen, dann sollte es auch mit dem Brennen klappen.
'tschuldigung, aber das versuche ich seit _geraumer_ Weile mit allen möglichen Ideen. Das Einzige, was ich noch nicht versucht habe, ist, einen 2.5.x Kernel zu benutzen. Aber: MUSS das sein...!
Es könnte sich wirklich um "special" ATAPI-Kommandos handeln. Nur warum das bei meinem System auftritt, ist mir schleierhaft.
Hm, gibt es kein Programm, mit dem man mitloggen kann, _was_ für Befehle dein Laufwerk bekommt und was es daraufhin antwortet? Falls es sowas gibt, sollte man mit dem Ergebnis vielleicht das Problem beseitigen (lassen) können. cu flo --
Ich muss mal suchen, wieso "Ihr alle" eigentlich so sauer auf Macromedia seid. Weil es mir das Surfen versaut. [Manni Becker und Clemens Beier in dcsmm]
Am Sonntag, 27. April 2003 18:41 schrieb René Matthäi: [...]
- CDs mit cdrecord bzw. cdrdao kopieren bzw. Audio-Daten auslesen zwingt das _ganze_ System nach wenigen Sekunden in die Knie. Daten über z. B. ISO-9660 lesen macht keine Probleme, Brennen(!) auch nicht.
in /usr/share/doc/cdrtools-2.01_alpha05/README.ATAPI.gz steht was dazu, vielleicht hilfts ja. Es gibt auch irgendwo einen Patch, leider habe ich den nicht zur Hand. Mein System (Via-Southbridge) geht zwar nicht in die Knie (preemp-Patch?), allerdings habe ich eine extrem hohe CPU-Last (über 40%). Beim meinem Laptop (IDE von Intel), ist die CPU-Last noch immer extrem hoch allerdings nur noch um die 20%. Gruß Kai
participants (4)
-
Florian Gross -
Kai Lindenberg -
René Matthäi -
Thomas Hertweck