[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Probleme mit IDE-Brenner und cdbakeoven



On 21.Feb 2003 - 13:29:30, Jan Schulz wrote:
> Hallo Andreas,
> 
> * Andreas Pakulat wrote:
> >Ja und nein, im Prinzip hast du solche Probleme wenn eines der Geräte im
> >PIO-Modus arbeitet, bei dem der ganze Datenstrom durch den Prozessor
> >muss!
> 
> Wie finde ich das raus? 

Das sagt dir das hdparm -v /dev/hdX, dort sind im unteren Drittel
sämtliche Modi die das Device unterstützt aufgelistet. Der aktuell
benutzte hat dabei ein *. 

> >Also isch hab hier denselben Brenner und DMA einschalten geht bei mir
> >überhaupt net, dann hängt sich der Kernel regelmäßig auf. Ich meine
> >damit das DMA vom Kernel, nicht das vom CD-Brenner. Liegt wohl am
> 
> Wie schaltet man den ein? Ich habe hier die Kernel Packages von 
> Adrain Bunk, also 1.4.20-k7

hdparm -d1 /dev/hdX, aber ich sehe grad das das ja bei dir sowieso an
ist.

BTW: Der kernel ist garantiert 2.4.20-k7 :)

> >IDE-Anschlüssen (nicht Controllern, da nur einer auf dem Board) so wie
> 
> ich dachte immer das es zwei sind: einer für den hda/b und einer 
> für hdc/d? Aber egal :)

Nein 1 Controller mit 2 IDE-Kanälen, an denen jeweils 2 Geräte hängen
können.

> >Interessanter wäre die Ausgabe von hdparm -v /dev/hd(b,c), also die
> >eingeschalteten Optionen für CDROM und LiteOn CDBrenner. Wie du siehst,
> >macht das LiteOn selbst eh MultiMode DMA (Frag mich jetzt bitte nicht,
> >was das ist das weiß ich nicht, nur ist es kein UDMA). Aber ob der
> >Kernel das auch an hat ist daraus nicht zu ersehen (der 2.4.18-bf24
> >machts glaub ich aus).
> 
> Hier mal die Ausgaben (als root) von hdparm -vi:
> ---
> /dev/hdb:
>  HDIO_GET_MULTCOUNT failed: Input/output error
>  I/O support  =  1 (32-bit)

Das sorgt lt. manpage von hdparm für 32 Bit Transport, und soll mit 3
betrieben werden, weil das viele Chipsets brauchen.

>  unmaskirq    =  1 (on)

Lt. Manpage soll das die "Responsiveness" (sorry Übersetzung fällt mir
grad nicht ein) verbessern, also ist's eigentlich gut.

>  using_dma    =  1 (on)

Das ist das wichtig, DMA-Transfer ist an, mmh dann kann ich nur noch
raten: Das DVD-ROM produziert zuviel CPU-Last durch die
Fehlerkorrektzur. Bei meinem Bruder ist auch so ein DVD-ROM mit ewig
langen Zugriffszeiten bei CD's und auch die Datentransferrate ist mies,
obwohl das Ding im UDMA 2 läuft :(

>  PIO modes: pio0 pio1 pio2 pio3 pio4
>  DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 *udma2

Das sind die unterstützten Modi, der udma2 ist aktiviert.

> >Habs grad mal getestet und hier gehts halbwegs im Hintergrund, 
> >sprich das Lesen von CD belastet das System etwas und hin und wieder
> >hakt die Maus, allerdings läuft hier auch KDE3.1, apache, cups, pdnsd,
> >xmms spielt, ... und der Brenner brennt ohne Realtime scheduling, da als
> >normaler User gestartet. 
> 
> Same here: kde3.1, alle möglichen Server im Hintergrund (apache, 
> Tomcat, cups), AMDK/ 700MHz (laut Bios), 524MB Ram. Ansonsten 
> 'rennt' der Computer ziemlich gut, Videos und sowas isind keien 
> Problem.

Sollte also nicht das Problem sein, ich denke das es wirklich am
DVD-Rom liegt.

> >Hier mal die Ausgabe der Geräte lt. hdparm:
> >|  I/O support  =  0 (default 16-bit)
> >|  unmaskirq    =  0 (off)
> [..]
> >|  I/O support  =  3 (32-bit w/sync)
> >|  unmaskirq    =  0 (off)
> >|  using_dma    =  0 (off)
> 
> Hier scheint der Unterscheid zu liegen: I/O ist bei mir beides mal 
> auf 1 und ich benutze 'unmaskirq = 1' (was auch immer das 
> bedeutet...). Und dma ist bei dir am Brenner aus. 

Also mein Tipp: versuchs erstmal mit hdparm -c3 auf beiden Devices und
wenn das nichts bringt brenn mal nicht on-the-fly, sondern erst ne Kopie
auf Platte ziehen und dann die Brennen. Wenn du beim Brennen keine
Aussetzer hast liegts wohl am DVD-ROM (dann hast du u.U. Aussetzer
während des Kopierens auf Platte) und dann hilft nur eines: neues
Laufwerk :(

Andreas

-- 
Wie man sein Kind nicht nennen sollte: 
  Wim Pel 

Attachment: pgpU0oHbzd98A.pgp
Description: PGP signature


Reply to: