On Tue, Nov 09, 2004 at 11:18:09PM +0100, Oliver Lehmann wrote:
> Hallo,
>
> ich habe hier ein aelteres
>
> sa0: <ARCHIVE IBM4326NP/RP !D 5ALB> Removable Sequential Access SCSI-2
> device
> sa0: 7.812MB/s transfers (7.812MHz, offset 15)
>
> welches bei einem camcontrol eject das tape erst nach einer ganzen weile
> dann irgendwann mal hergibt, sich aber mit
Nun er wird erst noch zurückspulen.
Oder macht er das auch wenn du vorher schon gespult hast?
> Error received from stop unit command
Error received ist jetzt nicht wirklich eine tolle Aussage.
> zurueckmeldet. Danach ist das Tape-Drive mittels camcontrol (mit neuem
> Band) nicht mehr zu gebrauchen. Wenn ich dann mal ein einfaches "mt
> status" mache, geht danach auch camcontrol wieder.
> Das Tape meldet per LED aber keinen Error. (was is z.B. macht
> wenn es mal gereinigt werden will usw) Die beschriebenen Baender lassen
> sich in anderen Laufwerken problemlos lesen.
> Hat einer eine Idee was man da machen koennte? Ich habe mal cam-debugging
> aktiviert, aber da kommt auch nicht viel bei rum. (bzw. nichts womit ich
> was anfangen koennte)
>
> cam_debug: xpt_schedule_dev
> cam_debug: Inserting onto queue
> cam_debug: xpt_run_dev_allocq
> cam_debug: qfrozen_cnt == 0x0, entries == 1, openings == 448, active ==
> 0
> cam_debug: running device 0xfffffc0000a48a00
> cam_debug: calling periph start
> cam_debug: xpt_schedule_dev
> cam_debug: Inserting onto queue
> cam_debug: xpt_run_dev_sendq
> cam_debug: running device 0xfffffc0000a48a00
> cam_debug: xpt_release_ccb
>
> in immer wiederkehrenden Bloecken bis zum abwinken.
Welche Meldungen kommen denn wenn du kein extra Debugging anmachst?
Die xpt_schedule Dinger sind jedenfalls nicht sonderlich hilfreich,
solange du den Fehler nicht im CAM Layer selber suchst.
-- B.Walter BWCT http://www.bwct.de bernd(at)bwct.de info(at)bwct.de To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org with "unsubscribe de-bsd-questions" in the body of the messageReceived on Tue 09 Nov 2004 - 23:32:54 CET