From owner-freebsd-scsi Mon Apr 9 16:51:48 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 9B21F37B424 for ; Mon, 9 Apr 2001 16:51:43 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id RAA86508; Mon, 9 Apr 2001 17:51:37 -0600 (MDT) (envelope-from ken) Date: Mon, 9 Apr 2001 17:51:37 -0600 From: "Kenneth D. Merry" To: Eric Lee Green Cc: Ken Menzel , freebsd-scsi@FreeBSD.ORG Subject: Re: 'ch' Errors using chio w-sony changer Message-ID: <20010409175137.C86267@panzer.kdm.org> References: <20010409102114.A82661@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from eric@estinc.com on Mon, Apr 09, 2001 at 04:32:16PM -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Apr 09, 2001 at 16:32:16 -0700, Eric Lee Green wrote: > On Mon, 9 Apr 2001, Kenneth D. Merry wrote: > > On Mon, Apr 09, 2001 at 10:23:49 -0400, Ken Menzel wrote: > > > Hi All, > > > I have looked at the man pages and manual and archives and source > > > for chio. My 'guess' is that there is soemthing in the return of the > > > status of the drive that the 'ch' driver doesn't like. The error is a > > > follows: > > > > > > janeway# chio return drive 0 > > > chio: /dev/ch0: CHIOGSTATUS: Invalid argument > > > > > > And /var/log/messages gets: > > > > > > Apr 9 10:17:54 janeway /kernel: (ch0:ahc0:0:6:1): READ ELEMENT > > > STATUS. CDB: b8 > > > 30 0 1 0 1 0 0 4 0 0 0 > > > Apr 9 10:17:54 janeway /kernel: (ch0:ahc0:0:6:1): ILLEGAL REQUEST > > > asc:24,0 > > > Apr 9 10:17:54 janeway /kernel: (ch0:ahc0:0:6:1): Invalid field in > > > CDB sks:cc,1 > > Let's see. b8 is read element status alright. But what's that 30? > According to my trusty T10 SMC draft specs, 30 is an illegal byte 1 for a > Read Element Status command. If it was 03 you would be requesting > import/export elements, if it was 10 you'd be requesting anything with bar > codes, but 30... no. Bits 6 and 5 are reserved, according to the T10 > specs. (bit 4 is okay, that's the voltag bit). They're reserved for the LUN number in SCSI-2 and below. The changer is at LUN 1, thus the '1' in the top three bits. (It claims to be SCSI-2, thus the reason we put the LUN there.) The sense key specific information is complaining about the voltag request, not the LUN. Evidently his changer doesn't like to return voltags. Ken, does your changer return an error (in dmesg) from 'chio status'? > Do note that the above message IS normal if you send a bit 4 in byte 1 of > the CDB to autoloaders which have no bar code reader. They spit up, and at > least in mtx I then back down to a plain 00 for byte 1 of the CDB (no bar > codes). Thus that entry in /var/log/messages is not an error, assuming > that chio does a similar thing (backs off and tries to get status without > bar codes). It doesn't attempt to get the status without voltags, so that's probably a bug. > > Have you tried 'chio move'? > > > > > However: > > > janeway# chio status > > > picker 0: > > > slot 0: > > > > Can you send the output of 'chio status -S'? > > > > Well, first off, you can only 'return' something if it has a valid source > > address. chio status -S will likely tell you if that is the case. > > Another possibility: Many loaders require you to eject the tape from the > drive prior to returning it to its source slot. I have no idea if chio > deals with that situation. I know I don't deal with it in mtx > (http://mtx.sourceforge.net), I just blithely spew guts all over and > expect you to figure it out for yourself. The problem was that his changer doesn't report source elements. He was able to fix the problem by using 'chio move', but he didn't CC that message to the list. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message