From owner-freebsd-scsi Sun Jan 14 05:10:18 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA04323 for freebsd-scsi-outgoing; Sun, 14 Jan 1996 05:10:18 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA04306 Sun, 14 Jan 1996 05:10:01 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id AAA05690; Mon, 15 Jan 1996 00:06:01 +1100 Date: Mon, 15 Jan 1996 00:06:01 +1100 From: Bruce Evans Message-Id: <199601141306.AAA05690@godzilla.zeta.org.au> To: freebsd-scsi@freefall.freebsd.org, gibbs@freefall.freebsd.org Subject: Re: Calling st_unmount for nrst* devices Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk >I don't like the fact that after closing the nrst* devices, we >don't reenable the eject button. In fact, although I haven't >tracked down exactly why, even if you rewind the tape via an "mt >rewind" after doing some operations on the nrst* devices, the drive >is still locked. I think these patches fix the problem, but I'll Isn't this behaviour a fundamental part of the idea of a "mount session"? See st.4. Perhaps there should be another special minor or 3 to give modes with different eject behaviour. OTOH, there may already be too many minors and too many variations to control with minor bits. Perhaps more emphasis could be placed on using the control minor (or direct ioctls) to set local preferences. This approach seems to work OK for ttys. Perhaps it could be improved by adding a standard devices and more programmable sub-devices: mode 0: Factory defaults. Not programmable. Use for portability. modes 1-n: Local defaults. mode n+1: (if ioctls aren't used) control device. Bruce From owner-freebsd-scsi Sun Jan 14 09:57:39 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA13903 for freebsd-scsi-outgoing; Sun, 14 Jan 1996 09:57:39 -0800 (PST) Received: from elwood.probe.net (root@elwood.probe.net [206.28.166.252]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA13892 for ; Sun, 14 Jan 1996 09:57:35 -0800 (PST) Received: from sylvia.tummy.com (jafo@ariel.tummy.com [206.28.166.237]) by elwood.probe.net (8.6.12/8.6.10) with ESMTP id LAA15035; Sun, 14 Jan 1996 11:56:05 -0600 Received: (from jafo@localhost) by sylvia.tummy.com (8.7.3/8.7.3) id LAA11847; Sun, 14 Jan 1996 11:56:00 -0600 From: Sean Reifschneider Message-Id: <199601141756.LAA11847@sylvia.tummy.com> Subject: FreeBSD NCR driver timeout? To: freebsd-scsi%freebsd.org@probe.net Date: Sun, 14 Jan 1996 11:56:00 -0600 (CST) Cc: wolf%cologne.de@probe.net, se%mi.Uni-Koeln.de@probe.net X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk Greetings. I'm trying to port some SCSI scanner code to FreeBSD 2.1.0 but have run across (what seems to be) a timeout problem. I'm trying to control a a SCSI scanner which emulates a processor device (as opposed to implementing the scanner commands). During the scan operation, the scanner starts doing it's thing to scan, but just before it would actually start sending data, I get a read error and the scanner resets. A "handshake timeout" is logged to the console. I tracked this through the ncr.c driver, and it seems that at line 4441 the handshake timeout is set to 1.6 seconds. My first question is wether it is possible to increase this value (to about 3 or 4 seconds). It seems that the scanner starts doing the scan when it gets the request to read data, but it has to position the scan head, activate the light, etc. It's just taking too long to start sending back data. I've tried upping the timeout through the SCSI library, but that has no effect. Unfortunately, the SCSI controller that's on my sound board completely hangs whenever I try to access the scanner (it's an Adaptec on a Sound Blaster 16). With the exception of this timeout, EVERYTHING else in my interactions with the scanner work -- inquiring name, negotiating scanning parameters, etc. Any pointers would be appreciated. My next course of action is going to be seeing if I can get a small program that I can ship off to somone with a different controller to try. Thanks, Sean -- "We just wanted to give the band a little more thrust than most other bands." - Donald Fagen's reply to why they chose the band name 'Steely Dan' Sean Reifschneider, Inimitably Superfluous URL: XVScan -- HP-UX/Linux X11 scanning software. From owner-freebsd-scsi Sun Jan 14 10:16:47 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA14476 for freebsd-scsi-outgoing; Sun, 14 Jan 1996 10:16:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA14471 Sun, 14 Jan 1996 10:16:44 -0800 (PST) Message-Id: <199601141816.KAA14471@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost [127.0.0.1] didn't use HELO protocol To: Bruce Evans cc: freebsd-scsi@freefall.freebsd.org Subject: Re: Calling st_unmount for nrst* devices In-reply-to: Your message of "Mon, 15 Jan 1996 00:06:01 +1100." <199601141306.AAA05690@godzilla.zeta.org.au> Date: Sun, 14 Jan 1996 10:16:43 -0800 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk >>I don't like the fact that after closing the nrst* devices, we >>don't reenable the eject button. In fact, although I haven't >>tracked down exactly why, even if you rewind the tape via an "mt >>rewind" after doing some operations on the nrst* devices, the drive >>is still locked. I think these patches fix the problem, but I'll > >Isn't this behaviour a fundamental part of the idea of a "mount >session"? See st.4. Then I think the man page should be changed. If you want special settings for an rst* session, you must use the control device. Why should nrst* devices be special in that you can close one, run some mt commands on the same device, and expect them to stick for the following open? My main gripe has to do with preventing media removal when the device is closed, so I could implement this another way, to maintain the "mount session" behavior, but I think the current "mount session" is confusing at best. >Perhaps there should be another special minor or 3 to give modes >with different eject behaviour. OTOH, there may already be too many >minors and too many variations to control with minor bits. Perhaps >more emphasis could be placed on using the control minor (or direct >ioctls) to set local preferences. This approach seems to work OK >for ttys. Perhaps it could be improved by adding a standard devices >and more programmable sub-devices: I think that the control device should be sufficient. I realy don't see how the curren't behavior replaces using the contrl device. I guess you could open nrst*, do a rewind, do some mt stuff to it, then do your dumps, but why go through a middle man when you can simply set the control device? >Bruce -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Sun Jan 14 10:55:00 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA16246 for freebsd-scsi-outgoing; Sun, 14 Jan 1996 10:55:00 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA16236 Sun, 14 Jan 1996 10:54:47 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id FAA14785; Mon, 15 Jan 1996 05:52:34 +1100 Date: Mon, 15 Jan 1996 05:52:34 +1100 From: Bruce Evans Message-Id: <199601141852.FAA14785@godzilla.zeta.org.au> To: bde@zeta.org.au, gibbs@freefall.freebsd.org Subject: Re: Calling st_unmount for nrst* devices Cc: freebsd-scsi@freefall.freebsd.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk >>Isn't this behaviour a fundamental part of the idea of a "mount >>session"? See st.4. >Then I think the man page should be changed. If you want special >settings for an rst* session, you must use the control device. >Why should nrst* devices be special in that you can close one, >run some mt commands on the same device, and expect them to stick >for the following open? Because then there would be complications involving how long-lived the settings are. You would need two control devices, one to set the defaults that are restored at the end of a mount session and a new one to control mount sessions. You would also need a new command to end mount sessions. >My main gripe has to do with preventing media removal when the >device is closed, so I could implement this another way, to maintain >the "mount session" behavior, but I think the current "mount session" >is confusing at best. I don't see the problem. If you're controlling the device interactively, then just type "st rewoffl". Otherwise you need a program to control anything more complicated than the rewinding device, and the program can do the "st rewoffl" just as easily as it can do a close. >>Perhaps there should be another special minor or 3 to give modes >>with different eject behaviour. OTOH, there may already be too many >>minors and too many variations to control with minor bits. Perhaps >>... >I think that the control device should be sufficient. I realy don't >see how the curren't behavior replaces using the contrl device. I guess >you could open nrst*, do a rewind, do some mt stuff to it, then do your >dumps, but why go through a middle man when you can simply set the >control device? The problem is the (time) scope of the controls. I use tar and always check backups by rewinding and doing a "tar df" (my data is still small enough for this to be practical :-). I don't want an auto offline on rewind. Allowing eject at any time that the hardware does and mount sessions extending across ejects might be useful, however. Bruce From owner-freebsd-scsi Sun Jan 14 11:30:02 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA18263 for freebsd-scsi-outgoing; Sun, 14 Jan 1996 11:30:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA18232 Sun, 14 Jan 1996 11:29:56 -0800 (PST) Message-Id: <199601141929.LAA18232@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost [127.0.0.1] didn't use HELO protocol To: Bruce Evans cc: freebsd-scsi@freefall.freebsd.org Subject: Re: Calling st_unmount for nrst* devices In-reply-to: Your message of "Mon, 15 Jan 1996 05:52:34 +1100." <199601141852.FAA14785@godzilla.zeta.org.au> Date: Sun, 14 Jan 1996 11:29:56 -0800 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk >>Then I think the man page should be changed. If you want special >>settings for an rst* session, you must use the control device. >>Why should nrst* devices be special in that you can close one, >>run some mt commands on the same device, and expect them to stick >>for the following open? > >Because then there would be complications involving how long-lived >the settings are. You would need two control devices, one to set >the defaults that are restored at the end of a mount session and >a new one to control mount sessions. You would also need a new >command to end mount sessions. I just don't see this. A mount session ends when you close the device. When you open a device, a new mount session is started and the settings from the control device are enforced. The only difference between the nrst* devices and rst* devices is that a close will rewind the tape. >>My main gripe has to do with preventing media removal when the >>device is closed, so I could implement this another way, to maintain >>the "mount session" behavior, but I think the current "mount session" >>is confusing at best. > >I don't see the problem. If you're controlling the device interactively, >then just type "st rewoffl". Otherwise you need a program to control >anything more complicated than the rewinding device, and the program >can do the "st rewoffl" just as easily as it can do a close. It just doesn't make sence that a closed device cannot be removed externally (ie from the eject button on my tape drive). There is also the problem that the busy light stays on for as long as the media is locked. Consider this: mt /dev/rst0 rewind dump 0uBf 2033646 /dev/nrst0 /dev/sd0s2e dump 0uBf 2033646 /dev/nrst0 /dev/sd0s2f mt /dev/rst0 rewind Now, can I go over to my machine after this runs and eject the media? Nope. Even though mt uses the rewinding device (which should end the mount session according to the man page), the mount session isn't closed because we only do an ioctl and that ioctl only performs an st_rewind. This is just like the Macintosh only worse... you actually have an eject button taunting you, but its disabled. >>>Perhaps there should be another special minor or 3 to give modes >>>with different eject behaviour. OTOH, there may already be too many >>>minors and too many variations to control with minor bits. Perhaps >>>... > >>I think that the control device should be sufficient. I realy don't >>see how the curren't behavior replaces using the contrl device. I guess >>you could open nrst*, do a rewind, do some mt stuff to it, then do your >>dumps, but why go through a middle man when you can simply set the >>control device? > >The problem is the (time) scope of the controls. I use tar and always >check backups by rewinding and doing a "tar df" (my data is still small >enough for this to be practical :-). I don't want an auto offline on >rewind. Allowing eject at any time that the hardware does and mount >sessions extending across ejects might be useful, however. Who said anything about an auto offline. Ending a mount session doesn't imply an eject. The only time the eject will happen is if you opened the ejecting device or, with my changes, if the nrst device is closed and you go hit the eject button on the drive. >Bruce -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Sun Jan 14 12:30:01 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA20874 for freebsd-scsi-outgoing; Sun, 14 Jan 1996 12:30:01 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA20857 Sun, 14 Jan 1996 12:29:35 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id HAA17864; Mon, 15 Jan 1996 07:26:34 +1100 Date: Mon, 15 Jan 1996 07:26:34 +1100 From: Bruce Evans Message-Id: <199601142026.HAA17864@godzilla.zeta.org.au> To: bde@zeta.org.au, gibbs@freefall.freebsd.org Subject: Re: Calling st_unmount for nrst* devices Cc: freebsd-scsi@freefall.freebsd.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk >>Because then there would be complications involving how long-lived >>the settings are. You would need two control devices, one to set >>the defaults that are restored at the end of a mount session and >>a new one to control mount sessions. You would also need a new >>command to end mount sessions. >I just don't see this. A mount session ends when you close the device. >When you open a device, a new mount session is started and the settings >from the control device are enforced. The only difference between the >nrst* devices and rst* devices is that a close will rewind the tape. This would defeat the point of the current control device which is to give almost fixed system defaults for the next mount session. >It just doesn't make sence that a closed device cannot be removed >externally (ie from the eject button on my tape drive). There is Agreed. Perhaps there should be a special device that is open through the mount session. It can't be the standard device because you want to see closes of the standard device as last-closes, e.g., for auto-rewind on close. >also the problem that the busy light stays on for as long as the media >is locked. Consider this: >mt /dev/rst0 rewind >dump 0uBf 2033646 /dev/nrst0 /dev/sd0s2e >dump 0uBf 2033646 /dev/nrst0 /dev/sd0s2f >mt /dev/rst0 rewind >Now, can I go over to my machine after this runs and eject the media? >Nope. Even though mt uses the rewinding device (which should end the mount >session according to the man page), the mount session isn't closed because >we only do an ioctl and that ioctl only performs an st_rewind. (At first I thought you meant nrst0 because the explicit rewinds are unecessary for rst0.) Eject works here after similar operations on a Wangdat 3100: mt -f /dev/nrst0 blocksize 0 od /dev/nrst0 # failed mt -f /dev/rst0 rewind >>enough for this to be practical :-). I don't want an auto offline on >>rewind. Allowing eject at any time that the hardware does and mount >>sessions extending across ejects might be useful, however. >Who said anything about an auto offline. Ending a mount session doesn't >imply an eject. The only time the eject will happen is if you opened the >ejecting device or, with my changes, if the nrst device is closed and you >go hit the eject button on the drive. I was confusing mount sessions with physical mounts/offlines and that's more or less what they are here. Eject permission is too closely tied to being offline. Perhaps there is no difference for some hardware. Bruce From owner-freebsd-scsi Sun Jan 14 12:36:11 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA21410 for freebsd-scsi-outgoing; Sun, 14 Jan 1996 12:36:11 -0800 (PST) Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA21330 for ; Sun, 14 Jan 1996 12:36:01 -0800 (PST) Received: by Sysiphos id AA16933 (5.67b/IDA-1.5 for freebsd-scsi@freebsd.org); Sun, 14 Jan 1996 21:35:52 +0100 Message-Id: <199601142035.AA16933@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Sun, 14 Jan 1996 21:35:52 +0100 In-Reply-To: Sean Reifschneider "FreeBSD NCR driver timeout?" (Jan 14, 11:56) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: Sean Reifschneider Subject: Re: FreeBSD NCR driver timeout? Cc: freebsd-scsi@freebsd.org Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk On Jan 14, 11:56, Sean Reifschneider wrote: } Subject: FreeBSD NCR driver timeout? } Greetings. I'm trying to port some SCSI scanner code to FreeBSD 2.1.0 } but have run across (what seems to be) a timeout problem. I'm trying } to control a a SCSI scanner which emulates a processor device (as opposed } to implementing the scanner commands). } } During the scan operation, the scanner starts doing it's thing to scan, } but just before it would actually start sending data, I get a read error } and the scanner resets. A "handshake timeout" is logged to the console. } } I tracked this through the ncr.c driver, and it seems that at line } 4441 the handshake timeout is set to 1.6 seconds. My first question is Well, sorry, those 1.6 seconds are already the maximum supported by the NCR hardware ... You may want to try with HTH not included in the interrupt enable mask: Change line 4482 (in my copy of ncr.c): OUTW (nc_sien , STO|HTH|MA|SGE|UDC|RST); into: OUTW (nc_sien , STO|MA|SGE|UDC|RST); Please let me know, whether this helps ... 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 Sun Jan 14 13:02:27 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA22815 for freebsd-scsi-outgoing; Sun, 14 Jan 1996 13:02:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA22789 Sun, 14 Jan 1996 13:02:18 -0800 (PST) Message-Id: <199601142102.NAA22789@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost [127.0.0.1] didn't use HELO protocol To: Bruce Evans cc: freebsd-scsi@freefall.freebsd.org Subject: Re: Calling st_unmount for nrst* devices In-reply-to: Your message of "Mon, 15 Jan 1996 07:26:34 +1100." <199601142026.HAA17864@godzilla.zeta.org.au> Date: Sun, 14 Jan 1996 13:02:16 -0800 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk >>I just don't see this. A mount session ends when you close the device. >>When you open a device, a new mount session is started and the settings >>from the control device are enforced. The only difference between the >>nrst* devices and rst* devices is that a close will rewind the tape. > >This would defeat the point of the current control device which is >to give almost fixed system defaults for the next mount session. How do I change the settings on a mount session for the rst* devices now? Do we need an "mt load" or some other operation so that you can create a mount session for these devices so that a subsequent open uses the new settings? I'll have to play with this a bit to see how it works now. >>It just doesn't make sence that a closed device cannot be removed >>externally (ie from the eject button on my tape drive). There is > >Agreed. Perhaps there should be a special device that is open >through the mount session. It can't be the standard device because >you want to see closes of the standard device as last-closes, e.g., >for auto-rewind on close. I just changed my patches to simply do the media locking/unlocking in st_open and st_close now. st_close is only called for last closes according to the comments. The problem with terminating the mount session is that st_mount does a media load operation that will rewind the tape. >>also the problem that the busy light stays on for as long as the media >>is locked. Consider this: > >>mt /dev/rst0 rewind >>dump 0uBf 2033646 /dev/nrst0 /dev/sd0s2e >>dump 0uBf 2033646 /dev/nrst0 /dev/sd0s2f >>mt /dev/rst0 rewind > >>Now, can I go over to my machine after this runs and eject the media? >>Nope. Even though mt uses the rewinding device (which should end the mount >>session according to the man page), the mount session isn't closed because >>we only do an ioctl and that ioctl only performs an st_rewind. > >(At first I thought you meant nrst0 because the explicit rewinds are >unecessary for rst0.) > >Eject works here after similar operations on a Wangdat 3100: Does the Wangdat honor media locking? >mt -f /dev/nrst0 blocksize 0 >od /dev/nrst0 # failed ??? What's od? >mt -f /dev/rst0 rewind >>Who said anything about an auto offline. Ending a mount session doesn't >>imply an eject. The only time the eject will happen is if you opened the >>ejecting device or, with my changes, if the nrst device is closed and you >>go hit the eject button on the drive. > >I was confusing mount sessions with physical mounts/offlines and that's >more or less what they are here. Eject permission is too closely tied >to being offline. Perhaps there is no difference for some hardware. The question boils down to, "When should we lock the media." Some people have said not to lock it at all. Perhaps the locking should be pushed into mt so as to be optional and more flexible. My tape drive shows a solid busy light when locked instead of having it follow actuall tape write operations, so having the media locked at all is a little anoying. >Bruce -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Sun Jan 14 13:07:57 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA23101 for freebsd-scsi-outgoing; Sun, 14 Jan 1996 13:07:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA23096 Sun, 14 Jan 1996 13:07:50 -0800 (PST) Message-Id: <199601142107.NAA23096@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost [127.0.0.1] didn't use HELO protocol To: se@ZPR.Uni-Koeln.DE (Stefan Esser) cc: Sean Reifschneider , freebsd-scsi@freebsd.org Subject: Re: FreeBSD NCR driver timeout? In-reply-to: Your message of "Sun, 14 Jan 1996 21:35:52 +0100." <199601142035.AA16933@Sysiphos> Date: Sun, 14 Jan 1996 13:07:50 -0800 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk >Well, sorry, those 1.6 seconds are already >the maximum supported by the NCR hardware ... You could easily count the number of handshake timeouts in the driver and make the interval a multiple of what the NCR supports. I don't see the value of a handshake timeout anyway since the SCSI spec doesn't place any lower bounds on communication speed, and you should be using the timeout value that was passed down to you in the scsi_xfer struct as an overall timeout value. >Please let me know, whether this helps ... > >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 -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Sun Jan 14 13:34:59 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA24247 for freebsd-scsi-outgoing; Sun, 14 Jan 1996 13:34:59 -0800 (PST) Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA24231 for ; Sun, 14 Jan 1996 13:34:43 -0800 (PST) Received: by Sysiphos id AA17404 (5.67b/IDA-1.5 for freebsd-scsi@freebsd.org); Sun, 14 Jan 1996 22:34:23 +0100 Message-Id: <199601142134.AA17404@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Sun, 14 Jan 1996 22:34:22 +0100 In-Reply-To: "Justin T. Gibbs" "Re: FreeBSD NCR driver timeout?" (Jan 14, 13:07) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: "Justin T. Gibbs" Subject: Re: FreeBSD NCR driver timeout? Cc: Sean Reifschneider , freebsd-scsi@freebsd.org Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk On Jan 14, 13:07, "Justin T. Gibbs" wrote: } Subject: Re: FreeBSD NCR driver timeout? } >Well, sorry, those 1.6 seconds are already } >the maximum supported by the NCR hardware ... } } You could easily count the number of handshake timeouts in the driver and } make the interval a multiple of what the NCR supports. I don't see the } value of a handshake timeout anyway since the SCSI spec doesn't place any } lower bounds on communication speed, and you should be using the timeout } value that was passed down to you in the scsi_xfer struct as an overall } timeout value. Well, most devices will not require 1.6s for a single bus transaction (locking out all other devices ...). I know about the command timeout, and I'm really not sure, whether the 1.6s timeout should be there too. But then, I'm seeng SCSI as a shared access bus, and I do expect a device to disconnect, if it won't have any data to send for more than a few milliseconds. The handshake timeout helps diagnose error situations, since I know, at which NCR instruction the lockup occured. I'm not sure whether it is possible to break a lock without loosing that information, if only a command timeout is used. I'll have to look into this. Regards, STefan From owner-freebsd-scsi Sun Jan 14 15:11:03 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA29562 for freebsd-scsi-outgoing; Sun, 14 Jan 1996 15:11:03 -0800 (PST) Received: from sylvia.tummy.com (jafo@ariel.tummy.com [206.28.166.237]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id PAA29555 for ; Sun, 14 Jan 1996 15:10:51 -0800 (PST) Received: (from jafo@localhost) by sylvia.tummy.com (8.7.3/8.7.3) id RAA12580; Sun, 14 Jan 1996 17:10:14 -0600 From: Sean Reifschneider Message-Id: <199601142310.RAA12580@sylvia.tummy.com> Subject: Re: FreeBSD NCR driver timeout? To: se@zpr.uni-koeln.de (Stefan Esser) Date: Sun, 14 Jan 1996 17:10:14 -0600 (CST) Cc: freebsd-scsi@freebsd.org In-Reply-To: <199601142134.AA17404@Sysiphos> from "Stefan Esser" at Jan 14, 96 10:34:22 pm X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk >} >Well, sorry, those 1.6 seconds are already >} >the maximum supported by the NCR hardware ... >} > [goes on to suggest removing HTH from the interrupt map] I'll try that right now and get the kernel recompiling. Thanks... >Well, most devices will not require 1.6s for a single >bus transaction (locking out all other devices ...). I completely agree here... It *SHOUDN'T*, but it does. :-) I was hoping that I could send the scan command, it would go off and do it's thing, I could sleep 4 seconds or so, and THEN start reading. But it doesn't actually start doing ANYTHING until I start reading the data. So there's nothing I can do. :-( As reference points, I don't run into any timeouts on HP machines or with the drivers I've tried under Linux -- including the NCR and a couple Adaptecs. >I know about the command timeout, and I'm really not >sure, whether the 1.6s timeout should be there too. >But then, I'm seeng SCSI as a shared access bus, and Personally, I'd like to see just the command timeout there... Thanks, Sean -- "We just wanted to give the band a little more thrust than most other bands." - Donald Fagen's reply to why they chose the band name 'Steely Dan' Sean Reifschneider, Inimitably Superfluous URL: XVScan -- HP-UX/Linux X11 scanning software. From owner-freebsd-scsi Sun Jan 14 16:14:52 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA02976 for freebsd-scsi-outgoing; Sun, 14 Jan 1996 16:14:52 -0800 (PST) Received: from hda.com (hda.com [199.232.40.182]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA02970 for ; Sun, 14 Jan 1996 16:14:48 -0800 (PST) Received: (from dufault@localhost) by hda.com (8.6.11/8.6.9) id TAA15464; Sun, 14 Jan 1996 19:18:29 -0500 From: Peter Dufault Message-Id: <199601150018.TAA15464@hda.com> Subject: Re: FreeBSD NCR driver timeout? To: jafo@tummy.com (Sean Reifschneider) Date: Sun, 14 Jan 1996 19:18:28 -0500 (EST) Cc: se@zpr.uni-koeln.de, freebsd-scsi@freebsd.org In-Reply-To: <199601142310.RAA12580@sylvia.tummy.com> from "Sean Reifschneider" at Jan 14, 96 05:10:14 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk > >Well, most devices will not require 1.6s for a single > >bus transaction (locking out all other devices ...). > > I completely agree here... It *SHOUDN'T*, but it does. :-) This is what I mentioned the Microtek scanner does. It locks up the SCSI bus while it positions the scan head. This is the problem with these "PC" scanners that ship with their own SCSI controllers - they can be completely anti-social about what they do on the bus. Unfortunately, Stefan, I think that if possible we ought to provide the same host adapter behavior across all adapters and use the timeout passed in (if we can), even if it is for an ungodly amount of time. Keep in mind that someone might elect to dedicate an NCR controller to talking to an anti-social scanner and will be disappointed if they can't make it work with a timeout of, say, 10 seconds. After all, those NCR controllers are among the cheapest we support and therefore a good choice for a second dedicated bus. -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267 From owner-freebsd-scsi Sun Jan 14 16:32:08 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA03610 for freebsd-scsi-outgoing; Sun, 14 Jan 1996 16:32:08 -0800 (PST) Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA03604 Sun, 14 Jan 1996 16:32:03 -0800 (PST) Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.9) id QAA19339; Sun, 14 Jan 1996 16:31:46 -0800 From: Julian Elischer Message-Id: <199601150031.QAA19339@ref.tfs.com> Subject: Re: Calling st_unmount for nrst* devices To: gibbs@freefall.freebsd.org (Justin T. Gibbs) Date: Sun, 14 Jan 1996 16:31:46 -0800 (PST) Cc: freebsd-scsi@freefall.freebsd.org In-Reply-To: <199601140308.TAA07484@freefall.freebsd.org> from "Justin T. Gibbs" at Jan 13, 96 07:08:48 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk > > > I don't like the fact that after closing the nrst* devices, we > don't reenable the eject button. In fact, although I haven't > tracked down exactly why, even if you rewind the tape via an "mt > rewind" after doing some operations on the nrst* devices, the drive > is still locked. I think these patches fix the problem, but I'll > have to do some more testing tomorrow to make sure. Perhaps some > of you would be interested in testing these as well? hmmmmm I think this was a deliberate act on my part but probably at a time. To me it makes perfect sense to have it as it is but I bow to public opinion. however I object to the way you've done it.. on the following grounds.. An "unmount" Ends a session and I want to only call the unmount call in this case. if you use the "nrst" device you are deliberatly NOT ending the session If you had wanted to end the session you should have used "rst" which is defined as ending a session.. If you want to enable the button between whenever ther device os closed, then you need simply execute the scsi_prevent() call from st_close(). To call "st_unmount() breaks my mental model of what is going on and is misleading.. If you DO enable the button, then pushing the button will eventually result in a "Unit Attention" which will end the session, (or should.. will check) but I don't want to call "st_unmount(), because you are NOT changing the mount session.. you are NOT reloading device parameters and driver settings.. you ARE leaving the present session active. leave it all the same and call scsi_prevent() from st_close() directly, (and possibly from st_open() to ensure it's locked when open) thanks julian From owner-freebsd-scsi Sun Jan 14 16:46:15 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA04090 for freebsd-scsi-outgoing; Sun, 14 Jan 1996 16:46:15 -0800 (PST) Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA04085 Sun, 14 Jan 1996 16:46:08 -0800 (PST) Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.9) id QAA19380; Sun, 14 Jan 1996 16:45:52 -0800 From: Julian Elischer Message-Id: <199601150045.QAA19380@ref.tfs.com> Subject: Re: Calling st_unmount for nrst* devices To: gibbs@freefall.freebsd.org (Justin T. Gibbs) Date: Sun, 14 Jan 1996 16:45:52 -0800 (PST) Cc: bde@zeta.org.au, freebsd-scsi@freefall.freebsd.org In-Reply-To: <199601141929.LAA18232@freefall.freebsd.org> from "Justin T. Gibbs" at Jan 14, 96 11:29:56 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk > > >>Then I think the man page should be changed. If you want special > >>settings for an rst* session, you must use the control device. > >>Why should nrst* devices be special in that you can close one, > >>run some mt commands on the same device, and expect them to stick > >>for the following open? > > > >Because then there would be complications involving how long-lived > >the settings are. You would need two control devices, one to set > >the defaults that are restored at the end of a mount session and > >a new one to control mount sessions. You would also need a new > >command to end mount sessions. > > I just don't see this. A mount session ends when you close the device. > When you open a device, a new mount session is started and the settings > from the control device are enforced. The only difference between the > nrst* devices and rst* devices is that a close will rewind the tape. Exactly WRONG A moutn session ends when you tell it to end.. a mount session is a method to allow one group of settings (e.g. blocksize, density, compression) to be used across multiple opens.. this allows the use of commands sunc as "mt fsf 1" in ashell script without losing your settings. the Control device is to set default settings to which the device returns after a session has ended. I can live with making the eject button act as a way of ending a session, but sessions themselves are too valuable to change it too much.. > > >>My main gripe has to do with preventing media removal when the > >>device is closed, so I could implement this another way, to maintain > >>the "mount session" behavior, but I think the current "mount session" > >>is confusing at best. > > > >I don't see the problem. If you're controlling the device interactively, > >then just type "st rewoffl". Otherwise you need a program to control > >anything more complicated than the rewinding device, and the program > >can do the "st rewoffl" just as easily as it can do a close. > > It just doesn't make sence that a closed device cannot be removed > externally (ie from the eject button on my tape drive). There is > also the problem that the busy light stays on for as long as the media > is locked. Consider this: that is only true for some devices.. and anyhow it's true.. > > mt /dev/rst0 rewind > dump 0uBf 2033646 /dev/nrst0 /dev/sd0s2e > dump 0uBf 2033646 /dev/nrst0 /dev/sd0s2f > mt /dev/rst0 rewind > > Now, can I go over to my machine after this runs and eject the media? yes you should be able to, because your last 'close' was of rst0 not nrst0 ans so the device should have released the tape.. the session has ended.. if not it's a bug. > Nope. Even though mt uses the rewinding device (which should end the mount > session according to the man page), the mount session isn't closed because > we only do an ioctl and that ioctl only performs an st_rewind. no, you also did a close.. and you had (in your example 'rst0' open) the tape should release in this case. > > This is just like the Macintosh only worse... you actually have an eject > button taunting you, but its disabled. I can live with the eject button ending the session > > >>>Perhaps there should be another special minor or 3 to give modes > >>>with different eject behaviour. OTOH, there may already be too many > >>>minors and too many variations to control with minor bits. Perhaps > >>>... aaarrggg, I already have one too many (the eject device should go away I think) > > > >>I think that the control device should be sufficient. I realy don't > >>see how the curren't behavior replaces using the contrl device. I guess > >>you could open nrst*, do a rewind, do some mt stuff to it, then do your > >>dumps, but why go through a middle man when you can simply set the > >>control device? because you (the operator) want to set decent system defaults and the user (another person) wants to TEMPORARILY over-ride them to read in or write some tape. two differnt devices with different permissions... you don't permit Joe User to change the defaults.. > > > >The problem is the (time) scope of the controls. I use tar and always > >check backups by rewinding and doing a "tar df" (my data is still small > >enough for this to be practical :-). I don't want an auto offline on > >rewind. Allowing eject at any time that the hardware does and mount > >sessions extending across ejects might be useful, however. hmmmm POSSIBLY a use for the 3rd minor combo.. [UNIT Attention doesn't reset the session..] > > Who said anything about an auto offline. Ending a mount session doesn't > imply an eject. The only time the eject will happen is if you opened the > ejecting device or, with my changes, if the nrst device is closed and you > go hit the eject button on the drive. Or you ask it to eject > > >Bruce > > -- > Justin T. Gibbs > =========================================== > FreeBSD: Turning PCs into workstations > =========================================== > From owner-freebsd-scsi Sun Jan 14 16:53:16 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA04403 for freebsd-scsi-outgoing; Sun, 14 Jan 1996 16:53:16 -0800 (PST) Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA04394 Sun, 14 Jan 1996 16:53:10 -0800 (PST) Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.9) id QAA19398; Sun, 14 Jan 1996 16:52:54 -0800 From: Julian Elischer Message-Id: <199601150052.QAA19398@ref.tfs.com> Subject: Re: Calling st_unmount for nrst* devices To: gibbs@freefall.freebsd.org (Justin T. Gibbs) Date: Sun, 14 Jan 1996 16:52:54 -0800 (PST) Cc: bde@zeta.org.au, freebsd-scsi@freefall.freebsd.org In-Reply-To: <199601142102.NAA22789@freefall.freebsd.org> from "Justin T. Gibbs" at Jan 14, 96 01:02:16 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk > > >>I just don't see this. A mount session ends when you close the device. > >>When you open a device, a new mount session is started and the settings > >>from the control device are enforced. The only difference between the > >>nrst* devices and rst* devices is that a close will rewind the tape. > > > >This would defeat the point of the current control device which is > >to give almost fixed system defaults for the next mount session. > > How do I change the settings on a mount session for the rst* devices > now? Do we need an "mt load" or some other operation so that you > can create a mount session for these devices so that a subsequent > open uses the new settings? I'll have to play with this a bit to > see how it works now. simple.. you change settings of the nrst device, until you have finished the session.. when you finish the session by using the rst device. (or using 'offline') the device goes back to the defaults set by the control device. As Bruce pointed out.. there MIGHT be a use for allowing the ejecting of a tape without ending the session, but that's not what you wanted to do.. (is it?) > > >>It just doesn't make sence that a closed device cannot be removed > >>externally (ie from the eject button on my tape drive). There is > > > >Agreed. Perhaps there should be a special device that is open > >through the mount session. It can't be the standard device because > >you want to see closes of the standard device as last-closes, e.g., > >for auto-rewind on close. minor # '2' might be used.... > > I just changed my patches to simply do the media locking/unlocking in > st_open and st_close now. st_close is only called for last closes > according to the comments. The problem with terminating the mount > session is that st_mount does a media load operation that will > rewind the tape. of course.. > > >>also the problem that the busy light stays on for as long as the media > >>is locked. Consider this: > > > >>mt /dev/rst0 rewind > >>dump 0uBf 2033646 /dev/nrst0 /dev/sd0s2e > >>dump 0uBf 2033646 /dev/nrst0 /dev/sd0s2f > >>mt /dev/rst0 rewind > > > >>Now, can I go over to my machine after this runs and eject the media? > >>Nope. Even though mt uses the rewinding device (which should end the mount > >>session according to the man page), the mount session isn't closed because > >>we only do an ioctl and that ioctl only performs an st_rewind. > > > >(At first I thought you meant nrst0 because the explicit rewinds are > >unecessary for rst0.) > > > >Eject works here after similar operations on a Wangdat 3100: I would expect this.. > From owner-freebsd-scsi Sun Jan 14 17:35:49 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA06168 for freebsd-scsi-outgoing; Sun, 14 Jan 1996 17:35:49 -0800 (PST) Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA06158 Sun, 14 Jan 1996 17:35:43 -0800 (PST) Message-Id: <199601150135.RAA06158@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol To: Julian Elischer cc: bde@zeta.org.au, freebsd-scsi@freefall.freebsd.org Subject: Re: Calling st_unmount for nrst* devices In-reply-to: Your message of "Sun, 14 Jan 1996 16:45:52 PST." <199601150045.QAA19380@ref.tfs.com> Date: Sun, 14 Jan 1996 17:35:43 -0800 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk >> I just don't see this. A mount session ends when you close the device. >> When you open a device, a new mount session is started and the settings >> from the control device are enforced. The only difference between the >> nrst* devices and rst* devices is that a close will rewind the tape. > >Exactly WRONG >A moutn session ends when you tell it to end.. This isn't true. A mount session ends when: 1) You change from nrst* to some other openning mode. 2) You close the rst* or erst* device. >a mount session is a method to allow one group of settings >(e.g. blocksize, density, compression) to be used across multiple >opens.. this allows the use of commands sunc as "mt fsf 1" in ashell script >without losing your settings. How do I do a single rewinding dump with settings other than what the control device is set for? The only option is to use the nrst device because the other devices don't have a true mount session. I can't do an: mt -f /dev/nrst0 blocksize X tar cvf /dev/rst0 /usr/src and expect the blocksize to stick even though I think it should because the media hasn't changed. >the Control device is to set default settings to which the device returns >after a session has ended. And should be applied only when new media is detected. >I can live with making the eject button act as a way of >ending a session, but sessions themselves are too valuable >to change it too much.. I think the session should encapsulate the time that a single piece of media is loaded. This would make sense. >> mt /dev/rst0 rewind >> dump 0uBf 2033646 /dev/nrst0 /dev/sd0s2e >> dump 0uBf 2033646 /dev/nrst0 /dev/sd0s2f >> mt /dev/rst0 rewind >> >> Now, can I go over to my machine after this runs and eject the media? > >yes you should be able to, because your last 'close' was of >rst0 not nrst0 ans so the device should have released the tape.. >the session has ended.. if not it's a bug. Hmmm. Yes this does work, but I don't see why the session ends simply by closing the rst0 device. It should end when we eject the tape or get a unit attention from new media being loaded instead of only having meaning for the nrst* devices. >> This is just like the Macintosh only worse... you actually have an eject >> button taunting you, but its disabled. > >I can live with the eject button ending the session I can live with the eject button being enabled so long as the device is closed, but I do think we should re-evaluate the semantics of a tape mount session. >aaarrggg, I already have one too many (the eject device should go away I think >) Agreed. >> >>I think that the control device should be sufficient. I realy don't >> >>see how the curren't behavior replaces using the contrl device. I guess >> >>you could open nrst*, do a rewind, do some mt stuff to it, then do your >> >>dumps, but why go through a middle man when you can simply set the >> >>control device? > >because you (the operator) want to set decent system defaults >and the user (another person) wants to TEMPORARILY over-ride them >to read in or write some tape. But aren't the overrides valid so long as the current tape is in the machine? Shouldn't the session be bracketted by media changes and not the devices you use? >two differnt devices with different permissions... >you don't permit Joe User to change the defaults.. Understood, but my problem isn't with the control device. >> >The problem is the (time) scope of the controls. I use tar and always >> >check backups by rewinding and doing a "tar df" (my data is still small >> >enough for this to be practical :-). I don't want an auto offline on >> >rewind. Allowing eject at any time that the hardware does and mount >> >sessions extending across ejects might be useful, however. >hmmmm POSSIBLY a use for the 3rd minor combo.. >[UNIT Attention doesn't reset the session..] Unit attention should always reset the session. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Sun Jan 14 19:02:33 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA12313 for freebsd-scsi-outgoing; Sun, 14 Jan 1996 19:02:33 -0800 (PST) Received: from rs6a.wln.com (rs6a.wln.com [192.156.252.2]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA12304 Sun, 14 Jan 1996 19:02:24 -0800 (PST) Received: by rs6a.wln.com (AIX 3.2/UCB 5.64/4.06) id AA09056; Sun, 14 Jan 1996 19:03:14 -0800 Date: Sun, 14 Jan 1996 19:03:12 -0800 (PST) From: Richard W Donovan Subject: Cant Boot on AHA1542CP / Micropolis 2210 To: freebsd-questions@freebsd.org Cc: freebsd-scsi@freebsd.org Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk I have a Pentium 90 w/ an Intel Neptune system board (Premiere PCI II) w/ 2 Western Digital hard drives on the built-in EIDE controller (1 1.2GB as DOS C:\ and 1 1.0GB as DOS D:\), an Adaptec AHA1542CP controller (this is the new Plug and Play one), a Plextor 6X CD-ROM drive connected to the Adaptec (SCSI ID 6), and three external Micropolis 2210 1050MB hard drives, set to SCSI ID's 0,1, and 2 respectively. Also, the Adaptec is on port 334 instead of 330 so it won't conflict w/ my SB-AWE32/Roland daughtercard combination. My goal is to have DOS & Win95 on the two Western Digitals and FreeBSD on one of the SCSI's. (The other 2, ID's 1 and 2, already have Linux and SunOS 5.4 for X86 installed on them w/ no problems.). I was able to boot up FreeBSD using the FBSDBOOT.EXE on the FreeBSD 2.0.5 Walnut Creek CD and install the software (it did complain bitterly about the disk geometry on the SCSI drive, but I persisted and installed anyway) with no problems. However, now I can't boot up the system using either the OSBS boot manager software from the CD or the boot floppy - it just locks up after stating "Waiting for SCSI devices to settle.". What is the proper way to install FreeBSD and then boot the OS? Thanks for your help. -Ryan R. Donovan rdonovan@wln.com From owner-freebsd-scsi Mon Jan 15 01:25:10 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA29413 for freebsd-scsi-outgoing; Mon, 15 Jan 1996 01:25:10 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA29268 for ; Mon, 15 Jan 1996 01:22:45 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA07789 for ; Mon, 15 Jan 1996 10:21:41 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id KAA12024 for freebsd-scsi@freefall.freebsd.org; Mon, 15 Jan 1996 10:21:41 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.3/8.6.9) id KAA11114 for freebsd-scsi@freefall.freebsd.org; Mon, 15 Jan 1996 10:18:48 +0100 (MET) From: J Wunsch Message-Id: <199601150918.KAA11114@uriah.heep.sax.de> Subject: Re: Calling st_unmount for nrst* devices To: freebsd-scsi@freefall.freebsd.org Date: Mon, 15 Jan 1996 10:18:47 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199601141852.FAA14785@godzilla.zeta.org.au> from "Bruce Evans" at Jan 15, 96 05:52:34 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk As Bruce Evans wrote: > > I don't see the problem. If you're controlling the device interactively, > then just type "st rewoffl". ``mt rewoffl'', that it is. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Mon Jan 15 01:57:56 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA01553 for freebsd-scsi-outgoing; Mon, 15 Jan 1996 01:57:56 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA01514 for ; Mon, 15 Jan 1996 01:56:11 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA09189; Mon, 15 Jan 1996 10:55:11 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id KAA12212; Mon, 15 Jan 1996 10:55:10 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.3/8.6.9) id KAA11225; Mon, 15 Jan 1996 10:26:42 +0100 (MET) From: J Wunsch Message-Id: <199601150926.KAA11225@uriah.heep.sax.de> Subject: Re: Cant Boot on AHA1542CP / Micropolis 2210 To: rdonovan@wln.com (Richard W Donovan) Date: Mon, 15 Jan 1996 10:26:42 +0100 (MET) Cc: freebsd-scsi@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "Richard W Donovan" at Jan 14, 96 07:03:12 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk As Richard W Donovan wrote: > I have a [...] > an Adaptec AHA1542CP controller (this is > the new Plug and Play one), ... > However, now I can't boot up the system using either the OSBS > boot manager software from the CD or the boot floppy - it just locks up > after stating "Waiting for SCSI devices to settle.". What is the proper > way to install FreeBSD and then boot the OS? Peter Dufault has been fixing the Plug'nPray AHA1542 adapter handling after 2.0.5R. You need a newer version (2.1R), or a running FreeBSD where you can build a new kernel with the following patch applied to /sys/i386/isa/aha1542.c: Index: aha1542.c =================================================================== RCS file: /home/cvs/src/sys/i386/isa/aha1542.c,v retrieving revision 1.47 retrieving revision 1.48 diff -u -r1.47 -r1.48 --- aha1542.c 1995/09/19 18:55:04 1.47 +++ aha1542.c 1995/10/01 15:09:51 1.48 @@ -12,7 +12,7 @@ * on the understanding that TFS is not responsible for the correct * functioning of this software in any circumstances. * - * $Id: aha1542.c,v 1.47 1995/09/19 18:55:04 bde Exp $ + * $Id: aha1542.c,v 1.48 1995/10/01 15:09:51 dufault Exp $ */ /* @@ -34,6 +34,7 @@ #include #include #include +#include /* XXX for bootverbose: a funny place */ #endif /* KERNEL */ #include #include @@ -255,6 +256,7 @@ /* 0x43 ('C') = AHA-1542C */ /* 0x44 ('D') = AHA-1542CF */ /* 0x45 ('E') = AHA-1542CF, BIOS v2.01 */ + /* 0x46 ('F') = AHA-1542CP, "Plug'nPlay" */ u_char spec_opts; /* special options ID */ /* 0x41 = Board is standard model */ u_char revision_1; /* firmware revision [0-9A-Z] */ @@ -963,7 +965,13 @@ scsi_done(xs); } -static char *board_rev(int type) +/* Macro to determine that a rev is potentially a new valid one + * so that the driver doesn't keep breaking on new revs as it + * did for the CF and CP. + */ +#define PROBABLY_NEW_BOARD(REV) (REV > 0x43 && REV < 0x56) + +static char *board_rev(int unit, int type) { switch(type) { @@ -974,7 +982,20 @@ case 0x43: return "AHA-1542C"; case 0x44: return "AHA-1542CF"; case 0x45: return "AHA-1542CF BIOS v2.01"; - default: return "Unknown board"; + case 0x46: return "AHA-1542CP"; + + default: + + + if (PROBABLY_NEW_BOARD(type)) + { + printf("aha%d: Assuming type %02x is a new board.\n", + unit, type); + return "New Adaptec rev?"; + } + + printf("aha%d: type %02x is an unknown board.\n", unit, type); + return "Unknown board"; } } @@ -986,6 +1007,7 @@ int unit; { struct aha_data *aha = ahadata[unit]; + char *desc; unsigned char ad[3]; volatile int i, sts; struct aha_config conf; @@ -1067,62 +1089,69 @@ aha->flags = SDEV_BOUNCE; +#define PRVERBOSE(x) if (bootverbose) printf x + /* - * If we are a 1542C or 1542CF disable the extended bios so that the + * If we are a new type of 1542 board (anything newer than a 1542C) + * then disable the extended bios so that the * mailbox interface is unlocked. * This is also true for the 1542B Version 3.20. First Adaptec * board that supports >1Gb drives. * No need to check the extended bios flags as some of the * extensions that cause us problems are not flagged in that byte. */ - printf("aha%d: %s-V%c.%c", - unit, board_rev(inquire.boardid), inquire.revision_1, - inquire.revision_2); + desc = board_rev(unit, inquire.boardid); + + PRVERBOSE( ("aha%d: Rev %02x (%s) V%c.%c", + unit, inquire.boardid, desc, inquire.revision_1, + inquire.revision_2) ); - if ((inquire.boardid == 0x43) || (inquire.boardid == 0x44) || - (inquire.boardid == 0x45) || (inquire.boardid == 0x41 + if (PROBABLY_NEW_BOARD(inquire.boardid) || + (inquire.boardid == 0x41 && inquire.revision_1 == 0x31 && inquire.revision_2 == 0x34)) { aha_cmd(unit, 0, sizeof(extbios), 0, &extbios, AHA_EXT_BIOS); #ifdef AHADEBUG printf("aha%d: extended bios flags %x\n", unit, extbios.flags); #endif /* AHADEBUG */ - printf(", enabling mailbox"); + PRVERBOSE( (", enabling mailbox") ); aha_cmd(unit, 2, 0, 0, 0, AHA_MBX_ENABLE, 0, extbios.mailboxlock); - } /* Which boards support residuals? Some early 1542A's apparently * don't. The 1542B with V0.5 of the software does, so I've * arbitrarily set that as the earliest rev. */ - if ((inquire.boardid == 0x43) || (inquire.boardid == 0x44) || - (inquire.boardid == 0x45) || (inquire.boardid == 0x41 + if (PROBABLY_NEW_BOARD(inquire.boardid) || + (inquire.boardid == 0x41 && (inquire.revision_1 > '0' || inquire.revision_2 >= '5'))) { - printf(", enabling residuals"); + + PRVERBOSE( (", enabling residuals") ); + aha->init_opcode = AHA_INIT_RESID_CCB; aha->sg_opcode = AHA_INIT_SG_RESID_CCB; } /* Which boards support target operations? The 1542C completely * locks up the SCSI bus if you enable them. I'm only sure - * about the B. + * about the B, which was sold in the OEM market as a target + * board. */ if (inquire.boardid == 0x41) { - printf(", target ops"); + PRVERBOSE( (", target ops") ); aha->flags |= SDEV_TARGET_OPS; } - printf("\n"); + PRVERBOSE( ("\n") ); /* * setup dma channel from jumpers and save int * level */ - printf("aha%d: reading board settings, ", unit); -#define PRNT(x) printf(x) + PRVERBOSE(("aha%d: reading board settings, ", unit)); + if (inquire.boardid == 0x20) { DELAY(1000); /* for Bustek 545 */ } @@ -1133,63 +1162,60 @@ outb(0x0b, 0x0c); outb(0x0a, 0x00); aha->aha_dma = 0; - PRNT("dma=0 "); break; case CHAN5: outb(0xd6, 0xc1); outb(0xd4, 0x01); aha->aha_dma = 5; - PRNT("dma=5 "); break; case CHAN6: outb(0xd6, 0xc2); outb(0xd4, 0x02); aha->aha_dma = 6; - PRNT("dma=6 "); break; case CHAN7: outb(0xd6, 0xc3); outb(0xd4, 0x03); aha->aha_dma = 7; - PRNT("dma=7 "); break; default: - printf("illegal dma jumper setting\n"); + printf("aha%d: illegal dma jumper setting\n", unit); return (EIO); } + + PRVERBOSE( ("dma=%d ", aha->aha_dma) ); + switch (conf.intr) { case INT9: aha->aha_int = 9; - PRNT("int=9 "); break; case INT10: aha->aha_int = 10; - PRNT("int=10 "); break; case INT11: aha->aha_int = 11; - PRNT("int=11 "); break; case INT12: aha->aha_int = 12; - PRNT("int=12 "); break; case INT14: aha->aha_int = 14; - PRNT("int=14 "); break; case INT15: aha->aha_int = 15; - PRNT("int=15 "); break; default: - printf("illegal int jumper setting\n"); + printf("aha%d: illegal int jumper setting\n", unit); return (EIO); } + PRVERBOSE( ("int=%d ", aha->aha_int) ); + /* who are we on the scsi bus? */ aha->aha_scsi_dev = conf.scsi_dev; + PRVERBOSE( ("id=%d ", aha->aha_scsi_dev) ); + /* * Change the bus on/off times to not clash with other dma users. */ @@ -1205,7 +1231,7 @@ return (EIO); } #else - printf (" (bus speed defaulted)\n"); + PRVERBOSE( (" (bus speed defaulted)\n") ); #endif /*TUNE_1542*/ /* * Initialize mail box -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Mon Jan 15 04:42:38 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA11240 for freebsd-scsi-outgoing; Mon, 15 Jan 1996 04:42:38 -0800 (PST) Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA11235 for ; Mon, 15 Jan 1996 04:42:31 -0800 (PST) Received: by Sysiphos id AA00997 (5.67b/IDA-1.5 for scsi@freebsd.org); Mon, 15 Jan 1996 13:41:09 +0100 Message-Id: <199601151241.AA00997@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Mon, 15 Jan 1996 13:41:09 +0100 In-Reply-To: Peter Dufault "Re: FreeBSD NCR driver timeout?" (Jan 14, 19:18) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: Peter Dufault Subject: Re: FreeBSD NCR driver timeout? Cc: scsi@freebsd.org Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk On Jan 14, 19:18, Peter Dufault wrote: } Subject: Re: FreeBSD NCR driver timeout? } > >Well, most devices will not require 1.6s for a single } > >bus transaction (locking out all other devices ...). } > } > I completely agree here... It *SHOUDN'T*, but it does. :-) } } This is what I mentioned the Microtek scanner does. It locks up } the SCSI bus while it positions the scan head. This is the problem } with these "PC" scanners that ship with their own SCSI controllers } - they can be completely anti-social about what they do on the bus. } } Unfortunately, Stefan, I think that if possible we ought to provide } the same host adapter behavior across all adapters and use the } timeout passed in (if we can), even if it is for an ungodly amount } of time. } } Keep in mind that someone might elect to dedicate an NCR controller } to talking to an anti-social scanner and will be disappointed if } they can't make it work with a timeout of, say, 10 seconds. After } all, those NCR controllers are among the cheapest we support and } therefore a good choice for a second dedicated bus. Well, guess I've got no choice :) I'm not sure whether masking HTH interrupts does not have bad effects, and I guess the command timeout handler has to be extended to give the same information as is currently available to the handshake timeout handler ... Ok. If there is a success report, I'll at least make disabling HTH a kernel config option. It is not required in the GENERIC kernel, since nobody will boot from a SCSI scanner anytime soon :) If this doesn't break anything else, it may become a standard feature, later ... 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 Mon Jan 15 06:09:47 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA14941 for freebsd-scsi-outgoing; Mon, 15 Jan 1996 06:09:47 -0800 (PST) Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA14931 Mon, 15 Jan 1996 06:09:44 -0800 (PST) Message-Id: <199601151409.GAA14931@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol To: se@ZPR.Uni-Koeln.DE (Stefan Esser) cc: Peter Dufault , scsi@freebsd.org Subject: Re: FreeBSD NCR driver timeout? In-reply-to: Your message of "Mon, 15 Jan 1996 13:41:09 +0100." <199601151241.AA00997@Sysiphos> Date: Mon, 15 Jan 1996 06:09:44 -0800 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk >On Jan 14, 19:18, Peter Dufault wrote: >} Unfortunately, Stefan, I think that if possible we ought to provide >} the same host adapter behavior across all adapters and use the >} timeout passed in (if we can), even if it is for an ungodly amount >} of time. >} >} Keep in mind that someone might elect to dedicate an NCR controller >} to talking to an anti-social scanner and will be disappointed if >} they can't make it work with a timeout of, say, 10 seconds. After >} all, those NCR controllers are among the cheapest we support and >} therefore a good choice for a second dedicated bus. > >Well, guess I've got no choice :) Well you do have a choice. I think our shortest timeout is 10s right now so this should work. I would suggest aborting the command if you see enought HTH timeouts to be roughly equivilent to the timeout value in the xfer or if your timeout handler is called. This would give you all the information you have now, but a longer (tunable) timeout. >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 -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Mon Jan 15 07:48:53 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA19341 for freebsd-scsi-outgoing; Mon, 15 Jan 1996 07:48:53 -0800 (PST) Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA19322 for ; Mon, 15 Jan 1996 07:48:41 -0800 (PST) Received: by Sysiphos id AA08578 (5.67b/IDA-1.5 for scsi@freebsd.org); Mon, 15 Jan 1996 16:47:09 +0100 Message-Id: <199601151547.AA08578@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Mon, 15 Jan 1996 16:47:08 +0100 In-Reply-To: "Justin T. Gibbs" "Re: FreeBSD NCR driver timeout?" (Jan 15, 6:09) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: "Justin T. Gibbs" Subject: Re: FreeBSD NCR driver timeout? Cc: scsi@freebsd.org Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk On Jan 15, 6:09, "Justin T. Gibbs" wrote: } Subject: Re: FreeBSD NCR driver timeout? } >On Jan 14, 19:18, Peter Dufault wrote: } >} Unfortunately, Stefan, I think that if possible we ought to provide } >} the same host adapter behavior across all adapters and use the } >} timeout passed in (if we can), even if it is for an ungodly amount } >} of time. } >} } >} Keep in mind that someone might elect to dedicate an NCR controller } >} to talking to an anti-social scanner and will be disappointed if } >} they can't make it work with a timeout of, say, 10 seconds. After } >} all, those NCR controllers are among the cheapest we support and } >} therefore a good choice for a second dedicated bus. } > } >Well, guess I've got no choice :) } } Well you do have a choice. I think our shortest timeout is 10s right now } so this should work. I would suggest aborting the command if you see } enought HTH timeouts to be roughly equivilent to the timeout value in the } xfer or if your timeout handler is called. This would give you all the } information you have now, but a longer (tunable) timeout. I'm not sure whether the command that failed can be restarted ... A timeout is generally considered a fault, and I probably have to disable it, and to make a software timer issue a NCR halt in such a way, that the chips state is conserved for analysis by the error handler. 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 Mon Jan 15 11:23:31 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA01844 for freebsd-scsi-outgoing; Mon, 15 Jan 1996 11:23:31 -0800 (PST) Received: from argus.flash.net (root@[206.149.24.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA01837 for ; Mon, 15 Jan 1996 11:23:27 -0800 (PST) Received: (from lists@localhost) by argus.flash.net (8.6.12/8.6.12) id NAA03367 for freebsd-scsi@freebsd.org; Mon, 15 Jan 1996 13:22:31 -0600 From: mailing list account Message-Id: <199601151922.NAA03367@argus.flash.net> Subject: IBM MTA-3230 m-o drive To: freebsd-scsi@freebsd.org Date: Mon, 15 Jan 1996 13:22:30 -0600 (CST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk okay, now that i'm back on the net.... I have managed to get my IBM MTA-3230 3.5" m-o drive working by playing with the dipswitches on the drive [type 0 as opposed to type 7], but have a problem now that only happens under freebsd [2.0,5, and 2.1.0]. when I reboot, my aha-1542cf or the drive doesn't seem to reset properly. The scsi bios will see a drive there, but will not be able to get any info from the drive [name, type, etc], freebsd will boot and say it is a type 0, fixed, unknown name, but come up with the proper geometry. mounting is possible in this state, but it may be indicative of a bigger problem. The only known fix for this is to power down both the system and the drive, bring up the drive, then the system, in that order. just powering down the system will not fix the problem. I do not seem to remember this happening with the AHA-2940W controller under 2.0.5. Any ideas? Jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" jbryant@argus.flash.net - FlashNet Communications - Ft. Worth, Texas From owner-freebsd-scsi Mon Jan 15 15:38:57 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA20062 for freebsd-scsi-outgoing; Mon, 15 Jan 1996 15:38:57 -0800 (PST) Received: from sylvia.tummy.com (jafo@ariel.tummy.com [206.28.166.237]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id PAA20053 for ; Mon, 15 Jan 1996 15:38:52 -0800 (PST) Received: (from jafo@localhost) by sylvia.tummy.com (8.7.3/8.7.3) id RAA16361; Mon, 15 Jan 1996 17:38:43 -0600 From: Sean Reifschneider Message-Id: <199601152338.RAA16361@sylvia.tummy.com> Subject: NCR Handshake timeout To: freebsd-scsi@freebsd.org Date: Mon, 15 Jan 1996 17:38:42 -0600 (CST) Cc: se@mi.Uni-Koeln.de X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk Wolfgang Stanglmeier suggested adding the following line to the kernel config file: options "SCSI_NCR_NO_HTH_TIMEOUT" # Disable handshake timeout and applying the patch included below (I made this from the 2.1.0 distribution ncr.c). This sets the handshake timeout to unlimited insetad of 1.6 seconds. Each nibble is "2 ** n * 50us" with 0 representing infinate timeout. This did quite effectively remove the handshake timeout and allowed the scanner to pound right along. Apparently, just removing the HTH from the interrupt mask causes confusion. The NCR chip generates an interrupt, and the driver just ignores it, so it gets flaky. Thanks to all, Sean ================cut here===================== *** ncr.c.orig Mon Jan 15 14:04:39 1996 --- ncr.c Mon Jan 15 17:25:18 1996 *************** *** 4438,4444 **** --- 4438,4448 ---- OUTB (nc_ctest4, 0x08 ); /* enable master parity checking */ OUTB (nc_stest2, EXT ); /* Extended Sreq/Sack filtering */ OUTB (nc_stest3, TE ); /* TolerANT enable */ + #ifdef SCSI_NCR_NO_HTH_TIMEOUT + OUTB (nc_stime0, 0x0b ); /* HTH = *NONE* STO = 0.1 sec. */ + #else OUTB (nc_stime0, 0xfb ); /* HTH = 1.6sec STO = 0.1 sec. */ + #endif /* ** Reinitialize usrsync. ================cut here===================== -- "We just wanted to give the band a little more thrust than most other bands." - Donald Fagen's reply to why they chose the band name 'Steely Dan' Sean Reifschneider, Inimitably Superfluous URL: XVScan -- HP-UX/Linux X11 scanning software. From owner-freebsd-scsi Mon Jan 15 15:46:25 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA20592 for freebsd-scsi-outgoing; Mon, 15 Jan 1996 15:46:25 -0800 (PST) Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA20587 for ; Mon, 15 Jan 1996 15:46:20 -0800 (PST) Received: by Sysiphos id AA18145 (5.67b/IDA-1.5 for scsi@freebsd.org); Tue, 16 Jan 1996 00:46:03 +0100 Message-Id: <199601152346.AA18145@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Tue, 16 Jan 1996 00:46:02 +0100 In-Reply-To: Sean Reifschneider "NCR Handshake timeout" (Jan 15, 17:38) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: Sean Reifschneider Subject: Re: NCR Handshake timeout Cc: scsi@freebsd.org Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk On Jan 15, 17:38, Sean Reifschneider wrote: } Subject: NCR Handshake timeout } Wolfgang Stanglmeier suggested adding the following line to the kernel } config file: } } options "SCSI_NCR_NO_HTH_TIMEOUT" # Disable handshake timeout } } and applying the patch included below (I made this from the 2.1.0 } distribution ncr.c). This sets the handshake timeout to unlimited } insetad of 1.6 seconds. Each nibble is "2 ** n * 50us" with 0 } representing infinate timeout. Ok. I knew that 100us was the lowest value, and had expected '0' to disable the timeouts, but had not had time to verify this. I already commited a patch to FreeBSD-current, which unconditionally disables the handshake time out. There has always been a software timeout, and I'll see whether there are any reports of problems after this change ... } This did quite effectively remove the handshake timeout and allowed the } scanner to pound right along. Fine! } Apparently, just removing the HTH from the interrupt mask causes confusion. } The NCR chip generates an interrupt, and the driver just ignores it, so it } gets flaky. Yes. I did expect problems like this. The interrupt mask register may prevent that the interrupt pin get sactive, but the chip sees the handshake timeout situation anyway. That was the reason that I did not apply that change to -current ... 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 Mon Jan 15 17:21:53 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA28068 for freebsd-scsi-outgoing; Mon, 15 Jan 1996 17:21:53 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA28059 for ; Mon, 15 Jan 1996 17:21:47 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id CAA13151; Tue, 16 Jan 1996 02:21:39 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id CAA24320; Tue, 16 Jan 1996 02:21:38 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.3/8.6.9) id CAA14868; Tue, 16 Jan 1996 02:13:19 +0100 (MET) From: J Wunsch Message-Id: <199601160113.CAA14868@uriah.heep.sax.de> Subject: Re: IBM MTA-3230 m-o drive To: lists@argus.flash.net (mailing list account) Date: Tue, 16 Jan 1996 02:13:18 +0100 (MET) Cc: freebsd-scsi@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199601151922.NAA03367@argus.flash.net> from "mailing list account" at Jan 15, 96 01:22:30 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk As mailing list account wrote: > I have managed to get my IBM MTA-3230 3.5" m-o drive working by > playing with the dipswitches on the drive [type 0 as opposed to type > 7], but have a problem now that only happens under freebsd [2.0,5, > and 2.1.0]. Can you turn the DIP switch into type 7, and try the `od' driver? It's in -current, and it's also available as a patch set on the 2.1R CD: usr/local/xperimnt/joergs-2.2-mixture/od-driver.diff (This is the extracted version on the second CD.) -- 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 Jan 16 01:58:27 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA01196 for freebsd-scsi-outgoing; Tue, 16 Jan 1996 01:58:27 -0800 (PST) Received: from hda.com (hda.com [199.232.40.182]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA01191 for ; Tue, 16 Jan 1996 01:58:24 -0800 (PST) Received: (from dufault@localhost) by hda.com (8.6.11/8.6.9) id FAA20190; Tue, 16 Jan 1996 05:02:00 -0500 From: Peter Dufault Message-Id: <199601161002.FAA20190@hda.com> Subject: Re: IBM MTA-3230 m-o drive To: lists@argus.flash.net (mailing list account) Date: Tue, 16 Jan 1996 05:01:59 -0500 (EST) Cc: freebsd-scsi@FreeBSD.org In-Reply-To: <199601151922.NAA03367@argus.flash.net> from "mailing list account" at Jan 15, 96 01:22:30 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@FreeBSD.org Precedence: bulk > when I reboot, my aha-1542cf or the drive doesn't seem to reset properly. The > scsi bios will see a drive there, but will not be able to get any info from > the drive [name, type, etc], freebsd will boot and say it is a type 0, fixed, > unknown name, but come up with the proper geometry. mounting is possible in > this state, but it may be indicative of a bigger problem. Can you post the dmesg output? -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267 From owner-freebsd-scsi Tue Jan 16 04:00:11 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA09495 for freebsd-scsi-outgoing; Tue, 16 Jan 1996 04:00:11 -0800 (PST) Received: from zit1.zit.th-darmstadt.de (zit1.zit.th-darmstadt.de [130.83.63.20]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA09415 for ; Tue, 16 Jan 1996 03:59:17 -0800 (PST) Received: (from petzi@localhost) by zit1.zit.th-darmstadt.de (8.6.12/8.6.9) id MAA00545; Tue, 16 Jan 1996 12:58:56 +0100 Date: Tue, 16 Jan 1996 12:58:56 +0100 (MET) From: Michael Beckmann To: scsi@freebsd.org Subject: Disk or controller or driver failure ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk Hi, today I found the hard disk in one of my systems spun down. I got lots of error messages on the console, and after a while the system rebooted. This is what I read on the console before it rebooted: sd0(ncr0:0:0): NOT READY asc:4.2 There was a similar problem this morning, which was logged in /var/log/messages (I wasn't there): Jan 16 04:08:55 zit1 /kernel: sd0(ncr0:0:0): Deferred Error: HARDWARE FAILURE info:50eb0 asc:15,0 Random positioning error field replaceable unit: 1 sks:80,3 Jan 16 04:09:10 zit1 /kernel: sd0(ncr0:0:0): Deferred Error: HARDWARE FAILURE info:50eb6 asc:15,0 Random positioning error field replaceable unit: 1 sks:80,3 Jan 16 06:11:56 zit1 /kernel: sd0(ncr0:0:0): Deferred Error: HARDWARE FAILURE info:50ef0 asc:15,0 Random positioning error field replaceable unit: 1 sks:80,3 Jan 16 06:12:00 zit1 /kernel: sd0(ncr0:0:0): Deferred Error: HARDWARE FAILURE info:50ef4 asc:15,0 Random positioning error field replaceable unit: 1 sks:80,3 Jan 16 06:12:06 zit1 /kernel: sd0(ncr0:0:0): Deferred Error: HARDWARE FAILURE info:50ef8 asc:15,0 Random positioning error field replaceable unit: 1 sks:80,3 Jan 16 06:12:12 zit1 /kernel: sd0(ncr0:0:0): Deferred Error: HARDWARE FAILURE info:50ef4 asc:15,0 Random positioning error field replaceable unit: 1 sks:80,3 Jan 16 06:12:16 zit1 /kernel: sd0(ncr0:0:0): Deferred Error: HARDWARE FAILURE info:50efc asc:15,0 Random positioning error field replaceable unit: 1 sks:80,3 Are these signs of a dying disk or is it the controller ? Or might it be a driver problem ? Has anyone seen this before ? Thanks for any help. Michael From owner-freebsd-scsi Tue Jan 16 04:39:11 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA12444 for freebsd-scsi-outgoing; Tue, 16 Jan 1996 04:39:11 -0800 (PST) Received: from argus.flash.net (root@[206.149.24.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA12439 for ; Tue, 16 Jan 1996 04:39:07 -0800 (PST) Received: (from lists@localhost) by argus.flash.net (8.6.12/8.6.12) id GAA00305; Tue, 16 Jan 1996 06:37:40 -0600 From: mailing list account Message-Id: <199601161237.GAA00305@argus.flash.net> Subject: Re: IBM MTA-3230 m-o drive To: dufault@hda.com (Peter Dufault) Date: Tue, 16 Jan 1996 06:37:39 -0600 (CST) Cc: freebsd-scsi@freebsd.org In-Reply-To: <199601161002.FAA20190@hda.com> from "Peter Dufault" at Jan 16, 96 05:01:59 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk > >>when I reboot, my aha-1542cf or the drive doesn't seem to reset properly. The >>scsi bios will see a drive there, but will not be able to get any info from >>the drive [name, type, etc],freebsd will boot and say it is a type 0,fixed, >>unknown name, but come up with the proper geometry. mounting is possible in >> this state, but it may be indicative of a bigger problem. > > Can you post the dmesg output? Here is the full dmesg output before a reboot: ----------------------------------------------------------------------------- FreeBSD 2.1.0-RELEASE #0: Fri Jan 5 17:07:35 CST 1996 jbryant@argus.flash.net:/usr/src/sys/compile/ARGUS CPU: i486DX (486-class CPU) real memory = 21233664 (20736K bytes) avail memory = 18735104 (18296K bytes) Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> psm0 not found at 0x60 lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2 at 0x3e8-0x3ef irq 10 on isa sio2: type 16550A sio3 at 0x2e8-0x2ef irq 11 on isa sio3: type 16550A pca0 on motherboard pca0: PC speaker audio driver 200 nSEC ok, using 250 nSEC aha0 at 0x330-0x333 irq 9 drq 6 on isa (aha0:0:0): "SEAGATE ST32550N 0011" type 0 fixed SCSI 2 sd0(aha0:0:0): Direct-Access 2047MB (4194058 512 byte sectors) sd0(aha0:0:0): with 3511 cyls, 11 heads, and an average 108 sectors/track (aha0:1:0): "IBM MTA-3230TC2210!B 0" type 0 removable SCSI 2 sd1(aha0:1:0): Direct-Access 217MB (446325 512 byte sectors) sd1(aha0:1:0): with 17934 cyls, 1 heads, and an average 24 sectors/track wdc0 at 0x1f0-0x1f7 irq 14 flags 0x80ff80ff on isa wdc0: unit 0 (wd0): , multi-block-16 wd0: 1033MB (2116800 sectors), 2100 cyls, 16 heads, 63 S/T, 512 B/S fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 765 fd0: 1.44MB 3.5in ft0: Colorado tape 1 3C5x9 board(s) on ISA found at 0x210 ep0 at 0x210-0x21f irq 15 on isa ep0: aui/bnc[*BNC*] address 00:20:af:d2:e4:ae irq 15 npx0 on motherboard npx0: INT 16 interface joy0 not found at 0x201 sb0 at 0x220 irq 5 drq 5 on isa sb0: sbxvi0 at 0x0 drq 5 on isa sbxvo0: sbmidi0 at 0x300 on isa opl0 at 0x388 on isa opl0: ----------------------------------------------------------------------------- here is after the reboot [with the -v option added to the boot]: ----------------------------------------------------------------------------- FreeBSD 2.1.0-RELEASE #0: Fri Jan 5 17:07:35 CST 1996 jbryant@argus.flash.net:/usr/src/sys/compile/ARGUS CPU: i486DX (486-class CPU) real memory = 21233664 (20736K bytes) avail memory = 18735104 (18296K bytes) Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> psm0 not found at 0x60 lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface bpf: lp0 attached sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2 at 0x3e8-0x3ef irq 10 on isa sio2: type 16550A sio3 at 0x2e8-0x2ef irq 11 on isa sio3: type 16550A pca0 on motherboard pca0: PC speaker audio driver aha0: Rev 45 (AHA-1542CF BIOS v2.01) VE.0, enabling mailbox, enabling residuals aha0: reading board settings, dma=6 int=9 id=7 200 nSEC ok, using 250 nSEC aha0 at 0x330-0x333 irq 9 drq 6 on isa Choosing drivers for scbus configured at 0 (aha0:0:0): "SEAGATE ST32550N 0011" type 0 fixed SCSI 2 sd is configured at 0 sd0(aha0:0:0): Direct-Access 2047MB (4194058 512 byte sectors) sd0(aha0:0:0): with 3511 cyls, 11 heads, and an average 108 sectors/track (aha0:1:0): "unknown unknown ????" type 0 fixed SCSI 0 sd is configured at 1 sd1(aha0:1:0): Direct-Access 217MB (446325 512 byte sectors) sd1(aha0:1:0): with 17934 cyls, 1 heads, and an average 24 sectors/track wdc0 at 0x1f0-0x1f7 irq 14 flags 0x80ff80ff on isa wdc0: unit 0 (wd0): , multi-block-16 wd0: 1033MB (2116800 sectors), 2100 cyls, 16 heads, 63 S/T, 512 B/S fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 765 fd0: 1.44MB 3.5in ft0: Colorado tape 1 3C5x9 board(s) on ISA found at 0x210 ep0 at 0x210-0x21f irq 15 on isa ep0: aui/bnc[*BNC*] address 00:20:af:d2:e4:ae irq 15 bpf: ep0 attached npx0 on motherboard npx0: INT 16 interface joy0 not found at 0x201 sb0 at 0x220 irq 5 drq 5 on isa sb0: sbxvi0 at 0x0 drq 5 on isa sbxvo0: sbmidi0 at 0x300 on isa opl0 at 0x388 on isa opl0: BIOS Geometries: 0:020b3f3f 0..523=524 cylinders, 0..63=64 heads, 1..63=63 sectors 1:03fe3f20 0..1022=1023 cylinders, 0..63=64 heads, 1..32=32 sectors 0 accounted for bpf: ds0 attached bpf: lo0 attached bpf: ppp0 attached bpf: ppp1 attached bpf: ppp2 attached bpf: ppp3 attached bpf: sl0 attached bpf: sl1 attached bpf: sl2 attached bpf: sl3 attached bpf: tun0 attached wd0s1: type 0xa5, start 63, end = 2116799, size 2116737 : OK sd0s1: type 0x6, start 32, end = 1023999, size 1023968 : OK sd0s2: type 0xa5, start 1024000, end = 4192255, size 3168256 : OK ----------------------------------------------------------------------------- check the diff between the two on aha0:1:0 this is after the reboot command, and [if i remember right] the scsi-bios says "Device name not available", but does detect the device, otherwise the the message wouldn't be there at all, plus FreeBSD seems to be getting the proper geometry, at least making mounts possible. Jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" jbryant@argus.flash.net - FlashNet Communications - Ft. Worth, Texas From owner-freebsd-scsi Tue Jan 16 08:24:20 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA23504 for freebsd-scsi-outgoing; Tue, 16 Jan 1996 08:24:20 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA23437 Tue, 16 Jan 1996 08:24:05 -0800 (PST) Received: from zit1.zit.th-darmstadt.de (zit1.zit.th-darmstadt.de [130.83.63.20]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id FAA25867 ; Tue, 16 Jan 1996 05:22:59 -0800 Received: (from petzi@localhost) by zit1.zit.th-darmstadt.de (8.6.12/8.6.9) id OAA01178; Tue, 16 Jan 1996 14:22:13 +0100 Date: Tue, 16 Jan 1996 14:22:13 +0100 (MET) From: Michael Beckmann To: Stefan Esser cc: hardware@FreeBSD.org, scsi@FreeBSD.org Subject: Re: Disk or controller or driver failure ? In-Reply-To: <199601161259.AA00719@Sysiphos> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.org Precedence: bulk > } Are these signs of a dying disk or is it the controller ? Or might it be > } a driver problem ? Has anyone seen this before ? > > Well, I'd take those messages to mean what they say: > > HARDWARE FAILURE: Random positioning error. > > This is an extended error code, returned by the hard disk, > and printed by the generic SCSI code. > > Make backups ! Every day ! > PS: You may want to check the power supply, too. This > could be caused by an out of spec 12V supply ... All I have is a digital voltmeter. I could only check if the voltage is correct; not if there are "brownouts" or something. But thanks a lot for this hint. You might be right. Maybe I'll have to change the power supply (build my machine into another housing). Michael From owner-freebsd-scsi Tue Jan 16 08:24:36 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA23546 for freebsd-scsi-outgoing; Tue, 16 Jan 1996 08:24:36 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA23449 Tue, 16 Jan 1996 08:24:08 -0800 (PST) Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by who.cdrom.com (8.6.12/8.6.11) with SMTP id EAA25637 ; Tue, 16 Jan 1996 04:59:50 -0800 Received: by Sysiphos id AA00719 (5.67b/IDA-1.5); Tue, 16 Jan 1996 13:59:40 +0100 Message-Id: <199601161259.AA00719@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Tue, 16 Jan 1996 13:59:39 +0100 In-Reply-To: Michael Beckmann "Disk or controller or driver failure ?" (Jan 16, 12:58) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: Michael Beckmann Subject: Re: Disk or controller or driver failure ? Cc: hardware@FreeBSD.org, scsi@FreeBSD.org Sender: owner-freebsd-scsi@FreeBSD.org Precedence: bulk On Jan 16, 12:58, Michael Beckmann wrote: } Subject: Disk or controller or driver failure ? } Hi, } } today I found the hard disk in one of my systems spun down. I got lots } of error messages on the console, and after a while the system } rebooted. This is what I read on the console before it rebooted: } } sd0(ncr0:0:0): NOT READY asc:4.2 } } There was a similar problem this morning, which was logged in } /var/log/messages (I wasn't there): } } Jan 16 04:08:55 zit1 /kernel: sd0(ncr0:0:0): Deferred Error: HARDWARE } FAILURE info:50eb0 asc:15,0 Random } positioning error field replaceable unit: 1 sks:80,3 } } Jan 16 04:09:10 zit1 /kernel: sd0(ncr0:0:0): Deferred Error: HARDWARE } FAILURE info:50eb6 asc:15,0 Random } positioning error field replaceable unit: 1 sks:80,3 [ ... ] } Are these signs of a dying disk or is it the controller ? Or might it be } a driver problem ? Has anyone seen this before ? Well, I'd take those messages to mean what they say: HARDWARE FAILURE: Random positioning error. This is an extended error code, returned by the hard disk, and printed by the generic SCSI code. Make backups ! Regards, STefan PS: You may want to check the power supply, too. This could be caused by an out of spec 12V supply ... -- 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 Tue Jan 16 09:31:00 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA27306 for freebsd-scsi-outgoing; Tue, 16 Jan 1996 09:31:00 -0800 (PST) Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA27300 for ; Tue, 16 Jan 1996 09:30:58 -0800 (PST) Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.9) id JAA24433; Tue, 16 Jan 1996 09:27:45 -0800 From: Julian Elischer Message-Id: <199601161727.JAA24433@ref.tfs.com> Subject: Re: IBM MTA-3230 m-o drive To: lists@argus.flash.net (mailing list account) Date: Tue, 16 Jan 1996 09:27:45 -0800 (PST) Cc: dufault@hda.com, freebsd-scsi@freebsd.org In-Reply-To: <199601161237.GAA00305@argus.flash.net> from "mailing list account" at Jan 16, 96 06:37:39 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk > (aha0:1:0): "IBM MTA-3230TC2210!B 0" type 0 removable SCSI 2 > sd1(aha0:1:0): Direct-Access 217MB (446325 512 byte sectors) > sd1(aha0:1:0): with 17934 cyls, 1 heads, and an average 24 sectors/track > After reboot: > (aha0:1:0): "unknown unknown ????" type 0 fixed SCSI 0 > sd is configured at 1 > sd1(aha0:1:0): Direct-Access 217MB (446325 512 byte sectors) > sd1(aha0:1:0): with 17934 cyls, 1 heads, and an average 24 sectors/track > > check the diff between the two on aha0:1:0 > > this is after the reboot command, and [if i remember right] the scsi-bios > says "Device name not available", but does detect the device, otherwise the > the message wouldn't be there at all, plus FreeBSD seems to be getting the > proper geometry, at least making mounts possible. basically the device is strange.... try setting the SCSI_DELAY (or is that SCSIDELAY?) option in the kernel config, to 30 and see if that changes it.. if it works, try reducing it to a lower value.. julian From owner-freebsd-scsi Tue Jan 16 10:58:35 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA03164 for freebsd-scsi-outgoing; Tue, 16 Jan 1996 10:58:35 -0800 (PST) Received: from argus.flash.net (root@[206.149.24.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA03159 for ; Tue, 16 Jan 1996 10:58:31 -0800 (PST) Received: (from lists@localhost) by argus.flash.net (8.6.12/8.6.12) id MAA00532; Tue, 16 Jan 1996 12:56:58 -0600 From: mailing list account Message-Id: <199601161856.MAA00532@argus.flash.net> Subject: Re: Disk or controller or driver failure ? To: petzi@zit.th-darmstadt.de (Michael Beckmann) Date: Tue, 16 Jan 1996 12:56:57 -0600 (CST) Cc: freebsd-scsi@freebsd.org In-Reply-To: from "Michael Beckmann" at Jan 16, 96 02:22:13 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk > > } Are these signs of a dying disk or is it the controller ? Or might it be > > } a driver problem ? Has anyone seen this before ? > > > > Well, I'd take those messages to mean what they say: > > > > HARDWARE FAILURE: Random positioning error. > > > > This is an extended error code, returned by the hard disk, > > and printed by the generic SCSI code. > > > > Make backups ! > > Every day ! > > > PS: You may want to check the power supply, too. This > > could be caused by an out of spec 12V supply ... > > All I have is a digital voltmeter. I could only check if the voltage is > correct; not if there are "brownouts" or something. But thanks a lot for > this hint. You might be right. Maybe I'll have to change the power supply > (build my machine into another housing). I think i had one of those when my stepper went bibi once. hard disks with the cover off make nice conversation pieces on the coffee table or mantlepiece.... :^( [and incredibly sad stories]. Jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" jbryant@argus.flash.net - FlashNet Communications - Ft. Worth, Texas From owner-freebsd-scsi Tue Jan 16 11:32:48 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA04941 for freebsd-scsi-outgoing; Tue, 16 Jan 1996 11:32:48 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA04930 for ; Tue, 16 Jan 1996 11:32:46 -0800 (PST) Received: from argus.flash.net (root@[206.149.24.19]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id LAA00112 for ; Tue, 16 Jan 1996 11:32:40 -0800 Received: (from lists@localhost) by argus.flash.net (8.6.12/8.6.12) id NAA00675; Tue, 16 Jan 1996 13:26:33 -0600 From: mailing list account Message-Id: <199601161926.NAA00675@argus.flash.net> Subject: Re: Disk or controller or driver failure ? To: se@zpr.uni-koeln.de (Stefan Esser) Date: Tue, 16 Jan 1996 13:26:33 -0600 (CST) Cc: freebsd-scsi@freebsd.org In-Reply-To: <199601161259.AA00719@Sysiphos> from "Stefan Esser" at Jan 16, 96 01:59:39 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk > > On Jan 16, 12:58, Michael Beckmann wrote: > } Subject: Disk or controller or driver failure ? > } Hi, > } > } today I found the hard disk in one of my systems spun down. I got lots > } of error messages on the console, and after a while the system > } rebooted. This is what I read on the console before it rebooted: > } > } sd0(ncr0:0:0): NOT READY asc:4.2 > } > } There was a similar problem this morning, which was logged in > } /var/log/messages (I wasn't there): > } > } Jan 16 04:08:55 zit1 /kernel: sd0(ncr0:0:0): Deferred Error: HARDWARE > } FAILURE info:50eb0 asc:15,0 Random > } positioning error field replaceable unit: 1 sks:80,3 > } > } Jan 16 04:09:10 zit1 /kernel: sd0(ncr0:0:0): Deferred Error: HARDWARE > } FAILURE info:50eb6 asc:15,0 Random > } positioning error field replaceable unit: 1 sks:80,3 > > [ ... ] > > } Are these signs of a dying disk or is it the controller ? Or might it be > } a driver problem ? Has anyone seen this before ? > > Well, I'd take those messages to mean what they say: > > HARDWARE FAILURE: Random positioning error. > > This is an extended error code, returned by the hard disk, > and printed by the generic SCSI code. > > Make backups ! > > Regards, STefan > > PS: You may want to check the power supply, too. This > could be caused by an out of spec 12V supply ... uh-yup, uh-yup, dat'z da one... clear a spot on yer coffee table.. you have definitely got a new conversation piece if you can get the cover off... as well as a sad story to tell. actually i was never sure if it was a stepper problem or a head melt, it was a barracuda, and seacrate hadn't yet fixed the barracuda head melt problem.... btw: it is an unwritten law that one will never be present to see this message in real-time... call it a gift from god at a bad time. i had just got home from work when i saw all the kernel printf's. i was too tired to get really pissed and commit hari-kari over my lost projects [that i had just made a major breakthrough on that morning]... M-A-K-E M-A-N-Y M-A-N-Y B-A-C-K-U-P-S !@# BTW: that last warning nevuh sticks until you get the above kernel printf's!! Jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" jbryant@argus.flash.net - FlashNet Communications - Ft. Worth, Texas From owner-freebsd-scsi Tue Jan 16 12:29:00 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA09062 for freebsd-scsi-outgoing; Tue, 16 Jan 1996 12:29:00 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA08841 for ; Tue, 16 Jan 1996 12:27:55 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id VAA01367; Tue, 16 Jan 1996 21:27:21 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id VAA04091; Tue, 16 Jan 1996 21:27:20 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.3/8.6.9) id VAA18808; Tue, 16 Jan 1996 21:24:54 +0100 (MET) From: J Wunsch Message-Id: <199601162024.VAA18808@uriah.heep.sax.de> Subject: Re: Disk or controller or driver failure ? To: petzi@zit.th-darmstadt.de (Michael Beckmann) Date: Tue, 16 Jan 1996 21:24:54 +0100 (MET) Cc: scsi@FreeBSD.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "Michael Beckmann" at Jan 16, 96 12:58:56 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@FreeBSD.org Precedence: bulk As Michael Beckmann wrote: > Jan 16 06:12:16 zit1 /kernel: sd0(ncr0:0:0): Deferred Error: HARDWARE > FAILURE info:50efc asc:15,0 Random > positioning error field replaceable unit: 1 sks:80,3 > > > Are these signs of a dying disk or is it the controller ? Or might it be > a driver problem ? Has anyone seen this before ? Your disk is going mad. :-( -- 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 Jan 17 00:51:34 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA26691 for freebsd-scsi-outgoing; Wed, 17 Jan 1996 00:51:34 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA26686 for ; Wed, 17 Jan 1996 00:51:29 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA25691; Wed, 17 Jan 1996 09:51:20 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id JAA09072; Wed, 17 Jan 1996 09:51:19 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.3/8.6.9) id JAA02175; Wed, 17 Jan 1996 09:25:56 +0100 (MET) From: J Wunsch Message-Id: <199601170825.JAA02175@uriah.heep.sax.de> Subject: Re: SCSI Scanner anybody? To: nate@sri.MT.net (Nate Williams) Date: Wed, 17 Jan 1996 09:25:56 +0100 (MET) Cc: jason@scott.net, freebsd-scsi@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199601170123.SAA06681@rocky.sri.MT.net> from "Nate Williams" at Jan 16, 96 06:23:57 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk (Redirected to freebsd-scsi) As Nate Williams wrote: > > > I sent this once but I believe that I didn't send it to the whole list. > > I have a HP 3c and use the SCSI interface card that came with the PC > > version. What needs to be included in the kernel in order to use this > > adapter. > > I'm pretty sure the SCSI card used by HP is not supported. The card > that came with mine uses a very basic NCR chip which is not supported. > > If you want to use it under FreeBSD, you'll need to get a supported SCSI > card. See the hardware handbook for information on supported SCSI > cards. Hmm, if it's an NCR chip, perhaps the NCR 7xx series? I remember some discussion about these controllers, but don't know what was the result. -- 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 Jan 17 08:24:42 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA19607 for freebsd-scsi-outgoing; Wed, 17 Jan 1996 08:24:42 -0800 (PST) Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA19589 for ; Wed, 17 Jan 1996 08:24:28 -0800 (PST) Received: by Sysiphos id AA08966 (5.67b/IDA-1.5 for freebsd-scsi@freebsd.org); Wed, 17 Jan 1996 17:24:07 +0100 Message-Id: <199601171624.AA08966@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Wed, 17 Jan 1996 17:24:06 +0100 In-Reply-To: J Wunsch "Re: SCSI Scanner anybody?" (Jan 17, 9:25) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Subject: Re: SCSI Scanner anybody? Cc: jason@scott.net, freebsd-scsi@freebsd.org Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk On Jan 17, 9:25, J Wunsch wrote: } Subject: Re: SCSI Scanner anybody? } > If you want to use it under FreeBSD, you'll need to get a supported SCSI } > card. See the hardware handbook for information on supported SCSI } > cards. } } Hmm, if it's an NCR chip, perhaps the NCR 7xx series? I remember some } discussion about these controllers, but don't know what was the } result. The 53c700 is too expensive (and powerful) for this purpose. Guess it's some 53c80, 53c90 or 53c400 variant. The "nca" driver might be near enough (see /sys/i386/isa/ncr5380.c). 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 Jan 18 04:02:18 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA02614 for freebsd-scsi-outgoing; Thu, 18 Jan 1996 04:02:18 -0800 (PST) Received: from zit1.zit.th-darmstadt.de (zit1.zit.th-darmstadt.de [130.83.63.20]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA02603 Thu, 18 Jan 1996 04:02:10 -0800 (PST) Received: (from michael@localhost) by zit1.zit.th-darmstadt.de (8.6.12/8.6.9) id MAA05784; Thu, 18 Jan 1996 12:56:28 +0100 Date: Thu, 18 Jan 1996 12:56:27 +0100 (MET) From: Michael Beckmann To: Joerg Wunsch cc: Michael Beckmann , scsi@freebsd.org, hardware@freebsd.org Subject: Problem solved ! Re: Disk or controller or driver failure ? In-Reply-To: <199601162024.VAA18808@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk > > Are these signs of a dying disk or is it the controller ? Or might it be > > a driver problem ? Has anyone seen this before ? > > Your disk is going mad. :-( I solved the problem. The disk is OK. It was a bad contact with the power supply. I simply plugged another cable from the computer's power supply into the hard drive. Since I did that (24 h ago), there have been no more disk problems. I assume that, as someone said, the bad contact affected the 12 V supply to the drive. However, I'm going to buy a better housing for my machine (it runs 24 h a day). Thanks to all who pointed me in the right direction. Michael From owner-freebsd-scsi Thu Jan 18 09:21:53 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA20295 for freebsd-scsi-outgoing; Thu, 18 Jan 1996 09:21:53 -0800 (PST) Received: from omega.physik.fu-berlin.de (omega.physik.fu-berlin.de [130.133.3.51]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA20290 for ; Thu, 18 Jan 1996 09:21:42 -0800 (PST) Received: from prospero (oberon.physik.fu-berlin.de [130.133.3.126]) by omega.physik.fu-berlin.de (8.7.1/8.7.1) with ESMTP id SAA19351 for ; Thu, 18 Jan 1996 18:21:21 +0100 (MET) Received: (from graichen@localhost) by prospero (8.6.12/8.6.12) id SAA00213 for freebsd-scsi@freebsd.org; Thu, 18 Jan 1996 18:17:10 +0100 From: Thomas Graichen Message-Id: <199601181717.SAA00213@prospero> Subject: kleine bitte To: freebsd-scsi@freebsd.org Date: Thu, 18 Jan 1996 18:17:09 +0100 (MET) In-Reply-To: <199601092223.XAA01271@uriah.heep.sax.de> from "J Wunsch" at Jan 9, 96 11:23:21 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk hallo ich habe mal eine kleine bitte an dich - koenntest du mir mal alle sachen aus den mailinglisten die mich evtl. auch betreffen forwarden ? - ich muss leider vorerst das lesen der listen aufgeben - da meine zeit nun gegen null geht (am ersten mai ist abgabetermin fuer meine diplomarbeit) - danach werde ich dann wieder zurueckkehren - vorher in den naechsten tagen dann evtl. noch den aktualisierten f2c committen - dann ist aber erst mal pause bis mai danke im voraus t _______________________________________________________||___________________ __|| Perfection is reached, not when there is no __|| thomas graichen longer anything to add, but when there __|| freie universitaet berlin is no longer anything to take away __|| fachbereich physik __|| - Antoine de Saint-Exupery - __|| graichen@mail.physik.fu-berlin.de ___________________________||__________________graichen@FreeBSD.org_________ From owner-freebsd-scsi Thu Jan 18 13:50:02 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA06149 for freebsd-scsi-outgoing; Thu, 18 Jan 1996 13:50:02 -0800 (PST) Received: from ncd.com (firewall-user@welch.ncd.com [192.43.160.250]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA06129 for ; Thu, 18 Jan 1996 13:49:52 -0800 (PST) Received: by ncd.com; id OAA18705; Thu, 18 Jan 1996 14:25:43 -0800 Received: from z-code.z-code.com(192.82.56.21) by welch.ncd.com via smap (g3.0.1) id xma018687; Thu, 18 Jan 96 14:25:13 -0800 Received: from zolaris.z-code.com (zolaris.z-code.com [192.82.56.41]) by z-code.z-code.com (8.6.9/8.6.9) with SMTP id NAA03456 for ; Thu, 18 Jan 1996 13:47:07 -0800 Received: by zolaris.z-code.com (5.x/SMI-SVR4) id AA21120; Thu, 18 Jan 1996 13:44:58 -0800 From: "Ulf Zimmermann" Message-Id: <9601181344.ZM21118@zolaris.z-code.com> Date: Thu, 18 Jan 1996 13:44:57 -0800 X-Mailer: Z-Mail (3.2.0 06sep94) To: scsi@freebsd.org Subject: Aaptec 3985 controller Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk Hello. I just got the bad news from Adaptec that the documents for the AIC-7810 chip, which makes the raid things like XOR, will not public available till the end of the year. :( Ulf. -- Ulf Zimmermann, NCD Software, 101 Rowland Way, Suite 300, Novato, CA 94945 phone: 415-899-7941, email: ulf@z-code.ncd.com, phone-home: 510-865-0204 ====================================== FreeBSD 2.1.0 is available now! -------------------------------------- FreeBSD: Turning PCs into Workstations ====================================== From owner-freebsd-scsi Thu Jan 18 13:50:08 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA06196 for freebsd-scsi-outgoing; Thu, 18 Jan 1996 13:50:08 -0800 (PST) Received: from antares.aero.org (antares.aero.org [130.221.192.46]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA06179 for ; Thu, 18 Jan 1996 13:50:04 -0800 (PST) Received: from anpiel.aero.org by antares.aero.org (4.1/AMS-1.0) id AA16938 for freebsd-scsi@freebsd.org; Thu, 18 Jan 96 13:49:23 PST Message-Id: <9601182149.AA16938@antares.aero.org> To: freebsd-scsi@freebsd.org Subject: Messing with the TUNE code Date: Thu, 18 Jan 1996 13:49:22 -0800 From: "Mike O'Brien" Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk I'm an old-line UNIX hacker. I messed a lot with the Rand kernel (we never went to V7, we already had all that stuff), 32/V, 3BSD, 4BSD, 4.1, 4.2, you get the idea. Curious as am about anything that slows down the boot process, I went grotting around the code this morning looking for the little wonder that was sitting for a long time, then printing "100 nSec ok, using 150 nSec." Ok, cool. Timing the DMA and using the fastest stable setting, sounds good. Hmmm. 100 nSec is the lowest one in the table. Since the code always backs off, we'll never use it, no matter what. Hey! Wait a minute! That's 50% of the available DMA bandwidth we're throwing away! 100 vs. 150 nSec, hmmm. Ok, here's the question: what are the codes for extending the table downward? Can it be extended downward? Not far, given memory bandwidth, I'd say. Even one slot would be enough, though. I mean, I could hotwire the code to use 100 nSec and see if my disk goes kaflooey and takes my file system with it, but... And shame, plus week-old bananas, on whoever hardwired those "7"s into the code. Mike O'Brien From owner-freebsd-scsi Thu Jan 18 15:17:13 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA11053 for freebsd-scsi-outgoing; Thu, 18 Jan 1996 15:17:13 -0800 (PST) Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA11047 Thu, 18 Jan 1996 15:17:11 -0800 (PST) Message-Id: <199601182317.PAA11047@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol To: "Ulf Zimmermann" cc: scsi@freebsd.org Subject: Re: Aaptec 3985 controller In-reply-to: Your message of "Thu, 18 Jan 1996 13:44:57 PST." <9601181344.ZM21118@zolaris.z-code.com> Date: Thu, 18 Jan 1996 15:17:10 -0800 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk >Hello. > >I just got the bad news from Adaptec that the documents for the AIC-7810 chip, >which makes the raid things like XOR, will not public available till the end o >f >the year. :( That sucks, although it doesn't surprise me. I got the impression the 7810 documents wouldn't be availible for a while when I asked for them the last time. >Ulf. > >-- >Ulf Zimmermann, NCD Software, 101 Rowland Way, Suite 300, Novato, CA 94945 >phone: 415-899-7941, email: ulf@z-code.ncd.com, phone-home: 510-865-0204 >====================================== > FreeBSD 2.1.0 is available now! >-------------------------------------- >FreeBSD: Turning PCs into Workstations >====================================== > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Thu Jan 18 21:51:07 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id VAA09373 for freebsd-scsi-outgoing; Thu, 18 Jan 1996 21:51:07 -0800 (PST) Received: from sivka.carrier.kiev.ua (sivka.carrier.kiev.ua [193.125.68.130]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id VAA09356 for ; Thu, 18 Jan 1996 21:51:01 -0800 (PST) Received: from elvisti.kiev.ua (uucp@localhost) by sivka.carrier.kiev.ua (Sendmail 8.who.cares/5) with UUCP id HAA18423 for scsi@freebsd.org; Fri, 19 Jan 1996 07:52:09 +0200 Received: from office.elvisti.kiev.ua (office.elvisti.kiev.ua [193.125.28.33]) by spider2.elvisti.kiev.ua (8.6.12/8.ElVisti) with ESMTP id FAA29756 for ; Fri, 19 Jan 1996 05:54:30 +0200 Received: (from stesin@localhost) by office.elvisti.kiev.ua (8.6.12/8.ElVisti) id FAA22288; Fri, 19 Jan 1996 05:54:29 +0200 From: "Andrew V. Stesin" Message-Id: <199601190354.FAA22288@office.elvisti.kiev.ua> Subject: Re: Aaptec 3985 controller To: gibbs@freefall.freebsd.org (Justin T. Gibbs) Date: Fri, 19 Jan 1996 05:54:29 +0200 (EET) Cc: scsi@freebsd.org In-Reply-To: <199601182317.PAA11047@freefall.freebsd.org> from "Justin T. Gibbs" at Jan 18, 96 03:17:10 pm X-Mailer: ELM [version 2.4 PL24alpha5] Content-Type: text Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk Hello, # >I just got the bad news from Adaptec that the documents for the AIC-7810 chip, # >which makes the raid things like XOR, will not public available till the end o # >f # >the year. :( # # That sucks, although it doesn't surprise me. I got the impression the # 7810 documents wouldn't be availible for a while when I asked for # them the last time. I occasionally have read the manuals of this new adaptec toy, and got a strong impression that it becomes RAID with the presence of software drivers (analog of 'ccd'?) only. Am I missing something? And I wonder -- did someone of the FreeBSD engineers try to talk with DPT? Their controllers are not too costly, but specs seem to be better than Adaptec's. And DPT _are_ RAIDish, AFAIK. # -- # Justin T. Gibbs # =========================================== # FreeBSD: Turning PCs into workstations # =========================================== # -- With best regards -- Andrew Stesin. +380 (44) 2760188 +380 (44) 2713457 +380 (44) 2713560 An undocumented feature is a coding error. From owner-freebsd-scsi Fri Jan 19 00:53:12 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA29868 for freebsd-scsi-outgoing; Fri, 19 Jan 1996 00:53:12 -0800 (PST) Received: from omega.physik.fu-berlin.de (omega.physik.fu-berlin.de [130.133.3.51]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA29679 for ; Fri, 19 Jan 1996 00:50:23 -0800 (PST) Received: from dirac.physik.fu-berlin.de (dirac.physik.fu-berlin.de [130.133.3.124]) by omega.physik.fu-berlin.de (8.7.1/8.7.1) with ESMTP id JAA30898; Fri, 19 Jan 1996 09:50:05 +0100 (MET) Received: (from graichen@localhost) by dirac.physik.fu-berlin.de (8.7.1/8.7.1) id JAA04648; Fri, 19 Jan 1996 09:50:04 +0100 (MET) From: Thomas Graichen Message-Id: <199601190850.JAA04648@dirac.physik.fu-berlin.de> Subject: Re: kleine bitte To: graichen@omega.physik.fu-berlin.de (Thomas Graichen) Date: Fri, 19 Jan 1996 09:50:04 +0100 (MET) Cc: freebsd-scsi@freebsd.org In-Reply-To: <199601181717.SAA00213@prospero> from "Thomas Graichen" at Jan 18, 96 06:17:09 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk hasn't Thomas Graichen said ? ... > > ich habe mal eine kleine bitte ... sorry - this mail was only intended for joerg wunsch - maybe i accidently used a group reply instead of a normal reply to joerg (i was to lazy to write his adress and simply replied to one of his mails in my folders) - it will never happen again (i hope :-) t _______________________________________________________||___________________ __|| Perfection is reached, not when there is no __|| thomas graichen longer anything to add, but when there __|| freie universitaet berlin is no longer anything to take away __|| fachbereich physik __|| - Antoine de Saint-Exupery - __|| graichen@mail.physik.fu-berlin.de ___________________________||__________________graichen@FreeBSD.org_________ From owner-freebsd-scsi Fri Jan 19 02:11:20 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA04827 for freebsd-scsi-outgoing; Fri, 19 Jan 1996 02:11:20 -0800 (PST) Received: from ncd.com (firewall-user@welch.ncd.com [192.43.160.250]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA04814 for ; Fri, 19 Jan 1996 02:11:12 -0800 (PST) Received: by ncd.com; id CAA15968; Fri, 19 Jan 1996 02:47:27 -0800 Received: from z-code.z-code.com(192.82.56.21) by welch.ncd.com via smap (g3.0.1) id xmaa15958; Fri, 19 Jan 96 02:47:11 -0800 Received: from zolaris.z-code.com (zolaris.z-code.com [192.82.56.41]) by z-code.z-code.com (8.6.9/8.6.9) with SMTP id BAA06640; Fri, 19 Jan 1996 01:52:45 -0800 Received: by zolaris.z-code.com (5.x/SMI-SVR4) id AA23926; Fri, 19 Jan 1996 01:50:33 -0800 From: "Ulf Zimmermann" Message-Id: <9601190150.ZM23924@zolaris.z-code.com> Date: Fri, 19 Jan 1996 01:50:32 -0800 In-Reply-To: "Andrew V. Stesin" "Re: Aaptec 3985 controller" (Jan 19, 5:54) References: <199601190354.FAA22288@office.elvisti.kiev.ua> X-Mailer: Z-Mail Lite (3.2.0 5jul94) To: "Andrew V. Stesin" , gibbs@freefall.freebsd.org (Justin T. Gibbs) Subject: Re: Aaptec 3985 controller Cc: scsi@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk On Jan 19, 5:54, Andrew V. Stesin wrote: > Subject: Re: Aaptec 3985 controller > Hello, > > # >I just got the bad news from Adaptec that the documents for the AIC-7810 chip, > # >which makes the raid things like XOR, will not public available till the end o > # >f > # >the year. :( > # > # That sucks, although it doesn't surprise me. I got the impression the > # 7810 documents wouldn't be availible for a while when I asked for > # them the last time. > > I occasionally have read the manuals of this new adaptec toy, > and got a strong impression that it becomes RAID with the > presence of software drivers (analog of 'ccd'?) only. > Am I missing something? > No, you are wrong. The 3985 has a PCI-PCI bridge on board. On the internal PCI bus are 4 chips: 3 x AIC-7870 (SCSI controller, like on 2940) and the AIC-7810 which is a chip build on the same platform like the whole AIC-7xxx serie. This chip performs via hardware the XOR of the data, which goes into a 1/4 MB big buffer on the PCI bus. From this buffer the 3 7870 reads the data and writes it to the harddisk. But recovering are done via Sequencer/OS-driver. Aka rebuild of the harddisk. Ulf. [Rest deleted] >-- End of excerpt from Andrew V. Stesin -- Ulf Zimmermann, NCD Software, 101 Rowland Way, Suite 300, Novato, CA 94945 phone: 415-899-7941, email: ulf@z-code.ncd.com, phone-home: 510-865-0204 ====================================== FreeBSD 2.1.0 is available now! -------------------------------------- FreeBSD: Turning PCs into Workstations ====================================== From owner-freebsd-scsi Fri Jan 19 03:52:36 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA10171 for freebsd-scsi-outgoing; Fri, 19 Jan 1996 03:52:36 -0800 (PST) Received: from iworks.InterWorks.org (iworks.interworks.org [128.255.18.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA10165 for ; Fri, 19 Jan 1996 03:52:33 -0800 (PST) Received: by iworks.InterWorks.org (1.37.109.8/16.2) id AA25208; Fri, 19 Jan 1996 05:49:55 -0600 Message-Id: <9601191149.AA25208@iworks.InterWorks.org> Date: Fri, 19 Jan 1996 05:49:55 -0600 From: "Daniel M. Eischen" To: gibbs@freefall.freebsd.org, owner-freebsd-scsi@freefall.freebsd.org Subject: Re: Aaptec 3985 controller Cc: scsi@freebsd.org Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk > # >I just got the bad news from Adaptec that the documents for the AIC-7810 chip, > # >which makes the raid things like XOR, will not public available till the end o > # >f > # >the year. :( > # > # That sucks, although it doesn't surprise me. I got the impression the > # 7810 documents wouldn't be availible for a while when I asked for > # them the last time. > > I occasionally have read the manuals of this new adaptec toy, > and got a strong impression that it becomes RAID with the > presence of software drivers (analog of 'ccd'?) only. > Am I missing something? > And I wonder -- did someone of the FreeBSD engineers try > to talk with DPT? Their controllers are not too costly, > but specs seem to be better than Adaptec's. And DPT _are_ > RAIDish, AFAIK. > > # -- > # Justin T. Gibbs > # =========================================== > # FreeBSD: Turning PCs into workstations > # =========================================== > # You might want to try contacting the author of the Linux DPT drives, Michael Neuffer (neuffer@goofy.zdv.Uni-Mainz.de). He is on good terms with DPT and has visited their headquarters in Florida. At one time he was considering porting his driver to FreeBSD, but I think that he didn't have the time. It was initially hard for him to get anything out of DPT. He signed the NDA, but they agreed to let him release the driver under the GPL. I've talked a few times with Michael, and I don't think there would be a problem with slapping on the standard BSD copyright if someone wanted to port his driver to FreeBSD. And if not, he could give a potential FreeBSD driver developer the name of one his contacts at DPT. Dan Eischen deischen@iworks.InterWorks.org From owner-freebsd-scsi Fri Jan 19 09:38:41 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA01255 for freebsd-scsi-outgoing; Fri, 19 Jan 1996 09:38:41 -0800 (PST) Received: from cabal.io.org (cabal.io.org [198.133.36.103]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA01249 for ; Fri, 19 Jan 1996 09:38:37 -0800 (PST) Received: (from taob@localhost) by cabal.io.org (8.6.12/8.6.12) id MAA01396; Fri, 19 Jan 1996 12:35:38 -0500 Date: Fri, 19 Jan 1996 12:35:37 -0500 (EST) From: Brian Tao To: "Andrew V. Stesin" cc: "Justin T. Gibbs" , scsi@freebsd.org Subject: Re: Aaptec 3985 controller In-Reply-To: <199601190354.FAA22288@office.elvisti.kiev.ua> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk On Fri, 19 Jan 1996, Andrew V. Stesin wrote: > > And I wonder -- did someone of the FreeBSD engineers try > to talk with DPT? Their controllers are not too costly, > but specs seem to be better than Adaptec's. And DPT _are_ > RAIDish, AFAIK. This would be more productive in the meantime, while Adaptec beats around the bush some more. Linux already has DPT drivers, so there is at least a code base from which to work. I'd love to drop one of those controllers in with a 64MB cache and run news on it... -- Brian Tao (BT300, taob@io.org) Systems Administrator, Internex Online Inc. "Though this be madness, yet there is method in't" From owner-freebsd-scsi Sat Jan 20 09:24:39 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA06657 for freebsd-scsi-outgoing; Sat, 20 Jan 1996 09:24:39 -0800 (PST) Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA06649 Sat, 20 Jan 1996 09:24:36 -0800 (PST) Message-Id: <199601201724.JAA06649@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol To: "Mike Pritchard" cc: freebsd-hackers@freebsd.org, freebsd-scsi Subject: Re: Can't take dumps w/Adaptec 2842 In-reply-to: Your message of "Sat, 20 Jan 1996 08:50:16 CST." <199601201450.IAA00247@mpp.minn.net> Date: Sat, 20 Jan 1996 09:24:35 -0800 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk >I noticed a while back that I couldn't take a dump after >a crash. Today I finally decided to track down the reason >for that. It appears that the Adaptec 2842 driver (aic7xxx) >and sddump don't quite agree on some return codes. > >The dump fails with an ENXIO error because it gets a SUCCESSFULLY_QUEUED >return code (retval = 0) from the aic7xxx driver, and it is expecting to >get a COMPLETE return code. Could someone who understands this code >better than I do please take a look into this? Here's the story. The aic7xxx driver doesn't poll anymore. The reason it doesn't poll is because its slower, not necessary during normal operation, and would cause massive confusion if you re-probed your SCSI bus with interrupts enabled since the SCSI code would tell you not to sleep. Now the problem is that sddump wants you to poll since interrupts may well be disabled. I have no problem putting polling back in for this one case so long as its differentiated from the other times that SCSI_NOSLEEP is used. Perhaps we need a new flag? I'd like SCSI_NOSLEEP to mean "calling tsleep may not be safe" and perhaps SCSI_POLL (only used during sddump) would cause drivers to disable there interrupt (just in case) and poll until complete. Furthermore, I'd like to change the way resorces are reserved so that everything is allocated when we can always sleep. This wouldn't be very difficult to do (getting a scsi_xfer calls into the driver to "attach" the driver's per transaction resource to the scsi_xfer). This would kill the SCSI_NOSLEEP flag. >-- >Mike Pritchard >mpp@minn.net >"Go that way. Really fast. If something gets in your way, turn" -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Sat Jan 20 11:22:07 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA14215 for freebsd-scsi-outgoing; Sat, 20 Jan 1996 11:22:07 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA14197 Sat, 20 Jan 1996 11:21:58 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id GAA03759; Sun, 21 Jan 1996 06:19:43 +1100 Date: Sun, 21 Jan 1996 06:19:43 +1100 From: Bruce Evans Message-Id: <199601201919.GAA03759@godzilla.zeta.org.au> To: gibbs@freefall.freebsd.org, mpp@mpp.minn.net Subject: Re: Can't take dumps w/Adaptec 2842 Cc: freebsd-hackers@FreeBSD.org, freebsd-scsi@freefall.freebsd.org Sender: owner-freebsd-scsi@FreeBSD.org Precedence: bulk >tell you not to sleep. Now the problem is that sddump wants you >to poll since interrupts may well be disabled. I have no problem ^^^^^^^^^^^ are always >putting polling back in for this one case so long as its differentiated >from the other times that SCSI_NOSLEEP is used. Perhaps we need >a new flag? I'd like SCSI_NOSLEEP to mean "calling tsleep may not >be safe" and perhaps SCSI_POLL (only used during sddump) would >cause drivers to disable there interrupt (just in case) and poll >until complete. I'd like a common polled mode i/o interface to all drivers. Something like int (*polled_write)(void *buf, off_t off, size_t nbytes); This could be used to write a single dump routine. (Currently, sddump() is a clone of an old, not so good version of wddump().) For dumping, it might be convenient to only implement the case where `buf' is page aligned, and `off' and `nbytes' are multiples of DEV_BSIZE then (they could be passed as daddr_t's). Bruce From owner-freebsd-scsi Sat Jan 20 19:01:49 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA09002 for freebsd-scsi-outgoing; Sat, 20 Jan 1996 19:01:49 -0800 (PST) Received: from Aspen.Woc.Atinc.COM ([198.138.38.206]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA08973 Sat, 20 Jan 1996 19:01:28 -0800 (PST) Received: (from jmb@localhost) by Aspen.Woc.Atinc.COM (8.6.12/8.6.9) id WAA01741; Sat, 20 Jan 1996 22:02:15 -0500 Date: Sat, 20 Jan 1996 22:02:15 -0500 (EST) From: "Jonathan M. Bresler" X-Sender: jmb@Aspen.Woc.Atinc.COM To: freebsd-scsi@FreeBSD.ORG cc: freebsd-hackers@FreeBSD.ORG Subject: nakamichi MBR-7, some bizarre behavior Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk i have a nakamichi MBR-7 scsi-ii 2x cdrom 7 changer. the unit has internal terminators controlled by a rear panel dip switch. the rear panel has 2 centronics 50-pin scsi connectors. the scsi card is an ASUS SC-200. regardless of whether the internal scsi terminator are enabled or i use an external scsi terminator (active) on the lower scsi connector of the MBR-7, i get scsi phase errors. when the cable connects the SC-200 to the upper scsi connector on the MBR-7, the unit reponds normally. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SC-200 connected to UPPER scsi connector: ncr1 rev 1 int a irq 11 on pci0:5 (ncr1:6:0): "NRC MBR-7 110" type 5 removable SCSI 2 cd0(ncr1:6:0): CD-ROM cd0(ncr1:6:0): asynchronous. cd present.[330927 x 2048 byte records] (ncr1:6:1): "NRC MBR-7 110" type 5 removable SCSI 2 cd1(ncr1:6:1): CD-ROM cd1(ncr1:6:1): asynchronous. cd present.[208702 x 2048 byte records] (ncr1:6:2): "NRC MBR-7 110" type 5 removable SCSI 2 cd2(ncr1:6:2): CD-ROM cd2(ncr1:6:2): asynchronous. cd present.[307527 x 2048 byte records] (ncr1:6:3): "NRC MBR-7 110" type 5 removable SCSI 2 cd3(ncr1:6:3): CD-ROM cd3(ncr1:6:3): asynchronous. cd present.[326402 x 2048 byte records] (ncr1:6:4): "NRC MBR-7 110" type 5 removable SCSI 2 cd4(ncr1:6:4): CD-ROM cd4(ncr1:6:4): asynchronous. cd4(ncr1:6:4): NOT READY asc:3a,0 Medium not present can't get the size (ncr1:6:5): "NRC MBR-7 110" type 5 removable SCSI 2 cd5(ncr1:6:5): CD-ROM cd5(ncr1:6:5): asynchronous. cd5(ncr1:6:5): NOT READY asc:3a,0 Medium not present can't get the size (ncr1:6:6): "NRC MBR-7 110" type 5 removable SCSI 2 cd6(ncr1:6:6): CD-ROM cd6(ncr1:6:6): asynchronous. cd6(ncr1:6:6): NOT READY asc:3a,0 Medium not present can't get the size ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SC-200 connected to LOWER scsi connector: ncr1 rev 1 int a irq 11 on pci0:5 ncr1: SCSI phase error fixup: CCB address mismatch (0xf0688b08 != 0x00000000) ncr1:6: ERROR (80:100) (e-ac-0) (0/13) @ (438:1e000000). script cmd = 868b0000 reg: da 10 80 13 47 00 06 1f 06 0e 06 ac 80 00 0c 00. ncr1: handshake timeout (ncr1:6:0): COMMAND FAILED (6 ff) @f0688b08. ncr1: SCSI phase error fixup: CCB address mismatch (0xf0688b08 != 0x00000000) ncr1:6: ERROR (80:100) (e-ac-0) (0/13) @ (438:1e000000). script cmd = 868b0000 reg: da 10 80 13 47 00 06 1f 06 0e 06 ac 80 00 0c 00. ncr1: handshake timeout (ncr1:6:0): COMMAND FAILED (6 ff) @f0688b08. ncr1: SCSI phase error fixup: CCB address mismatch (0xf0688b08 != 0x00000000) ncr1:6: ERROR (80:100) (e-ac-0) (0/13) @ (438:1e000000). script cmd = 868b0000 reg: da 10 80 13 47 00 06 1f 06 0e 06 ac 80 00 0c 00. ncr1: handshake timeout (ncr1:6:0): COMMAND FAILED (6 ff) @f0688b08. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ full boot messages from /sbin/dmesg: Rebooting... FreeBSD 2.1-STABLE #1: Wed Jan 10 21:21:24 EST 1996 jmb@Aspen.Woc.Atinc.COM:/home/sup/src/sys/compile/ASPEN CPU: i486DX (486-class CPU) real memory = 16777216 (16384K bytes) avail memory = 15077376 (14724K bytes) Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2 not found at 0x3e8 sio3 not found at 0x2e8 lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface lpt1 not found at 0xffffffff fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in wdc0 not found at 0x1f0 ep0 not found at 0x300 npx0 on motherboard npx0: INT 16 interface Probing for devices on the PCI bus: chip0 rev 4 on pci0:0 ncr0 rev 2 int a irq 9 on pci0:1 (ncr0:0:0): "DEC DSP3053LS X442" type 0 fixed SCSI 2 sd0(ncr0:0:0): Direct-Access sd0(ncr0:0:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. 511MB (1046532 512 byte sectors) (ncr0:1:0): "FUJITSU M1606S-512 6220" type 0 fixed SCSI 2 sd1(ncr0:1:0): Direct-Access sd1(ncr0:1:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. 1041MB (2131992 512 byte sectors) chip1 rev 3 on pci0:2 vga0 rev 0 on pci0:4 ncr1 rev 1 int a irq 11 on pci0:5 (ncr1:6:0): "NRC MBR-7 110" type 5 removable SCSI 2 cd0(ncr1:6:0): CD-ROM cd0(ncr1:6:0): asynchronous. cd present.[330927 x 2048 byte records] (ncr1:6:1): "NRC MBR-7 110" type 5 removable SCSI 2 cd1(ncr1:6:1): CD-ROM cd1(ncr1:6:1): asynchronous. cd present.[208702 x 2048 byte records] (ncr1:6:2): "NRC MBR-7 110" type 5 removable SCSI 2 cd2(ncr1:6:2): CD-ROM cd2(ncr1:6:2): asynchronous. cd present.[307527 x 2048 byte records] (ncr1:6:3): "NRC MBR-7 110" type 5 removable SCSI 2 cd3(ncr1:6:3): CD-ROM cd3(ncr1:6:3): asynchronous. cd present.[326402 x 2048 byte records] (ncr1:6:4): "NRC MBR-7 110" type 5 removable SCSI 2 cd4(ncr1:6:4): CD-ROM cd4(ncr1:6:4): asynchronous. cd4(ncr1:6:4): NOT READY asc:3a,0 Medium not present can't get the size (ncr1:6:5): "NRC MBR-7 110" type 5 removable SCSI 2 cd5(ncr1:6:5): CD-ROM cd5(ncr1:6:5): asynchronous. cd5(ncr1:6:5): NOT READY asc:3a,0 Medium not present can't get the size (ncr1:6:6): "NRC MBR-7 110" type 5 removable SCSI 2 cd6(ncr1:6:6): CD-ROM cd6(ncr1:6:6): asynchronous. cd6(ncr1:6:6): NOT READY asc:3a,0 Medium not present can't get the size cd3(ncr1:6:3): asynchronous. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ kernel config file: # # ASPEN # # machine "i386" cpu "I486_CPU" ident ASPEN maxusers 10 options INET #InterNETworking options FFS #Berkeley Fast Filesystem options PROCFS #Process filesystem options MSDOSFS #MSDOS Filesystem options "CD9660" #ISO 9660 Filesystem options UCONSOLE #X Console support options "FAT_CURSOR" #block cursor in syscons or pccons # options "SCSI_DELAY=15" #Be pessimistic about Joe SCSI device options "NCONS=4" #4 virtual consoles options USERCONFIG #Allow user configuration with -c options "COMPAT_43" #Compatible with BSD 4.3 # options BOUNCE_BUFFERS #include support for DMA bounce buffers options PROBE_VERBOSE #get all pci bus data options COMPAT_LINUX options SYSVSHM options SYSVSEM options SYSVMSG options "IBCS2" # options MAXMEM= config kernel root on sd1 swap on sd1 and sd0 dumps on sd1 controller isa0 controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 # tape ft0 at fdc0 drive 2 controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr disk wd0 at wdc0 drive 0 disk wd1 at wdc0 drive 1 controller ncr0 #Only need one of these, the memory allocation grows controller scbus0 device sd0 device sd1 device sd2 device sd3 device st0 device st1 device cd0 #Only need one of these, the code dynamically grows device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr device npx0 at isa? port "IO_NPX" irq 13 vector npxintr device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr device sio2 at isa? port "IO_COM3" tty irq 5 vector siointr device sio3 at isa? port "IO_COM4" tty irq 9 vector siointr device lpt0 at isa? port? tty irq 7 vector lptintr device lpt1 at isa? port? tty device ep0 at isa? port 0x300 net irq 10 vector epintr pseudo-device loop pseudo-device ether pseudo-device log pseudo-device sl 2 # # ijppp uses tun instead of ppp device # pseudo-device tun 2 pseudo-device pty 16 pseudo-device speaker pseudo-device gzip # Exec gzipped a.out's pseudo-device bpfilter 4 Jonathan M. Bresler FreeBSD Postmaster jmb@FreeBSD.ORG play go. ride bike. hack FreeBSD.--ah the good life i am moving to a new job. PLEASE USE: jmb@FreeBSD.ORG