From owner-freebsd-scsi Sun Jun 22 04:22:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA27488 for freebsd-scsi-outgoing; Sun, 22 Jun 1997 04:22:04 -0700 (PDT) Received: from ns1.netcologne.de (ns1.netcologne.de [194.8.194.70]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id EAA27397; Sun, 22 Jun 1997 04:21:51 -0700 (PDT) Received: from theseus.mediaconsult.de by ns1.netcologne.de (8.6.12/NetCologne/marvin/netsafe-a0020) id ; Sun, 22 Jun 1997 12:58:25 +0200 with ESMTP X-Ncc-Regid: de.netcologne Message-ID: <33AD0A8E.ED1452A0@netcologne.de> Date: Sun, 22 Jun 1997 13:20:46 +0200 From: Richard Cochius Reply-To: richard.cochius@netcologne.de Organization: Media Connect Cologne X-Mailer: Mozilla 4.0b5 [en] (Win95; I) MIME-Version: 1.0 To: FREEBSD-ADMIN@freebsd.org, FREEBSD-ANNOUNCE@freebsd.org, FREEBSD-ARCH@freebsd.org, FREEBSD-BUGS@freebsd.org, FREEBSD-CORE@freebsd.org, FREEBSD-CURRENT@freebsd.org, FREEBSD-CURRENT-DIGEST@freebsd.org, FREEBSD-STABLE@freebsd.org, FREEBSD-DOC@freebsd.org, FREEBSD-FS@freebsd.org, FREEBSD-HACKERS@freebsd.org, FREEBSD-HACKERS-DIGEST@freebsd.org, FREEBSD-HARDWARE@freebsd.org, FREEBSD-INSTALL@freebsd.org, FREEBSD-ISP@freebsd.org, FREEBSD-MULTIMEDIA@freebsd.org, FREEBSD-PLATFORMS@freebsd.org, FREEBSD-PORTS@freebsd.org, FREEBSD-QUESTIONS@freebsd.org, FREEBSD-QUESTIONS-DIGEST@freebsd.org, FREEBSD-SCSI@freebsd.org, FREEBSD-SECURITY@freebsd.org, FREEBSD-SECURITY-NOTIFICATIONS@freebsd.org, FREEBSD-USER-GROUPS@freebsd.org Subject: subscribe X-Priority: 3 (Normal) Content-Type: text/plain; charset=iso-8859-1 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk From owner-freebsd-scsi Mon Jun 23 00:36:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA19037 for freebsd-scsi-outgoing; Mon, 23 Jun 1997 00:36:10 -0700 (PDT) Received: from oskar.nanoteq.co.za (oskar.nanoteq.co.za [163.195.220.170]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA18984; Mon, 23 Jun 1997 00:35:52 -0700 (PDT) Received: (from rbezuide@localhost) by oskar.nanoteq.co.za (8.8.5/8.8.5) id JAA15488; Mon, 23 Jun 1997 09:35:14 +0200 (SAT) From: Reinier Bezuidenhout Message-Id: <199706230735.JAA15488@oskar.nanoteq.co.za> Subject: Re: SCSI Problems In-Reply-To: from Jared Proudfoot at "Jun 19, 97 04:09:56 pm" To: jaredp@direct.ca (Jared Proudfoot) Date: Mon, 23 Jun 1997 09:35:14 +0200 (SAT) Cc: freebsd-questions@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi ... > I'm currently running FreeBSD 2.2.1-RELEASE on a P166 with 128MB RAM, an > Adaptec 2940 UW controller, 2 Quantam Atlases, 1 Quantam Grand Prix and an > IDE Quantum Sirocco. I'm running the latest SCSI code I could find (I think) on a P166 128MB RAM and an adaptek 2940 controller and have experienced the same error messages. Same thing with the "time out while idle" etc. I only don't have Quantum disks, but two IBM DORS and an HP DAT (4Gig). In this case it is the HP DAT dat seems to be the culprit everytime, BUT !!, when attaching the DAT to a 2.2 (not even the latest SCSI code) macine (120 MHz pentium 16MB RAM) the error does not occur ???? !!!!! Can this be a timing problem with faster machines, like a P166 ?? > > The machine will lock up periodically, giving SCSI drive errors. Here's > the errors I've been getting, the error as reported in /var/log/messages > and a copy of my dmesg output: > > sd1(ahc0:5:0): UNIT ATTENTION asc:29,1 retires: 4 > SCB: 0x1 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 > > SEQADDR == 0x4 > Queueing an Abort SCB > Queueing an Abort SCB > > no longer in timeout Mine doesn't always get out of the timeout :( :( Reinier From owner-freebsd-scsi Mon Jun 23 00:52:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA19881 for freebsd-scsi-outgoing; Mon, 23 Jun 1997 00:52:27 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA19875; Mon, 23 Jun 1997 00:52:22 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA02429; Mon, 23 Jun 1997 09:52:20 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id JAA26750; Mon, 23 Jun 1997 09:36:37 +0200 (MET DST) Message-ID: <19970623093637.MV17592@uriah.heep.sax.de> Date: Mon, 23 Jun 1997 09:36:37 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: scsi@freebsd.org Cc: mmcg@cs.monash.edu.au, jmz@freebsd.org Subject: Re:kern/3909:Apatchsupportingsomenewwormdrivers References: <199706230355.NAA21529@heraclitus.cs.monash.edu.au> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199706230355.NAA21529@heraclitus.cs.monash.edu.au>; from mmcg@cs.monash.edu.au on Jun 23, 1997 13:55:12 +1000 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk (Redirecting from `bugs' to `scsi'. Jean-Marc, are you also on this list?) As mmcg@cs.monash.edu.au wrote: > > Multisession works fine for me (one of my test CDs bailed out with [...] > > For writing, you should always set the block number to 0. > > Hmm. My SCSI manual claims that blocks are always relative to > logical block 0, which is at 0:02:00 (I presumed this included > when writing). Do I want to ruin my perfect record to test > this? (29 CDs, 0 coasters :) I don't think you're ruining anything. Since writes to a CD-R are always in streaming mode, and per track, the block number doesn't make much sense at all. My Plasmon manual marks the block address in the WRITE command as `reserved', the HP manual mandates it to be either the next block in sequence, or 0. We settled to always provide it as 0 in the current driver. > > These things have been moved out to scsiconfig.c. I assume you had to > > modify scsiconfig.c anyway, in order to make the device known as a > > CD-R, did you? > > No, it's configured as a `worm' type scsi device (device type 4?), > and the kernel happily attaches it to worm0. Interesting. Then it's different from the HPs in this respect. My Plasmon also announces itself as type 4, unless i put a CD-ROM (or fixated CD-R) into the drive. > > scsiconfig { "T.YUDEN CD-WO", "EW-50", ...} or { "T.YUDEN", "CD-WO > > EW-50", ... }? > 04 80 02 02 27 00 00 18 54 2e 59 55 44 45 4e 20 # ....'...T.YUDEN > 43 44 2d 57 4f 20 45 57 2d 35 30 20 20 20 20 20 # CD-WO EW-50 > 32 2e 31 36 31 38 2f 31 30 2f 39 36 00 00 00 00 # 2.1618/10/96.... > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 # ................ This makes it { "T.YUDEN", "CD-WO EW-50", ... }. > > What's the difference to the existing HP4020/HP6020/CDD2000/CDD2660 > > option? From a cursory look, i didn't see any. There's not much use > > to duplicate code. > > You're quite right - the only quirk function that changed was the > prepare_track routine. I added a `Write Track' command, which > causes laser calibration to commence on the unit. Hmm, doesn't the drive do this automatically at the first write? I think that's how it's documented for my drive. The write channel can either be opened explicitly by a WRITE TRACK command, or implicitly by the first WRITE command provided that the other preparations have been done. I opted for the latter sequence, since it looked easier to implement to me. As i understand it, the power calibration is a necessary step the burner cannot omit at all. > the general (non drive-specific) finalize_track routine to do the > flush to disk before issuing the spindown; doing it in the other > order confused my drive. As i wrote, we agreed that the spindown is totally useless (it has apparently been cloned from the CD-ROM driver), and Jean-Marc did already do the deed of killing it. > > I suspect you could have been successfully using the old code, too, by > > pretending it to be an HP 4020i? > > No, this failed when finalizing the track. Ah, yep. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Mon Jun 23 02:13:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA23780 for freebsd-scsi-outgoing; Mon, 23 Jun 1997 02:13:20 -0700 (PDT) Received: from elch.heim4.tu-clausthal.de (100@elch.heim4.tu-clausthal.de [139.174.244.250]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA23770 for ; Mon, 23 Jun 1997 02:13:15 -0700 (PDT) Received: (from olli@localhost) by elch.heim4.tu-clausthal.de (8.8.5/8.8.5) id LAA16661 for freebsd-scsi@freebsd.org; Mon, 23 Jun 1997 11:13:01 +0200 (MET DST) Message-Id: <199706230913.LAA16661@elch.heim4.tu-clausthal.de> Subject: Re: SCSI Problems To: freebsd-scsi@freebsd.org Date: Mon, 23 Jun 1997 11:13:01 +0200 (MET DST) In-Reply-To: <199706230735.JAA15488@oskar.nanoteq.co.za> from "Reinier Bezuidenhout" at Jun 23, 97 09:35:14 am From: oliver.fromme@heim3.tu-clausthal.de (Oliver Fromme) X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > > I'm currently running FreeBSD 2.2.1-RELEASE on a P166 with 128MB RAM, an > > Adaptec 2940 UW controller, 2 Quantam Atlases, 1 Quantam Grand Prix and an > > IDE Quantum Sirocco. > > I'm running the latest SCSI code I could find (I think) on a P166 128MB RAM > and an adaptek 2940 controller and have experienced the same error messages. > Same thing with the "time out while idle" etc. > > I only don't have Quantum disks, but two IBM DORS and an HP DAT (4Gig). In > this case it is the HP DAT dat seems to be the culprit everytime, > > BUT !!, when attaching the DAT to a 2.2 (not even the latest SCSI code) > macine (120 MHz pentium 16MB RAM) the error does not occur ???? !!!!! > Can this be a timing problem with faster machines, like a P166 ?? > [...] > Mine doesn't always get out of the timeout :( :( Mine neither. I'd just like to mention that exactly the same happens to me -- I also have a P166, 128 Mb RAM, and a HP DAT streamer (connected to an Adaptec 2940) which is causing problems: a bunch of kernel messages regarding the SCSI bus, followed by a complete lockup (no sync, no panic -- have to press the red button). If it is of any help for someone, I can quote the exact messages/logs if necessary. By the way, this is a 2.2.1 with updated kernel (which was said to fix the adaptec problems of the 2.2.1 kernel). My SCSI bus is correctly terminated and not too long, the cables are ok. I have no problems accessing the DAT streamer under NT (yes, I still have to use WinNT sometimes ... I wish FreeBSD would support my scanner). Sometimes my CD-ROM (a NEC CDR-512) causes problems, too, but the HP DAT is much worse, it's almost unusable under FreeBSD. I'll try to plug the HP DAT into a slower box, maybe it's really the timing. Regards Oliver Fromme -- Oliver Fromme, Leibnizstr. 18-61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) From owner-freebsd-scsi Mon Jun 23 12:00:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA22409 for freebsd-scsi-outgoing; Mon, 23 Jun 1997 12:00:46 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA22386 for ; Mon, 23 Jun 1997 12:00:40 -0700 (PDT) Received: (qmail 5952 invoked by uid 1000); 23 Jun 1997 19:00:26 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Mon, 23 Jun 1997 12:00:25 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: FreeBSD-SCSI@FreeBSD.ORG Subject: DPT for FreeBSD - New Driver Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Y'all, We just completed a new version of the DPT driver. It will be available momentarily on ftp://sendero-ppp.i-connect.net/crash. Highlights: * Some minor bug fixes. * Initial working sample of the Raid Manager driver Raid Manager Driver: The DPT SCSI subsystem allows a high degree of tuning and configuration control. For these features to run under FreeBSD, we have added a character device driver. Pending approval and acceptance, here are some highlights and ``how to play'' notes: * There are two interfaces, an IOCTL interface which is a superset of the standard DPT interface. This is being made compatible with the SCO and UnixWare interfaces. ALL the pertinent DPT calls will be supported, in addition to some ``local'' FreeBSD specific ones. These later ones are mapped to mirror the READ/WRITE interface described below. * The R/W interface allows you to write an ASCII message to the controller and then read the result. To make things a bit safer, no action is taken on the write operation, only on the READ. Results are provided as ASCII readable records. * To install the interface, create /dev/dptX, where X is the controller number. Set the major number to 130 (pending approval) and the minor number to match X The first DPT is /dev/dpt0 130,0, then /dev/dpt1 130,1, etc. * To WRITE a command, simply use ``echo -n "some command'' > /dev/dptX. you need the -n as without it echo makes TWO write system calls; one with the message, one with the '\n'. Without the -n, the command will be NULL; We always remember the last command. * To have the command parsed, executed, and results returned, read 4095 bytes from /dev/dptX. Do not try the cat command yet. It tries to read 64K and gets confused when we return a residual. I wrote a little throwaway that reads 4095 bytes from the port, using syscalls rather than buffered I/O. Called dpt_get.c and in the usual place. * Only few commands are implemented: "dump softc" Will dump the entire softc structure for the controller. Things of interest are the queue management and timers. We time how long it takes for a SCSI command before we actually put it into the DPT (waiting queue), how long it takes the DPT to return to us (submitted queue) and how long before we send it back to the SCSI layer. We keep the maximum depth of each queue, the shortest time spent there and the longest time spent there. Another thing measured is the min/max time the DPT took to execute each type of SCSI command, along with the number of commands executed. "dump metrics" Dumps just the metrics portion of the softc. Future release will include statistics gathered by the DPT hardware. These include I/O by block size, error rates, RAID status, cabinet status, etc. "sintr on" Enables software interrupts. This is the default mode. In this mode, submitting SCSI commands and actually parsing completion errors are done in a separate execution thread. This thread is managed by calling software interrupts to invoke these procedures. For workstation type loads it is quite meaningless, but for heavily loaded servers it is very meaningfull. For example; 256 concurrent processes all doing continious I/O on the disk result, in a non-sintr (see below) load average of about 110-120. This makes the machine very, very sluggish in responding to non-DPT events, as well as DPT events. With sintr on, the same exact load results in LA of about 5 (with occasional peaks at 9). Response and throughput on the DPT is still miserable, but the rest of the system responds very well. This allows us to respond, without timeouts, to real- time network events, even when the disk is absurdely busy. "sintr off" Turns off software interrupts. In this mode, the driver blocks until a command is submitted and the interrupt routine stays in critical section until a completion is resolved. This is almost identical to the normal FreeBSD SCSI driver. NOTE: Changing from one mode to another, on a ``hot'' system is akin to changing gears in a manual transmission without a clutch. It can be done but you really need to know what you are doing. Transalation: Use at your own peril. This is it folks. Please try and break it. We are counting on you :-) Thanx, Simon From owner-freebsd-scsi Tue Jun 24 04:58:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA10488 for freebsd-scsi-outgoing; Tue, 24 Jun 1997 04:58:44 -0700 (PDT) Received: from bagpuss.visint.co.uk (bagpuss.visint.co.uk [194.207.134.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA10482 for ; Tue, 24 Jun 1997 04:58:39 -0700 (PDT) Received: from dylan.visint.co.uk (dylan.visint.co.uk [194.207.134.180]) by bagpuss.visint.co.uk (8.7.5/8.7.3) with SMTP id MAA09633; Tue, 24 Jun 1997 12:58:35 +0100 (BST) Date: Tue, 24 Jun 1997 12:58:35 +0100 (BST) From: Stephen Roome To: scsi@freebsd.org cc: steve@visint.co.uk Subject: SCSI errors since removing FreeBSD. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Weird problem follows: I've got an Gigabyte GA-586DX (dual processor pentium) motherboard which has an onboard Adaptec-7880P. Attached to this is one Quantum Fireball TM3200, 3.2 GB SCSI-2 drive. (P/N: TM32S012 Rev 04-D). I can't get the disk to either verify or format from the SCSI BIOS. Attempting to verify the disk, causes the entire machine to hang and an attempt to format fails partway through and the next attempt to format results in the following.. % Unexpected SCSI Command Failed Target SCSI ID: 0 SCSI CDB Sent: 03 00 00 00 0E 00 70 00 03 00 Host Adapter Status: OOh - No host adapter error Target Status: O2h - Check Condition Sense Key: 03h - Medium error +Sense Code: 31h +Sense Code Qualifier: 00h Press ESC to continue % The drive is properly terminated and the motherboard is jumpered for high byte terminator ON/OFF controlled by software. The BIOS is set as controller terminated. Other than that, there is one ISA graphics card in this machine, 64MB of EDO RAM and two Intel P133's, nothing else. Now what's really odd is that I used this setup with FreeBSD-current and SMP fairly recently and all was fine, since wiping the disc down from FreeBSD and attempting to install over the top I'm getting all these problems from a system that was working fine. Many Thanks, Steve Roome - Vision Interactive Ltd. Tel:+44(0)117 9730597 Home:+44(0)976 241342 WWW: http://dylan.visint.co.uk/ From owner-freebsd-scsi Tue Jun 24 13:29:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA04857 for freebsd-scsi-outgoing; Tue, 24 Jun 1997 13:29:08 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA04844 for ; Tue, 24 Jun 1997 13:29:02 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA24453; Tue, 24 Jun 1997 22:28:53 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id WAA02737; Tue, 24 Jun 1997 22:12:18 +0200 (MET DST) Message-ID: <19970624221218.KT52263@uriah.heep.sax.de> Date: Tue, 24 Jun 1997 22:12:18 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: scsi@FreeBSD.ORG Cc: steve@visint.co.uk (Stephen Roome) Subject: Re: SCSI errors since removing FreeBSD. References: X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Stephen Roome on Jun 24, 1997 12:58:35 +0100 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Stephen Roome wrote: > % > Unexpected SCSI Command Failed > Target SCSI ID: 0 > SCSI CDB Sent: 03 00 00 00 0E 00 70 00 03 00 > Host Adapter Status: OOh - No host adapter error > Target Status: O2h - Check Condition > Sense Key: 03h - Medium error > +Sense Code: 31h > +Sense Code Qualifier: 00h 31 00 DT W O MEDIUM FORMAT CORRUPTED That means formatting has been incomplete. You need to find out why. Try the FreeBSD fixit floppy. I think scsiformat is missing on it, but scsi(8) itself should be there. Try: scsi -s 3600 -f /dev/rsd0.ctl -c "4 0 0 0 0 0" (and get a cup of coffee afterwards). At least, if FreeBSD fails to format it, you'll get a useful SCSI error message... I think if formatting repeatedly fails, it's really your drive that went south now, for whatever reason. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)