K3B hängt system auf

raprezent

Well-Known Member
hallooooo so kaum ein tag vergangen komme ich mit dem nächsten problem

ich habe k3b auf meinem system (FreeBSD 5.3) installiert
so weit so gut .. brenner alles schön erkannt ...
doch wenn ich eine cd brennen will ... kaum hat der brennvorgang begonnen hängt sich mein system auf ... ich kann dann nur noch sehr sehr schwer den brennvorgang abbrechen ...

folgendes ist mit dmesg rausgekommen

acd1: timeout waiting for ATAPI ready
acd1: timeout sending command=a0
acd1: error issuing ATA PACKET command
acd1: timeout sending command=a0
acd1: error issuing ATA PACKET command
acd1: timeout sending command=a0
acd1: error issuing ATA PACKET command
acd1: timeout sending command=a0
acd1: error issuing ATA PACKET command
acd1: timeout sending command=a0
acd1: error issuing ATA PACKET command
acd1: timeout sending command=a0
acd1: error issuing ATA PACKET command


wenn man ein bisschen googeld stellt sich heraus dass das ein problem mit atapicam im kernel ist .. na toll .. ich brauch das aber für k3b .. wegen der scsi-emulation .. ansonsten würde es mir die laufwerke nicht erkennen ....

was kann ich da blos machen? das nervt gewaltig! ...
 
Uh also deine Fehlerbeschreibung ist aber auch wirklich nicht sehr aussagekräftig. Wie bitte kannst du denn nach dem Absturz den Brennvorgang noch beenden? Versteh ich nicht.

Daß du für die Verwendung von k3b (bzw eigentlich nur für dao/cdrecord) atapicam brauchst hast du ja selbst schon rausgefunden. Hast du denn atapicam auch korrekt installiert?
---> http://www.freebsd.org/doc/de_DE.ISO8859-1/books/handbook/creating-cds.html ganz unten "16.6.9. Der ATAPI/CAM Treiber"

Im wiki und im Howto-Bereich sind dazu mehrere Einträge zu finden.

Gruß, matze
 
hehehe .. ja das system hängt dann einfach extrem .. aber so alle 10 sekunden kann man die maus wieder ein bisschen bewegen :D oder eine taste drücken :D so kann man den vorgang abbrechen .. sonst wär ich ja nie an diese fehlermeldungen gekommen ... im k3b kommt einfach die fehlermeldung "eingabe-/ausgabefehler" aber da findet man auch nix gescheites bei google


und das aus dem freebsd handbuch hab ich genau so gemacht :) also da sollte kein fehler sein ...
 
Ich hab mal selber kurz gegoogelt. Scheinbar handelt es sich um ein Problem, daß nur mit manchen CD-Laufwerken auftritt.
Die Fehlerbeschreibung von dir reicht einfach nicht aus um das zweifelsfrei zu sagen. Sag doch mal was für ein Laufwerk das ist. Wie sehen deine dmesg-Ausgaben zum Laufwerk aus? Wie sprichst du es an (wie wird es laut fstab gemountet)? Kannst du denn eine beliebigen CD mit diesem Laufwerk mounten und auf die Daten zugreifen? Fragen über Fragen...

Gruß, matze
 
Hi,

hatte ich letztens auch (alle 10 Sekunden Maus bewegen und so) mit einem MITSUMI CR-48XGTE 1.0L. Laufwerk hat ständig geblinkt, 'nen fastboot hat nicht gewirkt. Musste die Kiste aus- und anschalten, damit das Mitsumi wieder mitspielen wollte.

Elwood

5.3 STABLE
 
na da haben wir ja was gemeinsam ... ist ein cyberdrive cw058d brenner ... nichts bekanntes ...

ich kann die dmesg ausgabe gerade nicht posten ich machs in 20 minuten .. bin gerade noch am kompilieren von java :) ...

@.mp .. ich wäre genau so froh wenn ich genauere angaben zum fehler mache könnte ...
aber man sieht nicht mehr :D ... das ist eben das grausame
 
Hi,

seh gerade, dass das Mitsumi offenbar ein Philips Lfw ist.

Code:
# cdrecord dev=2,1,0 driveropts=help -checkdrive
Cdrecord-Clone 2.01 (i386-unknown-freebsd5.3) Copyright (C) 1995-2004 Jörg Schilling
scsidev: '2,1,0'
scsibus: 2 target: 1 lun: 0
Using libscg version 'schily-0.8'.
Device type    : Removable CD-ROM
Version        : 0
Response Format: 1
Vendor_info    : 'MITSUMI '
Identifikation : 'CR-48XGTE       '
Revision       : '1.0L'
Device seems to be: Philips CDD-522.
Driver options:
burnfree        Prepare writer to use BURN-Free technology
noburnfree      Disable using BURN-Free technology

Elwood
 
das kommt bei mir


# cdrecord dev=1,1,0 driveropts=help -checkdrive
Cdrecord-Clone 2.01 (i386-unknown-freebsd5.3) Copyright (C) 1995-2004 Jörg Schilling
scsidev: '1,1,0'
scsibus: 1 target: 1 lun: 0
Using libscg version 'schily-0.8'.
Device type : Removable CD-ROM
Version : 0
Response Format: 1
Vendor_info : 'CyberDrv'
Identifikation : 'CW058D CD-R/RW '
Revision : '140D'
Device seems to be: Generic mmc CD-RW.
Driver options:
burnfree Prepare writer to use BURN-Free technology
noburnfree Disable using BURN-Free technology
 
jetzt weiss ich ein bisschen mehr :) ... es hängt nur beim onfly kopieren .... wenn es zu erst ein image erstellt und dann brennt gehts :) .. na toll ... ich will aber on-fly :))
 
k3b hängt sich auch auf, wenn ich einen usb 2.0 stick am computer hängen habe. dann stolpert k3b bei der laufwerkserkennung über den stick und bleibt hängen.

nur zur information.

ps: kann ich k3b dazu bringen, in die laufwerksuche die usb-geräte nicht mit einzubeziehen?
 
K3b ist auch mit iomega zip Laufwerken unverträglich!

Hallo,

bei mir schafft es K3b auch sich aufzuhängen,
wenn ein iomega zip atapi Laufwerk angeschlossen ist.

Wenn ich brennen will, muß ich vorher
das iomega zip atapi Laufwerk abstöpseln. :ugly:

Gruß, Fusselbär
 
Hatte das Problem und hab es gelöst

Ich hatte auch dieses Problem mit k3b; der Fehler wurde dadurch verursacht, daß beim Test der Laufwerke versucht wurde mein Zip-Laufwerk anzusprechen, aber ich dachte zuerst auch es liegt an atapicam.
Mein Zip-Lw ist bei mir /dev/pass6, welches beim Systemstart einfach gelöscht wird durch einen Eintrag in rc.local.
Ich hatte seitdem keine derartigen Probleme mehr.
Ich hoffe, daß es euch vielleicht ein wenig weiter hilft, um das Problem bei euch auch zu beseitigen.
 
Bitte um Beispiel für rc.local

Hallo Ego,

kannst Du mal als Beispiel posten,
wie Du das in Deiner rc.local bzw rc.conf.local gemacht hast,
mit dem iomega zip atapi Laufwerk.

Ich lese mir gerade nochmal die man Pages durch,
und suche mit Google,
aber so schnelll krieg ich´s nicht zusammen.


Wäre supernett, so eine Vorgabe als Beispiel. :)
Danke im voraus.

Gruß, Fusselbär
 
Wie gesagt bei mir wird Zip noch als /dev/pass6 angelegt
In der rc.local habe ich dann einfach: rm /dev/pass6
alternativ sollte auch ein chmod gehen, so daß du kein Recht hast darauf zuzugreifen
 
Danke für den Tipp, es funktioniert wunderbar!

Hallo Ego,

da möchte ich mich ganz herzlich für bedanken! :)

Ich habe es jetzt einfach mal in die rc.conf
eingetragen, und es funktioniert!

K3b startet ganz brav ohne zu mucken.

Rausfinden welches device es ist, mit :
camcontrol devlist

Dann (bei mir ist es pass2) in die rc.conf
Code:
#######################################
# Iomega Zip atapi camcontroll entf   #
#######################################

rm /dev/pass2

Und freuen! *Juchhu*

Gruß, Fusselbär
 
Noch eine kleine Optimierung für das iomega zip atapi Laufwerk

Hallo,

für diejenigen die den pass für ihr iomega zip atapi Laufwerk
entfernen wollen,
noch ein klitzekleiner Tipp:

ein einfaches
rm /dev/pass2

in der rc.conf
wirft ab dem zweiten mal eine Fehlermeldung zurück,
weil dann ja das /dev/pass2 schon weg ist.

Also wird man mit Fehlermeldungen vollgespammt. :apaul:
Um das abzustellen, habe ich das so geändert:

rc.conf
Code:
#######################################
# Iomega Zip atapi camcontroll entf   #
#######################################

rm -f /dev/pass2

Seitdem ist Ruhe. :D

Noch eleganter wäre sicherlich,
wenn das /dev/pass_für_das_iomega_zip_atapi_Laufwerk
nur ein einziges mal gelöscht würde.

Aber leider habe ich noch zu wenig Plan. ;'(


Gruß, Fusselbär
 
@ raprezent

Hast Du mal den in /usr/ports/sysutils/k3b make showinfo gemacht?
Die Sachen die dort stehen sind sehr wichtig.
Meistens kommt es zum hackeln, wenn man

a) keinen DMA33 Mode an hat.
b) vieleicht der Brenner Treiber fuer k3b auf auto steht.
c) in der fstab den mountpoint nicht richtig festgelegt hat.

Ein paar mehr Info's zum OS waeren auch toll.

CAT
 
hallihallo

also ich schaffs jetzt doch zum on-fly brennen ... mit folgenden einträgen in der loader.conf

hw.ata.atapi_dma=1
hw.ata.ata_dma=1
hw.ata.wc=1
hw.ata.tags=1

bringt zwar immer noch ein eingabe-/ausgabefehler .. egal .. es brennt ... und die cds sind nachher auch lesbar :)

danke trotzdem für eure bemühungen
 
snoopy said:
k3b hängt sich auch auf, wenn ich einen usb 2.0 stick am computer hängen habe. dann stolpert k3b bei der laufwerkserkennung über den stick und bleibt hängen.
In k3b-0.11.18 ist an der devicedetection noch was verändert worden, was diesen Fehler beheben könnte.

Unabhängig davon wird nicht umsonst bei jedem Port ein Maintainer angegeben. Wenn man also sicher ist, dass es nicht an einer Fehlkonfiguration des eigenen Systems liegt (und devicenodes aus /dev zu löschen ist nur ein temporärer Workaround, keine Lösung) ist es sinnvoll, den Maintainer anzumailen (aber bitte pkg-message vorher lesen!).

Der Maintainer kann Fehler nicht beheben, die bei ihm nicht auftreten und die ihm keiner mitteilt.

Falls diese Fehler bei der Laufwerkserkennung auch bei der aktuellen Version aus den Ports auftreten, schickt dem Maintainer bitte eine Mail, wo ihr euer Problem beschreibt und mindestens folgende Informationen beifügt:

- uname -a
- camcontrol devlist -v
- pkg_info | grep k3b
- Ein Log der Ausgabe von k3b (k3b aus dem Terminal heraus aufrufen und alles was ausgegeben wird mitloggen (kann man gut mit script(1) machen).

Markus
 
Maintainer sofort benachrichtigen?

Hallo,

leider habe ich ja noch nicht so den Plan was FreeBSD betrifft,
ich habe noch viel zu lernen.

Also ist es nicht sicher,
das ein Fehler den ich hier habe,
ein Fehler des Programms ist,
oder ich irgendwo zu schusselig war. :ugly:

Darum werde ich mich im Augenblick hüten,
den Maintainer zu verunsichern,
oder dazu zu bewegen, das Programm umzubauen,
das es auf meiner angeknacksten Installation läuft,
aber eventuell viele weitere User zusätzliche Probleme bekommen,
nur weil ich so ein dusseliges iomega zip atapi Laufwerk habe,
das mit atapicam und cdrecord und K3b mein System zum Absturz bringt.

Nichts für ungut, mit dem Vorschlag den Maintainer zu verständigen,
aber ich fühle mich mit meinem Wissenstand noch nicht berufen,
irgendwelche Änderungen herbeizuführen.

Womöglich richte ich da mehr Schaden an,
als das es zu Verbesserungen führt. :apaul:

Der Workaround mit dem
"rm -f /dev/pass_des_iomega_zip_atapi_laufwerk"
Funktioniert ja auf meinem eigenen Recher.
(Er steht zu Hause und wird privat genutzt)
Und ist noch recht überschaubar,
wenn vielleicht auch nicht besonders ästhetisch.

So beschäftige ich mich lieber noch ein bißchen
mit dem eigenem FreeBSD System,
bis ich glaube,
das ich wenigstens nicht noch Schaden bei anderen anrichte,
wenn ich den Maintainer dazu bringe, Veränderungen vorzunehmen.

Ich hoffe, das kann so erst mal akzeptiert werden.


Gruß, Fusselbär
 
Mann muss die Laufwerke nicht loeschen lassen beim Start.

Code:
 # vim /etc/devfs.conf
perm      0660   xpt0
perm      0660   pass0
perm      0600   pass1

So kann man es einfach realisieren, dass nicht auf pass1 zugegriffen werden kann.
Jeder Device bekommt ja sein eigenes pass*.

Das klappt, ausser man benutzt sein System als root User.... Dann ist man aber auch selbst schuld.


CAT
 
Hallo,

Das mit den geänderten Rechten wäre nätürlich auch eine Idee,
aber ich brauche doch überhaupt keine SCSI Emulation
für mein iomega atapi zip Laufwerk.

Also kann ich doch den unötigen Devicenode
auch gleich ganz entfernen, oder? :confused:

Gruß, Fusselbär
 
Fusselbär said:
Hallo,

aber ich brauche doch überhaupt keine SCSI Emulation
für mein iomega atapi zip Laufwerk.

Also kann ich doch den unötigen Devicenode
auch gleich ganz entfernen, oder?

Als welchen device "erkennt" k3b Dein IOMEGA Drive denn?
Wenn man das Geraet benutzen will ist es doof es vorher zu loeschen oder?
Dein Iomega ist da kein gutes Beispiel.
Ein Kartenleser wird aber auch im k3b "erkannt".
Mit der /etc/devfs.conf Methode kann man es fuer k3b "sperren".
Loesche ich jedesmal die device nodes beim start kann ich auch keine Bilder von meinen Karten auslesen oder? FreeBSD denkt sich ja was dabei, wenn es den device erkennt. Benutzt Du das Laufwerk nicht, kannst Du es ja aus dem Kernel entfernen. Dann haste den ganzen Stress schon nicht.

CAT
 
Back
Top