From owner-freebsd-scsi Sun Jul 7 10:58:54 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA01906 for freebsd-scsi-outgoing; Sun, 7 Jul 1996 10:58:54 -0700 (PDT) Received: from mailbox.neosoft.com (mailbox.neosoft.com [206.109.1.16]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA01897 for ; Sun, 7 Jul 1996 10:58:51 -0700 (PDT) Received: from bonkers.taronga.com (root@bonkers.neosoft.com [206.109.2.48]) by mailbox.neosoft.com (8.7.5/8.7.3) with SMTP id MAA03490 for ; Sun, 7 Jul 1996 12:58:47 -0500 (CDT) Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id MAA16799 for scsi@freebsd.org; Sun, 7 Jul 1996 12:55:30 -0500 Date: Sun, 7 Jul 1996 12:55:30 -0500 From: peter@taronga.com (Peter da Silva) Message-Id: <199607071755.MAA16799@bonkers.taronga.com> To: scsi@freebsd.org Subject: aha1542b errors, any ideas? Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I keep getting these scsi bus lockups on my secondary SCSI controller. Any ideas? Any way to reset the controller (it's only got a tape drive on it)? Jul 6 20:25:25 bonkers /kernel: st1(aha0:6:0): timed out Jul 6 20:25:29 bonkers /kernel: st1(aha0:6:0): timed out Jul 6 20:25:29 bonkers /kernel: adapter not taking commands.. frozen?! Jul 6 20:25:29 bonkers /kernel: Debugger("aha1542") called. Jul 6 20:25:29 bonkers /kernel: AGAIN Jul 6 20:25:29 bonkers /kernel: aha0: MBO 02 and not 00 (free) Jul 6 20:27:09 bonkers /kernel: st1(aha0:6:0): timed out Jul 6 20:27:09 bonkers /kernel: adapter not taking commands.. frozen?! Jul 6 20:27:09 bonkers /kernel: Debugger("aha1542") called. Jul 6 20:27:09 bonkers /kernel: Jul 6 20:27:13 bonkers /kernel: st1(aha0:6:0): timed out Jul 6 20:27:13 bonkers /kernel: adapter not taking commands.. frozen?! Jul 6 20:27:13 bonkers /kernel: Debugger("aha1542") called. Jul 6 20:27:13 bonkers /kernel: AGAIN Jul 6 20:27:13 bonkers /kernel: aha0: MBO 02 and not 00 (free) Jul 6 20:28:53 bonkers /kernel: st1(aha0:6:0): timed out Jul 6 20:28:53 bonkers /kernel: adapter not taking commands.. frozen?! Jul 6 20:28:53 bonkers /kernel: Debugger("aha1542") called. Jul 6 20:28:53 bonkers /kernel: Jul 6 20:28:57 bonkers /kernel: st1(aha0:6:0): timed out Jul 6 20:28:57 bonkers /kernel: adapter not taking commands.. frozen?! Jul 6 20:28:57 bonkers /kernel: Debugger("aha1542") called. Jul 6 20:28:57 bonkers /kernel: AGAIN Jul 6 20:28:57 bonkers /kernel: aha0: MBO 02 and not 00 (free) Jul 6 20:30:37 bonkers /kernel: st1(aha0:6:0): timed out Jul 6 20:30:37 bonkers /kernel: adapter not taking commands.. frozen?! Jul 6 20:30:37 bonkers /kernel: Debugger("aha1542") called. Jul 6 20:30:37 bonkers /kernel: Jul 6 20:30:41 bonkers /kernel: st1(aha0:6:0): timed out Jul 6 20:30:41 bonkers /kernel: adapter not taking commands.. frozen?! Jul 6 20:30:41 bonkers /kernel: Debugger("aha1542") called. Jul 6 20:30:41 bonkers /kernel: AGAIN Jul 6 20:30:41 bonkers /kernel: aha0: MBO 02 and not 00 (free) Jul 6 20:32:21 bonkers /kernel: st1(aha0:6:0): timed out Jul 6 20:32:21 bonkers /kernel: adapter not taking commands.. frozen?! Jul 6 20:32:21 bonkers /kernel: Debugger("aha1542") called. Jul 6 20:32:21 bonkers /kernel: Jul 6 20:32:25 bonkers /kernel: st1(aha0:6:0): timed out Jul 6 20:32:25 bonkers /kernel: adapter not taking commands.. frozen?! Jul 6 20:32:25 bonkers /kernel: Debugger("aha1542") called. Jul 6 20:32:25 bonkers /kernel: AGAIN Jul 6 20:32:25 bonkers /kernel: aha0: MBO 02 and not 00 (free) Jul 6 20:34:05 bonkers /kernel: st1(aha0:6:0): timed out Jul 6 20:34:05 bonkers /kernel: adapter not taking commands.. frozen?! Jul 6 20:34:05 bonkers /kernel: Debugger("aha1542") called. Jul 6 20:34:05 bonkers /kernel: Jul 6 20:34:09 bonkers /kernel: st1(aha0:6:0): timed out Jul 6 20:34:09 bonkers /kernel: adapter not taking commands.. frozen?! Jul 6 20:34:09 bonkers /kernel: Debugger("aha1542") called. Jul 6 20:34:09 bonkers /kernel: AGAIN Jul 6 20:34:09 bonkers /kernel: aha0: MBO 02 and not 00 (free) Jul 6 20:35:49 bonkers /kernel: st1(aha0:6:0): timed out Jul 6 20:35:49 bonkers /kernel: adapter not taking commands.. frozen?! Jul 6 20:35:49 bonkers /kernel: Debugger("aha1542") called. Jul 6 20:35:49 bonkers /kernel: Jul 6 20:35:53 bonkers /kernel: st1(aha0:6:0): timed out Jul 6 20:35:53 bonkers /kernel: adapter not taking commands.. frozen?! Jul 6 20:35:53 bonkers /kernel: Debugger("aha1542") called. Jul 6 20:35:53 bonkers /kernel: AGAIN Jul 6 20:35:53 bonkers /kernel: aha0: MBO 02 and not 00 (free) Jul 6 20:37:33 bonkers /kernel: st1(aha0:6:0): timed out Jul 6 20:37:33 bonkers /kernel: adapter not taking commands.. frozen?! Jul 6 20:37:33 bonkers /kernel: Debugger("aha1542") called. Jul 6 20:37:33 bonkers /kernel: Jul 6 20:37:37 bonkers /kernel: st1(aha0:6:0): timed out Jul 6 20:37:37 bonkers /kernel: adapter not taking commands.. frozen?! Jul 6 20:37:37 bonkers /kernel: Debugger("aha1542") called. Jul 6 20:37:38 bonkers /kernel: AGAIN Jul 6 20:37:38 bonkers /kernel: aha0: MBO 02 and not 00 (free) Jul 6 20:39:17 bonkers /kernel: st1(aha0:6:0): timed out Jul 6 20:39:17 bonkers /kernel: adapter not taking commands.. frozen?! Jul 6 20:39:17 bonkers /kernel: Debugger("aha1542") called. Jul 6 20:39:17 bonkers /kernel: Jul 6 20:39:21 bonkers /kernel: st1(aha0:6:0): timed out Jul 6 20:39:21 bonkers /kernel: adapter not taking commands.. frozen?! Jul 6 20:39:21 bonkers /kernel: Debugger("aha1542") called. Jul 6 20:39:21 bonkers /kernel: AGAIN Jul 6 20:39:21 bonkers /kernel: aha0: MBO 02 and not 00 (free) Jul 6 20:41:01 bonkers /kernel: st1(aha0:6:0): timed out Jul 6 20:41:01 bonkers /kernel: adapter not taking commands.. frozen?! Jul 6 20:41:01 bonkers /kernel: Debugger("aha1542") called. Jul 6 20:41:01 bonkers /kernel: Jul 6 20:41:05 bonkers /kernel: st1(aha0:6:0): timed out Jul 6 20:41:05 bonkers /kernel: adapter not taking commands.. frozen?! Jul 6 20:41:05 bonkers /kernel: Debugger("aha1542") called. Jul 6 20:41:05 bonkers /kernel: AGAIN Jul 6 20:41:05 bonkers /kernel: aha0: MBO 02 and not 00 (free) Jul 6 20:42:45 bonkers /kernel: st1(aha0:6:0): timed out Jul 6 20:42:45 bonkers /kernel: adapter not taking commands.. frozen?! Jul 6 20:42:45 bonkers /kernel: Debugger("aha1542") called. Jul 6 20:42:45 bonkers /kernel: Jul 6 20:42:49 bonkers /kernel: st1(aha0:6:0): timed out Jul 6 20:42:49 bonkers /kernel: adapter not taking commands.. frozen?! Jul 6 20:42:49 bonkers /kernel: Debugger("aha1542") called. Jul 6 20:42:49 bonkers /kernel: AGAIN Jul 6 20:42:49 bonkers /kernel: aha0: MBO 02 and not 00 (free) Jul 6 20:44:29 bonkers /kernel: st1(aha0:6:0): timed out Jul 6 20:44:29 bonkers /kernel: adapter not taking commands.. frozen?! Jul 6 20:44:29 bonkers /kernel: Debugger("aha1542") called. Jul 6 20:44:29 bonkers /kernel: Jul 6 20:44:33 bonkers /kernel: st1(aha0:6:0): timed out Jul 6 20:44:33 bonkers /kernel: adapter not taking commands.. frozen?! Jul 6 20:44:33 bonkers /kernel: Debugger("aha1542") called. Jul 6 20:44:33 bonkers /kernel: AGAIN Jul 6 20:44:33 bonkers /kernel: aha0: MBO 02 and not 00 (free) Jul 6 20:49:33 bonkers /kernel: st1(aha0:6:0): timed out Jul 6 20:49:33 bonkers /kernel: adapter not taking commands.. frozen?! Jul 6 20:49:33 bonkers /kernel: Debugger("aha1542") called. Jul 6 20:49:33 bonkers /kernel: Jul 6 20:49:37 bonkers /kernel: st1(aha0:6:0): timed out Jul 6 20:49:37 bonkers /kernel: adapter not taking commands.. frozen?! Jul 6 20:49:37 bonkers /kernel: Debugger("aha1542") called. Jul 6 20:49:37 bonkers /kernel: AGAIN Jul 6 20:49:37 bonkers /kernel: aha0: MBO 02 and not 00 (free) Jul 6 20:49:42 bonkers /kernel: st1(aha0:6:0): timed out Jul 6 20:49:42 bonkers /kernel: adapter not taking commands.. frozen?! Jul 6 20:49:42 bonkers /kernel: Debugger("aha1542") called. Jul 6 20:49:42 bonkers /kernel: Jul 6 20:49:46 bonkers /kernel: st1(aha0:6:0): timed out Jul 6 20:49:46 bonkers /kernel: adapter not taking commands.. frozen?! Jul 6 20:49:46 bonkers /kernel: Debugger("aha1542") called. Jul 6 20:49:46 bonkers /kernel: AGAIN From owner-freebsd-scsi Mon Jul 8 19:51:09 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA28161 for freebsd-scsi-outgoing; Mon, 8 Jul 1996 19:51:09 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA28143; Mon, 8 Jul 1996 19:51:05 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id CAA19338; Tue, 9 Jul 1996 02:51:02 GMT Date: Tue, 9 Jul 1996 11:51:02 +0900 (JST) From: Michael Hancock Reply-To: Michael Hancock To: freebsd-current@FreeBSD.ORG cc: freebsd-scsi@FreeBSD.ORG Subject: Adding Jaz drive with sysinstall 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 I managed to create a FreeBSD partition using sysinstall's custom install. But sysinstall wouldn't label it. After 'W'ing the partition changes and entering the label screen I kept getting a "You must partition the disk" error when trying to Write the label. I ended up creating a DOS partition and a FreeBSD partition on the Jaz cartridge using sysinstall and then running disklabel -r sd2 to see what raw device it reported. I then newfs'ed the device manually. It's a pretty fast device, I set MAKEOBJDIR to /jaz and did a make world on it and it wasn't that bad. dmesg tells me that the Jaz reports that its a removable SCSI 2. Is this the source of the ILLEGAL REQUEST message? FreeBSD 2.2-CURRENT #11: Wed Jul 3 12:45:46 JST 1996 (ncr0:5:0): "iomega jaz 1GB G.60" type 0 removable SCSI 2 sd2(ncr0:5:0): Direct-Access sd2(ncr0:5:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. sd2(ncr0:5:0): ILLEGAL REQUEST asc:24,0 Invalid field in CDB sd2 could not mode sense (4). Using ficticious geometry 1021MB (2091050 512 byte sectors) From owner-freebsd-scsi Mon Jul 8 20:07:37 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA29947 for freebsd-scsi-outgoing; Mon, 8 Jul 1996 20:07:37 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA29931; Mon, 8 Jul 1996 20:07:34 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id UAA04582; Mon, 8 Jul 1996 20:06:51 -0700 (PDT) To: Michael Hancock cc: freebsd-current@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: Adding Jaz drive with sysinstall In-reply-to: Your message of "Tue, 09 Jul 1996 11:51:02 +0900." Date: Mon, 08 Jul 1996 20:06:51 -0700 Message-ID: <4580.836881611@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I managed to create a FreeBSD partition using sysinstall's custom install. > But sysinstall wouldn't label it. After 'W'ing the partition changes and > entering the label screen I kept getting a "You must partition the disk" > error when trying to Write the label. Ah, I think I just found and smashed that one - thanks for making me look again.. :-) Jordan From owner-freebsd-scsi Mon Jul 8 21:21:15 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA09936 for freebsd-scsi-outgoing; Mon, 8 Jul 1996 21:21:15 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA09931; Mon, 8 Jul 1996 21:21:12 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id EAA19943; Tue, 9 Jul 1996 04:20:50 GMT Date: Tue, 9 Jul 1996 13:20:50 +0900 (JST) From: Michael Hancock To: "Jordan K. Hubbard" cc: freebsd-current@FreeBSD.org, freebsd-scsi@FreeBSD.org Subject: Re: Adding Jaz drive with sysinstall In-Reply-To: <4580.836881611@time.cdrom.com> 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 On Mon, 8 Jul 1996, Jordan K. Hubbard wrote: > > I managed to create a FreeBSD partition using sysinstall's custom install. > > But sysinstall wouldn't label it. After 'W'ing the partition changes and > > entering the label screen I kept getting a "You must partition the disk" > > error when trying to Write the label. > > Ah, I think I just found and smashed that one - thanks for making me look > again.. :-) Cool. One more observation. When I want to add a new drive the label option insists in making /, /usr/, and swap if I only have the new drive selected. Are you supposed to select all the drives and existing partitions when you use sysinstall to label? I guess it needs some way of differentiating between a new installation and a change of configuration. mike hancock From owner-freebsd-scsi Mon Jul 8 21:23:48 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA10142 for freebsd-scsi-outgoing; Mon, 8 Jul 1996 21:23:48 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA10127; Mon, 8 Jul 1996 21:23:39 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id VAA06320; Mon, 8 Jul 1996 21:22:51 -0700 (PDT) To: Michael Hancock cc: freebsd-current@FreeBSD.org, freebsd-scsi@FreeBSD.org Subject: Re: Adding Jaz drive with sysinstall In-reply-to: Your message of "Tue, 09 Jul 1996 13:20:50 +0900." Date: Mon, 08 Jul 1996 21:22:50 -0700 Message-ID: <6318.836886170@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Cool. One more observation. When I want to add a new drive the label > option insists in making /, /usr/, and swap if I only have the new drive > selected. Ah. Woog. That's a good point. I'll add something to disable the mandatory /, /usr and swap checks when you're adding a new drive. Jordan From owner-freebsd-scsi Tue Jul 9 10:07:27 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA22241 for freebsd-scsi-outgoing; Tue, 9 Jul 1996 10:07:27 -0700 (PDT) Received: from mail.ruhrgebiet.individual.net (in-ruhr.ruhr.de [193.100.176.38]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA22230 for ; Tue, 9 Jul 1996 10:07:22 -0700 (PDT) Received: by mail.ruhrgebiet.individual.net (8.7.1/8.6.12) with UUCP id SAA12541 for freebsd.org!freebsd-scsi; Tue, 9 Jul 1996 18:49:20 +0200 (MET DST) Received: by robkaos.ruhr.de (/\oo/\ Smail3.1.29.1 #29.1) id ; Tue, 9 Jul 96 18:45 MET DST Message-Id: From: robsch@robkaos.ruhr.de (Robert Schien) Subject: Low noise 2 GB hard drive To: freebsd-scsi@freebsd.org Date: Tue, 9 Jul 1996 18:45:46 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm looking for a 2 GB SCSI hard drive which is fast, reliable and most important, quiet ("normal" SCSI, no wide or ulta-wide ones). Which model do you recommend? TIA Robert From owner-freebsd-scsi Tue Jul 9 10:46:10 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA24239 for freebsd-scsi-outgoing; Tue, 9 Jul 1996 10:46:10 -0700 (PDT) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA24234 for ; Tue, 9 Jul 1996 10:46:06 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id KAA07383; Tue, 9 Jul 1996 10:45:48 -0700 From: "Rodney W. Grimes" Message-Id: <199607091745.KAA07383@GndRsh.aac.dev.com> Subject: Re: Low noise 2 GB hard drive To: robsch@robkaos.ruhr.de (Robert Schien) Date: Tue, 9 Jul 1996 10:45:48 -0700 (PDT) Cc: freebsd-scsi@freebsd.org In-Reply-To: from Robert Schien at "Jul 9, 96 06:45:46 pm" X-Mailer: ELM [version 2.4ME+ PL11 (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 > I'm looking for a 2 GB SCSI hard drive which is fast, reliable and > most important, quiet ("normal" SCSI, no wide or ulta-wide ones). Finding high performance drives that are quiet is a very hard. It's kinda like trying to make a top fuel funny car quiet... but I have just brought these drives in and they are reasonably quiet. They are 5400 RPM drives, which helps, and the casing is die cast aluminium top and bottom which also helps to keep them quiet. Reliablility in the field is unclear at this time as this is a brand new drive model, but Micropolis has a rather good track record. > Which model do you recommend? XX. TMG MPL34763 Micropolis MC4421 2G, 3.5"x1" 5400RPM 8.8mS, 512k $ 549.00 Also known as a Micropolis Aries-II drive, the part number is TZ0030-02-5, watch out, there is another part number for the MC4421 which has a 9.6mS seek time. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-scsi Tue Jul 9 11:41:30 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA27330 for freebsd-scsi-outgoing; Tue, 9 Jul 1996 11:41:30 -0700 (PDT) Received: from boom.vars.com (boom.BSDI.COM [205.230.226.129]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA27322 for ; Tue, 9 Jul 1996 11:41:28 -0700 (PDT) Received: from boom.vars.com (localhost.vars.com [127.0.0.1]) by boom.vars.com (8.7.3/8.6.5) with ESMTP id MAA12079; Tue, 9 Jul 1996 12:40:51 -0600 (MDT) Message-Id: <199607091840.MAA12079@boom.vars.com> To: "Rodney W. Grimes" cc: robsch@robkaos.ruhr.de (Robert Schien), freebsd-scsi@freebsd.org Subject: Re: Low noise 2 GB hard drive In-reply-to: Your message of "Tue, 09 Jul 1996 10:45:48 PDT." <199607091745.KAA07383@GndRsh.aac.dev.com> Date: Tue, 09 Jul 1996 12:40:51 -0600 From: Eric Varsanyi Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> I'm looking for a 2 GB SCSI hard drive which is fast, reliable and >> most important, quiet ("normal" SCSI, no wide or ulta-wide ones). > >Finding high performance drives that are quiet is a very hard. It's kinda >like trying to make a top fuel funny car quiet... but I have just brought >these drives in and they are reasonably quiet. I read (I think in EETimes a few months back) that there are "sleeves" that you can put 3.5" drives in to quiet them down (it was in an article about obstacles to having a set-top PC) - these sleeves are designed to conduct heat while keeping the drive quiet. -Eric From owner-freebsd-scsi Tue Jul 9 11:47:14 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA27627 for freebsd-scsi-outgoing; Tue, 9 Jul 1996 11:47:14 -0700 (PDT) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA27617 for ; Tue, 9 Jul 1996 11:47:08 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id LAA07618; Tue, 9 Jul 1996 11:46:49 -0700 From: "Rodney W. Grimes" Message-Id: <199607091846.LAA07618@GndRsh.aac.dev.com> Subject: Re: Low noise 2 GB hard drive To: ewv@boom.bsdi.com (Eric Varsanyi) Date: Tue, 9 Jul 1996 11:46:49 -0700 (PDT) Cc: robsch@robkaos.ruhr.de, freebsd-scsi@freebsd.org In-Reply-To: <199607091840.MAA12079@boom.vars.com> from Eric Varsanyi at "Jul 9, 96 12:40:51 pm" X-Mailer: ELM [version 2.4ME+ PL11 (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 > > >> I'm looking for a 2 GB SCSI hard drive which is fast, reliable and > >> most important, quiet ("normal" SCSI, no wide or ulta-wide ones). > > > >Finding high performance drives that are quiet is a very hard. It's kinda > >like trying to make a top fuel funny car quiet... but I have just brought > >these drives in and they are reasonably quiet. > > I read (I think in EETimes a few months back) that there are "sleeves" that > you can put 3.5" drives in to quiet them down (it was in an article about > obstacles to having a set-top PC) - these sleeves are designed to conduct > heat while keeping the drive quiet. Don't try to put a 7200 RPM class drive in one of those ``sleeves'', it'll cook it in very short order. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD From owner-freebsd-scsi Tue Jul 9 12:22:15 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA29496 for freebsd-scsi-outgoing; Tue, 9 Jul 1996 12:22:15 -0700 (PDT) Received: from Sisyphos (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA29483; Tue, 9 Jul 1996 12:22:00 -0700 (PDT) Received: by Sisyphos id AA15665 (5.67b/IDA-1.5); Tue, 9 Jul 1996 21:20:25 +0200 Message-Id: <199607091920.AA15665@Sisyphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Tue, 9 Jul 1996 21:20:25 +0200 In-Reply-To: Michael Hancock "Adding Jaz drive with sysinstall" (Jul 9, 11:51) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: Michael Hancock Subject: Re: Adding Jaz drive with sysinstall Cc: current@freebsd.org, scsi@freebsd.org Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Jul 9, 11:51, Michael Hancock wrote: } Subject: Adding Jaz drive with sysinstall } dmesg tells me that the Jaz reports that its a removable SCSI 2. Is this } the source of the ILLEGAL REQUEST message? No, the JAZ seems not to like some field in a request sent to it and rejects the command. The command that caused this appears to have been the geometry query, which leads to the "fictious geometry" being used. A possible cause of this might be that there was no media loaded into the drive, I suppose ... } FreeBSD 2.2-CURRENT #11: Wed Jul 3 12:45:46 JST 1996 } } (ncr0:5:0): "iomega jaz 1GB G.60" type 0 removable SCSI 2 } sd2(ncr0:5:0): Direct-Access } sd2(ncr0:5:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. } sd2(ncr0:5:0): ILLEGAL REQUEST asc:24,0 Invalid field in CDB } sd2 could not mode sense (4). Using ficticious geometry } 1021MB (2091050 512 byte sectors) Regards, STefan From owner-freebsd-scsi Tue Jul 9 13:50:25 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA06215 for freebsd-scsi-outgoing; Tue, 9 Jul 1996 13:50:25 -0700 (PDT) Received: from uucp.tip.net ([194.16.0.15]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA06208 for ; Tue, 9 Jul 1996 13:50:18 -0700 (PDT) Received: from icon.pp.se (uucp@localhost) by uucp.tip.net (8.6.12/8.6.5) with UUCP id WAA03398 for freebsd-scsi@freebsd.org; Tue, 9 Jul 1996 22:50:31 +0200 Received: (from daniel@localhost) by icon.pp.se (8.7.5/8.7.3) id WAA00457; Tue, 9 Jul 1996 22:47:19 +0200 (MET DST) Date: Tue, 9 Jul 1996 22:47:19 +0200 (MET DST) Message-Id: <199607092047.WAA00457@icon.pp.se> From: Daniel Eriksson To: freebsd-scsi@freebsd.org In-reply-to: <199607091846.LAA07618@GndRsh.aac.dev.com> (rgrimes@gndrsh.aac.dev.com) Subject: Re: Low noise 2 GB hard drive Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Rod Grimes wrote: > Don't try to put a 7200 RPM class drive in one of those ``sleeves'', it'll > cook it in very short order. The generated heat differs immensly between models! My brand new Quantum Atlas (2GB, 7200rpm, 8.5ms, 1MB cache) for example has no problems at all with heat even without a fan (and with a fan it is just a couple of degrees above room temperature). My old Micrpolis 4110 (1GB, 5400rpm, 8.5ms) on the other hand generates loads of heat and I wouldn't dare running it without a fan. Both drives are lightly loaded and I have no idea what would happen if the drives got hit by a full newsspool, but then again, we are talking about desktop "set-top" computers, and they rarely serve as newsservers, do they? -- Daniel Eriksson, daniel@icon.pp.se, eradaer@gaer16.ericsson.se From owner-freebsd-scsi Tue Jul 9 15:00:01 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA11355 for freebsd-scsi-outgoing; Tue, 9 Jul 1996 15:00:01 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA11334 for ; Tue, 9 Jul 1996 14:59:51 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id XAA17722; Tue, 9 Jul 1996 23:59:07 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id XAA20624; Tue, 9 Jul 1996 23:59:06 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id WAA06178; Tue, 9 Jul 1996 22:29:15 +0200 (MET DST) From: J Wunsch Message-Id: <199607092029.WAA06178@uriah.heep.sax.de> Subject: Re: Low noise 2 GB hard drive To: freebsd-scsi@freebsd.org Date: Tue, 9 Jul 1996 22:29:14 +0200 (MET DST) Cc: robsch@robkaos.ruhr.de (Robert Schien) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from Robert Schien at "Jul 9, 96 06:45:46 pm" 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 X-Mailer: ELM [version 2.4ME+ PL17 (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 As Robert Schien wrote: > I'm looking for a 2 GB SCSI hard drive which is fast, reliable and > most important, quiet ("normal" SCSI, no wide or ulta-wide ones). > > Which model do you recommend? I'm happy with my: uriah /kernel: (ncr0:1:0): "SEAGATE ST32430N 0510" type 0 fixed SCSI 2 uriah /kernel: sd1(ncr0:1:0): Direct-Access uriah /kernel: sd1(ncr0:1:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. uriah /kernel: 2049MB (4197405 512 byte sectors) This is one of the 1" height Hawk series. Alas, i think the Hawk is no longer produced. No idea whether the new (even flatter) Medalist is as reliable as the Hawks used to be. One thing i love with the Hawks is that they remain really cool (which was important for the situation in my machine's cabinet). There's also an ST3655N in that box, but you can hardly even hear the Hawk among the old disk and the noise of the power supply fan. I know that there's much religion when it comes to the choice of a disk, and in particular when it comes to Seacrate. However, Robert has been asking for experiences, and that's just mine. Please, redirect any discussion about ``My Quantum is longer than your Seacrate'' to /dev/null. -- 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 Tue Jul 9 15:06:33 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA12106 for freebsd-scsi-outgoing; Tue, 9 Jul 1996 15:06:33 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA12100; Tue, 9 Jul 1996 15:06:29 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id IAA06894; Wed, 10 Jul 1996 08:04:01 +1000 Date: Wed, 10 Jul 1996 08:04:01 +1000 From: Bruce Evans Message-Id: <199607092204.IAA06894@godzilla.zeta.org.au> To: michaelh@cet.co.jp, se@ZPR.Uni-Koeln.DE Subject: Re: Adding Jaz drive with sysinstall Cc: current@freebsd.org, scsi@freebsd.org Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >} dmesg tells me that the Jaz reports that its a removable SCSI 2. Is this >} the source of the ILLEGAL REQUEST message? >No, the JAZ seems not to like some field in a request >sent to it and rejects the command. The command that >caused this appears to have been the geometry query, >which leads to the "fictious geometry" being used. >A possible cause of this might be that there was no >media loaded into the drive, I suppose ... >} ... >} sd2(ncr0:5:0): ILLEGAL REQUEST asc:24,0 Invalid field in CDB >} sd2 could not mode sense (4). Using ficticious geometry Iomega zip drives give the same message when media is present. I guess the problem is a low quality implementation of the SCSI spec. Bruce From owner-freebsd-scsi Tue Jul 9 15:16:25 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA12722 for freebsd-scsi-outgoing; Tue, 9 Jul 1996 15:16:25 -0700 (PDT) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA12596 for ; Tue, 9 Jul 1996 15:14:58 -0700 (PDT) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id RAA24844; Tue, 9 Jul 1996 17:13:46 -0500 From: Joe Greco Message-Id: <199607092213.RAA24844@brasil.moneng.mei.com> Subject: Re: Low noise 2 GB hard drive To: daniel@icon.pp.se (Daniel Eriksson) Date: Tue, 9 Jul 1996 17:13:45 -0500 (CDT) Cc: freebsd-scsi@freebsd.org In-Reply-To: <199607092047.WAA00457@icon.pp.se> from "Daniel Eriksson" at Jul 9, 96 10:47:19 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > just a couple of degrees above room temperature). My old Micrpolis > 4110 (1GB, 5400rpm, 8.5ms) on the other hand generates loads of > heat and I wouldn't dare running it without a fan. > > Both drives are lightly loaded and I have no idea what would happen > if the drives got hit by a full newsspool, but then again, we are > talking about desktop "set-top" computers, and they rarely serve > as newsservers, do they? I've a 4110 running on spool.mu.edu's news spool (Solaris 2.5.1, SPARC 10/30) It's a really nice drive and has had no problems - excellent performance. I'm not a Micropolis fan, but they do make some good drives (and some bad ones too). ... JG From owner-freebsd-scsi Tue Jul 9 15:23:04 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA13191 for freebsd-scsi-outgoing; Tue, 9 Jul 1996 15:23:04 -0700 (PDT) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA13186 for ; Tue, 9 Jul 1996 15:23:00 -0700 (PDT) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id RAA24890; Tue, 9 Jul 1996 17:21:50 -0500 From: Joe Greco Message-Id: <199607092221.RAA24890@brasil.moneng.mei.com> Subject: Re: Low noise 2 GB hard drive To: joerg_wunsch@uriah.heep.sax.de Date: Tue, 9 Jul 1996 17:21:50 -0500 (CDT) Cc: freebsd-scsi@freebsd.org, robsch@robkaos.ruhr.de In-Reply-To: <199607092029.WAA06178@uriah.heep.sax.de> from "J Wunsch" at Jul 9, 96 10:29:14 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > uriah /kernel: (ncr0:1:0): "SEAGATE ST32430N 0510" type 0 fixed SCSI 2 > uriah /kernel: sd1(ncr0:1:0): Direct-Access > uriah /kernel: sd1(ncr0:1:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. > uriah /kernel: 2049MB (4197405 512 byte sectors) > > This is one of the 1" height Hawk series. Alas, i think the Hawk is > no longer produced. No idea whether the new (even flatter) Medalist > is as reliable as the Hawks used to be. One thing i love with the The Medalists are louder, slower, and noisier (at least last time I tried). All you Hawk fans out there - check out the ST31051N and the ST31055N 1G's! We built a news server out of fifteen of them and a few 4G Barra's a month or two ago and haven't seen a single case of infant death. Their only downsides over the older Hawks is that they're a shade noisier and their cache is smaller. I would not be afraid to recommend one of these to a friend. I used to recommend the older Hawk 1G's but these seem like a fine replacement. http://www.seagate.com/stor/hawk/hawk2xl.shtml ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968 From owner-freebsd-scsi Wed Jul 10 00:05:43 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA16355 for freebsd-scsi-outgoing; Wed, 10 Jul 1996 00:05:43 -0700 (PDT) Received: from tekram.com.tw (root@tekram.hinet.net [168.95.200.69]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id AAA16348 for ; Wed, 10 Jul 1996 00:05:30 -0700 (PDT) From: ching@tekram.com.tw Received: from [] ([132.147.161.120]) by tekram.com.tw (8.6.11/8.6.9) with SMTP id OAA18402 for ; Wed, 10 Jul 1996 14:05:50 +0800 Message-Id: <199607100605.OAA18402@tekram.com.tw> Comments: Authenticated sender is To: freebsd-scsi@FreeBSD.ORG Date: Wed, 10 Jul 1996 15:00:39 +0000 Subject: How to make "Installation Boot Floppy" ? Priority: urgent X-mailer: Pegasus Mail for Windows (v2.01) Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk From: C.L. Huang To: freebsd-scsi@FreeBSD.ORG Subject: How to make custom "Installation Boot Floppy" ? Date sent: Wen, 10 Jul 1996 13:50:00 +0000 Hi, We are SCSI adapter manufacture, Tekram Technology Co., Ltd. We are developing adapter driver under FreeBSD 2.1.0 for our product DC-390(T) (with AMD 53c974 scsi chip) and DC-390W/U/F(T) (with SYMBIOS 53c825A, 53c875). It is late for our driver to build in RELEASE-2.1.0. So, we have to make custom "Installation Boot Floppy" for our user. I had trying to make it by using the Makefile at /usr/src/release, but met some error. Is anyone can help me ? Any help would be very appreciate. Best Regard, C.L. Huang From owner-freebsd-scsi Wed Jul 10 00:27:51 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA17342 for freebsd-scsi-outgoing; Wed, 10 Jul 1996 00:27:51 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id AAA17131 for ; Wed, 10 Jul 1996 00:23:40 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA02450; Wed, 10 Jul 1996 09:21:47 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA26769; Wed, 10 Jul 1996 09:21:46 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id JAA09079; Wed, 10 Jul 1996 09:16:59 +0200 (MET DST) From: J Wunsch Message-Id: <199607100716.JAA09079@uriah.heep.sax.de> Subject: Re: tandberg scsi tape + FreeBSD 2.1/2.0.5 To: freebsd-scsi@freebsd.org Date: Wed, 10 Jul 1996 09:16:59 +0200 (MET DST) Cc: jbh@labyrinth.net.au (John Hartley) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199607100316.NAA25059@minotaur.labyrinth.net.au> from John Hartley at "Jul 10, 96 01:16:11 pm" 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 X-Mailer: ELM [version 2.4ME+ PL17 (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 (I'm moving this to freebsd-scsi, therefore quoting much of the original article.) As John Hartley wrote: > > Following is a copy of message posted onto *.freebsd.misc new group > re: Problem with tandberg 4100 scsi tape. > I have not had any suggestion which have provide a solution to my problem > and so am posting this bug report. > > >I have been trying to get a tandberg 4100 scsi tape > >drive running so far unsuccessfully. > >My configuration is: > >IBM 350/DX4-100 32 MB Adaptec 2940 SCSI controller, > >Fujitsu HD scsi 0 > >Matshita CD-ROM scsi 1 > >Tandberg TDC 4100 scsi 3 > > Now changed to 2 following mailed suggestion!! > > > > >The tape is recognised at boot as follows: > >(ahc0:3:0): "TANDBERG TDC 4100 J04" Type 1 removeable SCSI 2 > >st(shc0:3:0): Sequential-Access density code 0x0, 512-byte blocks > > > >all operations done on the tape drive result in the following type of message: > > > >st0(ahc0:3:0): ILLEGAL REQUEST csi:0,8,0,0 asc:24,0 Invalid field in CDB field > > replacement unit: 2 > >st0: Cannot set selected mode st0: oops not queued > > > >I have tried a number of suggestions all of which fail with the same codes: > >these include: > >mt -f /dev/st0ctl.0 density 0x11 > >mt -f /dev/st0ctl.0 blocksize 512 > > > >It has been suggested that the firmware version is the problem, however > >the unit works fine with Windows NT and DOS tar for ASPI. > > > >I have recompiled the kernel with the SCSIDEBUG option on, but all the > >scsi commands produce a simillar error: > >scsi -f /dev/rst0 -d 0x10 > >produces: > >st0(ahc0:3:0): ILLEGAL REQUEST csi ..... You need to perform this operation on the control device. This one is only intended to affect the driver itself, not the actual tape drive. j@uriah 817% ls -l /dev/*st0*ctl* crw------- 1 root wheel 14, 0x20000000 May 19 16:50 /dev/rst0.ctl crw------- 1 root operator 14, 3 May 19 16:50 /dev/st0ctl.0 crw------- 1 root operator 14, 7 May 19 16:50 /dev/st0ctl.1 crw------- 1 root operator 14, 11 May 19 16:50 /dev/st0ctl.2 crw------- 1 root operator 14, 15 May 19 16:50 /dev/st0ctl.3 Either of them is supposed to work, the first one wasn't provided by default in 2.1R. You can however created it with mknod manually (but have to use the decimal value 536870912 for the minor number). > >I have read many articles in the various archives reporting > simillar problems but no statement of the solution. Apparently, nobody with sufficient knowledge about what happens, and with sufficient time to investigate (who does also experience the problem) was among them. Remember, FreeBSD is officially unsupported in Usenet. Its only official `support' is on the mailing lists. So your problem starts to exist for many of the FreeBSD developers right now, with your first mail to one of the mailing lists. Since the error message is ``Invalid field in CDB'', i think it would be of essential interest to learn about the CDB that is sent to the drive. This one will be logged with a sufficient high debug level. Having said this, i'm using a Tandberg TDC4222 myself, and i've seen a TDC4120 working with FreeBSD 1.1.5.1 at my former employer. (Their machine hasn't been upgraded and most likely never will be.) -- 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 Wed Jul 10 01:27:39 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA21533 for freebsd-scsi-outgoing; Wed, 10 Jul 1996 01:27:39 -0700 (PDT) Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA21527; Wed, 10 Jul 1996 01:27:31 -0700 (PDT) Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1]) by soleil.uvsq.fr (8.7.5/jtpda-5.2) with ESMTP id KAA17976 ; Wed, 10 Jul 1996 10:27:28 +0200 (METDST) Received: from angrand.prism.uvsq.fr (angrand.prism.uvsq.fr [193.51.25.85]) by guillotin.prism.uvsq.fr (8.7.5/jtpda-5.2) with ESMTP id KAA00273 ; Wed, 10 Jul 1996 10:27:27 +0200 (MET DST) Received: from (son@localhost) by angrand.prism.uvsq.fr (8.7.5/jtpda-5.2) id LAA02630 ; Wed, 10 Jul 1996 11:30:07 +0200 (MET DST) Date: Wed, 10 Jul 1996 11:30:07 +0200 (MET DST) Message-Id: <199607100930.LAA02630@angrand.prism.uvsq.fr> From: Nicolas Souchu To: freebsd-fs@freebsd.org CC: freebsd-scsi@freebsd.org Subject: msdosfs and scsi Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've developed a polling driver for an scsi drive ZIP 100 drive connected to the parallel port. http://www.prism.uvsq.fr/~son/ppa3.html Here is my question/problem: When polling, the system load is horrible... then I want to insert some tsleep() in the driver. In fact, when data is not available, the process which runs into the driver is scheduled with : s = splbio(); tsleep(..., PRIBIO, "mywait", 1); splx (s); BUT: doing this leads 2 concurent processes to a deadlock. $ mount -t msdos /dev/sd0s4 /zip $ time dd if=/dev/zero of=/zip/file bs=8192 count=512 & $ ls -l /zip dd is waiting on channel "getblk", ls is waiting on channel "msdhgt". Debugging the driver shows that dd is scheduled and ls starts reading data from the disk. But then everythings stop. Should the driver be atomic until returning SUCCESSFULLY_QUEUED ? Why ? Why not ? I may get more info. if you need... nicolas -- Nicolas.Souchu@prism.uvsq.fr Laboratoire PRiSM - Versailles, FRANCE From owner-freebsd-scsi Wed Jul 10 11:54:53 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA04802 for freebsd-scsi-outgoing; Wed, 10 Jul 1996 11:54:53 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA04530 for ; Wed, 10 Jul 1996 11:51:25 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id UAA16648; Wed, 10 Jul 1996 20:51:21 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id UAA03989; Wed, 10 Jul 1996 20:51:21 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id UAA10778; Wed, 10 Jul 1996 20:32:28 +0200 (MET DST) From: J Wunsch Message-Id: <199607101832.UAA10778@uriah.heep.sax.de> Subject: Re: How to make "Installation Boot Floppy" ? To: ching@tekram.com.tw Date: Wed, 10 Jul 1996 20:32:27 +0200 (MET DST) Cc: freebsd-scsi@FreeBSD.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199607100605.OAA18402@tekram.com.tw> from "ching@tekram.com.tw" at "Jul 10, 96 03:00:39 pm" 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 X-Mailer: ELM [version 2.4ME+ PL17 (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 As ching@tekram.com.tw wrote: > SYMBIOS 53c825A, 53c875). It is late for our driver to build in > RELEASE-2.1.0. So, we have to make custom "Installation Boot Floppy" > for our user. I had trying to make it by using the Makefile at > /usr/src/release, but met some error. Is anyone can help me ? Which error? Something like make release CHROOTDIR=/usr/release RELEASETAG=RELENG_2_1_0 \ BUILDNAME=2.1-RELEASE is supposed to work. However, right as it stands now, you are required to have a full CVS tree in order to get it going. Julian Elischer started to support the creation of seperate install- ation floppies without the need to do a full release first, but i have no idea about the status of this project. (freebsd-scsi was a good list for your information about the driver support, but is certainly a poor choice for discussion of `make release'. Offhand, i don't know about a well-suited one however.) -- 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 Wed Jul 10 12:15:24 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA05943 for freebsd-scsi-outgoing; Wed, 10 Jul 1996 12:15:24 -0700 (PDT) Received: from ref.tfs.com ([206.245.251.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA05935 for ; Wed, 10 Jul 1996 12:15:22 -0700 (PDT) Received: (from julian@localhost) by ref.tfs.com (8.7.5/8.7.3) id MAA23999; Wed, 10 Jul 1996 12:13:11 -0700 (PDT) Message-Id: <199607101913.MAA23999@ref.tfs.com> Subject: Re: How to make "Installation Boot Floppy" ? To: joerg_wunsch@uriah.heep.sax.de Date: Wed, 10 Jul 1996 12:13:11 -0700 (PDT) From: "JULIAN Elischer" Cc: ching@tekram.com.tw, freebsd-scsi@FreeBSD.org In-Reply-To: <199607101832.UAA10778@uriah.heep.sax.de> from "J Wunsch" at Jul 10, 96 08:32:27 pm X-Mailer: ELM [version 2.4 PL25 ME8b] 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 > > As ching@tekram.com.tw wrote: > > > SYMBIOS 53c825A, 53c875). It is late for our driver to build in > > RELEASE-2.1.0. So, we have to make custom "Installation Boot Floppy" > > for our user. I had trying to make it by using the Makefile at > > /usr/src/release, but met some error. Is anyone can help me ? > > Which error? > > Something like > > make release CHROOTDIR=/usr/release RELEASETAG=RELENG_2_1_0 \ > BUILDNAME=2.1-RELEASE > > is supposed to work. However, right as it stands now, you are > required to have a full CVS tree in order to get it going. > > Julian Elischer started to support the creation of seperate install- > ation floppies without the need to do a full release first, but i have > no idea about the status of this project. I checked in the working code to /usr/src/etc/floppies about a month or so ago.. it should work for 2.1 as well, if 'grafted' into a 2.1 tree. not a soul has commented on it since I checked it in, and I think that even jkh and others have not tried it.. I think it's a great improvement though. You need to have done a "make world" before, so that all the .o files can exist ready for hte crunch program to use them.. julian > > (freebsd-scsi was a good list for your information about the driver > support, but is certainly a poor choice for discussion of `make > release'. Offhand, i don't know about a well-suited one however.) > > -- > 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 Wed Jul 10 14:21:20 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA15182 for freebsd-scsi-outgoing; Wed, 10 Jul 1996 14:21:20 -0700 (PDT) Received: from sag.space.lockheed.com (sag.space.lockheed.com [192.68.162.134]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA15175 for ; Wed, 10 Jul 1996 14:21:18 -0700 (PDT) Received: from localhost by sag.space.lockheed.com; (5.65v3.2/1.1.8.2/21Nov95-0423PM) id AA32563; Wed, 10 Jul 1996 14:21:26 -0700 Date: Wed, 10 Jul 1996 14:21:26 -0700 (PDT) From: "Brian N. Handy" Reply-To: "Brian N. Handy" To: freebsd-scsi@freebsd.org Subject: Mounting CD's with WORM drive? 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 Hey Folks, I've got some locals writing CD's with an HP-4020i and everything seems to work fine. I can write CD's with impunity. Question is...can I mount a written CD in the worm drive and read it? I don't seem to know how to do that. Is it as simple as mount -t cd9660 /dev/worm0 /mnt, or is something else involved? Thanks, Brian From owner-freebsd-scsi Wed Jul 10 16:52:58 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA27720 for freebsd-scsi-outgoing; Wed, 10 Jul 1996 16:52:58 -0700 (PDT) Received: from minotaur.labyrinth.net.au (minotaur.labyrinth.net.au [203.9.148.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA27682 for ; Wed, 10 Jul 1996 16:52:48 -0700 (PDT) Received: (from mail@localhost) by minotaur.labyrinth.net.au (8.7.2/8.7.2) id JAA25478 for ; Thu, 11 Jul 1996 09:52:38 +1000 (EST) Date: Thu, 11 Jul 1996 09:52:38 +1000 (EST) Message-Id: <199607102352.JAA25478@minotaur.labyrinth.net.au> X-Authentication-Warning: minotaur.labyrinth.net.au: mail set sender to using -f Received: from portal-as18.labyrinth.net.au(203.9.148.28) by minotaur.labyrinth.net.au via smap (V1.3) id sma025473; Thu Jul 11 09:52:03 1996 X-Sender: jbh@labyrinth.net.au X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: freebsd-scsi@freebsd.org From: John Hartley Subject: Re: tandberg scsi tape + FreeBSD 2.1/2.0.5 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The following logs provide extra information on the problem I am having with my tandberg 4100 scsi tape drive and freebsd 2.1. Firstly here are the boot up logs: (I have a recomiled kernel with extraneous devices removed + 2 3COM Etherlink Cards + Mouse port + options SCSCIDEBUG) Jul 10 21:24:41 qwiff /kernel: FreeBSD 2.1.0-RELEASE #0: Wed Jul 10 21:10:45 1996 Jul 10 21:24:41 qwiff /kernel: jbh@qwiff.graphica.com.au:/usr/src/sys/compile/TP_SIMPLE Jul 10 21:24:41 qwiff /kernel: CPU: i486 DX4 (486-class CPU) Jul 10 21:24:42 qwiff /kernel: Origin = "GenuineIntel" Id = 0x480 Stepping=0 Jul 10 21:24:42 qwiff /kernel: Features=0x3 Jul 10 21:24:42 qwiff /kernel: real memory = 33554432 (32768K bytes) Jul 10 21:24:42 qwiff /kernel: avail memory = 31035392 (30308K bytes) Jul 10 21:24:42 qwiff /kernel: Probing for devices on the ISA bus: Jul 10 21:24:42 qwiff /kernel: sc0 at 0x60-0x6f irq 1 on motherboard Jul 10 21:24:42 qwiff /kernel: sc0: VGA color <16 virtual consoles, flags=0x0> Jul 10 21:24:43 qwiff /kernel: sio0 at 0x3f8-0x3ff irq 4 on isa Jul 10 21:24:43 qwiff /kernel: sio0: type 16550A Jul 10 21:24:43 qwiff /kernel: sio1 at 0x2f8-0x2ff irq 3 on isa Jul 10 21:24:43 qwiff /kernel: sio1: type 16550A Jul 10 21:24:43 qwiff /kernel: lpt0 at 0x3bc-0x3c3 irq 7 on isa Jul 10 21:24:43 qwiff /kernel: lpt0: Interrupt-driven port Jul 10 21:24:43 qwiff /kernel: lp0: TCP/IP capable interface Jul 10 21:24:43 qwiff /kernel: psm0 at 0x60-0x63 irq 12 on motherboard Jul 10 21:24:43 qwiff /kernel: fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa Jul 10 21:24:44 qwiff /kernel: fdc0: NEC 72065B Jul 10 21:24:44 qwiff /kernel: fd0: 1.44MB 3.5in Jul 10 21:24:44 qwiff /kernel: 2 3C5x9 board(s) on ISA found at 0x310 0x300 Jul 10 21:24:44 qwiff /kernel: ep0 at 0x300-0x30f irq 10 on isa Jul 10 21:24:44 qwiff /kernel: ep0: aui/bnc[*BNC*] address 00:60:8c:60:ac:0e irq 10 Jul 10 21:24:44 qwiff /kernel: ep1 at 0x310-0x31f irq 11 on isa Jul 10 21:24:44 qwiff /kernel: ep1: aui/bnc[*BNC*] address 00:20:af:0f:6c:0a irq 11 Jul 10 21:24:44 qwiff /kernel: npx0 on motherboard Jul 10 21:24:44 qwiff /kernel: npx0: INT 16 interface Jul 10 21:24:45 qwiff /kernel: Probing for devices on the PCI bus: Jul 10 21:24:45 qwiff /kernel: ahc0 rev 0 int a irq 5 on pci0:12 Jul 10 21:24:45 qwiff /kernel: ahc0: aic7870 Ultra Single Channel, SCSI Id=7, aic7870, 255 SCBs Jul 10 21:24:45 qwiff /kernel: ahc0 waiting for scsi devices to settle Jul 10 21:24:45 qwiff /kernel: (ahc0:0:0): "FUJITSU M1606S-512 6234" type 0 fixed SCSI 2 Jul 10 21:24:45 qwiff /kernel: sd0(ahc0:0:0): Direct-Access 1041MB (2131992 512 byte sectors) Jul 10 21:24:45 qwiff /kernel: (ahc0:1:0): "MATSHITA CD-ROM CR-5XX 1.0b" type 5 removable SCSI 1 Jul 10 21:24:46 qwiff /kernel: cd0(ahc0:1:0): CD-ROM cd present.[326402 x 2048 byte records] Jul 10 21:24:46 qwiff /kernel: (ahc0:2:0): "TANDBERG TDC 4100 J04:" type 1 removable SCSI 2 Jul 10 21:24:46 qwiff /kernel: st0(ahc0:2:0): Sequential-Access density code 0x0, 512-byte blocks, write-enabled Jul 10 21:24:46 qwiff /kernel: pci0:16: OPTI, device=0xc822, class=bridge (host) [no driver assigned] Jul 10 21:24:41 qwiff named[64]: starting. named LOCAL-951116.090057 Thu Nov 16 09:00:57 1995 jkh@westhill.cdrom.com:/usr/src/usr.sbin/named Jul 10 21:24:42 qwiff named[65]: Ready to answer queries. Jul 10 21:24:45 qwiff lpd[87]: restarted Here is the log from performing a "tar tvf /dev/rst0", after first turning on SCSI debugging: scsi -f /dev/st0ctl.0 -d 0xff tar tvf /dev/rst0 Jul 10 21:41:47 qwiff /kernel: st0(ahc0:2:0): stclose: Closing device Jul 10 21:41:58 qwiff /kernel: st0(ahc0:2:0): scsi_cmd Jul 10 21:41:58 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 10 21:41:58 qwiff /kernel: st0(ahc0:2:0): returning Jul 10 21:41:58 qwiff /kernel: xs(0xf0859980): flg(0x60)sc_link(0xf0859780)retr(0x2)timo(0x186a0)cmd(0xf08599d8)len(0x6)dat a(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 10 21:41:59 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 10 21:41:59 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 10 21:41:59 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 10 21:41:59 qwiff /kernel: command: 1b,0,0,0,1,0-[0 bytes] Jul 10 21:41:59 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 10 21:41:59 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 10 21:41:59 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 10 21:41:59 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 10 21:41:59 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): scsi_cmd Jul 10 21:41:59 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 10 21:41:59 qwiff /kernel: st0(ahc0:2:0): returning Jul 10 21:41:59 qwiff /kernel: xs(0xf0aaff80): flg(0x60)sc_link(0xf0859780)retr(0x2)timo(0x186a0)cmd(0xf0aaffd8)len(0x6)dat a(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 10 21:41:59 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 10 21:41:59 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 10 21:41:59 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 10 21:41:59 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 10 21:41:59 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 10 21:42:00 qwiff /kernel: st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 10 21:42:00 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 10 21:42:00 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 10 21:42:00 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 10 21:42:00 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 10 21:42:00 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): scsi_cmd Jul 10 21:42:00 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 10 21:42:00 qwiff /kernel: st0(ahc0:2:0): returning Jul 10 21:42:00 qwiff /kernel: xs(0xf0aaff80): flg(0x420)sc_link(0xf0859780)retr(0x4)timo(0x1388)cmd(0xf0aaffd8)len(0x6)dat a(0xf2772000)len(0x6)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 5,0,0,0,0,0-[6 bytes] Jul 10 21:42:00 qwiff /kernel: ------------------------------ Jul 10 21:42:00 qwiff /kernel: 000: 00 00 00 00 00 00 Jul 10 21:42:00 qwiff /kernel: ------------------------------ Jul 10 21:42:00 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 10 21:42:00 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 10 21:42:00 qwiff /kernel: st0(ahc0:2:0): 6 @0xf2772000:- 0x4b000(0x6) Jul 10 21:42:00 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 10 21:42:00 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 10 21:42:00 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 10 21:42:01 qwiff /kernel: st0(ahc0:2:0): command: 5,0,0,0,0,0-[6 bytes] Jul 10 21:42:01 qwiff /kernel: ------------------------------ Jul 10 21:42:01 qwiff /kernel: 000: 00 ff ff ff 00 01 Jul 10 21:42:01 qwiff /kernel: ------------------------------ Jul 10 21:42:01 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 10 21:42:01 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 10 21:42:01 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 10 21:42:01 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 10 21:42:01 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): (1 <= blksiz <= 16777215) Jul 10 21:42:01 qwiff /kernel: st0(ahc0:2:0): scsi_cmd Jul 10 21:42:01 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 10 21:42:01 qwiff /kernel: st0(ahc0:2:0): returning Jul 10 21:42:01 qwiff /kernel: xs(0xf0aaff80): flg(0x420)sc_link(0xf0859780)retr(0x4)timo(0x1388)cmd(0xf0aaffd8)len(0x6)dat a(0xf2772000)len(0xc)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 1a,0,0,0,c,0-[12 bytes] Jul 10 21:42:01 qwiff /kernel: ------------------------------ Jul 10 21:42:01 qwiff /kernel: 000: 00 00 00 00 00 00 00 00 00 00 00 00 Jul 10 21:42:01 qwiff /kernel: ------------------------------ Jul 10 21:42:01 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 10 21:42:01 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 10 21:42:02 qwiff /kernel: st0(ahc0:2:0): 12 @0xf2772000:- 0x4b000(0xc) Jul 10 21:42:02 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 10 21:42:02 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 10 21:42:02 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 10 21:42:02 qwiff /kernel: st0(ahc0:2:0): command: 1a,0,0,0,c,0-[12 bytes] Jul 10 21:42:02 qwiff /kernel: ------------------------------ Jul 10 21:42:02 qwiff /kernel: 000: 2f 25 10 08 00 00 00 00 00 00 02 00 Jul 10 21:42:02 qwiff /kernel: ------------------------------ Jul 10 21:42:02 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 10 21:42:02 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 10 21:42:02 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 10 21:42:02 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 10 21:42:02 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): density code 0x0, 512-byte blocks, write-enabled, st0(ahc0:2:0): buffered Jul 10 21:42:02 qwiff /kernel: st0(ahc0:2:0): starting block mode decision Jul 10 21:42:02 qwiff /kernel: st0(ahc0:2:0): Give up and default to variable mode Jul 10 21:42:03 qwiff /kernel: st0(ahc0:2:0): scsi_cmd Jul 10 21:42:03 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 10 21:42:03 qwiff /kernel: st0(ahc0:2:0): returning Jul 10 21:42:03 qwiff /kernel: xs(0xf0859980): flg(0x820)sc_link(0xf0859780)retr(0x4)timo(0x1388)cmd(0xf08599d8)len(0x6)dat a(0xf2772000)len(0xc)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 15,0,0,0,c,0-[12 bytes] Jul 10 21:42:03 qwiff /kernel: ------------------------------ Jul 10 21:42:03 qwiff /kernel: 000: 00 00 10 08 00 00 00 00 00 00 00 00 Jul 10 21:42:03 qwiff /kernel: ------------------------------ Jul 10 21:42:03 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 10 21:42:03 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0ab0000) Jul 10 21:42:03 qwiff /kernel: st0(ahc0:2:0): 12 @0xf2772000:- 0x4b000(0xc) Jul 10 21:42:03 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 10 21:42:03 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 10 21:42:03 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 10 21:42:03 qwiff /kernel: st0(ahc0:2:0): command: 15,0,0,0,c,0-[12 bytes] Jul 10 21:42:03 qwiff /kernel: ------------------------------ Jul 10 21:42:04 qwiff /kernel: 000: 00 00 10 08 00 00 00 00 00 00 00 00 Jul 10 21:42:04 qwiff /kernel: ------------------------------ Jul 10 21:42:04 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 10 21:42:04 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x1 Jul 10 21:42:04 qwiff /kernel: code70 valid0 seg0 key5 ili0 eom0 fmark0 Jul 10 21:42:04 qwiff /kernel: info: 0 0 0 0 followed by 10 extra bytes Jul 10 21:42:04 qwiff /kernel: extra: 0 8 0 0 24 0 2 0 0 0 Jul 10 21:42:04 qwiff /kernel: st0(ahc0:2:0): calling private err_handler() Jul 10 21:42:04 qwiff /kernel: st0(ahc0:2:0): private err_handler() returned -1 Jul 10 21:42:04 qwiff /kernel: st0(ahc0:2:0): ILLEGAL REQUEST csi:0,8,0,0 asc:24,0 Invalid field in CDB field replaceable unit: 2 Jul 10 21:42:04 qwiff /kernel: st0(ahc0:2:0): scsi_interpret_sense (no bp) returned 22 Jul 10 21:42:04 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 10 21:42:04 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 10 21:42:04 qwiff /kernel: st0(ahc0:2:0): ststart st0: Cannot set selected modest0(ahc0:2:0): Open complete Jul 10 21:42:05 qwiff /kernel: st0(ahc0:2:0): stopen: dev=0xe00 (unit 0) result 0 Jul 10 21:42:05 qwiff /kernel: st0(ahc0:2:0): Jul 10 21:42:05 qwiff /kernel: ststrategy st0(ahc0:2:0): 10240 bytes @ blk0 Jul 10 21:42:05 qwiff /kernel: st0(ahc0:2:0): ststart st0: oops not queued Jul 10 21:42:05 qwiff /kernel: st0(ahc0:2:0): stclose: Closing device Finally here is the output from an mt status request: mt -f /dev/rst0 status Present Mode: Density = ECMA TC17 Blocksize variable ---------available modes--------- Mode 0: Density = 0x00 Blocksize variable Mode 1: Density = 0x00 Blocksize variable Mode 2: Density = 0x00 Blocksize variable Mode 3: Density = 0x00 Blocksize variable Finally thanks for investigating this problem. If you wish me to perform further testing please let me know. Regards. John Hartley jbh@labyrinth.net.au Graphica Software Pty. Ltd. From owner-freebsd-scsi Thu Jul 11 00:55:52 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA23634 for freebsd-scsi-outgoing; Thu, 11 Jul 1996 00:55:52 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id AAA23610 for ; Thu, 11 Jul 1996 00:55:19 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA09429; Thu, 11 Jul 1996 09:54:03 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA11951; Thu, 11 Jul 1996 09:53:57 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id JAA14511; Thu, 11 Jul 1996 09:49:26 +0200 (MET DST) From: J Wunsch Message-Id: <199607110749.JAA14511@uriah.heep.sax.de> Subject: Re: Mounting CD's with WORM drive? To: freebsd-scsi@freebsd.org Date: Thu, 11 Jul 1996 09:49:26 +0200 (MET DST) Cc: handy@sag.space.lockheed.com Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "Brian N. Handy" at "Jul 10, 96 02:21:26 pm" 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 X-Mailer: ELM [version 2.4ME+ PL17 (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 As Brian N. Handy wrote: > I've got some locals writing CD's with an HP-4020i and everything seems to > work fine. I can write CD's with impunity. Question is...can I mount a > written CD in the worm drive and read it? I don't seem to know how to do > that. Is it as simple as mount -t cd9660 /dev/worm0 /mnt, or is something > else involved? It's impossible right now. We don't mind you coming up with a good idea on how to hook the `cd' driver into the `worm' driver. ;-) -- 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 Thu Jul 11 02:14:52 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA28203 for freebsd-scsi-outgoing; Thu, 11 Jul 1996 02:14:52 -0700 (PDT) Received: from viking.ucsalf.ac.uk (viking.ucsalf.ac.uk [192.195.1.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA28177 for ; Thu, 11 Jul 1996 02:14:43 -0700 (PDT) Received: by viking.ucsalf.ac.uk (Smail3.1.29.1 #4) id m0ueHpV-00036uC; Thu, 11 Jul 96 10:14 BST Message-Id: From: mark@plato.ucsalf.ac.uk (Mark Powell) Subject: Does Adaptec 7880 Ultra support simultaneous wide and narrow transfers? To: freebsd-scsi@freebsd.org Date: 11 Jul 1996 10:14:32 +0100 X-Gated-To-News-By: news@ucsalf.ac.uk Xref: viking.ucsalf.ac.uk comp.periphs.scsi:25225 list.freebsd.scsi:362 list.freebsd.questions:6987 comp.unix.bsd.freebsd.misc:22289 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I have a motherboard with a built in 7880 Ultra with a narrow and a wide connector surface mounted. I have a Conner CFP4207S on the narrow channel with TERM/PWR enabled and a Conner CFP4207W on the wide channel with TERM/PWR enabled. I wanted to move my FreeBSD-2.1-stable filesystem from the narrow disk to the wide. I assumed that I could simply copy all the data over with (narrow on sd0, wide on sd1; with 512k on board data buffer): $ dd if=/dev/sd0c of=/dev/sd1c bs=512k However, this only yields data transfer rates in the 200K/s range. I've tried both larger and smaller buffer sizes with no apparent increase. I'm beginning to wonder if the 7870 chipset is performing these transfers simultaneously. I would expect such a command to push both drives at full speed with the drive access lights on solidly. However, the drive lights are alternating off/no for around 1 sec. periods. Am I expecting the wrong thing here? If I turn on WIDE negotiation for the W drive, the kernel enables 16bit transfers: ahc0 rev 0 int a irq 11 on pci0:18 mapreg[10] type=1 addr=00006000 size=0100. mapreg[14] type=0 addr=f2000000 size=1000. ahc0: BurstLen = 8DWDs, Latency Timer = 32PCLKS ahc0: Reading SEEPROM...done. ahc0: aic7880 Wide Channel, SCSI Id=7, 16 SCBs Reseting Channel A ahc0: Downloading Sequencer Program...Done ahc0: Probing channel A ahc0: target 0 synchronous at 10.0MHz, offset = 0xf (ahc0:0:0): "CONNER CFP4207S 4.28GB 1524" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 4096MB (8388608 512 byte sectors) sd0(ahc0:0:0): with 3999 cyls, 20 heads, and an average 104 sectors/ track ahc0: target 1 using 16Bit transfers ahc0: target 1 synchronous at 10.0MHz, offset = 0x8 (ahc0:1:0): "CONNER CFP4207W 4.28GB 1524" type 0 fixed SCSI 2 sd1(ahc0:1:0): Direct-Access 4096MB (8388608 512 byte sectors) sd1(ahc0:1:0): with 3999 cyls, 20 heads, and an average 104 sectors/ track ahc0: target 2 synchronous at 10.0MHz, offset = 0x8 (ahc0:2:0): "HP C1533A 9503" type 1 removable SCSI 2 st0(ahc0:2:0): Sequential-Access density code 0x24, variable blocks, write-enabled ahc0:A:4: refuses WIDE negotiation. Using 8bit transfers ahc0: target 4 synchronous at 4.4MHz, offset = 0xf (ahc0:4:0): "TOSHIBA CD-ROM XM-3701TA 0236" type 5 removable SCSI 2 cd0(ahc0:4:0): CD-ROM cd0(ahc0:4:0): NOT READY asc:4,1 cd0(ahc0:4:0): Logical unit is in process of becoming ready can't get the size However, the same command causes the following SCSI errors on the console: sd0(ahc0:0:0): timed out in dataout phase, SCSISIGI == 0x48 ahc0: Issued Channel A Bus Reset #2. 2 SCBs aborted sd0(ahc0:0:0): UNIT ATTENTION asc:29,0 sd0(ahc0:0:0): Power on, reset, or bus device reset occurred field replaceable unit: 14 This effectively hangs the machine, requiring a reset. Whats wrong here? -- Mark Powell - Senior Network Technician - Room: C806 Computer Services Unit, University College Salford, Salford, Manchester, UK. Tel: +44 161 745 3376 Fax: +44 161 736 3596 Email: mark@ucsalf.ac.uk finger mark@ucsalf.ac.uk (for PGP key) Home Page From owner-freebsd-scsi Thu Jul 11 09:27:46 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA08563 for freebsd-scsi-outgoing; Thu, 11 Jul 1996 09:27:46 -0700 (PDT) Received: from freefall.freebsd.org (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA08545; Thu, 11 Jul 1996 09:27:42 -0700 (PDT) Message-Id: <199607111627.JAA08545@freefall.freebsd.org> To: mark@plato.ucsalf.ac.uk (Mark Powell) cc: freebsd-scsi@freebsd.org Subject: Re: Does Adaptec 7880 Ultra support simultaneous wide and narrow transfers? In-reply-to: Your message of "11 Jul 1996 10:14:32 BST." Date: Thu, 11 Jul 1996 09:27:42 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >$ dd if=/dev/sd0c of=/dev/sd1c bs=512k dd is a linear program. It will read all 512k from the source then write all 512k to the destination then loop. You should ensure that 512k divides evenly into the total capacity of the drive too. You will probably see better performance if you use an 8 or 16k buffer. >If I turn on WIDE negotiation for the W drive, the kernel enables 16bit transf >ers: ... >However, the same command causes the following SCSI errors on the console: > >sd0(ahc0:0:0): timed out in dataout phase, SCSISIGI == 0x48 >ahc0: Issued Channel A Bus Reset #2. 2 SCBs aborted >sd0(ahc0:0:0): UNIT ATTENTION asc:29,0 >sd0(ahc0:0:0): Power on, reset, or bus device reset occurred field >replaceable unit: 14 When was the last time you updated your stable? This sounds like a bug I fixed on June 8th. >-- >Mark Powell - Senior Network Technician - Room: C806 >Computer Services Unit, University College Salford, Salford, Manchester, UK. >Tel: +44 161 745 3376 Fax: +44 161 736 3596 >Email: mark@ucsalf.ac.uk finger mark@ucsalf.ac.uk (for PGP key) >Home Page -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Thu Jul 11 10:47:01 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA22021 for freebsd-scsi-outgoing; Thu, 11 Jul 1996 10:47:01 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA22015 for ; Thu, 11 Jul 1996 10:46:58 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id DAA06242; Fri, 12 Jul 1996 03:39:31 +1000 Date: Fri, 12 Jul 1996 03:39:31 +1000 From: Bruce Evans Message-Id: <199607111739.DAA06242@godzilla.zeta.org.au> To: freebsd-scsi@freebsd.org, mark@plato.ucsalf.ac.uk Subject: Re: Does Adaptec 7880 Ultra support simultaneous wide and narrow transfers? Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >$ dd if=/dev/sd0c of=/dev/sd1c bs=512k >However, this only yields data transfer rates in the 200K/s range. I've tried both >larger and smaller buffer sizes with no apparent increase. I'm beginning to wonder This gives an effective buffer size of 2K for writes. This is far too small for good performance. >Am I expecting the wrong thing here? Yes, using the buffered device is wrong. It forces the kernel to allocate kernel memory for buffer(s). This wastes a lot of memory and forces the kernel to split up the i/o. The kernel uses a buffer size of 2K. This is too small for yesterday's and today's SCSI drives, at least if the drive or driver doesn't support command queueing. More seriously, using the buffered device gives poor error handling. Write errors (if any) occur asynchronously, so they can't be reported by the application. They just get logged. Bruce From owner-freebsd-scsi Thu Jul 11 14:24:11 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA06220 for freebsd-scsi-outgoing; Thu, 11 Jul 1996 14:24:11 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA06074 for ; Thu, 11 Jul 1996 14:23:29 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id XAA28578; Thu, 11 Jul 1996 23:22:27 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id XAA20244; Thu, 11 Jul 1996 23:22:26 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id XAA16265; Thu, 11 Jul 1996 23:19:21 +0200 (MET DST) From: J Wunsch Message-Id: <199607112119.XAA16265@uriah.heep.sax.de> Subject: Re: tandberg scsi tape + FreeBSD 2.1/2.0.5 To: freebsd-scsi@freebsd.org Date: Thu, 11 Jul 1996 23:19:21 +0200 (MET DST) Cc: jbh@labyrinth.net.au (John Hartley) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199607102352.JAA25478@minotaur.labyrinth.net.au> from John Hartley at "Jul 11, 96 09:52:38 am" 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 X-Mailer: ELM [version 2.4ME+ PL17 (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 As John Hartley wrote: > Jul 10 21:42:02 qwiff /kernel: st0(ahc0:2:0): command: 1a,0,0,0,c,0-[12 bytes] > Jul 10 21:42:02 qwiff /kernel: ------------------------------ > Jul 10 21:42:02 qwiff /kernel: 000: 2f 25 10 08 00 00 00 00 00 00 02 00 > Jul 10 21:42:02 qwiff /kernel: ------------------------------ > Jul 10 21:42:02 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): density > code 0x0, 512-byte blocks, write-enabled, st0(ahc0:2:0): buffered > Present Mode: Density = ECMA TC17 Blocksize variable > ---------available modes--------- > Mode 0: Density = 0x00 Blocksize variable > Mode 1: Density = 0x00 Blocksize variable > Mode 2: Density = 0x00 Blocksize variable > Mode 3: Density = 0x00 Blocksize variable This looks self-contradicionary. The kernel message claims density code 0, while the mt status output claims density code 0x15. The kernel message says 512-byte blocks... What's the actual medium type in the drive while you captured the above? (Just curious.) > Jul 10 21:42:03 qwiff /kernel: st0(ahc0:2:0): command: 15,0,0,0,c,0-[12 bytes] > Jul 10 21:42:03 qwiff /kernel: ------------------------------ > Jul 10 21:42:04 qwiff /kernel: 000: 00 00 10 08 00 00 00 00 00 00 00 00 > Jul 10 21:42:04 qwiff /kernel: ------------------------------ > Jul 10 21:42:04 qwiff /kernel: code70 valid0 seg0 key5 ili0 eom0 fmark0 > Jul 10 21:42:04 qwiff /kernel: info: 0 0 0 0 followed by 10 extra bytes > Jul 10 21:42:04 qwiff /kernel: extra: 0 8 0 0 24 0 2 0 0 0 > Jul 10 21:42:04 qwiff /kernel: st0(ahc0:2:0): ILLEGAL REQUEST csi:0,8,0,0 > asc:24,0 Invalid field in CDB field replaceable unit: 2 I cannot find anything about the meaning of the CSI for sequential- access devices in the standard, so the 0,8,0,0 seems unintelligible to me. The above SCSI command looks reasonable if the cartridge in question is QIC-525 or higher. Basically, it requests the drive to use variable blocksize. This is IMHO invalid for QIC-150. So if your cartridge is QIC-150, does the following help you in any way? mt -f /dev/st0ctl.1 blocksize 512 mt -f /dev/st0ctl.1 density 0x10 tar tvf /dev/rst0.1 I *think* we need the same quirk record for the Tandberg 4100 that we're using for the 42xx series. Basically, it forces the drive to do one IO operation on the cartridge before retrieving the density and blocksize information. After this first IO operation, the returned data are valid, and can be used in subsequent IO. -- 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 Thu Jul 11 15:43:40 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA11324 for freebsd-scsi-outgoing; Thu, 11 Jul 1996 15:43:40 -0700 (PDT) Received: from Sisyphos (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA11319 for ; Thu, 11 Jul 1996 15:43:32 -0700 (PDT) Received: from x14.mi.uni-koeln.de (annexr2-45.slip.Uni-Koeln.DE) by Sisyphos with SMTP id AA23002 (5.67b/IDA-1.5 for ); Fri, 12 Jul 1996 00:43:25 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.7.5/8.6.9) id AAA02063; Fri, 12 Jul 1996 00:42:30 +0200 (MET DST) Message-Id: <199607112242.AAA02063@x14.mi.uni-koeln.de> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Fri, 12 Jul 1996 00:42:29 +0000 In-Reply-To: ching@tekram.com.tw "How to make "Installation Boot Floppy" ?" (Jul 10, 15:00) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: ching@tekram.com.tw Subject: Re: How to make "Installation Boot Floppy" ? Cc: freebsd-scsi@freebsd.org Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Jul 10, 15:00, ching@tekram.com.tw wrote: } Subject: How to make "Installation Boot Floppy" ? } Hi, } } We are SCSI adapter manufacture, Tekram Technology Co., Ltd. We are } developing adapter driver under FreeBSD 2.1.0 for our product } DC-390(T) (with AMD 53c974 scsi chip) and DC-390W/U/F(T) (with } SYMBIOS 53c825A, 53c875). It is late for our driver to build in } RELEASE-2.1.0. So, we have to make custom "Installation Boot Floppy" } for our user. I had trying to make it by using the Makefile at } /usr/src/release, but met some error. Is anyone can help me ? Well, 2.1.0R has been released a long time ago ... But the upcoming 2.1.5 ought to be able to boot from a NCR 53c825A or 875 controller card. Did you try with any of the SNAP releases ? I have prepared most of the changes required to integrate full support for the 53c875. Since the 875 will need different SCRIPTS code than the older 53c8xx chips to take full advantage of its new features, the driver will decompress and dynamically link the code executed by the SCSI chip in the driver init phase. (These changes are also supposed to go into the ncrBsd driver, which is the FreeBSD driver ported to Linux by Gerard Roudier.) This is a very complex change, and I'll need a controller card to test my changes with. But I did not find any cheap 53c875 based card, yet. If I saw one announced, then it was much more expensive than an Adaptec 2940UW. And while it can be as fast as the Adaptec, I won't pay significantly more ... What will your card cost and who will sell it in Germany ? The AMD SCSI chip appears to be far inferior to even the cheapest NCR/Symbios, the 53c810. The AMD requires multiple interrupts per transfer, while the NCR generelly completes the SCSI command including any disconnects/reselects with no host CPU intervention except for the command complete interrupt. (And the NCR driver in *BSD does not wait for the CPU to service the interrupt but continues working on other SCSI commands immediately after raising the interrupt line!) Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/~se From owner-freebsd-scsi Thu Jul 11 16:48:35 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA14828 for freebsd-scsi-outgoing; Thu, 11 Jul 1996 16:48:35 -0700 (PDT) Received: from isgate.is (isgate.is [193.4.58.51]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA14822 for ; Thu, 11 Jul 1996 16:48:33 -0700 (PDT) Received: from hummer.islandia.is by isgate.is (8.7.5-M/ISnet/14-10-91); Thu, 11 Jul 1996 23:48:18 GMT Received: from hummer.islandia.is by hummer.islandia.is (8.7.5/ISnet/12-09-94); Thu, 11 Jul 1996 23:48:59 GMT Date: Thu, 11 Jul 1996 23:48:59 +0000 () From: Stefan Thor Hreinsson To: freebsd-scsi@freebsd.org Subject: Conner going bad. 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 Hi all. I'm getting one of these as seen below on my conner 2.1, i'ts a bad sector right ? :( So how do I fix it, using scsi(8) og some other methood, or is it to the shop to buy a new one ? ahc0 rev 3 int a irq 11 on pci0:10 ahc0: aic7870 Single Channel, SCSI Id=7, 16 SCBs ahc0 waiting for scsi devices to settle (ahc0:0:0): "CONNER CFP2107S 2.14GB 1420" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 2048MB (4194304 512 byte sectors) (ahc0:6:0): "Quantum XP32150 81HB" type 0 fixed SCSI 2 sd1(ahc0:6:0): Direct-Access 2050MB (4199760 512 byte sectors) sd0(ahc0:0:0): MEDIUM ERROR info:2dcd96 csi:a,18,4,4a asc:11,0 Unrecovered read error field replaceable unit: 15 , retries:4 sd0(ahc0:0:0): MEDIUM ERROR info:2dcd96 csi:a,18,4,4a asc:11,0 Unrecovered read error field replaceable unit: 15 , retries:3 sd0(ahc0:0:0): MEDIUM ERROR info:2dcd96 csi:a,18,4,4a asc:11,0 Unrecovered read error field replaceable unit: 15 , retries:2 sd0(ahc0:0:0): MEDIUM ERROR info:2dcd96 csi:a,18,4,4a asc:11,0 Unrecovered read error field replaceable unit: 15 , retries:1 sd0(ahc0:0:0): MEDIUM ERROR info:2dcd96 csi:a,18,4,4a asc:11,0 Unrecovered read error field replaceable unit: 15 , FAILURE From owner-freebsd-scsi Thu Jul 11 18:46:48 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA19921 for freebsd-scsi-outgoing; Thu, 11 Jul 1996 18:46:48 -0700 (PDT) Received: from minotaur.labyrinth.net.au (minotaur.labyrinth.net.au [203.9.148.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA19915 for ; Thu, 11 Jul 1996 18:46:41 -0700 (PDT) Received: (from mail@localhost) by minotaur.labyrinth.net.au (8.7.2/8.7.2) id LAA12432 for ; Fri, 12 Jul 1996 11:46:35 +1000 (EST) Date: Fri, 12 Jul 1996 11:46:35 +1000 (EST) Message-Id: <199607120146.LAA12432@minotaur.labyrinth.net.au> X-Authentication-Warning: minotaur.labyrinth.net.au: mail set sender to using -f Received: from portal-as3.labyrinth.net.au(203.9.148.13) by minotaur.labyrinth.net.au via smap (V1.3) id sma012416; Fri Jul 12 11:46:12 1996 X-Sender: jbh@labyrinth.net.au (Unverified) X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: freebsd-scsi@freebsd.org From: John Hartley Subject: Re: tandberg scsi tape + FreeBSD 2.1/2.0.5 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 23:19 11/07/96 +0200, you wrote: J"org, >As John Hartley wrote: > >> Jul 10 21:42:02 qwiff /kernel: st0(ahc0:2:0): command: 1a,0,0,0,c,0-[12 bytes] >> Jul 10 21:42:02 qwiff /kernel: ------------------------------ >> Jul 10 21:42:02 qwiff /kernel: 000: 2f 25 10 08 00 00 00 00 00 00 02 00 >> Jul 10 21:42:02 qwiff /kernel: ------------------------------ > >> Jul 10 21:42:02 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): density >> code 0x0, 512-byte blocks, write-enabled, st0(ahc0:2:0): buffered > >> Present Mode: Density = ECMA TC17 Blocksize variable >> ---------available modes--------- >> Mode 0: Density = 0x00 Blocksize variable >> Mode 1: Density = 0x00 Blocksize variable >> Mode 2: Density = 0x00 Blocksize variable >> Mode 3: Density = 0x00 Blocksize variable > >This looks self-contradicionary. The kernel message claims density >code 0, while the mt status output claims density code 0x15. The >kernel message says 512-byte blocks... > >What's the actual medium type in the drive while you captured the >above? (Just curious.) > The tape am using is a 1.2 GB "Magnus", I'm not sure what this translates to in QIC terms. I have reperformed the test, having booted the box with the tape in the drive. The following commands where then done: scsi -f /dev/st0ctl.0 -d 0xff mt -f /dev/rst0 status tar tvf /dev/rst0 mt -f /dev/rst0 status The following logs show the audit trail. I am no longer getting the density=ECMA TC17 This may have been as a result of some other "twiddling" I had done. So heres a clean set of tests, on a freshly booted machine. Boot Log, with Magnus 1.2 GB tape in drive: Jul 12 10:45:11 qwiff /kernel: FreeBSD 2.1.0-RELEASE #0: Wed Jul 10 21:10:45 1996 Jul 12 10:45:11 qwiff /kernel: jbh@qwiff.graphica.com.au:/usr/src/sys/compile/TP_SIMPLE Jul 12 10:45:12 qwiff /kernel: CPU: i486 DX4 (486-class CPU) Jul 12 10:45:12 qwiff /kernel: Origin = "GenuineIntel" Id = 0x480 Stepping=0 Jul 12 10:45:12 qwiff /kernel: Features=0x3 Jul 12 10:45:12 qwiff /kernel: real memory = 33554432 (32768K bytes) Jul 12 10:45:12 qwiff /kernel: avail memory = 31035392 (30308K bytes) Jul 12 10:45:12 qwiff /kernel: Probing for devices on the ISA bus: Jul 12 10:45:13 qwiff /kernel: sc0 at 0x60-0x6f irq 1 on motherboard Jul 12 10:45:13 qwiff /kernel: sc0: VGA color <16 virtual consoles, flags=0x0> Jul 12 10:45:13 qwiff /kernel: sio0 at 0x3f8-0x3ff irq 4 on isa Jul 12 10:45:13 qwiff /kernel: sio0: type 16550A Jul 12 10:45:13 qwiff /kernel: sio1 at 0x2f8-0x2ff irq 3 on isa Jul 12 10:45:13 qwiff /kernel: sio1: type 16550A Jul 12 10:45:13 qwiff /kernel: lpt0 at 0x3bc-0x3c3 irq 7 on isa Jul 12 10:45:13 qwiff /kernel: lpt0: Interrupt-driven port Jul 12 10:45:14 qwiff /kernel: lp0: TCP/IP capable interface Jul 12 10:45:14 qwiff /kernel: psm0 at 0x60-0x63 irq 12 on motherboard Jul 12 10:45:14 qwiff /kernel: fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa Jul 12 10:45:14 qwiff /kernel: fdc0: NEC 72065B Jul 12 10:45:14 qwiff /kernel: fd0: 1.44MB 3.5in Jul 12 10:45:14 qwiff /kernel: 2 3C5x9 board(s) on ISA found at 0x310 0x300 Jul 12 10:45:15 qwiff /kernel: ep0 at 0x300-0x30f irq 10 on isa Jul 12 10:45:15 qwiff /kernel: ep0: aui/bnc[*BNC*] address 00:60:8c:60:ac:0e irq 10 Jul 12 10:45:15 qwiff /kernel: ep1 at 0x310-0x31f irq 11 on isa Jul 12 10:45:15 qwiff /kernel: ep1: aui/bnc[*BNC*] address 00:20:af:0f:6c:0a irq 11 Jul 12 10:45:15 qwiff /kernel: npx0 on motherboard Jul 12 10:45:15 qwiff /kernel: npx0: INT 16 interface Jul 12 10:45:15 qwiff /kernel: Probing for devices on the PCI bus: Jul 12 10:45:15 qwiff /kernel: ahc0 rev 0 int a irq 5 on pci0:12 Jul 12 10:45:15 qwiff /kernel: ahc0: aic7870 Ultra Single Channel, SCSI Id=7, aic7870, 255 SCBs Jul 12 10:45:16 qwiff /kernel: ahc0 waiting for scsi devices to settle Jul 12 10:45:16 qwiff /kernel: (ahc0:0:0): "FUJITSU M1606S-512 6234" type 0 fixed SCSI 2 Jul 12 10:45:16 qwiff /kernel: sd0(ahc0:0:0): Direct-Access 1041MB (2131992 512 byte sectors) Jul 12 10:45:16 qwiff /kernel: (ahc0:1:0): "MATSHITA CD-ROM CR-5XX 1.0b" type 5 removable SCSI 1 Jul 12 10:45:16 qwiff /kernel: cd0(ahc0:1:0): CD-ROM Jul 12 10:45:16 qwiff /kernel: cd0(ahc0:1:0): NOT READY asc:a0,0 Jul 12 10:45:17 qwiff /kernel: can't get the size Jul 12 10:45:17 qwiff /kernel: Jul 12 10:45:17 qwiff /kernel: (ahc0:2:0): "TANDBERG TDC 4100 J04:" type 1 removable SCSI 2 Jul 12 10:45:17 qwiff /kernel: st0(ahc0:2:0): Sequential-Access density code 0x0, 512-byte blocks, write-enabled Jul 12 10:45:17 qwiff /kernel: pci0:16: OPTI, device=0xc822, class=bridge (host) [no driver assigned] Jul 12 10:45:11 qwiff named[64]: starting. named LOCAL-951116.090057 Thu Nov 16 09:00:57 1995 jkh@westhill.cdrom.com:/usr/src/usr.sbin/named Jul 12 10:45:12 qwiff named[65]: Ready to answer queries. Jul 12 10:45:14 qwiff lpd[87]: restarted >>>>> mt -f /dev/st0ctl.0 <<<<<<<< >>> Output <<< Present Mode: Density = 0x00 Blocksize variable ---------available modes--------- Mode 0: Density = 0x00 Blocksize variable Mode 1: Density = 0x00 Blocksize variable Mode 2: Density = 0x00 Blocksize variable Mode 3: Density = 0x00 Blocksize variable >>> Log <<< Jul 12 10:47:58 qwiff /kernel: st0(ahc0:2:0): stclose: Closing device Jul 12 10:49:36 qwiff /kernel: st0(ahc0:2:0): scsi_cmd Jul 12 10:49:36 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 12 10:49:36 qwiff /kernel: st0(ahc0:2:0): returning Jul 12 10:49:36 qwiff /kernel: xs(0xf0859980): flg(0x60)sc_link(0xf0859780)retr(0x2)timo(0x186a0)cmd(0xf08599d8)len(0x6)dat a(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 12 10:49:37 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 12 10:49:37 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 12 10:49:37 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 12 10:49:37 qwiff /kernel: _sent Jul 12 10:49:37 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 12 10:49:37 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 12 10:49:37 qwiff /kernel: st0(ahc0:2:0): command: 1b,0,0,0,1,0-[0 bytes] Jul 12 10:49:37 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 12 10:49:37 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 12 10:49:37 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 12 10:49:37 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 12 10:49:37 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): scsi_cmd Jul 12 10:49:37 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 12 10:49:37 qwiff /kernel: st0(ahc0:2:0): returning Jul 12 10:49:37 qwiff /kernel: xs(0xf0aaff80): flg(0x60)sc_link(0xf0859780)retr(0x2)timo(0x186a0)cmd(0xf0aaffd8)len(0x6)dat a(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 12 10:49:38 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 12 10:49:38 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 12 10:49:38 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 12 10:49:38 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 12 10:49:38 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 12 10:49:38 qwiff /kernel: st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 12 10:49:38 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 12 10:49:38 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 12 10:49:38 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 12 10:49:38 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 12 10:49:38 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): scsi_cmd Jul 12 10:49:38 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 12 10:49:38 qwiff /kernel: st0(ahc0:2:0): returning Jul 12 10:49:38 qwiff /kernel: xs(0xf0aaff80): flg(0x420)sc_link(0xf0859780)retr(0x4)timo(0x1388)cmd(0xf0aaffd8)len(0x6)dat a(0xf2772000)len(0x6)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 5,0,0,0,0,0-[6 bytes] Jul 12 10:49:38 qwiff /kernel: ------------------------------ Jul 12 10:49:39 qwiff /kernel: 000: 00 00 00 00 00 00 Jul 12 10:49:39 qwiff /kernel: ------------------------------ Jul 12 10:49:39 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 12 10:49:39 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 12 10:49:39 qwiff /kernel: st0(ahc0:2:0): 6 @0xf2772000:- 0x4b000(0x6) Jul 12 10:49:39 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 12 10:49:39 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 12 10:49:39 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 12 10:49:39 qwiff /kernel: st0(ahc0:2:0): command: 5,0,0,0,0,0-[6 bytes] Jul 12 10:49:39 qwiff /kernel: ------------------------------ Jul 12 10:49:39 qwiff /kernel: 000: 00 ff ff ff 00 01 Jul 12 10:49:39 qwiff /kernel: ------------------------------ Jul 12 10:49:39 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 12 10:49:39 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 12 10:49:39 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 12 10:49:40 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 12 10:49:40 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): (1 <= blksiz <= 16777215) Jul 12 10:49:40 qwiff /kernel: st0(ahc0:2:0): scsi_cmd Jul 12 10:49:40 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 12 10:49:40 qwiff /kernel: st0(ahc0:2:0): returning Jul 12 10:49:40 qwiff /kernel: xs(0xf0aaff80): flg(0x420)sc_link(0xf0859780)retr(0x4)timo(0x1388)cmd(0xf0aaffd8)len(0x6)dat a(0xf2772000)len(0xc)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 1a,0,0,0,c,0-[12 bytes] Jul 12 10:49:40 qwiff /kernel: ------------------------------ Jul 12 10:49:40 qwiff /kernel: 000: 00 00 00 00 00 00 00 00 00 00 00 00 Jul 12 10:49:40 qwiff /kernel: ------------------------------ Jul 12 10:49:40 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 12 10:49:40 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 12 10:49:40 qwiff /kernel: st0(ahc0:2:0): 12 @0xf2772000:- 0x4b000(0xc) Jul 12 10:49:40 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 12 10:49:40 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 12 10:49:40 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 12 10:49:41 qwiff /kernel: st0(ahc0:2:0): command: 1a,0,0,0,c,0-[12 bytes] Jul 12 10:49:41 qwiff /kernel: ------------------------------ Jul 12 10:49:41 qwiff /kernel: 000: 2f 25 10 08 00 00 00 00 00 00 02 00 Jul 12 10:49:41 qwiff /kernel: ------------------------------ Jul 12 10:49:41 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 12 10:49:41 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 12 10:49:41 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 12 10:49:41 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 12 10:49:41 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): density code 0x0, 512-byte blocks, write-enabled, st0(ahc0:2:0): buffered Jul 12 10:49:41 qwiff /kernel: st0(ahc0:2:0): starting block mode decision Jul 12 10:49:41 qwiff /kernel: st0(ahc0:2:0): Give up and default to variable mode Jul 12 10:49:41 qwiff /kernel: st0(ahc0:2:0): scsi_cmd Jul 12 10:49:41 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 12 10:49:41 qwiff /kernel: st0(ahc0:2:0): returning Jul 12 10:49:41 qwiff /kernel: xs(0xf0859980): flg(0x820)sc_link(0xf0859780)retr(0x4)timo(0x1388)cmd(0xf08599d8)len(0x6)dat a(0xf2772000)len(0xc)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 15,0,0,0,c,0-[12 bytes] Jul 12 10:49:42 qwiff /kernel: ------------------------------ Jul 12 10:49:42 qwiff /kernel: 000: 00 00 10 08 00 00 00 00 00 00 00 00 Jul 12 10:49:42 qwiff /kernel: ------------------------------ Jul 12 10:49:42 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 12 10:49:42 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0ab0000) Jul 12 10:49:42 qwiff /kernel: st0(ahc0:2:0): 12 @0xf2772000:- 0x4b000(0xc) Jul 12 10:49:42 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 12 10:49:42 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 12 10:49:42 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 12 10:49:42 qwiff /kernel: st0(ahc0:2:0): command: 15,0,0,0,c,0-[12 bytes] Jul 12 10:49:42 qwiff /kernel: ------------------------------ Jul 12 10:49:42 qwiff /kernel: 000: 00 00 10 08 00 00 00 00 00 00 00 00 Jul 12 10:49:42 qwiff /kernel: ------------------------------ Jul 12 10:49:42 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 12 10:49:42 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x1 Jul 12 10:49:43 qwiff /kernel: code70 valid0 seg0 key5 ili0 eom0 fmark0 Jul 12 10:49:43 qwiff /kernel: info: 0 0 0 0 followed by 10 extra bytes Jul 12 10:49:43 qwiff /kernel: extra: 0 8 0 0 24 0 2 0 0 0 Jul 12 10:49:43 qwiff /kernel: st0(ahc0:2:0): calling private err_handler() Jul 12 10:49:43 qwiff /kernel: st0(ahc0:2:0): private err_handler() returned -1 Jul 12 10:49:43 qwiff /kernel: st0(ahc0:2:0): ILLEGAL REQUEST csi:0,8,0,0 asc:24,0 Invalid field in CDB field replaceable unit: 2 Jul 12 10:49:43 qwiff /kernel: st0(ahc0:2:0): scsi_interpret_sense (no bp) returned 22 Jul 12 10:49:43 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 12 10:49:43 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 12 10:49:43 qwiff /kernel: st0(ahc0:2:0): ststart st0: Cannot set selected modest0(ahc0:2:0): Open complete Jul 12 10:49:43 qwiff /kernel: st0(ahc0:2:0): stopen: dev=0xe00 (unit 0) result 0 Jul 12 10:49:43 qwiff /kernel: st0(ahc0:2:0): [ioctl: get status] >>>>>> tar tvf /dev/rst0 <<<<<<< Jul 12 10:49:43 qwiff /kernel: st0(ahc0:2:0): stclose: Closing device Jul 12 10:50:20 qwiff /kernel: st0(ahc0:2:0): scsi_cmd Jul 12 10:50:20 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 12 10:50:20 qwiff /kernel: st0(ahc0:2:0): returning Jul 12 10:50:20 qwiff /kernel: xs(0xf0859980): flg(0x60)sc_link(0xf0859780)retr(0x2)timo(0x186a0)cmd(0xf08599d8)len(0x6)dat a(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 12 10:50:20 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 12 10:50:21 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 12 10:50:21 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 12 10:50:21 qwiff /kernel: command: 1b,0,0,0,1,0-[0 bytes] Jul 12 10:50:21 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 12 10:50:21 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 12 10:50:21 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 12 10:50:21 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 12 10:50:21 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): scsi_cmd Jul 12 10:50:21 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 12 10:50:21 qwiff /kernel: st0(ahc0:2:0): returning Jul 12 10:50:21 qwiff /kernel: xs(0xf0859980): flg(0x60)sc_link(0xf0859780)retr(0x2)timo(0x186a0)cmd(0xf08599d8)len(0x6)dat a(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 12 10:50:21 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 12 10:50:21 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 12 10:50:21 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 12 10:50:21 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 12 10:50:21 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 12 10:50:22 qwiff /kernel: st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 12 10:50:22 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 12 10:50:22 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 12 10:50:22 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 12 10:50:22 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 12 10:50:22 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): scsi_cmd Jul 12 10:50:22 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 12 10:50:22 qwiff /kernel: st0(ahc0:2:0): returning Jul 12 10:50:22 qwiff /kernel: xs(0xf0859980): flg(0x420)sc_link(0xf0859780)retr(0x4)timo(0x1388)cmd(0xf08599d8)len(0x6)dat a(0xf2772000)len(0x6)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 5,0,0,0,0,0-[6 bytes] Jul 12 10:50:22 qwiff /kernel: ------------------------------ Jul 12 10:50:22 qwiff /kernel: 000: 00 00 00 00 00 00 Jul 12 10:50:22 qwiff /kernel: ------------------------------ Jul 12 10:50:22 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 12 10:50:22 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0ab0000) Jul 12 10:50:22 qwiff /kernel: st0(ahc0:2:0): 6 @0xf2772000:- 0x4b000(0x6) Jul 12 10:50:22 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 12 10:50:23 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 12 10:50:23 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 12 10:50:23 qwiff /kernel: st0(ahc0:2:0): command: 5,0,0,0,0,0-[6 bytes] Jul 12 10:50:23 qwiff /kernel: ------------------------------ Jul 12 10:50:23 qwiff /kernel: 000: 00 ff ff ff 00 01 Jul 12 10:50:23 qwiff /kernel: ------------------------------ Jul 12 10:50:23 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 12 10:50:23 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 12 10:50:23 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 12 10:50:23 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 12 10:50:23 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): (1 <= blksiz <= 16777215) Jul 12 10:50:23 qwiff /kernel: st0(ahc0:2:0): scsi_cmd Jul 12 10:50:23 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 12 10:50:23 qwiff /kernel: st0(ahc0:2:0): returning Jul 12 10:50:23 qwiff /kernel: xs(0xf0859980): flg(0x420)sc_link(0xf0859780)retr(0x4)timo(0x1388)cmd(0xf08599d8)len(0x6)dat a(0xf2772000)len(0xc)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 1a,0,0,0,c,0-[12 bytes] Jul 12 10:50:24 qwiff /kernel: ------------------------------ Jul 12 10:50:24 qwiff /kernel: 000: 00 00 00 00 00 00 00 00 00 00 00 00 Jul 12 10:50:24 qwiff /kernel: ------------------------------ Jul 12 10:50:24 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 12 10:50:24 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0ab0000) Jul 12 10:50:24 qwiff /kernel: st0(ahc0:2:0): 12 @0xf2772000:- 0x4b000(0xc) Jul 12 10:50:24 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 12 10:50:24 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 12 10:50:24 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 12 10:50:24 qwiff /kernel: st0(ahc0:2:0): command: 1a,0,0,0,c,0-[12 bytes] Jul 12 10:50:24 qwiff /kernel: ------------------------------ Jul 12 10:50:24 qwiff /kernel: 000: 2f 25 10 08 00 00 00 00 00 00 02 00 Jul 12 10:50:24 qwiff /kernel: ------------------------------ Jul 12 10:50:24 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 12 10:50:24 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 12 10:50:24 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 12 10:50:24 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 12 10:50:25 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): density code 0x0, 512-byte blocks, write-enabled, st0(ahc0:2:0): buffered Jul 12 10:50:25 qwiff /kernel: st0(ahc0:2:0): starting block mode decision Jul 12 10:50:25 qwiff /kernel: st0(ahc0:2:0): Give up and default to variable mode Jul 12 10:50:25 qwiff /kernel: st0(ahc0:2:0): scsi_cmd Jul 12 10:50:25 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 12 10:50:25 qwiff /kernel: st0(ahc0:2:0): returning Jul 12 10:50:25 qwiff /kernel: xs(0xf0aaff80): flg(0x820)sc_link(0xf0859780)retr(0x4)timo(0x1388)cmd(0xf0aaffd8)len(0x6)dat a(0xf2772000)len(0xc)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 15,0,0,0,c,0-[12 bytes] Jul 12 10:50:25 qwiff /kernel: ------------------------------ Jul 12 10:50:25 qwiff /kernel: 000: 00 00 10 08 00 00 00 00 00 00 00 00 Jul 12 10:50:25 qwiff /kernel: ------------------------------ Jul 12 10:50:25 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 12 10:50:25 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 12 10:50:25 qwiff /kernel: st0(ahc0:2:0): 12 @0xf2772000:- 0x4b000(0xc) Jul 12 10:50:25 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 12 10:50:25 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 12 10:50:26 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 12 10:50:26 qwiff /kernel: st0(ahc0:2:0): command: 15,0,0,0,c,0-[12 bytes] Jul 12 10:50:26 qwiff /kernel: ------------------------------ Jul 12 10:50:26 qwiff /kernel: 000: 00 00 10 08 00 00 00 00 00 00 00 00 Jul 12 10:50:26 qwiff /kernel: ------------------------------ Jul 12 10:50:26 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 12 10:50:26 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x1 Jul 12 10:50:26 qwiff /kernel: code70 valid0 seg0 key5 ili0 eom0 fmark0 Jul 12 10:50:26 qwiff /kernel: info: 0 0 0 0 followed by 10 extra bytes Jul 12 10:50:26 qwiff /kernel: extra: 0 8 0 0 24 0 2 0 0 0 Jul 12 10:50:26 qwiff /kernel: st0(ahc0:2:0): calling private err_handler() Jul 12 10:50:26 qwiff /kernel: st0(ahc0:2:0): private err_handler() returned -1 Jul 12 10:50:26 qwiff /kernel: st0(ahc0:2:0): ILLEGAL REQUEST csi:0,8,0,0 asc:24,0 Invalid field in CDB field replaceable unit: 2 Jul 12 10:50:26 qwiff /kernel: st0(ahc0:2:0): scsi_interpret_sense (no bp) returned 22 Jul 12 10:50:26 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 12 10:50:27 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 12 10:50:27 qwiff /kernel: st0(ahc0:2:0): ststart st0: Cannot set selected modest0(ahc0:2:0): Open complete Jul 12 10:50:27 qwiff /kernel: st0(ahc0:2:0): stopen: dev=0xe00 (unit 0) result 0 Jul 12 10:50:27 qwiff /kernel: st0(ahc0:2:0): Jul 12 10:50:27 qwiff /kernel: ststrategy st0(ahc0:2:0): 10240 bytes @ blk0 Jul 12 10:50:27 qwiff /kernel: st0(ahc0:2:0): ststart st0: oops not queued >>>>>>>> mt -f /dev/rst0 status >>> Output <<< Present Mode: Density = 0x00 Blocksize variable ---------available modes--------- Mode 0: Density = 0x00 Blocksize variable Mode 1: Density = 0x00 Blocksize variable Mode 2: Density = 0x00 Blocksize variable Mode 3: Density = 0x00 Blocksize variable >>> Log <<< Jul 12 10:50:27 qwiff /kernel: st0(ahc0:2:0): stclose: Closing device Jul 12 10:50:57 qwiff /kernel: st0(ahc0:2:0): scsi_cmd Jul 12 10:50:57 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 12 10:50:57 qwiff /kernel: st0(ahc0:2:0): returning Jul 12 10:50:57 qwiff /kernel: xs(0xf0aaff80): flg(0x60)sc_link(0xf0859780)retr(0x2)timo(0x186a0)cmd(0xf0aaffd8)len(0x6)dat a(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 12 10:50:57 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 12 10:50:57 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0ab0000) Jul 12 10:50:57 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 12 10:50:57 qwiff /kernel: _sent Jul 12 10:50:57 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 12 10:50:57 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 12 10:50:57 qwiff /kernel: st0(ahc0:2:0): command: 1b,0,0,0,1,0-[0 bytes] Jul 12 10:50:57 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 12 10:50:57 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 12 10:50:58 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 12 10:50:58 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 12 10:50:58 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): scsi_cmd Jul 12 10:50:58 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 12 10:50:58 qwiff /kernel: st0(ahc0:2:0): returning Jul 12 10:50:58 qwiff /kernel: xs(0xf0aaff80): flg(0x60)sc_link(0xf0859780)retr(0x2)timo(0x186a0)cmd(0xf0aaffd8)len(0x6)dat a(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 12 10:50:58 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 12 10:50:58 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 12 10:50:58 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 12 10:50:58 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 12 10:50:58 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 12 10:50:58 qwiff /kernel: st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 12 10:50:58 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 12 10:50:58 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 12 10:50:58 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 12 10:50:59 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 12 10:50:59 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): scsi_cmd Jul 12 10:50:59 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 12 10:50:59 qwiff /kernel: st0(ahc0:2:0): returning Jul 12 10:50:59 qwiff /kernel: xs(0xf0aaff80): flg(0x420)sc_link(0xf0859780)retr(0x4)timo(0x1388)cmd(0xf0aaffd8)len(0x6)dat a(0xf2772000)len(0x6)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 5,0,0,0,0,0-[6 bytes] Jul 12 10:50:59 qwiff /kernel: ------------------------------ Jul 12 10:50:59 qwiff /kernel: 000: 00 00 00 00 00 00 Jul 12 10:50:59 qwiff /kernel: ------------------------------ Jul 12 10:50:59 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 12 10:50:59 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 12 10:50:59 qwiff /kernel: st0(ahc0:2:0): 6 @0xf2772000:- 0x4b000(0x6) Jul 12 10:50:59 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 12 10:50:59 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 12 10:50:59 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 12 10:50:59 qwiff /kernel: st0(ahc0:2:0): command: 5,0,0,0,0,0-[6 bytes] Jul 12 10:51:00 qwiff /kernel: ------------------------------ Jul 12 10:51:00 qwiff /kernel: 000: 00 ff ff ff 00 01 Jul 12 10:51:00 qwiff /kernel: ------------------------------ Jul 12 10:51:00 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 12 10:51:00 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 12 10:51:00 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 12 10:51:00 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 12 10:51:00 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): (1 <= blksiz <= 16777215) Jul 12 10:51:00 qwiff /kernel: st0(ahc0:2:0): scsi_cmd Jul 12 10:51:00 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 12 10:51:00 qwiff /kernel: st0(ahc0:2:0): returning Jul 12 10:51:00 qwiff /kernel: xs(0xf0aaff80): flg(0x420)sc_link(0xf0859780)retr(0x4)timo(0x1388)cmd(0xf0aaffd8)len(0x6)dat a(0xf2772000)len(0xc)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 1a,0,0,0,c,0-[12 bytes] Jul 12 10:51:00 qwiff /kernel: ------------------------------ Jul 12 10:51:00 qwiff /kernel: 000: 00 00 00 00 00 00 00 00 00 00 00 00 Jul 12 10:51:00 qwiff /kernel: ------------------------------ Jul 12 10:51:01 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 12 10:51:01 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 12 10:51:01 qwiff /kernel: st0(ahc0:2:0): 12 @0xf2772000:- 0x4b000(0xc) Jul 12 10:51:01 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 12 10:51:01 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 12 10:51:01 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 12 10:51:01 qwiff /kernel: st0(ahc0:2:0): command: 1a,0,0,0,c,0-[12 bytes] Jul 12 10:51:01 qwiff /kernel: ------------------------------ Jul 12 10:51:01 qwiff /kernel: 000: 2f 25 10 08 00 00 00 00 00 00 02 00 Jul 12 10:51:01 qwiff /kernel: ------------------------------ Jul 12 10:51:01 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 12 10:51:01 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 12 10:51:01 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 12 10:51:01 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 12 10:51:01 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): density code 0x0, 512-byte blocks, write-enabled, st0(ahc0:2:0): buffered Jul 12 10:51:02 qwiff /kernel: st0(ahc0:2:0): starting block mode decision Jul 12 10:51:02 qwiff /kernel: st0(ahc0:2:0): Give up and default to variable mode Jul 12 10:51:02 qwiff /kernel: st0(ahc0:2:0): scsi_cmd Jul 12 10:51:02 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 12 10:51:02 qwiff /kernel: st0(ahc0:2:0): returning Jul 12 10:51:02 qwiff /kernel: xs(0xf0859980): flg(0x820)sc_link(0xf0859780)retr(0x4)timo(0x1388)cmd(0xf08599d8)len(0x6)dat a(0xf2772000)len(0xc)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 15,0,0,0,c,0-[12 bytes] Jul 12 10:51:02 qwiff /kernel: ------------------------------ Jul 12 10:51:02 qwiff /kernel: 000: 00 00 10 08 00 00 00 00 00 00 00 00 Jul 12 10:51:02 qwiff /kernel: ------------------------------ Jul 12 10:51:02 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 12 10:51:02 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0ab0000) Jul 12 10:51:02 qwiff /kernel: st0(ahc0:2:0): 12 @0xf2772000:- 0x4b000(0xc) Jul 12 10:51:02 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 12 10:51:02 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 12 10:51:02 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 12 10:51:03 qwiff /kernel: st0(ahc0:2:0): command: 15,0,0,0,c,0-[12 bytes] Jul 12 10:51:03 qwiff /kernel: ------------------------------ Jul 12 10:51:03 qwiff /kernel: 000: 00 00 10 08 00 00 00 00 00 00 00 00 Jul 12 10:51:03 qwiff /kernel: ------------------------------ Jul 12 10:51:03 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 12 10:51:03 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x1 Jul 12 10:51:03 qwiff /kernel: code70 valid0 seg0 key5 ili0 eom0 fmark0 Jul 12 10:51:03 qwiff /kernel: info: 0 0 0 0 followed by 10 extra bytes Jul 12 10:51:03 qwiff /kernel: extra: 0 8 0 0 24 0 2 0 0 0 Jul 12 10:51:03 qwiff /kernel: st0(ahc0:2:0): calling private err_handler() Jul 12 10:51:03 qwiff /kernel: st0(ahc0:2:0): private err_handler() returned -1 Jul 12 10:51:03 qwiff /kernel: st0(ahc0:2:0): ILLEGAL REQUEST csi:0,8,0,0 asc:24,0 Invalid field in CDB field replaceable unit: 2 Jul 12 10:51:03 qwiff /kernel: st0(ahc0:2:0): scsi_interpret_sense (no bp) returned 22 Jul 12 10:51:03 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 12 10:51:04 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 12 10:51:04 qwiff /kernel: st0(ahc0:2:0): ststart st0: Cannot set selected modest0(ahc0:2:0): Open complete Jul 12 10:51:04 qwiff /kernel: st0(ahc0:2:0): stopen: dev=0xe00 (unit 0) result 0 Jul 12 10:51:04 qwiff /kernel: st0(ahc0:2:0): [ioctl: get status] Jul 12 10:51:04 qwiff /kernel: st0(ahc0:2:0): stclose: Closing device Thanks it for now. Thanks. John Hartley. jbh@labyrinth.net.au Graphica Software Pty. Ltd. From owner-freebsd-scsi Thu Jul 11 18:57:32 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA20428 for freebsd-scsi-outgoing; Thu, 11 Jul 1996 18:57:32 -0700 (PDT) Received: from commerce.imagenet.on.ca (commerce.imagenet.on.ca [207.107.36.10]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA20404; Thu, 11 Jul 1996 18:57:23 -0700 (PDT) Received: from commerce.imagenet.on.ca (commerce.imagenet.on.ca [207.107.36.10]) by commerce.imagenet.on.ca (8.6.12/8.6.12) with SMTP id WAA10729; Thu, 11 Jul 1996 22:00:34 -0400 Message-ID: <31E5B1C1.695678E2@imagenet.on.ca> Date: Thu, 11 Jul 1996 22:00:33 -0400 From: Stephen Couchman Organization: ImageNet Web Design Services Inc. X-Mailer: Mozilla 2.02 (X11; I; FreeBSD 2.1.0-RELEASE i386) MIME-Version: 1.0 To: freebsd-scsi@FreeBSD.org, freebsd-questions@FreeBSD.org Subject: Jaz drive questions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I have installed a Jaz drive as sd1 (SCSI id #2). I am using an Adaptec 2940 Ultra SCSI host adapter. FreeBSD does not seem to recognize the drive and produces the following messages: (ahc0:2:0): "iomega jaz 1GB G.60" type 0 removable SCSI 2 sd1(ahc0:2:0): Direct-Access sd1(ahc0:2:0): ILLEGAL REQUEST asc:24,0 Invalid field in CDB sd1 could not mode sense (4). Using ficticious geometry 1021MB (2091050 512 byte sectors) I would like to use this Jaz drive as a second hard disk to backup the contents of my bootable (SCSI) disk. I tried installing FreeBSD 2.1 on the Jaz drive by choosing sd1 as the destination. Unfortunately, the install program started re-installing sd0! :-(( How can I determine the correct geometry for the drive? How do I setup that geometry so that FreeBSD recognizes the drive? How can I partition the drive and setup the filesystems? I have looked at disklabel and newfs, and would appreciate a short example. I would really appreciate ANY advice that you can give. Thanks -- Stephen ______________________________________________________________________ Stephen.Couchman@imagenet.on.ca http://www.imagenet.on.ca/ From owner-freebsd-scsi Thu Jul 11 22:23:47 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA01494 for freebsd-scsi-outgoing; Thu, 11 Jul 1996 22:23:47 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id WAA01484 for ; Thu, 11 Jul 1996 22:23:31 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id HAA09333; Fri, 12 Jul 1996 07:22:59 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id HAA25410; Fri, 12 Jul 1996 07:22:59 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id HAA18642; Fri, 12 Jul 1996 07:01:30 +0200 (MET DST) From: J Wunsch Message-Id: <199607120501.HAA18642@uriah.heep.sax.de> Subject: Re: Conner going bad. To: freebsd-scsi@freebsd.org Date: Fri, 12 Jul 1996 07:01:29 +0200 (MET DST) Cc: stefan@islandia.is (Stefan Thor Hreinsson) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from Stefan Thor Hreinsson at "Jul 11, 96 11:48:59 pm" 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 X-Mailer: ELM [version 2.4ME+ PL17 (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 As Stefan Thor Hreinsson wrote: > I'm getting one of these as seen below on my conner 2.1, i'ts a bad > sector right ? :( So how do I fix it, using scsi(8) og some other > methood, or is it to the shop to buy a new one ? > sd0(ahc0:0:0): MEDIUM ERROR info:2dcd96 csi:a,18,4,4a asc:11,0 Unrecovered read error field replaceable unit: 15 > , retries:4 It's a bad sector. Do you have automatic bad sector remapping enabled? It's on mode page 1, and you find a command to modify this page in the EXAMPLES section of scsi(8). -- 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 Thu Jul 11 22:24:51 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA01555 for freebsd-scsi-outgoing; Thu, 11 Jul 1996 22:24:51 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id WAA01545 for ; Thu, 11 Jul 1996 22:24:31 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id HAA09337; Fri, 12 Jul 1996 07:23:01 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id HAA25411; Fri, 12 Jul 1996 07:23:00 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id HAA18699; Fri, 12 Jul 1996 07:07:09 +0200 (MET DST) From: J Wunsch Message-Id: <199607120507.HAA18699@uriah.heep.sax.de> Subject: Re: tandberg scsi tape + FreeBSD 2.1/2.0.5 To: freebsd-scsi@freebsd.org Date: Fri, 12 Jul 1996 07:07:09 +0200 (MET DST) Cc: jbh@labyrinth.net.au (John Hartley) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199607120146.LAA12432@minotaur.labyrinth.net.au> from John Hartley at "Jul 12, 96 11:46:35 am" 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 X-Mailer: ELM [version 2.4ME+ PL17 (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 As John Hartley wrote: > >What's the actual medium type in the drive while you captured the > >above? (Just curious.) > > > > The tape am using is a 1.2 GB "Magnus", I'm not sure what this translates > to in QIC terms. I think the ECMA-17 density was correct for this cartridge. > I have reperformed the test, having booted the box with the tape in the drive. > The following commands where then done: > scsi -f /dev/st0ctl.0 -d 0xff > mt -f /dev/rst0 status > tar tvf /dev/rst0 > mt -f /dev/rst0 status > Would the drive work if you do: mt fsr mt rewind tar tv ? -- 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 Fri Jul 12 00:25:18 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA10195 for freebsd-scsi-outgoing; Fri, 12 Jul 1996 00:25:18 -0700 (PDT) Received: from isgate.is (isgate.is [193.4.58.51]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA10186 for ; Fri, 12 Jul 1996 00:25:15 -0700 (PDT) Received: from hummer.islandia.is by isgate.is (8.7.5-M/ISnet/14-10-91); Fri, 12 Jul 1996 07:25:11 GMT Received: from hummer.islandia.is by hummer.islandia.is (8.7.5/ISnet/12-09-94); Fri, 12 Jul 1996 07:25:47 GMT Date: Fri, 12 Jul 1996 07:25:47 +0000 () From: Stefan Thor Hreinsson To: Joerg Wunsch cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Conner going bad. In-Reply-To: <199607120501.HAA18642@uriah.heep.sax.de> 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 On Fri, 12 Jul 1996, J Wunsch wrote: > As Stefan Thor Hreinsson wrote: > > > I'm getting one of these as seen below on my conner 2.1, i'ts a bad > > sector right ? :( So how do I fix it, using scsi(8) og some other > > methood, or is it to the shop to buy a new one ? > > > sd0(ahc0:0:0): MEDIUM ERROR info:2dcd96 csi:a,18,4,4a asc:11,0 Unrecovered read error field replaceable unit: 15 > > , retries:4 > > It's a bad sector. Do you have automatic bad sector remapping enabled? Nope, didn't have it on, didn't even know it existed. All is well now, thanks alot. > It's on mode page 1, and you find a command to modify this page in the > EXAMPLES section of scsi(8). > > -- > 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 Fri Jul 12 02:26:10 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA19868 for freebsd-scsi-outgoing; Fri, 12 Jul 1996 02:26:10 -0700 (PDT) Received: from nike.efn.org (gurney_j@garcia.efn.org [198.68.17.5]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA19859 for ; Fri, 12 Jul 1996 02:26:00 -0700 (PDT) Received: from localhost (localhost.efn.org [127.0.0.1]) by nike.efn.org (8.7.5/8.7.3) with SMTP id CAA12012; Fri, 12 Jul 1996 02:20:37 -0700 (PDT) Date: Fri, 12 Jul 1996 02:20:35 -0700 (PDT) From: John-Mark Gurney Reply-To: John-Mark Gurney To: Joerg Wunsch cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Conner going bad. In-Reply-To: <199607120501.HAA18642@uriah.heep.sax.de> 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 On Fri, 12 Jul 1996, J Wunsch wrote: > As Stefan Thor Hreinsson wrote: > > > I'm getting one of these as seen below on my conner 2.1, i'ts a bad > > sector right ? :( So how do I fix it, using scsi(8) og some other > > methood, or is it to the shop to buy a new one ? > > > sd0(ahc0:0:0): MEDIUM ERROR info:2dcd96 csi:a,18,4,4a asc:11,0 Unrecovered read error field replaceable unit: 15 > > , retries:4 > > It's a bad sector. Do you have automatic bad sector remapping enabled? > > It's on mode page 1, and you find a command to modify this page in the > EXAMPLES section of scsi(8). if you enable it do you need to reformat the drive? or can you safely turn AWRE and ARRE on on a running system? thanks for the info... thought I might check my conner even though I wasn't having problems with it.. Thanks for the info... TTYL. John-Mark gurney_j@efn.org http://resnet.uoregon.edu/~gurney_j/ Modem/FAX: (541) 683-6954 (FreeBSD Box) Live in Peace, destroy Micro$oft, support free software, run FreeBSD (unix) From owner-freebsd-scsi Fri Jul 12 03:25:38 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA26389 for freebsd-scsi-outgoing; Fri, 12 Jul 1996 03:25:38 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id DAA26369 for ; Fri, 12 Jul 1996 03:25:36 -0700 (PDT) Received: from minotaur.labyrinth.net.au (minotaur.labyrinth.net.au [203.9.148.2]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id DAA11800 for ; Fri, 12 Jul 1996 03:25:17 -0700 Received: (from mail@localhost) by minotaur.labyrinth.net.au (8.7.2/8.7.2) id UAA07480 for ; Fri, 12 Jul 1996 20:20:03 +1000 (EST) Date: Fri, 12 Jul 1996 20:20:03 +1000 (EST) Message-Id: <199607121020.UAA07480@minotaur.labyrinth.net.au> X-Authentication-Warning: minotaur.labyrinth.net.au: mail set sender to using -f Received: from portal-as28.labyrinth.net.au(203.9.148.38) by minotaur.labyrinth.net.au via smap (V1.3) id sma007478; Fri Jul 12 20:19:51 1996 X-Sender: jbh@labyrinth.net.au (Unverified) X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: freebsd-scsi@freebsd.org From: John Hartley Subject: Re: tandberg scsi tape + FreeBSD 2.1/2.0.5 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 07:07 12/07/96 +0200, you wrote: >As John Hartley wrote: > >> >What's the actual medium type in the drive while you captured the >> >above? (Just curious.) >> > >> >> The tape am using is a 1.2 GB "Magnus", I'm not sure what this translates >> to in QIC terms. > >I think the ECMA-17 density was correct for this cartridge. > >> I have reperformed the test, having booted the box with the tape in the drive. >> The following commands where then done: >> scsi -f /dev/st0ctl.0 -d 0xff >> mt -f /dev/rst0 status >> tar tvf /dev/rst0 >> mt -f /dev/rst0 status >> > >Would the drive work if you do: > > > mt fsr > mt rewind > tar tv > I tried this, doing a boot with no tape in the drive then: mt fsr (reports the ussual error ILLEGAL REQUEST csi:0,8,0,0 .... however the tape drive itself did some whirrringgg) mt rewind (ditto) tar tv (ditto, but no whirrringgg!) I then retryed with a non-blank tape in the unit Same results. Interestingly though following this suite of test an: mt status now reports "Density = ECMA TC17", so obviously there has been some negotiation going on. >-- >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. ;-) > > Thanks for your persistence. Me thinks maybe I should go out and buy a CD-ROM writer..... ;-) (I noticed you worked on the drivers for that.) (Irrelevent aside here, when you cut the CD I presume you are cutting a direct ufs image? So where do "Rock Ridge Extensions" come into play with Unix CDs? and what would you need to cut a "RRE" cd?) John Hartley Graphica Software Pty. Ltd. From owner-freebsd-scsi Fri Jul 12 05:49:20 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA10011 for freebsd-scsi-outgoing; Fri, 12 Jul 1996 05:49:20 -0700 (PDT) Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA10006 for ; Fri, 12 Jul 1996 05:49:17 -0700 (PDT) Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1]) by soleil.uvsq.fr (8.7.5/jtpda-5.2) with ESMTP id OAA11529 for ; Fri, 12 Jul 1996 14:49:14 +0200 (METDST) Received: from angrand.prism.uvsq.fr (angrand.prism.uvsq.fr [193.51.25.85]) by guillotin.prism.uvsq.fr (8.7.5/jtpda-5.2) with ESMTP id OAA06857 for ; Fri, 12 Jul 1996 14:49:13 +0200 (MET DST) Received: from (son@localhost) by angrand.prism.uvsq.fr (8.7.5/jtpda-5.2) id PAA00186 ; Fri, 12 Jul 1996 15:51:58 +0200 (MET DST) Date: Fri, 12 Jul 1996 15:51:58 +0200 (MET DST) Message-Id: <199607121351.PAA00186@angrand.prism.uvsq.fr> From: Nicolas Souchu To: freebsd-scsi@freebsd.org Subject: TRY_AGAIN_LATER return value Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >From /sys/scsi/scsi_base.c, /* * Do the transfer. If we are polling we will return: * COMPLETE, Was poll, and scsi_done has been called * TRY_AGAIN_LATER, Adapter short resources, try again ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * * if under full steam (interrupts) it will return: * SUCCESSFULLY_QUEUED, will do a wakeup when complete * TRY_AGAIN_LATER, (as for polling) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * * After the wakeup, we must still check if it succeeded * * If we have a bp however, all the error proccessing * and the buffer code both expect us to return straight * to them, so as soon as the command is queued, return */ After the last retry, the bp structure is updated like this: if (bp && retval) { bp->b_error = retval; bp->b_flags |= B_ERROR; biodone(bp); } then scsi_scsi_cmd() returns. Another possibility on short resources is to return HAD_ERROR with xs->error = XS_BUSY (XS_TIMEOUT is equivalent), then the bp structure is updated like this in sc_done() after the last retry: if (bp) { bp->b_error = 0; bp->b_flags |= B_ERROR; bp->b_error = code; bp->b_resid = bp->b_bcount; SC_DEBUG(xs->sc_link, SDEV_DB3, ("scsi_interpret_sense (bp) returned %d\n", code)); } and later... if (bp && retval) { bp->b_error = retval; bp->b_flags |= B_ERROR; biodone(bp); } then scsi_scsi_cmd() returns. Converting TRY_AGAIN_LATER to HAD_ERROR and XS_BUSY seem to correct the deadlock bug I previously posted. What about TRY_AGAIN_LATER then ? nicolas -- Nicolas.Souchu@prism.uvsq.fr Laboratoire PRiSM - Versailles, FRANCE From owner-freebsd-scsi Fri Jul 12 09:02:12 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA21624 for freebsd-scsi-outgoing; Fri, 12 Jul 1996 09:02:12 -0700 (PDT) Received: from freefall.freebsd.org (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA21617; Fri, 12 Jul 1996 09:02:09 -0700 (PDT) Message-Id: <199607121602.JAA21617@freefall.freebsd.org> To: Nicolas Souchu cc: freebsd-scsi@freebsd.org Subject: Re: TRY_AGAIN_LATER return value In-reply-to: Your message of "Fri, 12 Jul 1996 15:51:58 +0200." <199607121351.PAA00186@angrand.prism.uvsq.fr> Date: Fri, 12 Jul 1996 09:02:08 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Much of this has already changed in my local tree. My first pass over the SCSI system is almost complete, and I've removed quite a few bogons. TRY_AGAIN_LATER will most likely go away. Its current usage is to flag resource shortages when the driver cannot sleep for them. In the new scheme of things, these resources are requested in advance of queuing the command via two new entry points, get_cdb() and free_cdb(). Sleeping is usually not required since the buffers are on a queue anyway, so if you are told not to sleep in get_cdb() just return NULL. You will only get a call into your scsi_cmd() routine once get_cdb() is successful. HAD_ERROR has been removed. You should return COMPLETE with a valid error in the scsi_xfer structure. XS_BUSY means the target returned BUSY status, not that the driver is busy. (Hmmm... This should probably be determined by the upper level SCSI layer by looking at the status byte. Perhaps XS_BUSY can go away too.) XS_TIMEOUT is a generic target or command error. It should not be used to report resource shortages. I'll be sure to look into the deadlock you're seeing, but it sounds like you are using the return codes in a very different way. You should not be returning to the scsi system unless the buffer is filled or the drive has reported an error. >Another possibility on short resources is to return HAD_ERROR with >xs->error = XS_BUSY (XS_TIMEOUT is equivalent), then the bp structure >is updated like this in sc_done() after the last retry: Are you not able to sleep waiting for these resources as all the other driver do? >nicolas > >-- >Nicolas.Souchu@prism.uvsq.fr >Laboratoire PRiSM - Versailles, FRANCE > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Fri Jul 12 09:06:56 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA21970 for freebsd-scsi-outgoing; Fri, 12 Jul 1996 09:06:56 -0700 (PDT) Received: from mail.ruhrgebiet.individual.net (in-ruhr.ruhr.de [193.100.176.38]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA21949 for ; Fri, 12 Jul 1996 09:06:48 -0700 (PDT) Received: by mail.ruhrgebiet.individual.net (8.7.1/8.6.12) with UUCP id RAA20376; Fri, 12 Jul 1996 17:43:14 +0200 (MET DST) Received: by robkaos.ruhr.de (/\oo/\ Smail3.1.29.1 #29.1) id ; Fri, 12 Jul 96 17:27 MET DST Message-Id: From: robsch@robkaos.ruhr.de (Robert Schien) Subject: CD RRE To: jbh@labyrinth.net.au (John Hartley) Date: Fri, 12 Jul 1996 17:27:39 +0200 (MET DST) Cc: freebsd-scsi@freebsd.org In-Reply-To: <199607121020.UAA07480@minotaur.labyrinth.net.au> from "John Hartley" at Jul 12, 96 08:20:03 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > (Irrelevent aside here, when you cut the CD I presume you are cutting a direct > ufs image? So where do "Rock Ridge Extensions" come into play with Unix CDs? > and what would you need to cut a "RRE" cd?) > I use 'mkisofs' (it comes with FreeBSD) to create a CD image. 'mkisofs' has several options, one is to use RRE. Look at the man page. The actual burning is done with 'wormcontrol'. Again see the man page. BTW, the CD burner support appeared after the 2.1.0-RELEASE. Robert From owner-freebsd-scsi Fri Jul 12 09:43:55 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA25144 for freebsd-scsi-outgoing; Fri, 12 Jul 1996 09:43:55 -0700 (PDT) Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA25139 for ; Fri, 12 Jul 1996 09:43:50 -0700 (PDT) Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1]) by soleil.uvsq.fr (8.7.5/jtpda-5.2) with ESMTP id SAA16277 ; Fri, 12 Jul 1996 18:43:37 +0200 (METDST) Received: from angrand.prism.uvsq.fr (angrand.prism.uvsq.fr [193.51.25.85]) by guillotin.prism.uvsq.fr (8.7.5/jtpda-5.2) with ESMTP id SAA10126 ; Fri, 12 Jul 1996 18:43:36 +0200 (MET DST) Received: from (son@localhost) by angrand.prism.uvsq.fr (8.7.5/jtpda-5.2) id TAA00314 ; Fri, 12 Jul 1996 19:46:20 +0200 (MET DST) Date: Fri, 12 Jul 1996 19:46:20 +0200 (MET DST) Message-Id: <199607121746.TAA00314@angrand.prism.uvsq.fr> From: Nicolas Souchu To: "Justin T. Gibbs" CC: freebsd-scsi@freebsd.org Subject: Re: TRY_AGAIN_LATER return value In-Reply-To: <199607121602.JAA21617@freefall.freebsd.org> References: <199607121351.PAA00186@angrand.prism.uvsq.fr> <199607121602.JAA21617@freefall.freebsd.org> Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Thanks for your reply. > HAD_ERROR has been removed. You should return COMPLETE with a valid error > in the scsi_xfer structure. We were already advised of this by scsi_base.c comments. I'll consider it. > > XS_BUSY means the target returned BUSY status, not that the driver is busy. > (Hmmm... This should probably be determined by the upper level > SCSI layer by looking at the status byte. Perhaps XS_BUSY can go > away too.) I don't feel the difference... you mean, a request for a busy device may be queued by the driver which isn't busy then ? This means the top SCSI layer expects the scsi_done() call but "after a moment" ? > I'll be sure to look into the deadlock you're seeing, but it sounds like > you are using the return codes in a very different way. You should ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is surely the source of my bugs. > not be returning to the scsi system unless the buffer is filled or the > drive has reported an error. ... More precisely, my driver polls the parallel port. When data are not available, instead of doing an active wait on the port, I want to schedule the process (tsleep() seems to be easier than timeout()). Thus, I must care no other process will access the driver while the process of the current request is asleep or timedout. Then, the BUGGY source code of my scsi_cmd () was something like that: (as it is in /sys/i386/isa/wd7000.c of the 2.1.0-RELEASE) if (device->flags & IN_USE) { XS_ERROR = XS_DRIVER_STUFFUP; return HAD_ERROR; } else device->flags |= IN_USE; I replaced it by the following code, which is *probably* a fix: -- I not sure yet :^( -- if (device->flags & IN_USE) { XS_ERROR = XS_TIMEOUT; return HAD_ERROR; } else device->flags |= IN_USE; > Are you not able to sleep waiting for these resources as all the other > driver do? Something like ... ? splbio(); while (device->flags & IN_USE) { tsleep (PRIBIO); } device->flags |= IN_USE; splx(); nicolas -- Nicolas.Souchu@prism.uvsq.fr Laboratoire PRiSM - Versailles, FRANCE From owner-freebsd-scsi Fri Jul 12 11:01:50 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA01311 for freebsd-scsi-outgoing; Fri, 12 Jul 1996 11:01:50 -0700 (PDT) Received: from webster.telebit.com (webster.telebit.com [143.191.3.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA01301; Fri, 12 Jul 1996 11:01:47 -0700 (PDT) Received: from Chelmsford.Telebit.COM (sharps.chelmsford.telebit.com) by webster.telebit.com (4.1/SMI-4.1/Telebit.COM-Sendmail-V4.3) id AA28340 to freebsd-scsi@freebsd.org; Fri, 12 Jul 96 14:00:42 EDT Received: from smtpgate.chelmsford.telebit.com by Chelmsford.Telebit.COM (4.1/SMI-4.1-pmm-2) id AA01787; Fri, 12 Jul 96 14:00:44 EDT Received: from ccMail by smtpgate.chelmsford.telebit.com (SMTPLINK V2.10.05) id AA837205829; Fri, 12 Jul 96 13:58:19 EST Date: Fri, 12 Jul 96 13:58:19 EST From: "Nathan Melhorn" Message-Id: <9606128372.AA837205829@smtpgate.chelmsford.telebit.com> To: freebsd-scsi@freebsd.org, freebsd-questions@freebsd.org, Stephen Couchman Subject: Re: Jaz drive questions Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ====== Message from Stephen Couchman 96.07.11 22:40 ====== I have installed a Jaz drive as sd1 (SCSI id #2). I am using an Adaptec 2940 Ultra SCSI host adapter. FreeBSD does not seem to recognize the drive and produces the following messages: (ahc0:2:0): "iomega jaz 1GB G.60" type 0 removable SCSI 2 sd1(ahc0:2:0): Direct-Access sd1(ahc0:2:0): ILLEGAL REQUEST asc:24,0 Invalid field in CDB sd1 could not mode sense (4). Using ficticious geometry 1021MB (2091050 512 byte sectors) =========================================================== I just installed an IOMega parallel port Zip drive into my kernel. It's not part of FreeBSD, I just found the PPA-3 driver on someone's web page (Nicolas.Souchu@prism.uvsq.fr) -- who can't actively support it at this time. The instructions said that I'd get messages about ficticious geometry, since it "can't be sensed". I can still mount_msdos the drive on the 4th slice of the drive (sd0s4) with a working DOS ZipDisk and see the contents. The instructions said to fdisk-examine the drive to confirm which was the proper slice. I don't know about your other problems, since I'm new to FreeBSD and still fooling around with the ZipDrive. Currently the probe at boot time takes 2 minutes! I also haven't yet tried formatting it as a Unix disk. -regards, Nate Melhorn (n_melhor@chelmsford.telebit.com) From owner-freebsd-scsi Fri Jul 12 12:56:12 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA11560 for freebsd-scsi-outgoing; Fri, 12 Jul 1996 12:56:12 -0700 (PDT) Received: from freefall.freebsd.org (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA11552; Fri, 12 Jul 1996 12:56:10 -0700 (PDT) Message-Id: <199607121956.MAA11552@freefall.freebsd.org> To: Nicolas Souchu cc: freebsd-scsi@freebsd.org Subject: Re: TRY_AGAIN_LATER return value In-reply-to: Your message of "Fri, 12 Jul 1996 19:46:20 +0200." <199607121746.TAA00314@angrand.prism.uvsq.fr> Date: Fri, 12 Jul 1996 12:56:09 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Thanks for your reply. > > > HAD_ERROR has been removed. You should return COMPLETE with a valid error > > in the scsi_xfer structure. > >We were already advised of this by scsi_base.c comments. I'll consider >it. It won't exist after I check in, so you should do more than consider it. B-) > > XS_BUSY means the target returned BUSY status, not that the driver is busy. > > (Hmmm... This should probably be determined by the upper level > > SCSI layer by looking at the status byte. Perhaps XS_BUSY can go > > away too.) > >I don't feel the difference... you mean, a request for a busy device >may be queued by the driver which isn't busy then ? This means the >top SCSI layer expects the scsi_done() call but "after a moment" ? XS_BUSY means that the device returned BUSY status during the status phase on the SCSI bus. If you cannot handle more than one request at a time per device, you should set the number of openings in the scsi_link template accordingly. If your queue is full, the upper level SCSI code should know this by openings going to zero. XS_BUSY has a limited number of retries. A driver queue full error should retry once the queue is no longer full. > > I'll be sure to look into the deadlock you're seeing, but it sounds like > > you are using the return codes in a very different way. You should > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >This is surely the source of my bugs. > > > not be returning to the scsi system unless the buffer is filled or the > > drive has reported an error. >... > >More precisely, my driver polls the parallel port. When data are not >available, instead of doing an active wait on the port, I want to >schedule the process (tsleep() seems to be easier than timeout()). You should use timeout() because you may not have a valid process context when your driver is called. >Thus, I must care no other process will access the driver while the >process of the current request is asleep or timedout. Then openings (opennings in the current source) should be preset to 1 so that your driver will never get re-entered. >Then, the BUGGY source code of my scsi_cmd () was something like that: >(as it is in /sys/i386/isa/wd7000.c of the 2.1.0-RELEASE) > >if (device->flags & IN_USE) { > XS_ERROR = XS_DRIVER_STUFFUP; > return HAD_ERROR; >} else > device->flags |= IN_USE; If openings is set correctly, you should be able to turn this into a panic as it should never occur. >I replaced it by the following code, which is *probably* a fix: >-- I not sure yet :^( -- > >if (device->flags & IN_USE) { > XS_ERROR = XS_TIMEOUT; > return HAD_ERROR; >} else > device->flags |= IN_USE; If you don't take it before the number of allowed retries are attempted, the command will fail. > > Are you not able to sleep waiting for these resources as all the other > > driver do? > >Something like ... ? > >splbio(); >while (device->flags & IN_USE) { > tsleep (PRIBIO); >} >device->flags |= IN_USE; >splx(); You shouldn't even need to sleep like this. Return successfully queued to the SCSI code and the process will sleep on the buffer. Schedule a timeout to poll the parallel port and when you return complete, the process will get woken up. > > >nicolas > >-- >Nicolas.Souchu@prism.uvsq.fr >Laboratoire PRiSM - Versailles, FRANCE > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Fri Jul 12 13:40:52 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA14843 for freebsd-scsi-outgoing; Fri, 12 Jul 1996 13:40:52 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA14811 for ; Fri, 12 Jul 1996 13:40:33 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA10152 for ; Fri, 12 Jul 1996 22:40:11 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA03338 for freebsd-scsi@freebsd.org; Fri, 12 Jul 1996 22:40:11 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id WAA20241 for freebsd-scsi@freebsd.org; Fri, 12 Jul 1996 22:33:22 +0200 (MET DST) From: J Wunsch Message-Id: <199607122033.WAA20241@uriah.heep.sax.de> Subject: Re: Conner going bad. To: freebsd-scsi@freebsd.org Date: Fri, 12 Jul 1996 22:33:22 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from John-Mark Gurney at "Jul 12, 96 02:20:35 am" 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 X-Mailer: ELM [version 2.4ME+ PL17 (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 As John-Mark Gurney wrote: > > It's a bad sector. Do you have automatic bad sector remapping enabled? > if you enable it do you need to reformat the drive? No, you don't. -- 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 Sat Jul 13 01:18:26 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA20441 for freebsd-scsi-outgoing; Sat, 13 Jul 1996 01:18:26 -0700 (PDT) Received: from relay7.UU.NET (relay7.UU.NET [192.48.96.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA20431 for ; Sat, 13 Jul 1996 01:18:23 -0700 (PDT) From: tedm@agora.rdrop.com Received: from agora.rdrop.com by relay7.UU.NET with SMTP (peer crosschecked as: firewall-eu.symantec.com [204.203.80.4]) id QQaydt27668; Sat, 13 Jul 1996 04:18:11 -0400 (EDT) Received: by agora.rdrop.com (IBM OS/2 SENDMAIL VERSION 1.3.6)/(3.0sos) id AA0041; Sat, 13 Jul 96 01:18:53 GMT Date: Sat, 13 Jul 96 01:18:53 GMT Message-Id: <9607130118.AA0041@agora.rdrop.com> To: joerg_wunsch@uriah.heep.sax.de, freebsd-scsi@freebsd.org Subject: Re: 2.1 RELEASE, Adaptec 1542CP and Toshiba CDROM stat33 error at boot Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk j@uriah.heep.sax.de (J Wunsch) writes: >james@socrates.demon.co.uk (James M. Bridson) wrote: > >> I recently managed to destroy my aged 1542B and the closest >> replacement I could get at the time was a new 1542CP. Since >> the board swap FreeBSD 2.1 RELEASE does not recognise the >> Toshiba CDROM drive. At boot I get the message aha0:target_stat33 >> at the point where the probe used to find the CDROM drive (at >> SCSI id 5). All the hard disks are still found OK. I have >> device cd in my config file and have rebuilt the kernel just >> in case something got corrupted but it is 100% reproduceable. >> It did work with the 1542B and same kernel config. > >Remember: FreeBSD is not supported in Usenet. > >I've just verified in the logs, FreeBSD 2.1R is supposed to handle the >`CP' correctly. So please, either ask your question at >freebsd-scsi@freebsd.org, or submit a problem report for it (send-pr). > >-- >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. ;-) > I answered him via email and he responded with it fixed. Disabling synchronous negotiation got the CD running again. Obviously a firmware change in the 1540CP didn't go down well with the Toshiba. I didn't have the heart to tell him he probably killed his disk throughput by doing so. :-) This is one of these "find another DOS/Windoze machine to `swap' the CD with" kind of answers. With 6x speed CD's going for $70 it isin't worth attempting to get a new ROM chip for an old CD from the manufacturer. (assuming they even bothered to fix their firmware to begin with) I don't know if the 1540C supports firmware upgrades, if it had flash on it that might be another route. Ted From owner-freebsd-scsi Sat Jul 13 02:11:08 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA25326 for freebsd-scsi-outgoing; Sat, 13 Jul 1996 02:11:08 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA25296 for ; Sat, 13 Jul 1996 02:10:57 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id LAA26061; Sat, 13 Jul 1996 11:10:03 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id LAA10256; Sat, 13 Jul 1996 11:10:02 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id KAA23177; Sat, 13 Jul 1996 10:52:32 +0200 (MET DST) From: J Wunsch Message-Id: <199607130852.KAA23177@uriah.heep.sax.de> Subject: Re: CD RRE To: freebsd-scsi@freebsd.org Date: Sat, 13 Jul 1996 10:52:32 +0200 (MET DST) Cc: jbh@labyrinth.net.au, robsch@robkaos.ruhr.de (Robert Schien) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from Robert Schien at "Jul 12, 96 05:27:39 pm" 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 X-Mailer: ELM [version 2.4ME+ PL17 (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 As Robert Schien wrote: > I use 'mkisofs' (it comes with FreeBSD) to create a CD image. 'mkisofs' has > several options, one is to use RRE. Look at the man page. > > The actual burning is done with 'wormcontrol'. Again see the man page. Jordan also checked in his scripts under /usr/share/examples recently. You might wanna have a look at them. > BTW, the CD burner support appeared after the 2.1.0-RELEASE. That's only partially correct. Of course, if you define `after' as being `at any time after' -- you're right. If you define it as `soon after', you're wrong. The worm driver has been created by Peter Dufault first, without ever seeing such a device before. This one was shipping with 2.1R, but it could only serve as a base for experiments. Once i've got my fingers on the first CD-R i've ever seen, a Yamaha CDR-100, i noticed that we need some sort of ``SCSI type override'', where you could assign a device lying about its identity to another driver. Many CD-R devices sometimes or always claim to be a CD-ROM, but we need to assign them to the WORM driver. This was the hour when i've been importing the changes for the type override into the *2.2* branch. Later on, i've got my current Plasmon CD-R. The machine was still running 2.1 (or perhaps even 2.0.5, i don't remember exactly) by that time, but with my type override modifications. After getting the SCSI reference manual for the Plasmon (and experimenting with some userland proof-of-example code using scsi(8)), i finally designed a scheme to hook up subdrivers for different CD-R models into the driver, and wrote the missing pieces of the worm(4) driver. I retrofitted them into 2.2-current in order to commit them to the tree. Once this worked reasonably well, i decided to no longer maintain two version of the driver (one locally on my 2.1 machine, one for the -current sources), but upgraded my machine at work to some relatively stable -current system around January 1996. From this on, the worm driver has only been maintained in the 2.2 branch (but didn't experience major changes anyway). A couple of weeks ago, when it came to the point to decide about its destiny for 2.1.5, i've been faced with two options: either remove the (defunct) old worm driver, or upgrade it to almost-2.2-current. I picked the latter route, but without the SCSI type override changes, since these would have affected the entire SCSI subsystem. So 2.1.5 will ship with a worm driver that is functional but will probably only work with Plasmon devices, since at least all the HP burners will be assigned to the `cd' driver. -- 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 Sat Jul 13 02:11:15 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA25353 for freebsd-scsi-outgoing; Sat, 13 Jul 1996 02:11:15 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA25318 for ; Sat, 13 Jul 1996 02:11:06 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id LAA26076; Sat, 13 Jul 1996 11:10:24 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id LAA10259; Sat, 13 Jul 1996 11:10:24 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id KAA23086; Sat, 13 Jul 1996 10:36:02 +0200 (MET DST) From: J Wunsch Message-Id: <199607130836.KAA23086@uriah.heep.sax.de> Subject: Re: tandberg scsi tape + FreeBSD 2.1/2.0.5 To: freebsd-scsi@freebsd.org Date: Sat, 13 Jul 1996 10:36:01 +0200 (MET DST) Cc: jbh@labyrinth.net.au (John Hartley) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199607121020.UAA07480@minotaur.labyrinth.net.au> from John Hartley at "Jul 12, 96 08:20:03 pm" 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 X-Mailer: ELM [version 2.4ME+ PL17 (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 As John Hartley wrote: > I tried this, doing a boot with no tape in the drive then: > > mt fsr > (reports the ussual error ILLEGAL REQUEST csi:0,8,0,0 .... > however the tape drive itself did some whirrringgg) Hmpf. I hoped this would not require a mode page setting yet. Anyone else out there having an idea? Julian? Peter? Well, you could give this a try: Index: sys/scsi/st.c =================================================================== RCS file: /home/ncvs/src/sys/scsi/st.c,v retrieving revision 1.36.4.5 diff -u -u -r1.36.4.5 st.c --- st.c 1996/06/25 17:45:58 1.36.4.5 +++ st.c 1996/07/13 08:33:34 @@ -113,6 +113,15 @@ {0, 0, QIC_120} /* minor 12,13,14,15 */ } }, + {"Tandberg tdc4100", "TANDBERG", " TDC 4100", "????", + ST_Q_NEEDS_PAGE_0|ST_Q_SNS_HLP, + { + {0, 0, 0}, /* minor 0,1,2,3 */ + {0, ST_Q_FORCE_VAR_MODE, QIC_525}, /* minor 4,5,6,7 */ + {0, 0, QIC_150}, /* minor 8,9,10,11 */ + {0, 0, QIC_120} /* minor 12,13,14,15 */ + } + }, {"Rev 5 of the Archive 2525", "ARCHIVE ", "VIPER 2525 25462", "-005", 0, { This is really stepping in the dark, but i know that my TDC4222 requires ST_Q_SNS_HLP, and i believe the NEEDS_PAGE_0 wouldn't hurt to the least. -- 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 Sat Jul 13 09:48:51 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA23651 for freebsd-scsi-outgoing; Sat, 13 Jul 1996 09:48:51 -0700 (PDT) Received: from robkaos.ruhr.de (robkaos.ruhr.de [193.100.180.87]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA23612 for ; Sat, 13 Jul 1996 09:48:47 -0700 (PDT) Received: by robkaos.ruhr.de (/\oo/\ Smail3.1.29.1 #29.1) id ; Sat, 13 Jul 96 18:46 MET DST Message-Id: From: robsch@robkaos.ruhr.de (Robert Schien) Subject: Re: CD RRE To: joerg_wunsch@uriah.heep.sax.de Date: Sat, 13 Jul 1996 18:46:22 +0200 (MET DST) Cc: freebsd-scsi@freebsd.org In-Reply-To: <199607130852.KAA23177@uriah.heep.sax.de> from "J Wunsch" at Jul 13, 96 10:52:32 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > As Robert Schien wrote: > > > BTW, the CD burner support appeared after the 2.1.0-RELEASE. > > That's only partially correct. Of course, if you define `after' as > being `at any time after' -- you're right. If you define it as `soon > after', you're wrong. > I defined it 'at any time after'. So I am right :-) > > A couple of weeks ago, when it came to the point to decide about its > destiny for 2.1.5, i've been faced with two options: either remove the > (defunct) old worm driver, or upgrade it to almost-2.2-current. I > picked the latter route, but without the SCSI type override changes, > since these would have affected the entire SCSI subsystem. So 2.1.5 > will ship with a worm driver that is functional but will probably only > work with Plasmon devices, since at least all the HP burners will be > assigned to the `cd' driver. That's rather pity. I thought I could use my HP burner with 2.1.5-RELEASE when it will be out. : -( Robert From owner-freebsd-scsi Sat Jul 13 12:22:31 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA05547 for freebsd-scsi-outgoing; Sat, 13 Jul 1996 12:22:31 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA05542 for ; Sat, 13 Jul 1996 12:22:26 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id VAA07341; Sat, 13 Jul 1996 21:22:13 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id VAA15592; Sat, 13 Jul 1996 21:22:13 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id VAA01719; Sat, 13 Jul 1996 21:14:25 +0200 (MET DST) From: J Wunsch Message-Id: <199607131914.VAA01719@uriah.heep.sax.de> Subject: Re: CD RRE To: freebsd-scsi@freebsd.org Date: Sat, 13 Jul 1996 21:14:25 +0200 (MET DST) Cc: robsch@robkaos.ruhr.de (Robert Schien) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from Robert Schien at "Jul 13, 96 06:46:22 pm" 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 X-Mailer: ELM [version 2.4ME+ PL17 (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 As Robert Schien wrote: > > So 2.1.5 > > will ship with a worm driver that is functional but will probably only > > work with Plasmon devices, since at least all the HP burners will be > > assigned to the `cd' driver. > > That's rather pity. I thought I could use my HP burner with 2.1.5-RELEASE > when it will be out. : -( Complain at HP. It's not truely understandable why they claim their device to be a CD-ROM. (However, the SCSI-2 WORM devices have been invented for something else than what they happen to be these days.) I'm afraid more people will ask for this. So without any guarantees, this is the patch that would bring the ``SCSI type override'' code into -stable/2.1.5 (pruned off any cosmetic changes): Index: sys/scsi/scsiconf.c =================================================================== RCS file: /home/ncvs/src/sys/scsi/scsiconf.c,v retrieving revision 1.30.4.9 diff -u -u -r1.30.4.9 scsiconf.c --- scsiconf.c 1996/06/28 16:59:47 1.30.4.9 +++ scsiconf.c 1996/07/13 19:09:43 @@ -150,6 +156,9 @@ */ struct scsidevs { u_int32_t type; +#ifdef NEW_SCSICONF + u_int32 driver; /* normally the same as type */ +#endif boolean removable; char *manufacturer; char *model; @@ -166,11 +175,19 @@ #define SC_ONE_LU 0x00 #define SC_MORE_LUS 0x02 +#ifdef NEW_SCSICONF +static struct scsidevs unknowndev = + { + T_UNKNOWN, T_UNKNOWN, 0, "*", "*", "*", + "uk", SC_MORE_LUS + }; +#else /* !NEW_SCSICONF */ static struct scsidevs unknowndev = { T_UNKNOWN, 0, "*", "*", "*", "uk", SC_MORE_LUS }; +#endif /* NEW_SCSICONF */ #ifdef NEW_SCSICONF static st_modes mode_tandberg3600 = @@ -223,101 +240,103 @@ /* od's must be probed before sd's since some of them identify as T_DIRECT */ #if NOD > 0 { - T_OPTICAL, T_REMOV, "MATSHITA", "PD-1 LF-1000", "*", + T_OPTICAL, T_OPTICAL, T_REMOV, "MATSHITA", "PD-1 LF-1000", "*", "od", SC_MORE_LUS }, - /* - * The SONY SMO is not really supported here, since it - * identifies as T_DIRECT, and thus doesn't get assigned - * to the od driver. - * You need to upgrade to the FreeBSD 2.2 line for this. - */ { - T_OPTICAL, T_REMOV, "SONY", "SMO-*", "*", + T_DIRECT, T_OPTICAL, T_REMOV, "SONY", "SMO-*", "*", "od", SC_MORE_LUS }, { - T_OPTICAL, T_REMOV, "*", "*", "*", + T_OPTICAL, T_OPTICAL, T_REMOV, "*", "*", "*", "od", SC_ONE_LU }, #endif /* NOD */ #if NSD > 0 { - T_DIRECT, T_FIXED, "MAXTOR", "XT-4170S", "B5A", + T_DIRECT, T_DIRECT, T_FIXED, "MAXTOR", "XT-4170S", "B5A", "mx1", SC_ONE_LU }, { - T_DIRECT, T_FIXED, "EMULEX", "MD21*" , "*", + T_DIRECT, T_DIRECT, T_FIXED, "EMULEX", "MD21*" , "*", "sd", SC_MORE_LUS }, { - T_DIRECT, T_FIXED, "*", "*", "*", + T_DIRECT, T_DIRECT, T_FIXED, "*", "*", "*", "sd", SC_ONE_LU }, #endif /* NSD */ #if NST > 0 { - T_SEQUENTIAL, T_REMOV, "TANDBERG", " TDC 3600", "*", + T_SEQUENTIAL, T_SEQUENTIAL, T_REMOV, "TANDBERG", " TDC 3600", "*", "st", SC_ONE_LU, ST_Q_NEEDS_PAGE_0, mode_tandberg3600 }, { - T_SEQUENTIAL, T_REMOV, "ARCHIVE", "VIPER 2525*", "-005", + T_SEQUENTIAL, T_SEQUENTIAL, T_REMOV, "ARCHIVE", "VIPER 2525*", "-005", "st", SC_ONE_LU, 0, mode_archive2525 }, { - T_SEQUENTIAL, T_REMOV, "ARCHIVE", "VIPER 150", "*", + T_SEQUENTIAL, T_SEQUENTIAL, T_REMOV, "ARCHIVE", "VIPER 150", "*", "st", SC_ONE_LU, ST_Q_NEEDS_PAGE_0, mode_archive150 }, { - T_SEQUENTIAL, T_REMOV, "WANGTEK", "5525ES*", "*", + T_SEQUENTIAL, T_SEQUENTIAL, T_REMOV, "WANGTEK", "5525ES*", "*", "st", SC_ONE_LU, 0, mode_wangtek5525 }, { - T_SEQUENTIAL, T_REMOV, "WangDAT", "Model 1300", "*", + T_SEQUENTIAL, T_SEQUENTIAL, T_REMOV, "WangDAT", "Model 1300", "*", "st", SC_ONE_LU, 0, mode_wangdat1300 }, { - T_SEQUENTIAL, T_REMOV, "*", "*", "*", + T_SEQUENTIAL, T_SEQUENTIAL, T_REMOV, "*", "*", "*", "st", SC_ONE_LU, 0, mode_unktape }, #endif /* NST */ #if NCH > 0 { - T_CHANGER, T_REMOV, "*", "*", "*", + T_CHANGER, T_CHANGER, T_REMOV, "*", "*", "*", "ch", SC_ONE_LU }, #endif /* NCH */ #if NCD > 0 #ifndef UKTEST /* make cdroms unrecognised to test the uk driver */ { - T_READONLY, T_REMOV, "SONY", "CD-ROM CDU-8012", "3.1a", + T_READONLY, T_READONLY, T_REMOV, "SONY", "CD-ROM CDU-8012", "3.1a", "cd", SC_ONE_LU }, { - T_READONLY, T_REMOV, "PIONEER", "CD-ROM DRM-600", "*", + T_READONLY, T_READONLY, T_REMOV, "PIONEER", "CD-ROM DRM-600", "*", "cd", SC_MORE_LUS }, { - T_READONLY, T_REMOV, "PIONEER", "CD-ROM DRM-602X" ,"*", + T_READONLY, T_READONLY, T_REMOV, "PIONEER", "CD-ROM DRM-602X" ,"*", "cd", SC_MORE_LUS }, { - T_READONLY, T_REMOV, "NRC", "MBR-7", "*", + T_READONLY, T_READONLY, T_REMOV, "NRC", "MBR-7", "*", "cd", SC_MORE_LUS }, { - T_READONLY, T_REMOV, "CHINON", "CD-ROM CDS-535","*", + T_READONLY, T_READONLY, T_REMOV, "CHINON", "CD-ROM CDS-535","*", "cd", SC_ONE_LU }, #endif /* !UKTEST */ #endif /* NCD */ #if NWORM > 0 { - T_WORM, T_REMOV, "YAMAHA", "CDR100", "*", + T_WORM, T_WORM, T_REMOV, "YAMAHA", "CDR100", "*", "worm", SC_ONE_LU }, { - T_WORM, T_REMOV, "*", "*", "*", + T_READONLY, T_WORM, T_REMOV, "HP", "C4324/C4325", "*", + "worm", SC_ONE_LU + }, + { + T_READONLY, T_WORM, T_REMOV, "PLASMON", "RF41*", "*", + "worm", SC_ONE_LU + }, + { + T_WORM, T_WORM, T_REMOV, "*", "*", "*", "worm", SC_ONE_LU }, #endif /* NWORM */ @@ -353,6 +372,16 @@ ,"B5A ", "mx1", SC_ONE_LU }, #endif /* NSD */ +#if NOD > 0 + { + T_OPTICAL, T_REMOV, "standard", "any" + ,"any", "od", SC_ONE_LU + }, + { + T_OPTICAL, T_REMOV, "MATSHITA", "PD-1 LF-1000" + ,"any", "od", SC_MORE_LUS + }, +#endif /* NOD */ #if NST > 0 { T_SEQUENTIAL, T_REMOV, "standard", "any" @@ -859,7 +891,7 @@ * 2. Via the minor number. That takes precedence over the config file. */ static errval - scsi_attach_sctarg() +scsi_attach_sctarg() { struct scsi_link *sc_link = NULL; int dev_unit; @@ -1264,7 +1296,12 @@ if (bestmatch == &unknowndev) *type_p = type; else - *type_p = bestmatch->type; + *type_p = +#ifdef NEW_SCSICONF + bestmatch->driver; +#else + bestmatch->type; +#endif return bestmatch; } -- 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 Sat Jul 13 15:59:49 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA27115 for freebsd-scsi-outgoing; Sat, 13 Jul 1996 15:59:49 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA27110; Sat, 13 Jul 1996 15:59:46 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id IAA03964; Sun, 14 Jul 1996 08:45:47 +1000 Date: Sun, 14 Jul 1996 08:45:47 +1000 From: Bruce Evans Message-Id: <199607132245.IAA03964@godzilla.zeta.org.au> To: Stephen.Couchman@imagenet.on.ca, freebsd-questions@freebsd.org, freebsd-scsi@freebsd.org, n_melhor@Telebit.COM Subject: Re: Jaz drive questions Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >====== Message from Stephen Couchman 96.07.11 22:40 ====== > I have installed a Jaz drive as sd1 (SCSI id #2). I am > using an Adaptec 2940 Ultra SCSI host adapter. FreeBSD > does not seem to recognize the drive and produces the > following messages: > > (ahc0:2:0): "iomega jaz 1GB G.60" type 0 removable SCSI 2 > sd1(ahc0:2:0): Direct-Access > sd1(ahc0:2:0): ILLEGAL REQUEST asc:24,0 Invalid field in > CDB sd1 could not mode sense (4). Using ficticious > geometry 1021MB (2091050 512 byte sectors) This means that FreeBSD _did_ recognize the drive. Iomega apparently didn't bother to implement the SCSI mode sense command, so the driver can't determine anything about the number of heads or sectors/track on the disk (if any). The last line shows that it successfully determined the total number of sectors on the disk. This is sufficient for most operations (for everything except writing a partition table that can be used by the BIOS for booting). >=========================================================== >I just installed an IOMega parallel port Zip drive into my kernel. It's not >part of FreeBSD, I just found the PPA-3 driver on someone's web page >(Nicolas.Souchu@prism.uvsq.fr) -- who can't actively support it at this >time. >The instructions said that I'd get messages about ficticious geometry, >since it "can't be sensed". >I can still mount_msdos the drive on the 4th slice of the drive (sd0s4) >with a working DOS ZipDisk and see the contents. The instructions said to >fdisk-examine the drive to confirm which was the proper slice. Zip disks are sometimes (always?) preformatted with a normal DOS partition table with one partition in the 4th slot and an (empty for "blank") disks MSDOS file system in the partition. FreeBSD automatically constructs a suitable geometry by looking at the partition table. >I don't know about your other problems, since I'm new to FreeBSD and still >fooling around with the ZipDrive. Currently the probe at boot time takes 2 >minutes! I also haven't yet tried formatting it as a Unix disk. The long delay is probably for IDE drives that you don't have. Boot with -c and disable hardware that you don't have if it causes problems. Formatting as a FreeBSD file system disk is best done by leaving the preformatted partition table alone except for changing its type from MSDOS to FreeBSD. Then put a label and a file system on the partition. Bruce From owner-freebsd-scsi Sat Jul 13 22:20:46 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA09448 for freebsd-scsi-outgoing; Sat, 13 Jul 1996 22:20:46 -0700 (PDT) Received: from minotaur.labyrinth.net.au (minotaur.labyrinth.net.au [203.9.148.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA09146 for ; Sat, 13 Jul 1996 22:18:01 -0700 (PDT) Received: (from mail@localhost) by minotaur.labyrinth.net.au (8.7.2/8.7.2) id PAA17083 for ; Sun, 14 Jul 1996 15:17:33 +1000 (EST) Date: Sun, 14 Jul 1996 15:17:33 +1000 (EST) Message-Id: <199607140517.PAA17083@minotaur.labyrinth.net.au> X-Authentication-Warning: minotaur.labyrinth.net.au: mail set sender to using -f Received: from portal-as15.labyrinth.net.au(203.9.148.25) by minotaur.labyrinth.net.au via smap (V1.3) id sma017079; Sun Jul 14 15:17:28 1996 X-Sender: jbh@labyrinth.net.au (Unverified) X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: freebsd-scsi@freebsd.org From: John Hartley Subject: Re: tandberg scsi tape + FreeBSD 2.1/2.0.5 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >Hmpf. I hoped this would not require a mode page setting yet. > >Anyone else out there having an idea? Julian? Peter? > >Well, you could give this a try: > >Index: sys/scsi/st.c >=================================================================== >RCS file: /home/ncvs/src/sys/scsi/st.c,v >retrieving revision 1.36.4.5 >diff -u -u -r1.36.4.5 st.c >--- st.c 1996/06/25 17:45:58 1.36.4.5 >+++ st.c 1996/07/13 08:33:34 >@@ -113,6 +113,15 @@ > {0, 0, QIC_120} /* minor 12,13,14,15 */ > } > }, >+ {"Tandberg tdc4100", "TANDBERG", " TDC 4100", "????", >+ ST_Q_NEEDS_PAGE_0|ST_Q_SNS_HLP, >+ { >+ {0, 0, 0}, /* minor 0,1,2,3 */ >+ {0, ST_Q_FORCE_VAR_MODE, QIC_525}, /* minor 4,5,6,7 */ >+ {0, 0, QIC_150}, /* minor 8,9,10,11 */ >+ {0, 0, QIC_120} /* minor 12,13,14,15 */ >+ } >+ }, > {"Rev 5 of the Archive 2525", "ARCHIVE ", "VIPER 2525 25462", "-005", > 0, > { > >This is really stepping in the dark, but i know that my TDC4222 >requires ST_Q_SNS_HLP, and i believe the NEEDS_PAGE_0 wouldn't hurt to >the least. > >-- >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. ;-) > > J"org I added the "rouge" code as suggested and .... sorry it didn't work but thanks again for the suggestions. Here are the logs from testing with the rouge code in, the same problem still seems to be occuring. >>> Boot with rouge code >>> Jul 14 14:48:27 qwiff /kernel: Jul 14 14:48:28 qwiff /kernel: (ahc0:2:0): "TANDBERG TDC 4100 J04:" type 1 removable SCSI 2 Jul 14 14:48:28 qwiff /kernel: st0(ahc0:2:0): Sequential-Access st0: Tandberg tdc4100 is a known rogue Jul 14 14:48:28 qwiff /kernel: density code 0x0, 512-byte blocks, write-enabled >>> mt fsr <<< Jul 14 14:48:58 qwiff /kernel: st0(ahc0:2:0): ILLEGAL REQUEST csi:0,8,0,0 asc:24,0 Invalid field in CDB field replaceable unit: 2 >>> mt rewind <<< Jul 14 14:49:38 qwiff /kernel: st0(ahc0:2:0): ILLEGAL REQUEST csi:0,8,0,0 asc:24,0 Invalid field in CDB field replaceable unit: 2 >>> tar vf <<< Jul 14 14:49:54 qwiff /kernel: st0(ahc0:2:0): ILLEGAL REQUEST csi:0,8,0,0 asc:24,0 Invalid field in CDB field replaceable unit: 2 Jul 14 14:49:54 qwiff /kernel: st0: oops not queued >>> Turned on DEBUG<< >>> tar vf >>> Jul 14 14:50:55 qwiff /kernel: st0(ahc0:2:0): stclose: Closing device Jul 14 14:51:15 qwiff /kernel: st0(ahc0:2:0): scsi_cmd Jul 14 14:51:15 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 14 14:51:15 qwiff /kernel: st0(ahc0:2:0): returning Jul 14 14:51:15 qwiff /kernel: xs(0xf0859980): flg(0x60)sc_link(0xf0859780)retr(0x2)timo(0x186a0)cmd(0xf08599d8)len(0x6)dat a(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 14 14:51:15 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 14 14:51:15 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 14 14:51:15 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 14 14:51:15 qwiff /kernel: : command: 0,0,0,0,0,0-[0 bytes] Jul 14 14:51:15 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 14 14:51:15 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 14 14:51:15 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 14 14:51:15 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 14 14:51:15 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 14 14:51:16 qwiff /kernel: st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 14 14:51:16 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 14 14:51:16 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 14 14:51:16 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 14 14:51:16 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 14 14:51:16 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): mounting Jul 14 14:51:16 qwiff /kernel: st0(ahc0:2:0): scsi_cmd Jul 14 14:51:16 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 14 14:51:16 qwiff /kernel: st0(ahc0:2:0): returning Jul 14 14:51:16 qwiff /kernel: xs(0xf0b06500): flg(0x20)sc_link(0xf0859780)retr(0x4)timo(0x493e0)cmd(0xf0b06558)len(0x6)dat a(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 1b,0,0,0,1,0-[0 bytes] Jul 14 14:51:16 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 14 14:51:16 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0b07000) Jul 14 14:51:16 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 14 14:51:16 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 14 14:51:17 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 14 14:51:17 qwiff /kernel: st0(ahc0:2:0): command: 1b,0,0,0,1,0-[0 bytes] Jul 14 14:51:17 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 14 14:51:17 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 14 14:51:17 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 14 14:51:17 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 14 14:51:17 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): scsi_cmd Jul 14 14:51:17 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 14 14:51:17 qwiff /kernel: st0(ahc0:2:0): returning Jul 14 14:51:17 qwiff /kernel: xs(0xf0b06500): flg(0x60)sc_link(0xf0859780)retr(0x2)timo(0x186a0)cmd(0xf0b06558)len(0x6)dat a(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 14 14:51:17 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 14 14:51:17 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 14 14:51:17 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 14 14:51:17 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 14 14:51:18 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 14 14:51:18 qwiff /kernel: st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 14 14:51:18 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 14 14:51:18 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 14 14:51:18 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 14 14:51:18 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 14 14:51:18 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): scsi_cmd Jul 14 14:51:18 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 14 14:51:18 qwiff /kernel: st0(ahc0:2:0): returning Jul 14 14:51:18 qwiff /kernel: xs(0xf0b06500): flg(0x420)sc_link(0xf0859780)retr(0x4)timo(0x1388)cmd(0xf0b06558)len(0x6)dat a(0xf2772000)len(0x18)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 1a,0,0,0,18,0-[24 bytes] Jul 14 14:51:18 qwiff /kernel: ------------------------------ Jul 14 14:51:18 qwiff /kernel: 000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Jul 14 14:51:18 qwiff /kernel: 016: 00 00 00 00 00 00 00 00 Jul 14 14:51:18 qwiff /kernel: ------------------------------ Jul 14 14:51:18 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 14 14:51:19 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 14 14:51:19 qwiff /kernel: st0(ahc0:2:0): 24 @0xf2772000:- 0x4b000(0x18) Jul 14 14:51:19 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 14 14:51:19 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 14 14:51:19 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 14 14:51:19 qwiff /kernel: st0(ahc0:2:0): command: 1a,0,0,0,18,0-[24 bytes] Jul 14 14:51:19 qwiff /kernel: ------------------------------ Jul 14 14:51:19 qwiff /kernel: 000: 2f 25 10 08 15 00 00 00 00 00 02 00 90 0e 00 00 Jul 14 14:51:19 qwiff /kernel: 016: 14 14 00 00 e0 00 38 00 Jul 14 14:51:19 qwiff /kernel: ------------------------------ Jul 14 14:51:19 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 14 14:51:19 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 14 14:51:19 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 14 14:51:19 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 14 14:51:19 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): density code 0x15, 512-byte blocks, write-enabled, st0(ahc0:2:0): buffered Jul 14 14:51:19 qwiff /kernel: st0(ahc0:2:0): scsi_cmd Jul 14 14:51:19 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 14 14:51:20 qwiff /kernel: st0(ahc0:2:0): returning Jul 14 14:51:20 qwiff /kernel: xs(0xf0b06500): flg(0x820)sc_link(0xf0859780)retr(0x4)timo(0x1388)cmd(0xf0b06558)len(0x6)dat a(0xf2772000)len(0x18)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 15,0,0,0,18,0-[24 bytes] Jul 14 14:51:20 qwiff /kernel: ------------------------------ Jul 14 14:51:20 qwiff /kernel: 000: 00 00 10 08 00 00 00 00 00 00 04 00 90 0e 00 00 Jul 14 14:51:20 qwiff /kernel: 016: 14 14 00 00 e0 00 38 00 Jul 14 14:51:20 qwiff /kernel: ------------------------------ Jul 14 14:51:20 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 14 14:51:20 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 14 14:51:20 qwiff /kernel: st0(ahc0:2:0): 24 @0xf2772000:- 0x4b000(0x18) Jul 14 14:51:20 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 14 14:51:20 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 14 14:51:20 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 14 14:51:20 qwiff /kernel: st0(ahc0:2:0): command: 15,0,0,0,18,0-[24 bytes] Jul 14 14:51:20 qwiff /kernel: ------------------------------ Jul 14 14:51:20 qwiff /kernel: 000: 00 00 10 08 00 00 00 00 00 00 04 00 90 0e 00 00 Jul 14 14:51:20 qwiff /kernel: 016: 14 14 00 00 e0 00 38 00 Jul 14 14:51:20 qwiff /kernel: ------------------------------ Jul 14 14:51:20 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 14 14:51:20 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x1 Jul 14 14:51:21 qwiff /kernel: code70 valid0 seg0 key5 ili0 eom0 fmark0 Jul 14 14:51:21 qwiff /kernel: info: 0 0 0 0 followed by 10 extra bytes Jul 14 14:51:21 qwiff /kernel: extra: 0 8 0 0 24 0 2 0 0 0 Jul 14 14:51:21 qwiff /kernel: st0(ahc0:2:0): calling private err_handler() Jul 14 14:51:21 qwiff /kernel: st0(ahc0:2:0): private err_handler() returned -1 Jul 14 14:51:21 qwiff /kernel: st0(ahc0:2:0): ILLEGAL REQUEST csi:0,8,0,0 asc:24,0 Invalid field in CDB field replaceable unit: 2 Jul 14 14:51:21 qwiff /kernel: st0(ahc0:2:0): scsi_interpret_sense (no bp) returned 22 Jul 14 14:51:21 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 14 14:51:21 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 14 14:51:21 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): Open complete Jul 14 14:51:21 qwiff /kernel: st0(ahc0:2:0): stopen: dev=0xe00 (unit 0) result 0 Jul 14 14:51:21 qwiff /kernel: st0(ahc0:2:0): Jul 14 14:51:21 qwiff /kernel: ststrategy st0(ahc0:2:0): 10240 bytes @ blk0 Jul 14 14:51:21 qwiff /kernel: st0(ahc0:2:0): ststart st0: oops not queued Jul 14 14:51:21 qwiff /kernel: st0(ahc0:2:0): stclose: Closing device >>>> The end of command sequence <<<< Thanks again, I am going to get a copy of the SCSI specs so that I might be of more use in diagnosing the problem. Regards. John Hartley jbh@labyrinth.net.au Graphica Software Pty. Ltd.