From owner-freebsd-scsi Sun Jan 28 9:41:30 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.147.1.144]) by hub.freebsd.org (Postfix) with ESMTP id 095A137B698 for ; Sun, 28 Jan 2001 09:41:13 -0800 (PST) Received: from Doug (h00e0297028b9.ne.mediaone.net [24.168.172.99]) by chmls06.mediaone.net (8.11.1/8.11.1) with SMTP id f0SHfBK17140 for ; Sun, 28 Jan 2001 12:41:11 -0500 (EST) Message-ID: <002301c08951$be70e580$63aca818@ne.mediaone.net> From: "Doug Johnson" To: Subject: subscribe freebsd-scsi dugdish@mediaone.net Date: Sun, 28 Jan 2001 12:42:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org subscribe freebsd-scsi dugdish@mediaone.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 29 9:26:47 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from web1.renley.com (unknown [210.176.231.28]) by hub.freebsd.org (Postfix) with ESMTP id 2583B37B69B; Mon, 29 Jan 2001 09:25:30 -0800 (PST) Received: from 210.176.231.28 (unverified [203.149.188.102]) by web1.renley.com (Rockliffe SMTPRA 2.1.2) with SMTP id ; Tue, 30 Jan 2001 01:34:00 +0800 Date: Tue, 30 Jan 2001 01:34:00 +0800 Message-ID: Reply-To: l705723712@yahoo.com From: l705723712@yahoo.com To: 20guido@freebsd.org Subject:¨g¤H¸ê°T³nÅé§ó·s¸ê°T ¥»¦¸·s¼W¤@¦Ê¤T¤Q¦h¤ù¡D¡D¡D¡D¡D¡D¨g¤H¸ê°T³nÅé§ó·s¸ê°T¨g¤H¸ê°T³nÅé§ó·s¸ê°T ¥»¦¸·s¼W¤@¦Ê¤T¤Q¦h¤ù¡D¡D¡D¨g¤H¸ê°T³nÅé§ó·s¸ê°T ¥»¦¸·s¼W¤@¦Ê¤T¤Q¦h¤ù¡D¡D MIME-Version: 1.0 Content-Type: text/html; charset=big5 Content-Transfer-Encoding: base64 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org PGh0bWw+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1MYW5ndWFnZSIg Y29udGVudD0iemgtdHciPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9YmlnNSI+DQo8bWV0YSBuYW1lPSJHRU5FUkFUT1Ii IGNvbnRlbnQ9Ik1pY3Jvc29mdCBGcm9udFBhZ2UgNC4wIj4NCjxtZXRhIG5hbWU9IlByb2dJ ZCIgY29udGVudD0iRnJvbnRQYWdlLkVkaXRvci5Eb2N1bWVudCI+DQo8dGl0bGU+q2Wpubr0 r7g8L3RpdGxlPg0KPC9oZWFkPg0KDQo8Ym9keT4NCg0KPGRpdiBhbGlnbj0iY2VudGVyIj4N CiAgPGNlbnRlcj4NCiAgPHRhYmxlIGJvcmRlcj0iMSIgd2lkdGg9IjQ1MSIgaGVpZ2h0PSIx MyI+DQogICAgPHRyPg0KICAgICAgPHRkIHdpZHRoPSI0NTEiIGhlaWdodD0iMTMiIGJnY29s b3I9IiM4MDgwODAiPjxzdHJvbmc+DQogICAgICAgIDxhIGhyZWY9Imh0dHA6Ly9nby50by9j cmF6eXgxIj4NCiAgICAgICAgPGZvbnQgY29sb3I9IiNGRkZGRkYiPg0KICAgICAgICA8bWFy cXVlZSBhbGlnbj0ibWlkZGxlIiBiZWhhdmlvcj0iYWx0ZXJuYXRlIj6rZam5qGekSLjqsFSl 5qx5pKSk37r0r7g8L21hcnF1ZWU+DQogICAgICAgIDwvZm9udD4NCiAgICAgICAgPC9hPg0K ICAgICAgICA8L3N0cm9uZz48L3RkPg0KICAgIDwvdHI+DQogIDwvdGFibGU+DQogIDwvY2Vu dGVyPg0KPC9kaXY+DQo8Zm9udCBTSVpFPSIzIj4NCjxibG9ja3F1b3RlPg0KICA8YmxvY2tx dW90ZT4NCiAgICA8YmxvY2txdW90ZT4NCiAgICAgIDxwIGFsaWduPSJsZWZ0Ij48Zm9udCBj b2xvcj0iI0ZGMDAwMCI+oXWp2rW0sbWo/KF2pbuvuLBUrqe90MJJv++hQDxhIGhyZWY9Im1h aWx0bzpmcmVlYmFua25vQDEwOC56em4uY29tIj6zb7jMPC9hPjwvZm9udD48L3A+DQogICAg ICA8cCBhbGlnbj0ibGVmdCI+PGZvbnQgY29sb3I9IiNGRjAwMDAiPqW7r7imYqasqOyxeqq6 pl7C0K7JoUGlsrftusmzdKjDq0/D0qdSsKOxeqq6uOquxqFDpbuvuKjDpKO3UbN5pqi0Y6nK tGDA9KFJPC9mb250PjwvcD4NCiAgICAgIDxwIGFsaWduPSJsZWZ0Ij48Zm9udCBjb2xvcj0i I0ZGMDAwMCI+oXXEQLdOsbWo/KF2pbuvuLBUrqe90MJJv++hQDxhIGhyZWY9Im1haWx0bzpm cmVlYmFua3llc0AxMDguenpuLmNvbSI+s2+4zDwvYT48L2ZvbnQ+PC9wPg0KICAgICAgPHAg YWxpZ249ImxlZnQiPjxmb250IGNvbG9yPSIjRkYwMDAwIj6lu6+4pmKmrKjssXqquqZewtCr 4aFBpbKxTqhDprizzLdzuOqwVLBluUaxeqq6q0i9Y6FDsXqqurC3sWShQbROrE+n2q3Mqrqw XbRJoUk8L2ZvbnQ+PC9wPg0KICAgICAgPHAgYWxpZ249ImxlZnQiPjxmb250IGNvbG9yPSIj RkYwMDAwIj6hdaZzpN+vfcNhoXalu6+4q0i9Y6rMvdCvZLdOPC9mb250PjwvcD4NCiAgICAg IDxwIGFsaWduPSJsZWZ0Ij48Zm9udCBjb2xvcj0iI0ZGMDAwMCI+pnCqR7F6rE+kz6v+qKmk SKRooUG90L1UqXexeqq6uXG4o6S6s6OsT6W/qqmqurNuxemhQzwvZm9udD48L3A+DQogICAg ICA8cCBhbGlnbj0ibGVmdCI+PGZvbnQgY29sb3I9IiNGRjAwMDAiPqZwqkexeqV1rE+3Ua5p snuxeqq6pVykT6FBoXWmYbJ5rE+26qq6oXY8L2ZvbnQ+PC9wPg0KICAgICAgPHAgYWxpZ249 ImxlZnQiPjxmb250IGNvbG9yPSIjRkYwMDAwIj6mcKpHsXqsT6ZQpuaqurjcoUG0Tr3Qptum 5qtPraunYaFJPC9mb250PjwvcD4NCiAgICA8L2Jsb2NrcXVvdGU+DQogIDwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjwvZm9udD4NCjxwIGFsaWduPSJjZW50ZXIiPqFAPC9wPg0K PHAgYWxpZ249ImNlbnRlciI+PGltZyBib3JkZXI9IjAiIHNyYz0iaHR0cDovL2Z0cC53b3Js ZC5uZXQudHcvfmNvb2xidWcvMDAuanBnIiB3aWR0aD0iNjQwIiBoZWlnaHQ9IjQyMCI+PC9w Pg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4NPEhUTUw+DQo8QSBuYW1lPSINCqhnpEgNClBNIDEx OjQ2OjU4DQoyMDAxLzEvMjkNCjEwMDAwMw0KIj48L2E+DQo8L0hUTUw+DTxIVE1MPg0KPEEg bmFtZT0iDQqoZ6RIDQpQTSAxMTo0NzozMA0KMjAwMS8xLzI5DQoxMDAwMDMNCiI+PC9hPg0K PC9IVE1MPg08SFRNTD4NCjxBIG5hbWU9Ig0KqGekSA0KQU0gMTI6MTg6NTINCjIwMDEvMS8z MA0KMTAwMDAzDQoiPjwvYT4NCjwvSFRNTD4NPEhUTUw+DQo8QSBuYW1lPSINCqhnpEi46rBU s27F6afzt3O46rBUIKW7pri3c7xXpECmyqRUpFGmaKT5oUShRKFEqGekSLjqsFSzbsXpp/O3 c7jqsFQgpbumuLdzvFekQKbKpFQNCkFNIDEyOjIwOjU1DQoyMDAxLzEvMzANCjEwMDAwMw0K Ij48L2E+DQo8L0hUTUw+DTxIVE1MPg0KPEEgbmFtZT0iDQqoZ6RIuOqwVLNuxemn87dzuOqw VCClu6a4t3O8V6RApsqkVKRRpmik+aFEqGekSLjqsFSzbsXpp/MNCkFNIDEyOjIxOjA1DQoy MDAxLzEvMzANCjEwMDAwMw0KIj48L2E+DQo8L0hUTUw+DTxIVE1MPg0KPEEgbmFtZT0iDQqo Z6RIuOqwVLNuxekNCkFNIDEyOjM3OjEzDQoyMDAxLzEvMzANCjEwMDAwMw0KIj48L2E+DQo8 L0hUTUw+DTxIVE1MPg0KPEEgbmFtZT0iDQqoZ6RIuOqwVLNuxemn87dzuOqwVCClu6a4DQpB TSAxMjo1NDo0NA0KMjAwMS8xLzMwDQoxMDAwMDMNCiI+PC9hPg0KPC9IVE1MPg08SFRNTD4N CjxBIG5hbWU9Ig0KqGekSLjqsFSzbsXpp/O3c7jqsFQgpbumuLdzvFekQKbKpFSkUaZopPmh RKFEoUShRA0KQU0gMDE6MDc6MjINCjIwMDEvMS8zMA0KMTAwMDAzDQoiPjwvYT4NCjwvSFRN TD4NPEhUTUw+DQo8QSBuYW1lPSINCqhnpEi46rBUs27F6afzt3O46rBUIKW7pri3c7xXpECm yqRUpFGmaA0KQU0gMDE6MTE6NTgNCjIwMDEvMS8zMA0KMTAwMDAzDQoiPjwvYT4NCjwvSFRN TD4NPEhUTUw+DQo8QSBuYW1lPSINCqhnpEi46rBUs27F6afzt3O46rBUIKW7pri3c7xXpECm yqRUpFGmaKT5oUShRKFEDQpBTSAwMToxNDowNw0KMjAwMS8xLzMwDQoxMDAwMDMNCiI+PC9h Pg0KPC9IVE1MPg08SFRNTD4NCjxBIG5hbWU9Ig0KqGekSLjqsFSzbsXpp/O3c7jqsFQgpbum uLdzvFcNCkFNIDAxOjI2OjI1DQoyMDAxLzEvMzANCjEwMDAwMw0KIj48L2E+DQo8L0hUTUw+ DQo= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 29 10:15:25 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from h23.estsatnet (gw.estinc.com [216.216.240.51]) by hub.freebsd.org (Postfix) with ESMTP id 8B66B37B69B for ; Mon, 29 Jan 2001 10:15:07 -0800 (PST) Received: from localhost (IDENT:eric@localhost.localdomain [127.0.0.1]) by h23.estsatnet (8.9.3/8.9.3) with ESMTP id LAA27158 for ; Mon, 29 Jan 2001 11:18:00 -0700 Date: Mon, 29 Jan 2001 11:18:00 -0700 (MST) From: Eric Lee Green X-Sender: eric@h23.estsatnet To: freebsd-scsi@freebsd.org Subject: Persistent block size? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Trying to figure this one out. 'mt -f /dev/sa0.ctl' does not give the expected result ('mt' carps that it can't do it), but reading the source, it looks like it should work. Anybody know whether it's 'mt' that's busted, 'sa.c', or simply a misguided notion in my head that the .ctl device is used to set persistent parameters (i.e., parameters that last longer than a session)? At the moment I'm just saying "%#@! it", since my storage manager resets the block size anyhow within a session (so non-persistence doesn't affect my backup software anyhow)... but that doesn't solve the problem of me being curious :-}. -- Eric Lee Green eric@estinc.com Software Engineer "The BRU Guys" Enhanced Software Technologies, Inc. http://www.estinc.com/ (602) 470-1115 voice (602) 470-1116 fax To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 29 10:29:42 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 6227937B69C for ; Mon, 29 Jan 2001 10:29:25 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id KAA06634; Mon, 29 Jan 2001 10:29:19 -0800 Date: Mon, 29 Jan 2001 10:29:18 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Eric Lee Green Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Persistent block size? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 29 Jan 2001, Eric Lee Green wrote: > Trying to figure this one out. 'mt -f /dev/sa0.ctl' does not give the > expected result ('mt' carps that it can't do it), You have to be a bit more prescise than 'mt carps'. > but reading the source, > it looks like it should work. Anybody know whether it's 'mt' that's > busted, 'sa.c', or simply a misguided notion in my head that the .ctl > device is used to set persistent parameters (i.e., parameters that last > longer than a session)? Hmm??? If a tape hasn't been mounted yet, i.e. read or accessed, it's quite possible that paramaters aren't known, are they? The purpose of the .ctl device is mostly to be able to access the device when somebody has the regular device open. The man page may need updating. What do you mean by 'persistent' parameters? Held across multiple mount sessions, or permanent across reboots? > At the moment I'm just saying "%#@! it", since my storage manager resets > the block size anyhow within a session (so non-persistence doesn't affect > my backup software anyhow)... but that doesn't solve the problem of me > being curious :-}. Did you unmount the tape? That will probably clear things. Sounds like an RFE is in the works here. Jeez, between you and Jean-Francois, it looks like I'll really have to fix things I've been putting off. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 29 12:42:26 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from h23.estsatnet (gw.estinc.com [216.216.240.51]) by hub.freebsd.org (Postfix) with ESMTP id A34EE37B6A4 for ; Mon, 29 Jan 2001 12:42:06 -0800 (PST) Received: from localhost (IDENT:eric@localhost.localdomain [127.0.0.1]) by h23.estsatnet (8.9.3/8.9.3) with ESMTP id NAA29468; Mon, 29 Jan 2001 13:44:59 -0700 Date: Mon, 29 Jan 2001 13:44:59 -0700 (MST) From: Eric Lee Green X-Sender: eric@h23.estsatnet To: Matthew Jacob Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Persistent block size? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 29 Jan 2001, Matthew Jacob wrote: > On Mon, 29 Jan 2001, Eric Lee Green wrote: > > Trying to figure this one out. 'mt -f /dev/sa0.ctl' does not give the > > expected result ('mt' carps that it can't do it), > > You have to be a bit more prescise than 'mt carps'. Sorry. 'mt' reports "Invalid parameter". > > but reading the source, > > it looks like it should work. Anybody know whether it's 'mt' that's > > busted, 'sa.c', or simply a misguided notion in my head that the .ctl > > device is used to set persistent parameters (i.e., parameters that last > > longer than a session)? > > Hmm??? If a tape hasn't been mounted yet, i.e. read or accessed, it's quite > possible that paramaters aren't known, are they? Err, I was trying to set a default block size that lasted longer than a mount session. It seemed to me that it ought to be possible, but reading the 'mtio' and 'sa' documentation, it wasn't clear how. The thought in my head (obviously misguided :-) was that setting the parameter via the .ctl device would make it persist (as vs. setting it on the /dev/nsa0 device, where quite obviously it goes away until the next mount session). > The purpose of the .ctl device is mostly to be able to access the device when > somebody has the regular device open. The man page may need updating. Ah. That clarifies things. > What do you mean by 'persistent' parameters? Held across multiple mount > sessions, or permanent across reboots? Held across multiple mount sessions. Having to set the block size back to zero every time I insert a tape is a nuisance, though not a big one because I only have to do that when I'm checking the tape format of various tapes with 'mt' and 'dd' to see whether I've achieved cross-platform commonality (sigh). As mentioned before, the backup software itself handles that in actual production, so it's no biggie and doesn't affect my software. Just that I've had that ability on The OS That Shall Not Be Mentioned, and missed it on FreeBSD. > > At the moment I'm just saying "%#@! it", since my storage manager resets > > the block size anyhow within a session (so non-persistence doesn't affect > > my backup software anyhow)... but that doesn't solve the problem of me > > being curious :-}. > > Did you unmount the tape? That will probably clear things. ??? (Puzzled). > Sounds like an RFE is in the works here. Jeez, between you and Jean-Francois, > it looks like I'll really have to fix things I've been putting off. Well, I can think of several things I'd put into an RFE, such as cross-session-persistent default parameters, but right now I'm too busy thinking gloomily about Solaris. (Their tape ioctl is totally worthless for our purposes, meaning that we had to basically write a new tape driver that issues raw SCSI commands for reading and writing data on tape... how the BLEEP these guys got to be #1 in front of people like SGI that have a sane OS baffles me). -- Eric Lee Green eric@estinc.com Software Engineer "The BRU Guys" Enhanced Software Technologies, Inc. http://www.estinc.com/ (602) 470-1115 voice (602) 470-1116 fax To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 29 15:15:53 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from dt051n37.san.rr.com (dt051n37.san.rr.com [204.210.32.55]) by hub.freebsd.org (Postfix) with ESMTP id 565E437B404 for ; Mon, 29 Jan 2001 15:15:35 -0800 (PST) Received: from slave (Studded@slave [10.0.0.1]) by dt051n37.san.rr.com (8.9.3/8.9.3) with ESMTP id PAA85959; Mon, 29 Jan 2001 15:15:19 -0800 (PST) (envelope-from DougB@gorean.org) Date: Mon, 29 Jan 2001 15:15:18 -0800 (PST) From: Doug Barton X-X-Sender: To: "David W. Chapman Jr." Cc: , Subject: Re: scsi Zip disk In-Reply-To: <017901c08748$08359be0$931576d8@inethouston.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 25 Jan 2001, David W. Chapman Jr. wrote: > I believe there is an adapter, but I'd wait for someone who knows a little > more about scsi to answer that. Yes, you can get adapters and/or cables that do this translation. Mine cost about $35. You can always go from more to less, you can't go the other way. Doug > ----- Original Message ----- > From: "greg simonoff" > To: > Sent: Thursday, January 25, 2001 8:35 PM > Subject: scsi Zip disk > > > > Hi, > > Got a 100Meg IOMEGA SCSI Zip drive > > and I want to attach it to my FreeBSD system. > > My SCSI card has an external scsi III > > connector ( 68pin ) and the zip drive has > > what looks like a DB25 connector - are > > there adaptors available to connec the > > 25pin cable to the 68pin scsi card??? > > > > > > GREG > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > -- "Pain heals. Chicks dig scars. Glory . . . lasts forever." -- Keanu Reeves as Shane Falco in "The Replacements" Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 29 15:56:51 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 5EF2A37B6A1 for ; Mon, 29 Jan 2001 15:56:32 -0800 (PST) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id PAA08096; Mon, 29 Jan 2001 15:56:26 -0800 Date: Mon, 29 Jan 2001 15:56:26 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Eric Lee Green Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Persistent block size? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 29 Jan 2001, Eric Lee Green wrote: > On Mon, 29 Jan 2001, Matthew Jacob wrote: > > On Mon, 29 Jan 2001, Eric Lee Green wrote: > > > Trying to figure this one out. 'mt -f /dev/sa0.ctl' does not give the > > > expected result ('mt' carps that it can't do it), > > > > You have to be a bit more prescise than 'mt carps'. > > Sorry. 'mt' reports "Invalid parameter". More details than this (like, the command line you're using) > > > > but reading the source, > > > it looks like it should work. Anybody know whether it's 'mt' that's > > > busted, 'sa.c', or simply a misguided notion in my head that the .ctl > > > device is used to set persistent parameters (i.e., parameters that last > > > longer than a session)? > > > > Hmm??? If a tape hasn't been mounted yet, i.e. read or accessed, it's quite > > possible that paramaters aren't known, are they? > > Err, I was trying to set a default block size that lasted longer than a > mount session. It seemed to me that it ought to be possible, but reading > the 'mtio' and 'sa' documentation, it wasn't clear how. The thought in my > head (obviously misguided :-) was that setting the parameter via the .ctl > device would make it persist (as vs. setting it on the /dev/nsa0 device, > where quite obviously it goes away until the next mount session). > > > The purpose of the .ctl device is mostly to be able to access the device when > > somebody has the regular device open. The man page may need updating. > > Ah. That clarifies things. > > > What do you mean by 'persistent' parameters? Held across multiple mount > > sessions, or permanent across reboots? > > Held across multiple mount sessions. Having to set the block size back to > zero every time I insert a tape is a nuisance, though not a big one > because I only have to do that when I'm checking the tape format of > various tapes with 'mt' and 'dd' to see whether I've achieved > cross-platform commonality (sigh). As mentioned before, the backup > software itself handles that in actual production, so it's no biggie and > doesn't affect my software. Just that I've had that ability on The OS > That Shall Not Be Mentioned, and missed it on FreeBSD. Hmm. > > > > At the moment I'm just saying "%#@! it", since my storage manager resets > > > the block size anyhow within a session (so non-persistence doesn't affect > > > my backup software anyhow)... but that doesn't solve the problem of me > > > being curious :-}. > > > > Did you unmount the tape? That will probably clear things. > > ??? (Puzzled). You said as much above. > > > > Sounds like an RFE is in the works here. Jeez, between you and Jean-Francois, > > it looks like I'll really have to fix things I've been putting off. > > Well, I can think of several things I'd put into an RFE, such as > cross-session-persistent default parameters, but right now I'm too busy > thinking gloomily about Solaris. (Their tape ioctl is totally worthless > for our purposes, meaning that we had to basically write a new tape driver > that issues raw SCSI commands for reading and writing data on tape... how > the BLEEP these guys got to be #1 in front of people like SGI that have a > sane OS baffles me). Well, I wrote the original Solaris tape driver back in 1990 or so (derived from SunOS 4.0.3c's tape driver) so you can complain to me. Hell, I might even be able find the current maintainer for you to talk directly with. You think IRIX is sane? Too much uncapped glue in your apartment, friend... -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 29 18: 7: 9 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from h23.estsatnet (gw.estinc.com [216.216.240.51]) by hub.freebsd.org (Postfix) with ESMTP id 113A537B402 for ; Mon, 29 Jan 2001 18:06:49 -0800 (PST) Received: from localhost (IDENT:eric@localhost.localdomain [127.0.0.1]) by h23.estsatnet (8.9.3/8.9.3) with ESMTP id TAA01040; Mon, 29 Jan 2001 19:08:09 -0700 Date: Mon, 29 Jan 2001 19:08:09 -0700 (MST) From: Eric Lee Green X-Sender: eric@h23.estsatnet To: Matthew Jacob Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Persistent block size? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 29 Jan 2001, Matthew Jacob wrote: > On Mon, 29 Jan 2001, Eric Lee Green wrote: > > On Mon, 29 Jan 2001, Matthew Jacob wrote: > > > On Mon, 29 Jan 2001, Eric Lee Green wrote: > > > > Trying to figure this one out. 'mt -f /dev/sa0.ctl' does not give the > > > > expected result ('mt' carps that it can't do it), > > > > > > You have to be a bit more prescise than 'mt carps'. > More details than this (like, the command line you're using) bash-2.04# mt -f /dev/sa0.ctl blocksize 0 mt: /dev/sa0.ctl: blocksize: Invalid argument > > > What do you mean by 'persistent' parameters? Held across multiple mount > > > sessions, or permanent across reboots? > > > > Held across multiple mount sessions. Having to set the block size back to > > zero every time I insert a tape is a nuisance, though not a big one > > because I only have to do that when I'm checking the tape format of > > various tapes with 'mt' and 'dd' to see whether I've achieved > > cross-platform commonality (sigh). As mentioned before, the backup > > software itself handles that in actual production, so it's no biggie and > > doesn't affect my software. Just that I've had that ability on The OS > > That Shall Not Be Mentioned, and missed it on FreeBSD. > > Hmm. > > > Sounds like an RFE is in the works here. Jeez, between you and Jean-Francois, > > > it looks like I'll really have to fix things I've been putting off. > > > > Well, I can think of several things I'd put into an RFE, such as > > cross-session-persistent default parameters, but right now I'm too busy > > thinking gloomily about Solaris. (Their tape ioctl is totally worthless > > for our purposes, meaning that we had to basically write a new tape driver > > that issues raw SCSI commands for reading and writing data on tape... how > > the BLEEP these guys got to be #1 in front of people like SGI that have a > > sane OS baffles me). > > Well, I wrote the original Solaris tape driver back in 1990 or so (derived > from SunOS 4.0.3c's tape driver) so you can complain to me. Hell, I might even > be able find the current maintainer for you to talk directly with. > > You think IRIX is sane? Too much uncapped glue in your apartment, friend... Maybe it's just that I've been doing SCSI media changer control, and IRIX comes with a generic interface to the SCSI bus to allow you to access arbitrary devices (similar to /dev/pass0 on FreeBSD), while Solaris 7 and below do not (Solaris 8 does). Interfacing with SCSI media changers is a pain in the #$%@ with Solaris because you have to load 3rd party kernel modules to do it (and even on Solaris 8 you have to configure the sgen driver to tell it what kinds of devices to map). The big problem with Solaris, though, is the inability to get a reliable block position out of the driver. That didn't matter in 1990, when few tape drives supported such functionality (the SCSI-2 standard didn't come around until, what, 1993?). But part of the reason why I'm doing what I'm doing is because I want to take advantage of all the modern functionality that has occurred *since* 1990. For example, setting up current tape backup products is a pain in the buttocks -- you have to know all about cryptic tape device node names, the difference between rewinding and non-rewinding devices, etc., as well as install specific drivers for your specific tape changer, etc. But modern SCSI tape drives and changers give an amazing amount of information via their INQUIRY and mode pages, and a modern program could (and does) do a 'camcontrol devlist' to find out how many devices there are on the SCSI bus, make sure there are enough /dev/pass devices to correspond to those, then query each of those devices on the SCSI bus via /dev/pass to see what it is and what its capabilities are. Then it could automagically set itself up (by being able to make the correspondence between /dev/nsa0 and /dev/pass3, for example). It works. I'm amazed every time I think about it. Tape backup isn't supposed to be that easy :-). I must admit that I was skeptical when Tim mentioned the notion to me, but when I sat down to implement it, it worked out really sweet (even if it WAS a pain in the %@!! to implement). And by using the serial numbers, I can even find your devices if you move them around, and make sure that your scheduled backups keep going where they're supposed to be going -- whoa, you mean adding a tape drive at ID 1 no longer means re-jiggering your whole backup script chain, it merely requires firing up the SCSI scanner again? Cool! All of this relies on functionality that did not exist in 1990. Similarly, there's lots of tape backup products that can put a file onto tape. Getting files off of tape, on the other hand, has traditionally been a slow and tedious operation. Traditionally it was a case of reading one block after the other, very very sloowly. Floppy-based tape drives didn't even have a random access 'seek' function, and until recently that was what most personal users had. But modern-day tape drives have very fast and accurate ability to seek a particular data block on tape, so that you can restore any given file without having to read through a whole tarball (or bruball, in my case) But that relies on being able to quickly and accurately be able to record where each file is on the tape as you write the tape, so that you can use that directory later to find the file when you want to restore it. MTIOCGET on Solaris is the only way to get a mt_blkno but that mt_blkno was not accurate when we tried it. The Solaris tape driver also gives no way of seeking to a particular tape block. Thus we had to discard the notion of using the provided tape driver, and wrote our own. Sucks. MTIOCKGET on IRIX will get an accurate blkno from the drive, while MTSEEK will go to a particular block on the drive. Anyhow: The net result is that, for our purposes, IRIX is much saner than Solaris for writing modern tape backup software. We can actually access the features of the drive without having to write our own SCSI tape driver. Solaris's tape driver in Solaris 8 (the only one I'm messing with) has lots of neat features for handling fibre channel subsystems, but won't access any of the advanced features of the tape drives themselves (where "advanced features" is any feature that has become common since you wrote the original back in 1990). I won't comment on other features of IRIX because all I know about IRIX is the tape subsystem (from a user perspective)... all I'll comment is that, from a tape driver perspective, IRIX makes Solaris look pathetic. Porting between Linux and FreeBSD is easy (it took me maybe 2 man-days to port BRU Professional to FreeBSD, not counting all the bugs in my networking code that were uncovered by the fact that FreeBSD works the way Unix is supposed to while Linux masks many bugs with its non-standard networking implementation). Porting between Linux, FreeBSD, and IRIX is easy -- I estimate that the IRIX port would be 2 man-days also. Solaris, on the other hand, is a pain. My existing system-dependent low-level driver module reports "Not Implemented" for large chunks of missing functionality on Solaris. This is a signal to the higher-level code to dump the notion of using the tape driver for that functionality, and instead start issuing raw SCSI commands. Note that once you start issuing raw SCSI commands, that's pretty much it -- you aren't going to use the tape driver anymore, because it gets confused (much as if you used both pass0 and /dev/sa0 on FreeBSD). Thus once the higher level system-independent code decides that the system-provided tape driver is useless, we effectively have our own tape driver on Solaris. Sorry about the long ode to IRIX. I know it's not really relevant to this list. It's just that I've been cursing tape drivers for too long (even relatively good ones like on FreeBSD and Linux occasionally raise my ire when I run into some quirk, such as the broken partition support in the Linux 'st.c' module, though since DLT/Dumb Linear Tape does not support partitions I had to dump the notion of using partitions for fast on-tape catalogs anyhow), and finding one that is actually sane is an experience akin to an angel descending from the heavens and blessing me. Besides, I'm procrastinating -- I'm supposed to be doing more work on Solaris at the moment (FreeBSD is working perfectly for QA now that I fixed all my networking bugs, so I don't have any excuse to mess w/FreeBSD anymore, alas, alak). Okay, so maybe my viewpoint is parochial. Maybe looking at systems from the viewpoint of their tape drivers isn't the best way to judge systems, but every time I compare the IRIX and Solaris tape drivers, I mutter "How did those people at Sun ever become #1 in the commercial Unix industry?". Solaris makes my life hard, IRIX makes my life easy, and (shrug) from my point of view, that's all I care about. Meanwhile, if you haven't checked out an IRIX system recently, you might want to take a look at what they've done to their tape driver. I see nothing there that really cries "this must go into FreeBSD!", since by going to /dev/passX using 'tapeinfo' I can get the same info, but they still have some pretty cool capabilities in there. -- Eric Lee Green eric@estinc.com Software Engineer "The BRU Guys" Enhanced Software Technologies, Inc. http://www.estinc.com/ (602) 470-1115 voice (602) 470-1116 fax To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jan 30 0:22:16 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from synology.com (dns1.synology.com [202.173.37.131]) by hub.freebsd.org (Postfix) with ESMTP id 1468E37B4E0 for ; Tue, 30 Jan 2001 00:21:58 -0800 (PST) Received: from derrenltest ([192.168.1.227]) by synology.com (8.9.3/8.9.3) with SMTP id QAA27338; Tue, 30 Jan 2001 16:24:01 +0800 Message-ID: <002301c08a97$3285faf0$e301a8c0@derrenltest> From: "Derren" To: "JustinT. Gibbs" Cc: "cheen" , Subject: RE: More target mode observations Date: Tue, 30 Jan 2001 16:32:32 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>Following up to myself with a bit more info, >I've been tied up with things, but I'll try to look into this tomorrow. >Target mode has worked, but I must have broken something recently. >I'm sure it won't take me long to figure out what. Thank you for your kindness for answering this question. Could you please tell me which version of FreeBSD you had successfully run the Target mode? And on what kind of chips? I think I need to reconstruct your environment to get much more information for this problem. Thanks, Derren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jan 31 0:13:39 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from clifford.inch.com (clifford.inch.com [216.223.192.27]) by hub.freebsd.org (Postfix) with ESMTP id 48F9D37B69D; Wed, 31 Jan 2001 00:13:17 -0800 (PST) Received: (from omar@localhost) by clifford.inch.com (8.9.3/8.8.5) id DAA26838; Wed, 31 Jan 2001 03:18:15 -0500 Message-ID: <20010131031815.A26661@clifford.inch.com> Date: Wed, 31 Jan 2001 03:18:15 -0500 From: Omar Thameen To: Mike Smith Cc: freebsd-hardware@freebsd.org, freebsd-scsi@freebsd.org Subject: Re: Mylex AcceleRAID 150 problems References: <20010127013545.A21945@clifford.inch.com> <200101272050.f0RKojx00993@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <200101272050.f0RKojx00993@mass.dis.org>; from Mike Smith on Sat, Jan 27, 2001 at 12:50:45PM -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Jan 27, 2001 at 12:50:45PM -0800, Mike Smith wrote: > > I have a Mylex AcceleRAID 150 running in a 4.2-RELEASE server and I've > > run into a couple problems and need some advice. > > Yes. The card requires 40-bit memory (byte-ECC), and Mylex' pricing is > actually fairly reasonable. However, adding more memory won't do you a > lot of good - the card has no battery backup, so you can't use it as > write cache, and the OS already read-caches better than the card does. That solves that problem/question, then, thanks. I've sent the memory back. > > Second, about 3 out of 5 times, the system fails to boot. It gets to the > > "press enter to boot [kernel]..." phase, then shows me the slash ( / ), > > then hangs, again rendering the power toggle functionless, but not the > > reset switch. I've checked the motherboard and mobo BIOS, and swapped > > out the RAM, eliminating those as problems. > > This one's beyond me; if it's intermittent and you can't find *any* > correspondence between any external factor and the failures, then I'd be > getting pretty desperate. Does the card work OK once the system is up > and running? Yes, it does. I've been able to proceed with server installation and configuration with no problems, even running a "make buildworld" as a test (probably of the SDRAM more than anything). The only thing I'm not sure about is whether this is the response I'm supposed to be getting: # mlxcontrol status -v mlxd0 mlxcontrol: couldn't get controller/drive for /dev/mlxd0 mlxd0: online > I'm afraid I don't have a lot here; check your SCSI cabling, check the > card is properly seated and the memory on the card is installed. Check > your jumpers, and that you have the activity LED plugged in properly (if > it's connected at all). I checked those initially, and re-checked as well. I've been a few days in following-up because I've actually been able to get a hold of another AcceleRAID 150 and swap out the card, but I'm getting the same thing. I can go several boots (sometimes up to 5 or so) before the problem recurs, then it can happen several times in a row, rendering the ATX case power switch functionless while the reset is fine. Thus far, I've changed the SDRAM, motherboard, and RAID card. I guess I'll try the SCSI cables next. I read up on the booting process and figured I must be getting past boot[012] to the loader since I get the "press enter to boot immediately" autocount prompt, so the problem must be when it tries to read "kernel". Thanks for the suggestions. If you have any others, please keep them coming. Omar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jan 31 0:24:18 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 47EFA37B4EC; Wed, 31 Jan 2001 00:23:55 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f0V8ONe04278; Wed, 31 Jan 2001 00:24:23 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200101310824.f0V8ONe04278@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Omar Thameen Cc: freebsd-hardware@freebsd.org, freebsd-scsi@freebsd.org Subject: Re: Mylex AcceleRAID 150 problems In-reply-to: Your message of "Wed, 31 Jan 2001 03:18:15 EST." <20010131031815.A26661@clifford.inch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 31 Jan 2001 00:24:23 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Yes, it does. I've been able to proceed with server installation > and configuration with no problems, even running a "make buildworld" as > a test (probably of the SDRAM more than anything). The only thing I'm > not sure about is whether this is the response I'm supposed to be getting: > > # mlxcontrol status -v mlxd0 > mlxcontrol: couldn't get controller/drive for /dev/mlxd0 > mlxd0: online You haven't created the /dev/mlx0 control node (bug in the application not telling you this). > I read up on the booting process and figured I must be getting past > boot[012] to the loader since I get the "press enter to boot immediately" > autocount prompt, so the problem must be when it tries to read "kernel". > > Thanks for the suggestions. If you have any others, please keep them > coming. Nothing else yet, sorry. 8( -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jan 31 14:53:39 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 548A437B491 for ; Wed, 31 Jan 2001 14:53:12 -0800 (PST) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 31 Jan 2001 22:53:10 +0000 (GMT) To: scsi@freebsd.org Cc: iedowse@maths.tcd.ie Subject: Corruption on ahc reads - seems PCI latency related Date: Wed, 31 Jan 2001 22:53:10 +0000 From: Ian Dowse Message-ID: <200101312253.aa86550@salmon.maths.tcd.ie> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org We have a heavily loaded 4.2-STABLE NFS fileserver machine that has recently delevoped a file corruption problem. The corruption seems to be occurring during reads from one SCSI disk (da0). It appears that small regions (usually 18 bytes) of a read are 'missed', so the buffer cache ends up with mostly the new data, but some bytes are from whatever happened to be in the buffer cache before the read. Here's an example of the corruption on an executable: --- good Fri Jan 19 21:46:18 2001 +++ corrupted Fri Jan 19 21:46:18 2001 @@ -5468,4 +5468,4 @@ 000155d0 25 73 00 43 6f 75 6c 64 20 6e 6f 74 20 6f 70 65 |%s.Could not ope| -000155e0 6e 20 68 6f 73 74 00 61 50 3a 75 3a 70 3a 4a 3a |n host.aP:u:p:J:| -000155f0 72 64 3a 67 3a 00 4d 61 6c 66 6f 72 6d 65 64 20 |rd:g:.Malformed | +000155e0 6e 20 68 6f 73 74 00 61 50 3a 75 3a 70 3a 6d 40 |n host.aP:u:p:m@| +000155f0 2f 36 df 7e 01 d9 6d 40 e0 ef 12 20 fd ce 6d 40 |/6.~..m@... ..m@| 00015600 55 52 4c 3a 20 25 73 0a 00 00 00 00 00 00 00 00 |URL: %s.........| All the examples I have seen involve the last few bytes of a 512-byte block. Sample offsets are 0x1dee, 0x15ee, 0x1df0, 0x15f0, 0x195ee. In the above example, the junk in place of the real data happens to be from a Matlab data file that was written from an NFS client to a different local disk (da2). No corruption was seen in the Matlab data file. I am able to repeat this corruption by doing the following: # clear out buffer cache perl -e '$_ = "x" x 12800000' # start a continuous write from an NFS client to da2 rsh client "cat hugefile > /server_da2/file" # /usr/local is on da0 md5 /usr/local/bin/* | diff /tmp/good_md5.out - # examine resulting differences The odd thing is that we can only reproduce the corruption when reading from da0 (Quantum 9Gb), while writing over NFS to another disk (I have only tried da2). Swapping out da0 with another similar disk did not help. Anyway, today I tried fiddling with the PCI latency timer settings, and it seems that reducing the value of the ahc PCI latency timer makes the corruption go away. On this motherboard (Supermicro with onboard SCSI) the default PCI latency timer value on all devices is 0x40. If I reduce this to 0x20 on ahc0,ahc1,fxp0,fxp1,pcib1, then I can't repeat the corruption. When I put it back to 0x40 on ahc0 and ahc1 the corruption returns. Has anyone any ideas on what this might mean? If a FIFO somewhere is filling or a DMA is failing, shouldn't an error get back to the driver or OS somehow? Or is this just a sign of dying hardware? There were no hardware or software changes to the machine around the time that the corruption first appeared, but there could have been an increase in NFS load. Ian Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.2-STABLE #0: Wed Jan 31 21:04:21 GMT 2001 iedowse@gosset.maths.tcd.ie:/mnt/obj/usr/src/sys/MACCULLAGH Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 451024893 Hz CPU: Pentium III/Pentium III Xeon/Celeron (451.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x672 Stepping = 2 Features=0x387fbff real memory = 268369920 (262080K bytes) avail memory = 257765376 (251724K bytes) Preloaded elf kernel "kernel" at 0xc0352000. Preloaded elf module "green_saver.ko" at 0xc035209c. ccd0-3: Concatenated disk drivers Pentium Pro MTRR support enabled md0: Malloc disk npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at 7.2 chip1: port 0x5000-0x500f at device 7.3 on pci0 pci0: at 15.0 irq 11 ahc0: port 0xd400-0xd4ff mem 0xed200000-0xed200fff irq 10 at device 16.0 on pci0 aic7890/91: Wide Channel A, SCSI Id=7, 32/255 SCBs fxp0: port 0xd800-0xd81f mem 0xed000000-0xed0fffff,0xed201000-0xed201fff irq 12 at device 18.0 on pci0 fxp0: Ethernet address 00:90:27:12:56:c5 fxp1: port 0xdc00-0xdc1f mem 0xed100000-0xed1fffff,0xed203000-0xed203fff irq 5 at device 19.0 on pci0 fxp1: Ethernet address 00:90:27:1d:1f:0b ahc1: port 0xe000-0xe0ff mem 0xed202000-0xed202fff irq 5 at device 20.0 on pci0 aic7890/91: Wide Channel A, SCSI Id=7, 32/255 SCBs fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 IP packet filtering initialized, divert disabled, rule-based forwarding enabled, default to accept, unlimited logging acd0: CDROM at ata0-master using PIO4 Waiting 5 seconds for SCSI devices to settle Mounting root from ufs:/dev/da0s1a da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled da0: 8683MB (17783250 512 byte sectors: 255H 63S/T 1106C) da3 at ahc1 bus 0 target 3 lun 0 da3: Fixed Direct Access SCSI-3 device da3: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled da3: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled da1: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) da4 at ahc1 bus 0 target 4 lun 0 da4: Fixed Direct Access SCSI-3 device da4: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled da4: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) da2 at ahc0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-3 device da2: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled da2: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jan 31 16:22:33 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from arjun.niksun.com (unknown [63.148.27.34]) by hub.freebsd.org (Postfix) with ESMTP id 2829637B4EC for ; Wed, 31 Jan 2001 16:22:11 -0800 (PST) Received: from stiegl.niksun.com (stiegl.niksun.com [10.0.0.44]) by arjun.niksun.com (8.9.3/8.9.3) with ESMTP id TAA64470; Wed, 31 Jan 2001 19:19:40 -0500 (EST) (envelope-from ath@stiegl.niksun.com) Received: (from ath@localhost) by stiegl.niksun.com (8.9.2/8.8.7) id TAA81554; Wed, 31 Jan 2001 19:21:08 -0500 (EST) (envelope-from ath) To: freebsd-scsi@freebsd.org Cc: Ian Dowse Subject: Re: Corruption on ahc reads - seems PCI latency related References: <200101312253.aa86550@salmon.maths.tcd.ie> From: Andrew Heybey Date: 31 Jan 2001 19:21:07 -0500 In-Reply-To: Ian Dowse's message of "Wed, 31 Jan 2001 22:53:10 +0000" Message-ID: <85r91jqmmj.fsf@stiegl.niksun.com> Lines: 96 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ian Dowse writes: > We have a heavily loaded 4.2-STABLE NFS fileserver machine that > has recently delevoped a file corruption problem. The corruption > seems to be occurring during reads from one SCSI disk (da0). It > appears that small regions (usually 18 bytes) of a read are 'missed', > so the buffer cache ends up with mostly the new data, but some > bytes are from whatever happened to be in the buffer cache before > the read. > [...] > The odd thing is that we can only reproduce the corruption when > reading from da0 (Quantum 9Gb), while writing over NFS to another > disk (I have only tried da2). Swapping out da0 with another similar > disk did not help. > > Anyway, today I tried fiddling with the PCI latency timer settings, > and it seems that reducing the value of the ahc PCI latency timer > makes the corruption go away. On this motherboard (Supermicro with > onboard SCSI) the default PCI latency timer value on all devices > is 0x40. If I reduce this to 0x20 on ahc0,ahc1,fxp0,fxp1,pcib1, > then I can't repeat the corruption. When I put it back to 0x40 on > ahc0 and ahc1 the corruption returns. > > Has anyone any ideas on what this might mean? If a FIFO somewhere > is filling or a DMA is failing, shouldn't an error get back to the > driver or OS somehow? Or is this just a sign of dying hardware? This sounds almost exactly like a problem I had with 3.1 in 1999. Under heavy disk and network load I would see exactly this problem. Fiddling with the PCI latency registers seemed to fix the problem at first but then it came back. See kern/10243. However (as noted at the end of the PR) my problem went away with sys/dev/aic7xxx/aic7xxx.seq revision 1.91. Looking at the diffs from 1.90 to 1.91, the fix for the bug is: +ultra2_dmafifoflush: or DFCNTRL, FIFOFLUSH; - test DFSTATUS, FIFOEMP jz . - 1; + /* + * The FIFOEMP status bit on the Ultra2 class + * of controllers seems to be a bit flaky. + * It appears that if the FIFO is full and the + * transfer ends with some data in the REQ/ACK + * FIFO, FIFOEMP will fall temporarily + * as the data is transferred to the PCI bus. + * This glitch lasts for fewer than 5 clock cycles, + * so we work around the problem by ensuring the + * status bit stays false through a full glitch + * window. + */ + test DFSTATUS, FIFOEMP jz ultra2_dmafifoflush; + test DFSTATUS, FIFOEMP jz ultra2_dmafifoflush; + test DFSTATUS, FIFOEMP jz ultra2_dmafifoflush; + test DFSTATUS, FIFOEMP jz ultra2_dmafifoflush; + test DFSTATUS, FIFOEMP jz ultra2_dmafifoflush; + +ultra2_dmafifoempty: + /* Don't clobber an inprogress host data transfer */ + test DFSTATUS, MREQPEND jnz ultra2_dmafifoempty; + In -stable, the corresponding code seems to be (rev 1.94.2.8): ultra2_dmafifoflush: if ((ahc->bugs & AHC_AUTOFLUSH_BUG) != 0) { /* * On Rev A of the aic7890, the autoflush * features doesn't function correctly. * Perform an explicit manual flush. During * a manual flush, the FIFOEMP bit becomes * true every time the PCI FIFO empties * regardless of the state of the SCSI FIFO. * It can take up to 4 clock cycles for the * SCSI FIFO to get data into the PCI FIFO * and for FIFOEMP to de-assert. Here we * guard against this condition by making * sure the FIFOEMP bit stays on for 5 full * clock cycles. */ or DFCNTRL, FIFOFLUSH; test DFSTATUS, FIFOEMP jz ultra2_dmafifoflush; test DFSTATUS, FIFOEMP jz ultra2_dmafifoflush; test DFSTATUS, FIFOEMP jz ultra2_dmafifoflush; test DFSTATUS, FIFOEMP jz ultra2_dmafifoflush; } test DFSTATUS, FIFOEMP jz ultra2_dmafifoflush; Maybe AHC_AUTOFLUSH_BUG does not get set for all the chips that actually have the bug? That is a WAG, since I am by no means an ahc expert. andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Feb 1 4:22:24 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from weirdo.netcraft.com (weirdo.netcraft.com [195.92.95.47]) by hub.freebsd.org (Postfix) with ESMTP id 477B137B65D for ; Thu, 1 Feb 2001 04:22:06 -0800 (PST) Received: (from sketchy@localhost) by weirdo.netcraft.com (8.11.1/8.11.1) id f11CM4X91803 for freebsd-scsi@freebsd.org; Thu, 1 Feb 2001 12:22:04 GMT (envelope-from sketchy) Date: Thu, 1 Feb 2001 12:22:04 +0000 From: Jonathan Perkin To: freebsd-scsi@freebsd.org Subject: Idle timeouts Message-ID: <20010201122204.G81792@netcraft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD/i386 4.2-STABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Not seen this before (or is it just the new format of a standard bus reset) - anything to worry about? (da3:ahc0:0:9:0): SCB 0x98 - timed out while idle, SEQADDR == 0x3 STACK == 0x1, 0x101, 0x15c, 0x184 SXFRCTL0 == 0x80 SCB count = 220 QINFIFO entries: Waiting Queue entries: Disconnected Queue entries: 8:152 QOUTFIFO entries: Sequencer Free SCB List: 5 9 10 1 13 4 7 6 0 11 14 12 2 3 15 Pending list: 152 Kernel Free SCB list: 105 11 174 122 68 112 103 161 79 51 24 169 50 151 118 121 127 133 196 37 5 55 135 218 14 180 99 28 148 181 139 34 160 59 192 153 149 123 144 164 76 204 90 170 22 140 141 194 53 150 101 74 3 65 200 58 124 176 93 156 87 102 18 72 208 47 6 10 61 117 57 15 64 98 205 42 167 89 217 52 158 126 111 110 138 189 82 171 9 77 202 147 33 104 107 203 63 70 19 128 159 106 83 66 177 27 114 36 209 71 62 56 179 40 48 198 1 132 38 187 131 143 49 219 193 178 88 165 0 43 81 146 162 41 2 145 197 44 32 12 184 20 108 116 46 17 136 30 109 190 175 95 67 120 7 92 75 80 69 137 73 168 188 39 113 134 172 60 25 13 16 185 78 4 125 31 163 154 21 85 155 195 54 129 86 142 115 130 207 94 23 183 26 91 45 157 166 173 97 186 100 8 199 35 182 119 96 206 84 201 191 29 215 214 213 212 211 210 sg[0] - Addr 0x3927000 : Length 4096 sg[1] - Addr 0x3b48000 : Length 2048 (da3:ahc0:0:9:0): Queuing a BDR SCB (da3:ahc0:0:9:0): Bus Device Reset Message Sent (da3:ahc0:0:9:0): no longer in timeout, status = 34b ahc0: Bus Device Reset on A:9. 1 SCBs aborted Machine seems to be fine afterwards. FreeBSD 4.2-RELEASE da3: Fixed Direct Access SCSI-2 device da3: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da3: 8683MB (17783112 512 byte sectors: 255H 63S/T 1106C) ahc0: port 0xd800-0xd8ff mem 0xf7800000-0xf7800fff irq 11 at device 11.0 on pci0 da3 is part of a ccd array hosted in an external Andataco enclosure with 2 other disks (da2 da4). The same thing happened a while back also, and on the same disk (da2 and da4 weren't affected). -- Jonathan Perkin +44 (0)1225 867914 Netcraft Ltd, Bradford on Avon, UK - http://www.netcraft.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Feb 1 7:19:42 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from usinfo.usemb.kiev.ua (usinfo.usemb.kiev.ua [194.44.168.253]) by hub.freebsd.org (Postfix) with ESMTP id F0B4F37B503 for ; Thu, 1 Feb 2001 07:19:10 -0800 (PST) Received: from cool (cool.usinfo.usemb.kiev.ua [194.44.168.250]) by usinfo.usemb.kiev.ua (8.10.2/8.10.2) with SMTP id f11FOOE21264 for ; Thu, 1 Feb 2001 17:24:24 +0200 (EET) Message-Id: <4.1.20010201171504.00a40740@194.44.168.253> Message-Id: <4.1.20010201171504.00a40740@194.44.168.253> Message-Id: <4.1.20010201171504.00a40740@194.44.168.253> X-Sender: max@194.44.168.253 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 01 Feb 2001 17:17:56 +0200 To: freebsd-scsi@freebsd.org From: max@ah.kiev.ua Subject: Support for HP NetRAID Ultra2 disk array controller under FreeBSD 4.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, I asked this in -questions, but alas, got no reply. Is there any confirmed info that FreeBSD 4.2 supports HP NetRAID Ultra2 disk array controller? Thanks in advance! Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Feb 1 11:56:33 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.dis.org (unknown [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 8B81D37B6AA for ; Thu, 1 Feb 2001 11:56:14 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f11JutM01001; Thu, 1 Feb 2001 11:56:56 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200102011956.f11JutM01001@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: max@ah.kiev.ua Cc: freebsd-scsi@freebsd.org Subject: Re: Support for HP NetRAID Ultra2 disk array controller under FreeBSD 4.2 In-reply-to: Your message of "Thu, 01 Feb 2001 17:17:56 +0200." <4.1.20010201171504.00a40740@194.44.168.253> <4.1.20010201171504.00a40740@194.44.168.253> <4.1.20010201171504.00a40740@194.44.168.253> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Feb 2001 11:56:55 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Hello, > > I asked this in -questions, but alas, got no reply. Is there any confirmed info > that FreeBSD 4.2 supports HP NetRAID Ultra2 disk array controller? See http://people.freebsd.org/~msmith/RAID/index.html for a list of supported RAID controllers. Since you don't actually indicate which NetRAID you're talking about, it's not clear whether you're referring to a NetRAID 1 or 3, which are supported in 4.2, or a NetRAID 4 which is supported in -stable and will be supported in the 4.3 release. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Feb 1 12:29:13 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 9FB0F37B503 for ; Thu, 1 Feb 2001 12:28:55 -0800 (PST) Received: from gosset.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 1 Feb 2001 20:28:53 +0000 (GMT) To: Andrew Heybey Cc: freebsd-scsi@freebsd.org, iedowse@maths.tcd.ie Subject: Re: Corruption on ahc reads - seems PCI latency related In-Reply-To: Your message of "31 Jan 2001 19:21:07 EST." <85r91jqmmj.fsf@stiegl.niksun.com> Date: Thu, 01 Feb 2001 20:28:53 +0000 From: Ian Dowse Message-ID: <200102012028.aa75208@salmon.maths.tcd.ie> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <85r91jqmmj.fsf@stiegl.niksun.com>, Andrew Heybey writes: >Maybe AHC_AUTOFLUSH_BUG does not get set for all the chips that >actually have the bug? That is a WAG, since I am by no means an ahc >expert. Thanks for the suggestion - this definitely sounds like the kind of think that could trigger such corruption. Unfortunately it seems that AHC_AUTOFLUSH_BUG is already set on both controllers. Here is the ahc_softc from ahc0 in case this information is of use to anyone. Ian (kgdb) p *(struct ahc_softc *)0xc17ccc00 $9 = {tag = 1, bsh = 3428909056, buffer_dmat = 0xc17cedc0, scb_data = 0xc17c9000, next_queued_scb = 0xc17cf1d4, pending_scbs = { lh_first = 0x0}, untagged_queue_lock = 0, untagged_queues = {{ tqh_first = 0x0, tqh_last = 0xc17ccc1c}, {tqh_first = 0x0, tqh_last = 0xc17ccc24}, {tqh_first = 0x0, tqh_last = 0xc17ccc2c}, { tqh_first = 0x0, tqh_last = 0xc17ccc34}, {tqh_first = 0x0, tqh_last = 0xc17ccc3c}, {tqh_first = 0x0, tqh_last = 0xc17ccc44}, { tqh_first = 0x0, tqh_last = 0xc17ccc4c}, {tqh_first = 0x0, tqh_last = 0xc17ccc54}, {tqh_first = 0x0, tqh_last = 0xc17ccc5c}, { tqh_first = 0x0, tqh_last = 0xc17ccc64}, {tqh_first = 0x0, tqh_last = 0xc17ccc6c}, {tqh_first = 0x0, tqh_last = 0xc17ccc74}, { tqh_first = 0x0, tqh_last = 0xc17ccc7c}, {tqh_first = 0x0, tqh_last = 0xc17ccc84}, {tqh_first = 0x0, tqh_last = 0xc17ccc8c}, { tqh_first = 0x0, tqh_last = 0xc17ccc94}}, platform_data = 0xc17cef40, dev_softc = 0xc17cdc80, enabled_targets = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xc17c5400, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, black_hole = 0x0, pending_device = 0x0, chip = 1034, features = 22262, bugs = 6, flags = 21825, unpause = 2 '\002', pause = 6 '\006', qoutfifonext = 9 '\t', qinfifonext = 24 '\030', qoutfifo = 0xc17cca00 "ÿÿÿÿÿÿÿÿO", 'ÿ' ..., qinfifo = 0xc17ccb00 "K\016K\016K\016K\016O\016K\016K\016OMKOKOKOKOK\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016K\016"..., critical_sections = 0xc0a39820, num_critical_sections = 7, links = {tqe_next = 0xc17e5e00, tqe_prev = 0xc02bafe0}, channel = 65 'A', channel_b = 0 '\000', our_id = 7 '\a', our_id_b = 0 '\000', targ_msg_req = 0, unsolicited_ints = 0, targetcmds = 0x0, tqinfifonext = 0 '\000', send_msg_perror = 0 '\000', msg_type = MSG_TYPE_NONE, msgout_buf = "\001\003\001\n\177\000\000\000\000\000\000", msgin_buf = "\001\003\001\n\037\000\000\000\000\000\000", msgout_len = 0, msgout_index = 5, msgin_index = 0, parent_dmat = 0xc17cef00, shared_data_dmat = 0xc17ced80, shared_data_dmamap = 0x0, shared_data_busaddr = 265292288, dma_bug_buf = 0, suspend_state = { channel = {{scsiseq = 0 '\000', sxfrctl0 = 0 '\000', sxfrctl1 = 0 '\000', simode0 = 0 '\000', simode1 = 0 '\000', seltimer = 0 '\000', seqctl = 0 '\000'}, {scsiseq = 0 '\000', sxfrctl0 = 0 '\000', sxfrctl1 = 0 '\000', simode0 = 0 '\000', simode1 = 0 '\000', seltimer = 0 '\000', seqctl = 0 '\000'}}, optionmode = 0 '\000', dscommand0 = 0 '\000', dspcistatus = 0 '\000', crccontrol1 = 0 '\000', scbbaddr = 0 '\000', dff_thrsh = 0 '\000', scratch_ram = 0x0, btt = 0x0}, enabled_luns = 0, init_level = 5, pci_cachesize = 32, description = 0xc0289ac0 "Adaptec 2940 Ultra2 SCSI adapter", name = 0xc0a3e260 "ahc0", unit = 0, seltime = 0, seltime_b = 0, user_discenable = 65535, user_tagenable = 65535} To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Feb 2 5:33:55 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 9440637B491 for ; Fri, 2 Feb 2001 05:33:37 -0800 (PST) Received: by gw.nectar.com (Postfix, from userid 1001) id B234E18C8F; Fri, 2 Feb 2001 07:33:36 -0600 (CST) Date: Fri, 2 Feb 2001 07:33:36 -0600 From: "Jacques A. Vidrine" To: freebsd-scsi@freebsd.org Subject: umass-sim device Message-ID: <20010202073336.C58832@spawn.nectar.com> Mail-Followup-To: "Jacques A. Vidrine" , freebsd-scsi@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Url: http://www.nectar.com/ Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi All, I recently got a SanDisk Imagemate USB. Works great! However, the next time I rebooted my machine, it was picked as `da0', and so file system mounts failed, etc. I figured ``no problem, I'll just wire these bad boys down''. The problem is that the umass-sim device has a dash in it, and config can't deal with it (it generates identifiers that aren't valid e.g. umass-sim0_resources). I worked around it for now by editing ioconf.c directly. What say we make DEVNAME_SIM "umass_sim" or even "umasssim"? Or perhaps the following (untested, and perhaps naive) patch to config is in order? --- mkioconf.c.orig Wed Jan 24 11:17:19 2001 +++ mkioconf.c Wed Jan 24 11:33:30 2001 @@ -60,13 +60,25 @@ return dp->d_name; } +static char * +sdevstr(struct device *dp) +{ + char *p, *q; + + p = devstr(dp); + for (q = p; *q; q++) + if (!isalnum(*q) && *q != '_') + *q = '_'; + return p; +} + static void write_device_resources(FILE *fp, struct device *dp) { int count = 0; char buf[80]; - fprintf(fp, "struct config_resource %s_resources[] = {\n", devstr(dp)); + fprintf(fp, "struct config_resource %s_resources[] = {\n", sdevstr(dp)); if (dp->d_conn) { if (dp->d_connunit >= 0) snprintf(buf, sizeof(buf), "%s%d", dp->d_conn, dp->d_connunit); @@ -124,7 +136,7 @@ count++; } fprintf(fp, "};\n"); - fprintf(fp, "#define %s_count %d\n", devstr(dp), count); + fprintf(fp, "#define %s_count %d\n", sdevstr(dp), count); } static void @@ -152,7 +164,7 @@ count = 0; fprintf(fp, "struct config_device config_devtab[] = {\n"); for (dp = dtab; dp != 0; dp = dp->d_next) { - char* n = devstr(dp); + char* n = sdevstr(dp); if (dp->d_type != DEVICE) continue; if (dp->d_unit == UNKNOWN) Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Feb 2 19:36:41 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from falcon.home.hentschel.net (w002.z064221160.smf-ca.dsl.cnc.net [64.221.160.2]) by hub.freebsd.org (Postfix) with ESMTP id EBC4E37B4EC for ; Fri, 2 Feb 2001 19:36:23 -0800 (PST) Received: from hentschel.net (booocnc.net@localhost [127.0.0.1]) by falcon.home.hentschel.net (8.11.1/8.11.1) with ESMTP id f133a1H25367; Fri, 2 Feb 2001 19:36:02 -0800 (PST) (envelope-from thomas@hentschel.net) Message-Id: <200102030336.f133a1H25367@falcon.home.hentschel.net> Date: Fri, 2 Feb 2001 19:35:59 -0800 (PST) From: thomas@hentschel.net Subject: Re: CANNOT ACCESS T20 TAPE To: mjacob@feral.com, wash@iconnect.co.ke Cc: freebsd-scsi@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> >> Sorry for my being daft. Here I attach the output from /var/log/messages after the test. > > Good. Exactly what I'm wanting to see.. So... The Sense Key 9 being returned > is "VENDOR SPECIFIC". W/O T20 docs I can't tell you what the issue is. > > So, the first thing the tape driver does when it sees a tape driver for the > first time is to make sure the tape is rewound. Clearly LOAD(to BOT) is > failing. With 5/24 as the ASC/ASCQ, I'm sure somebody at HP *MEANT* to use > Sense Key 5 (Illegal Command) but they just forgot their SCSI spec at home > that day. > > Now, the REWIND command (used alternately) is failing with Sense Key 2 (Not > Ready) and the ASC/ASCQ values are 'Medium Not Present'. So, you either don't > have a tape inserted in the drive or the drive doesn't like the tape at all. > > Things don't work w/o a tape inserted. Sorry to step into the middle of the conversation (got this from the archives), but did you folks ever sort that problem out ? I'm seeing the same thing here. uname details : FreeBSD falcon.home.hentschel.net 4.2-STABLE FreeBSD 4.2-STABLE #0: Wed Jan 24 14:29:12 PST 2001 dmesg snipped : sa0 at ahc0 bus 0 target 3 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 3.300MB/s transfers otherwise same symptons as for Wash. If there is anything else needed, please let me know. -Th [just subscribing to -scsi, so please cc: me] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Feb 2 23:30:29 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id A279637B4EC for ; Fri, 2 Feb 2001 23:30:11 -0800 (PST) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id XAA28677; Fri, 2 Feb 2001 23:29:49 -0800 Date: Fri, 2 Feb 2001 23:29:47 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: thomas@hentschel.net Cc: wash@iconnect.co.ke, freebsd-scsi@freebsd.org Subject: Re: CANNOT ACCESS T20 TAPE In-Reply-To: <200102030336.f133a1H25367@falcon.home.hentschel.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have my doubts. The errors he was seeing indicated complete breakage (i.e,, never could have worked at all). I have a T20 that works for me 3.01. W/O more details about how it fails for you (please build a CAMDEBUG kernel and use the -Ic option to turn on debugging when doing an initial 'mt status' if this is where it's failing for you) I can't say whether "same" is a meaningful statement. > dmesg snipped : > sa0 at ahc0 bus 0 target 3 lun 0 > sa0: Removable Sequential Access SCSI-2 device > sa0: 3.300MB/s transfers > > otherwise same symptons as for Wash. > If there is anything else needed, please let me know. > > -Th [just subscribing to -scsi, so please cc: me] > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Feb 3 14:40: 7 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from falcon.home.hentschel.net (w002.z064221160.smf-ca.dsl.cnc.net [64.221.160.2]) by hub.freebsd.org (Postfix) with ESMTP id B64C737B503 for ; Sat, 3 Feb 2001 14:39:46 -0800 (PST) Received: from hentschel.net (booocnc.net@localhost [127.0.0.1]) by falcon.home.hentschel.net (8.11.1/8.11.1) with ESMTP id f13Mdvr00742; Sat, 3 Feb 2001 14:39:58 -0800 (PST) (envelope-from thomas@hentschel.net) Message-Id: <200102032239.f13Mdvr00742@falcon.home.hentschel.net> Date: Sat, 3 Feb 2001 14:39:56 -0800 (PST) From: thomas@hentschel.net Subject: Re: CANNOT ACCESS T20 TAPE To: mjacob@feral.com Cc: wash@iconnect.co.ke, freebsd-scsi@FreeBSD.ORG In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 2 Feb, Matthew Jacob wrote: > > I have my doubts. The errors he was seeing indicated complete breakage (i.e,, > never could have worked at all). I have a T20 that works for me 3.01. > > W/O more details about how it fails for you (please build a CAMDEBUG kernel > and use the -Ic option to turn on debugging when doing an initial 'mt status' > if this is where it's failing for you) I can't say whether "same" is a > meaningful statement. I take it you meant camcontrol debug -Ic ? Anyhow, here it is : falcon# camcontrol debug -Ic 0:3 Debugging enabled for 0:3:-1 falcon# mt -f /dev/nsa0 status mt: /dev/nsa0: Input/output error spits the following to the console : (sa0:ahc0:0:3:0): saopen(0): dev=0x0 softc=0x0 (sa0:ahc0:0:3:0): sastart(sa0:ahc0:0:3:0): RESERVE(06). CDB: 16 0 0 0 0 0 (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 (sa0:ahc0:0:3:0): RESERVE(06). CDB: 16 0 0 0 0 0 (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 (sa0:ahc0:0:3:0): RESERVE(06). CDB: 16 0 0 0 0 0 (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 falcon# mt -f /dev/nsa0 rewind mt: /dev/nsa0: Input/output error (sa0:ahc0:0:3:0): saopen(0): dev=0x0 softc=0x0 (sa0:ahc0:0:3:0): sastart(sa0:ahc0:0:3:0): RESERVE(06). CDB: 16 0 0 0 0 0 (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 (sa0:ahc0:0:3:0): RESERVE(06). CDB: 16 0 0 0 0 0 (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 (sa0:ahc0:0:3:0): RESERVE(06). CDB: 16 0 0 0 0 0 (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 Looks like the thing doesn't get ready, just would like to know why.... If there's anything else which would help here, please let me know. -Th > >> dmesg snipped : >> sa0 at ahc0 bus 0 target 3 lun 0 >> sa0: Removable Sequential Access SCSI-2 device >> sa0: 3.300MB/s transfers >> >> otherwise same symptons as for Wash. >> If there is anything else needed, please let me know. >> >> -Th [just subscribing to -scsi, so please cc: me] >> > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Feb 3 14:48: 6 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 1E15837B401 for ; Sat, 3 Feb 2001 14:47:48 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id OAA30603; Sat, 3 Feb 2001 14:47:39 -0800 Date: Sat, 3 Feb 2001 14:47:37 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: thomas@hentschel.net Cc: wash@iconnect.co.ke, freebsd-scsi@FreeBSD.ORG Subject: Re: CANNOT ACCESS T20 TAPE In-Reply-To: <200102032239.f13Mdvr00742@falcon.home.hentschel.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > I take it you meant camcontrol debug -Ic ? Anyhow, here it is : > > falcon# camcontrol debug -Ic 0:3 > Debugging enabled for 0:3:-1 > > falcon# mt -f /dev/nsa0 status > mt: /dev/nsa0: Input/output error > > spits the following to the console : > > (sa0:ahc0:0:3:0): saopen(0): dev=0x0 softc=0x0 > (sa0:ahc0:0:3:0): sastart(sa0:ahc0:0:3:0): RESERVE(06). CDB: 16 0 0 0 0 0 > (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 > (sa0:ahc0:0:3:0): RESERVE(06). CDB: 16 0 0 0 0 0 > (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 > (sa0:ahc0:0:3:0): RESERVE(06). CDB: 16 0 0 0 0 0 > (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 > > falcon# mt -f /dev/nsa0 rewind > mt: /dev/nsa0: Input/output error > > (sa0:ahc0:0:3:0): saopen(0): dev=0x0 softc=0x0 > (sa0:ahc0:0:3:0): sastart(sa0:ahc0:0:3:0): RESERVE(06). CDB: 16 0 0 0 0 0 > (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 > (sa0:ahc0:0:3:0): RESERVE(06). CDB: 16 0 0 0 0 0 > (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 > (sa0:ahc0:0:3:0): RESERVE(06). CDB: 16 0 0 0 0 0 > (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 > > > Looks like the thing doesn't get ready, just would like to know why.... > If there's anything else which would help here, please let me know. Go back to HP and tell them write Firmware that actually works? RESERVE (as in RESERVE/RELEASE) is an optional command. Instead of returning "Illegal Command" they're returning "HARDWARE ERROR" with 'ASC/ASCQ(0x40/0xA0)=' Go into scsi_sa.c:samount and comment out the call to sareservereleaseunit and ditto fo the call from saclose. Frankly, I inherited this section of code and I'm not all that excited about requiring a reservation. But at the same time, some *minimum* sanity for a SCSI device should be required for it to be supported. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Feb 3 16:27:24 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from falcon.home.hentschel.net (w002.z064221160.smf-ca.dsl.cnc.net [64.221.160.2]) by hub.freebsd.org (Postfix) with ESMTP id 88CE637B684 for ; Sat, 3 Feb 2001 16:27:05 -0800 (PST) Received: from hentschel.net (booocnc.net@localhost [127.0.0.1]) by falcon.home.hentschel.net (8.11.1/8.11.1) with ESMTP id f140RHk00571; Sat, 3 Feb 2001 16:27:18 -0800 (PST) (envelope-from thomas@hentschel.net) Message-Id: <200102040027.f140RHk00571@falcon.home.hentschel.net> Date: Sat, 3 Feb 2001 16:27:16 -0800 (PST) From: thomas@hentschel.net Subject: Re: CANNOT ACCESS T20 TAPE To: mjacob@feral.com Cc: wash@iconnect.co.ke, freebsd-scsi@FreeBSD.ORG In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 3 Feb, Matthew Jacob wrote: > >> >> If there's anything else which would help here, please let me know. > > > Go back to HP and tell them write Firmware that actually works? Hehe, if it was in my power... I just inherited that thing. > > RESERVE (as in RESERVE/RELEASE) is an optional command. Instead of returning > "Illegal Command" they're returning "HARDWARE ERROR" with > 'ASC/ASCQ(0x40/0xA0)=' > > Go into scsi_sa.c:samount and comment out the call to sareservereleaseunit > and ditto fo the call from saclose. Did as you said, here the new output : (sa0:ahc0:0:3:0): saopen(0): dev=0x0 softc=0x0 (sa0:ahc0:0:3:0): sastart(sa0:ahc0:0:3:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 (sa0:ahc0:0:3:0): LOAD UNLOAD. CDB: 1b 0 0 0 1 0 (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 (sa0:ahc0:0:3:0): LOAD UNLOAD. CDB: 1b 0 0 0 1 0 (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 (sa0:ahc0:0:3:0): LOAD UNLOAD. CDB: 1b 0 0 0 1 0 (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 (sa0:ahc0:0:3:0): REWIND. CDB: 1 0 0 0 0 0 (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 (sa0:ahc0:0:3:0): REWIND. CDB: 1 0 0 0 0 0 (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 (sa0:ahc0:0:3:0): REWIND. CDB: 1 0 0 0 0 0 (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 (sa0:ahc0:0:3:0): sastart(sa0:ahc0:0:3:0): RELEASE(06). CDB: 17 0 0 0 0 0 (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 (sa0:ahc0:0:3:0): RELEASE(06). CDB: 17 0 0 0 0 0 (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 (sa0:ahc0:0:3:0): RELEASE(06). CDB: 17 0 0 0 0 0 (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 -Th To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Feb 3 20:25: 7 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id B47B037B4EC for ; Sat, 3 Feb 2001 20:24:49 -0800 (PST) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id UAA31293; Sat, 3 Feb 2001 20:24:35 -0800 Date: Sat, 3 Feb 2001 20:24:32 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: thomas@hentschel.net Cc: wash@iconnect.co.ke, freebsd-scsi@FreeBSD.ORG Subject: Re: CANNOT ACCESS T20 TAPE In-Reply-To: <200102040027.f140RHk00571@falcon.home.hentschel.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > (sa0:ahc0:0:3:0): saopen(0): dev=0x0 softc=0x0 > (sa0:ahc0:0:3:0): sastart(sa0:ahc0:0:3:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 > (sa0:ahc0:0:3:0): LOAD UNLOAD. CDB: 1b 0 0 0 1 0 > (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 > (sa0:ahc0:0:3:0): LOAD UNLOAD. CDB: 1b 0 0 0 1 0 > (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 > (sa0:ahc0:0:3:0): LOAD UNLOAD. CDB: 1b 0 0 0 1 0 > (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 > (sa0:ahc0:0:3:0): REWIND. CDB: 1 0 0 0 0 0 > (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 > (sa0:ahc0:0:3:0): REWIND. CDB: 1 0 0 0 0 0 > (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 > (sa0:ahc0:0:3:0): REWIND. CDB: 1 0 0 0 0 0 > (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 > (sa0:ahc0:0:3:0): sastart(sa0:ahc0:0:3:0): RELEASE(06). CDB: 17 0 0 0 0 0 > (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 > (sa0:ahc0:0:3:0): RELEASE(06). CDB: 17 0 0 0 0 0 > (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 > (sa0:ahc0:0:3:0): RELEASE(06). CDB: 17 0 0 0 0 0 > (sa0:ahc0:0:3:0): Key 0x4 ASC/ASCQ 0x40 0xa0 flags 0x0 resid 0 dxfer_len 0 Well, it keeps saying h/w error. It speaks for itself. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message