cdrecord und Plextor Brenner

[hugenay]

Das leidige Brenner-Thema.

Morgen,
ich versuch gerade nen IDE Brenner von Plextor ans laufen zu bringen. Hab den Kernel neu gebacken und starte jetzt den debian 2.2 Kernel über lilo mit dem append="hdb=ide-scsi". Dementsprechend kann ich über mount /dev/hdb nicht mehr an den Brenner, sondern nur noch über mount /dev/scd0. Weiterhin lasse ich sr_mod, sg und loop (lsmod sagt hier unused?!?) als Module laden.
Klingt doch richtig. Auch cdrecord -scanbus gibt als (einziges) scsi Gerät brav den Brenner an Position 0,0,0 aus.
Nur spuckt cdrecord immer "Funktion not implemented. Shmget failed" aus. Ich rufe es bspw. folgendermaßen auf:
"cdrecord -v speed=2 dev=0,0,0 -data cd_image.raw"., wobei cd_image.raw vorher mit mkisofs erstellt wurde. Tja, ich kann auch bei dev was völlig fiktives angeben, es ist immer dasselebe -:(
Ich benutze Debian 2.2 und dem selbst kompilierten cdrecord_1.9.
Da ich kein X habe bringt mir xroast etc. nichts.

Ich vermute mal, dass irgendwas mit der scsi emulation doch nicht richtig ist. Wer kann mir da mehr sagen?
gruss hug.

[Jochen]

"Shmget failed" sollte besagen, dass cdrecord shared memory belegen will und nicht kann/darf. Hast Du Deinen Kernel selbstgebacken und dabei SystemV-IPC rausgeschmissen? Falls ja, neuen Kernel inkl. SysV IPC backen, booten und cdrecord testen. (SysV-IPC umfasst Shared memory, Semaphoren und Message Queues). Ein einfacher Testfall sollte das Kommando "ipcs" (IPC show) sein, der gibt alle IPC-Mittel aus. Streikt der, dann s.o.

Viel Erfolg!

[hugenay]

kewl!

Kannste nochwas zu Shared memory, Semaphoren und Message Queues sagen? damit ich auch was gelernt hab....-:)

[jochen]

Ja also - war das jetzt ironisch oder ernst?!?

Aber wo ich schon mal so 'ne schulmeisterliche Ader hab... <img src="http://www.pl-forum.de/UltraBoard/Images/Happy.gif" border="0" align="middle">

IPC löst sich auf in "Inter-Process Communication", und genau das macht man damit: Prozesse miteinander kommunizieren lassen. "Ja aber - da gibt es doch Sockets für?" Richtig - wenn man ein modernes Unix oder eins aus der älteren BSD-Schiene fährt. In der SystemV-Linie von AT&T hat man sich die IPC-Mittelchen ausgedacht. Wie üblich haben beide Linien ihre Vor- und Nachteile. Unter SysV-IPC hat man jetzt 3 Features zur Verfügung:

<li>Shared Memory: Zwei oder noch mehr Prozesse teilen sich einen Speicherbereich, d.h. alle Prozesse können darauf zugreifen. Ist natürlich rasend schnell, aber die Prozesse müssen sich synchronisieren, da der eine sonst die Änderungen des anderen überschreiben kann.
<li>Genau dazu gibt es die Semaphoren. So nannte man früher Signalmasten, und so kann man sich die Dinger auch im Rechner vorstellen. Wer auf shared mem zugreifen will, setzt einen Semaphor. Wenn's klappt, hat der Prozess Zugriff. Wenn der Semaphor schon belegt ist, wird der Prozess so lange schlafen gelegt, bis der Semaphor nach getaner Arbeit vom anderen Prozess wieder freigegeben wird.
<li>Und noch die Message Queues. Die kann man sich ganz, ganz grob als UNIX-Domain-Sockets vorstellen.

(Die obige Beschreibung ist nur grob, ne?)

So, näheres liest Du am besten im Stevens nach (Programmieren in der UNIX-Umgebung)!

[hugenay]

thx für die Info, war nicht ironisch gemeint. vielleicht leg ich mir das Buch mal zu (muss nur noch (mehr) programmieren lernen-:))
gruss hug.