From owner-freebsd-scsi Sun Dec 3 11:56:08 1995 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA19860 for freebsd-scsi-outgoing; Sun, 3 Dec 1995 11:56:08 -0800 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA19854 for ; Sun, 3 Dec 1995 11:56:05 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id LAA04268 for ; Sun, 3 Dec 1995 11:55:35 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id UAA28666; Sun, 3 Dec 1995 20:41:36 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id UAA22221; Sun, 3 Dec 1995 20:41:35 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id RAA02736; Sun, 3 Dec 1995 17:09:40 +0100 From: J Wunsch Message-Id: <199512031609.RAA02736@uriah.heep.sax.de> Subject: Re: /sys/scsi/st.c and NEW_SCSICONF? To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sun, 3 Dec 1995 17:09:40 +0100 (MET) Cc: freebsd-scsi@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <15657.817811157@time.cdrom.com> from "Jordan K. Hubbard" at Dec 1, 95 01:45:57 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 Content-Length: 683 Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk As Jordan K. Hubbard wrote: > > If you have NEW_SCSICONF defined in -current, it disables a block of > defines in /sys/scsi/scsi_tape.h. All well and good, but one of those > defines is "QIC_3080" which gets referenced in st.c regardless. > > I've conditionalized the QIC_3080 references in st.c on !NEW_SCSICONF > as well and gotten past the problem for now, but I'm not sure if > that's what the author(s) intended. NEW_SCSICONF should die (one way or the other), but apparently everybody is too busy to kill it... -- 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 Sun Dec 3 16:44:52 1995 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA09748 for freebsd-scsi-outgoing; Sun, 3 Dec 1995 16:44:52 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA09741 for ; Sun, 3 Dec 1995 16:44:38 -0800 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.9) id QAA02303; Sun, 3 Dec 1995 16:35:12 -0800 From: Julian Elischer Message-Id: <199512040035.QAA02303@ref.tfs.com> Subject: Re: /sys/scsi/st.c and NEW_SCSICONF? To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 3 Dec 1995 16:35:12 -0800 (PST) Cc: jkh@time.cdrom.com, freebsd-scsi@freebsd.org In-Reply-To: <199512031609.RAA02736@uriah.heep.sax.de> from "J Wunsch" at Dec 3, 95 05:09:40 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 814 Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk > > As Jordan K. Hubbard wrote: > > > > If you have NEW_SCSICONF defined in -current, it disables a block of > > defines in /sys/scsi/scsi_tape.h. All well and good, but one of those > > defines is "QIC_3080" which gets referenced in st.c regardless. > > > > I've conditionalized the QIC_3080 references in st.c on !NEW_SCSICONF > > as well and gotten past the problem for now, but I'm not sure if > > that's what the author(s) intended. > > NEW_SCSICONF should die (one way or the other), but apparently > everybody is too busy to kill it... I've scheduled some of my time in the upcoming holiday to cleaning up the SCSI code.. > > -- > 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 Sun Dec 3 23:04:08 1995 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA02435 for freebsd-scsi-outgoing; Sun, 3 Dec 1995 23:04:08 -0800 Received: from wiley.csusb.edu (wiley.csusb.edu [139.182.2.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA02430 for ; Sun, 3 Dec 1995 23:04:03 -0800 Received: (from rmallory@localhost) by wiley.csusb.edu (8.6.11/8.6.11) id XAA29624 for freebsd-scsi@freefall.cdrom.com; Sun, 3 Dec 1995 23:08:49 -0800 From: Rob Mallory Message-Id: <199512040708.XAA29624@wiley.csusb.edu> Subject: df of cdrom bit hard To: freebsd-scsi@freefall.FreeBSD.org Date: Sun, 3 Dec 1995 23:08:49 -0800 (PST) X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2009 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk [asus MB, ncr825 bios3.04, plextor 6x] off a new kernel from sunday night, I got the following when doing a `df` with a mounted cdrom... any clues? ps: the new clustering code on cd9660's works excellent! I can (almost) watch two ~100MB qt movies off a cd at the same time! root@kickme$ df Dec 3 22:56:03 kickme /kernel: ncr0:6: ERROR (80:140) (8-2a-0) (88/13) @ (bd4:900b0000). Dec 3 22:56:03 kickme /kernel: ncr0:6: ERROR (80:140) (8-2a-0) (88/13) @ (bd4:900b0000). Filesystem 512-blocks Used Avail Capacity Mounted on /dev/sd0a 38974 34136 1720 95% / procfs 8 8 0 100% /proc /dev/sd0e 689150 560818 93874 86% /usr /dev/sd3e 945534 505338 364552 58% /usr/obj /dev/sd2d 1918642 1794178 -29028 102% /src /dev/cd0a 1262412 1262412 0 100% /cdrom root@kickme$ Dec 3 22:56:04 kickme /kernel: script cmd = 910a0000 Dec 3 22:56:04 kickme /kernel: script cmd = 910a0000 Dec 3 22:56:04 kickme /kernel: reg: da 10 80 13 47 88 06 0f 01 08 02 2a 80 00 0a 00. Dec 3 22:56:04 kickme /kernel: reg: da 10 80 13 47 88 06 0f 01 08 02 2a 80 00 0a 00. Dec 3 22:56:04 kickme /kernel: ncr0: handshake timeout Dec 3 22:56:04 kickme /kernel: ncr0: handshake timeout Dec 3 22:56:04 kickme /kernel: cd0(ncr0:6:0): COMMAND FAILED (6 ff) @f0aa8a00. Dec 3 22:56:04 kickme /kernel: cd0(ncr0:6:0): COMMAND FAILED (6 ff) @f0aa8a00. Dec 3 22:56:04 kickme /kernel: sd0(ncr0:0:0): COMMAND FAILED (6 ff) @f0aa7c00. Dec 3 22:56:04 kickme /kernel: sd0(ncr0:0:0): COMMAND FAILED (6 ff) @f0aa7c00. Dec 3 22:56:04 kickme /kernel: sd0(ncr0:0:0): UNIT ATTENTION asc:29,0 Dec 3 22:56:04 kickme /kernel: sd0(ncr0:0:0): UNIT ATTENTION asc:29,0 Dec 3 22:56:05 kickme /kernel: sd0(ncr0:0:0): Power on, reset, or bus device reset occurred Dec 3 22:56:05 kickme /kernel: sd0(ncr0:0:0): Power on, reset, or bus device reset occurred -- Rob Mallory [rmallory@csusb.edu] From owner-freebsd-scsi Sun Dec 3 23:34:06 1995 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA04489 for freebsd-scsi-outgoing; Sun, 3 Dec 1995 23:34:06 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA04464 ; Sun, 3 Dec 1995 23:34:00 -0800 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.9) id XAA04323; Sun, 3 Dec 1995 23:33:50 -0800 From: Julian Elischer Message-Id: <199512040733.XAA04323@ref.tfs.com> Subject: Re: df of cdrom bit hard To: rmallory@wiley.csusb.edu (Rob Mallory) Date: Sun, 3 Dec 1995 23:33:49 -0800 (PST) Cc: scsi@freebsd.org, se@freebsd.org In-Reply-To: <199512040708.XAA29624@wiley.csusb.edu> from "Rob Mallory" at Dec 3, 95 11:08:49 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2259 Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk looks like a power glitch.. are those devices in an external cabinet? OR possibly the ncd drive detected a hang and reset the scsi bus.. what do you think stefan? julian > > > [asus MB, ncr825 bios3.04, plextor 6x] > off a new kernel from sunday night, I got the following when doing > a `df` with a mounted cdrom... any clues? > ps: the new clustering code on cd9660's works excellent! > I can (almost) watch two ~100MB qt movies off a cd at the same time! > > root@kickme$ df > Dec 3 22:56:03 kickme /kernel: ncr0:6: ERROR (80:140) (8-2a-0) (88/13) @ (bd4:900b0000). > Dec 3 22:56:03 kickme /kernel: ncr0:6: ERROR (80:140) (8-2a-0) (88/13) @ (bd4:900b0000). > Filesystem 512-blocks Used Avail Capacity Mounted on > /dev/sd0a 38974 34136 1720 95% / > procfs 8 8 0 100% /proc > /dev/sd0e 689150 560818 93874 86% /usr > /dev/sd3e 945534 505338 364552 58% /usr/obj > /dev/sd2d 1918642 1794178 -29028 102% /src > /dev/cd0a 1262412 1262412 0 100% /cdrom > root@kickme$ Dec 3 22:56:04 kickme /kernel: script cmd = 910a0000 > Dec 3 22:56:04 kickme /kernel: script cmd = 910a0000 > Dec 3 22:56:04 kickme /kernel: reg: da 10 80 13 47 88 06 0f 01 08 02 2a 80 00 0a 00. > Dec 3 22:56:04 kickme /kernel: reg: da 10 80 13 47 88 06 0f 01 08 02 2a 80 00 0a 00. > Dec 3 22:56:04 kickme /kernel: ncr0: handshake timeout > Dec 3 22:56:04 kickme /kernel: ncr0: handshake timeout > Dec 3 22:56:04 kickme /kernel: cd0(ncr0:6:0): COMMAND FAILED (6 ff) @f0aa8a00. > Dec 3 22:56:04 kickme /kernel: cd0(ncr0:6:0): COMMAND FAILED (6 ff) @f0aa8a00. > Dec 3 22:56:04 kickme /kernel: sd0(ncr0:0:0): COMMAND FAILED (6 ff) @f0aa7c00. > Dec 3 22:56:04 kickme /kernel: sd0(ncr0:0:0): COMMAND FAILED (6 ff) @f0aa7c00. > Dec 3 22:56:04 kickme /kernel: sd0(ncr0:0:0): UNIT ATTENTION asc:29,0 > Dec 3 22:56:04 kickme /kernel: sd0(ncr0:0:0): UNIT ATTENTION asc:29,0 > Dec 3 22:56:05 kickme /kernel: sd0(ncr0:0:0): Power on, reset, or bus device reset occurred > Dec 3 22:56:05 kickme /kernel: sd0(ncr0:0:0): Power on, reset, or bus device reset occurred > > -- > Rob Mallory [rmallory@csusb.edu] > > From owner-freebsd-scsi Sun Dec 3 23:56:16 1995 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id XAA05638 for freebsd-scsi-outgoing; Sun, 3 Dec 1995 23:56:16 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA05633 for ; Sun, 3 Dec 1995 23:56:03 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA13724 for ; Mon, 4 Dec 1995 08:51:52 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id IAA25575 for freebsd-scsi@freebsd.org; Mon, 4 Dec 1995 08:51:52 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id IAA07452 for freebsd-scsi@freebsd.org; Mon, 4 Dec 1995 08:14:03 +0100 From: J Wunsch Message-Id: <199512040714.IAA07452@uriah.heep.sax.de> Subject: Re: /sys/scsi/st.c and NEW_SCSICONF? To: freebsd-scsi@freebsd.org Date: Mon, 4 Dec 1995 08:14:02 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199512040035.QAA02303@ref.tfs.com> from "Julian Elischer" at Dec 3, 95 04:35: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 Content-Length: 505 Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk As Julian Elischer wrote: > > > NEW_SCSICONF should die (one way or the other), but apparently > > everybody is too busy to kill it... > > I've scheduled some of my time in the upcoming holiday > to cleaning up the SCSI code.. Count me in for testing. I've got all sorts of weird hardware (though the CD burner ain't there at the moment). -- 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 Dec 4 04:34:45 1995 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA28337 for freebsd-scsi-outgoing; Mon, 4 Dec 1995 04:34:45 -0800 Received: from hda.com (hda.com [199.232.40.182]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA28329 for ; Mon, 4 Dec 1995 04:34:37 -0800 Received: (from dufault@localhost) by hda.com (8.6.11/8.6.9) id HAA02121; Mon, 4 Dec 1995 07:23:50 -0500 From: Peter Dufault Message-Id: <199512041223.HAA02121@hda.com> Subject: Re: /sys/scsi/st.c and NEW_SCSICONF? To: julian@ref.tfs.com (Julian Elischer) Date: Mon, 4 Dec 1995 07:23:49 -0500 (EST) Cc: joerg_wunsch@uriah.heep.sax.de, jkh@time.cdrom.com, freebsd-scsi@FreeBSD.ORG In-Reply-To: <199512040035.QAA02303@ref.tfs.com> from "Julian Elischer" at Dec 3, 95 04:35:12 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 946 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk > > > > > As Jordan K. Hubbard wrote: > > > > > > If you have NEW_SCSICONF defined in -current, it disables a block of > > > defines in /sys/scsi/scsi_tape.h. All well and good, but one of those > > > defines is "QIC_3080" which gets referenced in st.c regardless. > > > > > > I've conditionalized the QIC_3080 references in st.c on !NEW_SCSICONF > > > as well and gotten past the problem for now, but I'm not sure if > > > that's what the author(s) intended. > > > > NEW_SCSICONF should die (one way or the other), but apparently > > everybody is too busy to kill it... > > I've scheduled some of my time in the upcoming holiday > to cleaning up the SCSI code.. > Good, so have I. We'll coordinate off line. You get all the low level drivers, I'll get the upper... -- 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 Mon Dec 4 16:45:27 1995 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA16101 for freebsd-scsi-outgoing; Mon, 4 Dec 1995 16:45:27 -0800 Received: from wiley.csusb.edu (wiley.csusb.edu [139.182.2.2]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id QAA16096 for ; Mon, 4 Dec 1995 16:45:25 -0800 Received: (from rmallory@localhost) by wiley.csusb.edu (8.6.11/8.6.11) id QAA29977; Mon, 4 Dec 1995 16:50:03 -0800 From: Rob Mallory Message-Id: <199512050050.QAA29977@wiley.csusb.edu> Subject: Re: df of cdrom bit hard To: julian@ref.tfs.com (Julian Elischer) Date: Mon, 4 Dec 1995 16:50:03 -0800 (PST) Cc: freebsd-scsi@freefall.FreeBSD.org In-Reply-To: <199512040733.XAA04323@ref.tfs.com> from "Julian Elischer" at Dec 3, 95 11:33:49 pm X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk > > looks like a power glitch.. are those devices in an external cabinet? 3 scsi disks + HP1533A + plextor cdrom, all internal, in that order with plextor termination enabled, I can't remember if the dat has term power enabled. and one st31200W on the other end (internal). 300W power supply, external UPS. after the bus reset, the cdrom gave I/O errors, but the bus was not hung. I sync'd rebooted, and everything was fine. > OR > possibly the ncd drive detected a hang and reset the scsi bus.. I thought plextor 6-plex's were the "more friendly" type :) ...should I add a ribbon-->micro-D converter and terminate with an active terminator? -RM > > what do you think stefan? > julian > From owner-freebsd-scsi Mon Dec 4 17:20:03 1995 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id RAA17579 for freebsd-scsi-outgoing; Mon, 4 Dec 1995 17:20:03 -0800 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id RAA17544 for ; Mon, 4 Dec 1995 17:19:57 -0800 Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.9) id RAA06982; Mon, 4 Dec 1995 17:19:52 -0800 From: Julian Elischer Message-Id: <199512050119.RAA06982@ref.tfs.com> Subject: Re: df of cdrom bit hard To: rmallory@wiley.csusb.edu (Rob Mallory) Date: Mon, 4 Dec 1995 17:19:51 -0800 (PST) Cc: scsi@freebsd.org In-Reply-To: <199512050050.QAA29977@wiley.csusb.edu> from "Rob Mallory" at Dec 4, 95 04:50:03 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 977 Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk > > > > > looks like a power glitch.. are those devices in an external cabinet? > > 3 scsi disks + HP1533A + plextor cdrom, all internal, in that order > with plextor termination enabled, I can't remember if the dat has term > power enabled. and one st31200W on the other end (internal). > 300W power supply, external UPS. hmm 3 disks? that could be quite a lot of power, but 300watts should cover it.. > after the bus reset, the cdrom gave I/O errors, but the bus was not hung. > I sync'd rebooted, and everything was fine. > > > OR > > possibly the ncd drive detected a hang and reset the scsi bus.. oops ^^^^^^^^^^ ncr driver, not ncd drive > > I thought plextor 6-plex's were the "more friendly" type :) > ...should I add a ribbon-->micro-D converter and terminate with > an active terminator? what termination do you have now? you should examine this carefully before proceeding > -RM > > > > > what do you think stefan? > > julian > > > From owner-freebsd-scsi Fri Dec 8 08:58:30 1995 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA17547 for freebsd-scsi-outgoing; Fri, 8 Dec 1995 08:58:30 -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 IAA17231 for ; Fri, 8 Dec 1995 08:55:01 -0800 (PST) Received: by Sysiphos id AA26892 (5.67b/IDA-1.5 for scsi@freebsd.org); Fri, 8 Dec 1995 16:23:21 +0100 Message-Id: <199512081523.AA26892@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Fri, 8 Dec 1995 16:23:21 +0100 In-Reply-To: Andrew Russell "Check back Re: Problem with IBM 2 gig" (Dec 3, 23:33) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: rmallory@wiley.csusb.edu, scsi@freebsd.org Subject: Re: Check back Re: Problem with IBM 2 gig Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk } Subject: Check back Re: Problem with IBM 2 gig } looks like a power glitch.. are those devices in an external cabinet? } OR } possibly the ncd drive detected a hang and reset the scsi bus.. } } what do you think stefan? } julian Thanks for forwarding the message ... } > [asus MB, ncr825 bios3.04, plextor 6x] } > off a new kernel from sunday night, I got the following when doing } > a `df` with a mounted cdrom... any clues? } > ps: the new clustering code on cd9660's works excellent! } > I can (almost) watch two ~100MB qt movies off a cd at the same time! } > } > root@kickme$ df } > Dec 3 22:56:03 kickme /kernel: ncr0:6: ERROR (80:140) (8-2a-0) (88/13) @ (bd4:900b0000). } > Dec 3 22:56:03 kickme /kernel: ncr0:6: ERROR (80:140) (8-2a-0) (88/13) @ (bd4:900b0000). It is quite funny to see this (and the other messages) appear twice ... Never observed that before ... dstat and istat registers = (80:140): 80: dma fifo empty (Ok) 140: arbitration complete + handshake timeout SCSI bus state: out: ATN (NCR issues ATN) bus: BSY + ATN + C_D (SCSI lines are: Command phase + Attention) data: 0 DISPATCH: ... ... bd4: 900b0000 00000000 return when (data_out) 910a0000 00000000 return if (data_in) Hmmm, this is where it fails ... The DISPATCH code waits for the SCSI phase to stabilize (that's the WHEN clause). It will just return (to the data transfer code), if either a data input or output phase is detected. Obviously the NCR chip blocked at the WHEN, because it considered the bus to be in an inconsistent state (e.g. not connected, arbitrating, ...) } > root@kickme$ Dec 3 22:56:04 kickme /kernel: script cmd = 910a0000 } > Dec 3 22:56:04 kickme /kernel: script cmd = 910a0000 } > Dec 3 22:56:04 kickme /kernel: reg: da 10 80 13 47 88 06 0f 01 08 02 2a 80 00 0a 00. } > Dec 3 22:56:04 kickme /kernel: reg: da 10 80 13 47 88 06 0f 01 08 02 2a 80 00 0a 00. } > Dec 3 22:56:04 kickme /kernel: ncr0: handshake timeout } > Dec 3 22:56:04 kickme /kernel: ncr0: handshake timeout } > Dec 3 22:56:04 kickme /kernel: cd0(ncr0:6:0): COMMAND FAILED (6 ff) @f0aa8a00. } > Dec 3 22:56:04 kickme /kernel: cd0(ncr0:6:0): COMMAND FAILED (6 ff) @f0aa8a00. The command failed because of the timeout. The NCR did not go on, because it considered the SCSI bus to not be in a valid state. } > Dec 3 22:56:04 kickme /kernel: sd0(ncr0:0:0): COMMAND FAILED (6 ff) @f0aa7c00. } > Dec 3 22:56:04 kickme /kernel: sd0(ncr0:0:0): COMMAND FAILED (6 ff) @f0aa7c00. This is a secondary effect. The hard disk had an active command, which also was terminated because of the timeout. It had not got a chance to connect, so this is a little unfair ... } > Dec 3 22:56:04 kickme /kernel: sd0(ncr0:0:0): UNIT ATTENTION asc:29,0 } > Dec 3 22:56:04 kickme /kernel: sd0(ncr0:0:0): UNIT ATTENTION asc:29,0 The hard disk complains about the bus reset. Why was there no message from the NCR driver, that it was about to send a SCSI bus reset ??? Hmmm. } > Dec 3 22:56:05 kickme /kernel: sd0(ncr0:0:0): Power on, reset, or bus device reset occurred } > Dec 3 22:56:05 kickme /kernel: sd0(ncr0:0:0): Power on, reset, or bus device reset occurred The same in text form ... I'm a little confused about the two identical error messages. The commands in question are one and the same (as the @f0aa8a00 command control block address proves). If this remains a single case, thaen I'd say it most likely was a glitch. The driver was in an consistent state, and the NCR seems to have missed the fact, that the bus was ready for the requested command transfer, according to the SCSI control lines printed in the error message. The timeout lead to a SCSI bus reset, but the generic SCSI code should have resent the command to the hard disk, and if the CDROM did not lock up internally, then it should have been able to continue normal operation as well. Or did the system crash as a result ??? 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 Fri Dec 8 17:23:59 1995 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA11767 for freebsd-scsi-outgoing; Fri, 8 Dec 1995 17:23:59 -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 RAA11762 for ; Fri, 8 Dec 1995 17:23:56 -0800 (PST) Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.9) id RAA07036; Fri, 8 Dec 1995 17:22:28 -0800 From: Julian Elischer Message-Id: <199512090122.RAA07036@ref.tfs.com> Subject: Re: Check back Re: Problem with IBM 2 gig To: se@zpr.uni-koeln.de (Stefan Esser) Date: Fri, 8 Dec 1995 17:22:27 -0800 (PST) Cc: rmallory@wiley.csusb.edu, scsi@freebsd.org In-Reply-To: <199512081523.AA26892@Sysiphos> from "Stefan Esser" at Dec 8, 95 04:23:21 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk > } > Dec 3 22:56:03 kickme /kernel: ncr0:6: ERROR (80:140) (8-2a-0) (88/13) @ (bd4:900b0000). > } > Dec 3 22:56:03 kickme /kernel: ncr0:6: ERROR (80:140) (8-2a-0) (88/13) @ (bd4:900b0000). > > It is quite funny to see this (and the other messages) > appear twice ... Never observed that before ... that's just syslog entering it twice I would guess. > > } > Dec 3 22:56:04 kickme /kernel: sd0(ncr0:0:0): UNIT ATTENTION asc:29,0 > > The hard disk complains about the bus reset. Why was there > no message from the NCR driver, that it was about to send > a SCSI bus reset ??? Hmmm. I tcould have been a power glitch to the drives too. I've seen that.. (loose power connector..) gives the same error message.... > > } > Dec 3 22:56:05 kickme /kernel: sd0(ncr0:0:0): Power on, reset, or bus device reset occurred > } > Dec 3 22:56:05 kickme /kernel: sd0(ncr0:0:0): Power on, reset, or bus device reset occurred > > The same in text form ... > > I'm a little confused about the two identical error messages. > The commands in question are one and the same (as the @f0aa8a00 > command control block address proves). as I said, that's just syslog If you looked in dmesg, there would only actually be one.. > > If this remains a single case, thaen I'd say it most likely was > a glitch. The driver was in an consistent state, and the NCR > seems to have missed the fact, that the bus was ready for the > requested command transfer, according to the SCSI control lines > printed in the error message. > > The timeout lead to a SCSI bus reset, but the generic SCSI code > should have resent the command to the hard disk, and if the > CDROM did not lock up internally, then it should have been able > to continue normal operation as well. > > Or did the system crash as a result ??? > > > Regards, STefan > That was my thought on the matter too... julian +----------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / On assignment | / \ julian@ref.tfs.com +------>x USA \ in a very strange | ( OZ ) 300 lakeside Dr. oakland CA. \___ ___ | country ! +- X_.---._/ USA+(510) 645-3137(wk) \_/ \\ v From owner-freebsd-scsi Fri Dec 8 22:38:57 1995 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA29729 for freebsd-scsi-outgoing; Fri, 8 Dec 1995 22:38:57 -0800 (PST) Received: from wiley.csusb.edu (wiley.csusb.edu [139.182.2.2]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id WAA29724 for ; Fri, 8 Dec 1995 22:38:53 -0800 (PST) Received: (from rmallory@localhost) by wiley.csusb.edu (8.6.11/8.6.11) id WAA08263; Fri, 8 Dec 1995 22:43:24 -0800 From: Rob Mallory Message-Id: <199512090643.WAA08263@wiley.csusb.edu> Subject: Re: Check back Re: Problem with IBM 2 gig To: se@zpr.uni-koeln.de (Stefan Esser) Date: Fri, 8 Dec 1995 22:43:24 -0800 (PST) Cc: scsi@FreeBSD.org In-Reply-To: <199512081523.AA26892@Sysiphos> from "Stefan Esser" at Dec 8, 95 04:23:21 pm X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.org Precedence: bulk > } looks like a power glitch.. are those devices in an external cabinet? > } OR > } possibly the ncd drive detected a hang and reset the scsi bus.. > } > } what do you think stefan? > } julian > > Thanks for forwarding the message ... > > It is quite funny to see this (and the other messages) > appear twice ... Never observed that before ... syslog... [from syslog.conf, which is the same in -current] *.err root *.notice;auth.debug root *.alert root both an err and an alert? ...I also get dual 'root login on...':) 'think I'll quiet it up tonight..:) [..excellent man(9) material omited..] [[man-9 material is the (understandably) commonly omited 'vaporware' pages where the authors and gurus describe their internals of their drivers:]] > } > Dec 3 22:56:05 kickme /kernel: sd0(ncr0:0:0): Power on, reset, or bus device reset occurred I usualy look first to termination/cable problems when I see this. but this bus is all on one ribbon. (6 devices, 2 or 3 of which are moving to my new 810 (see next message:)) > The same in text form ... > > I'm a little confused about the two identical error messages. > The commands in question are one and the same (as the @f0aa8a00 > command control block address proves). > > > If this remains a single case, thaen I'd say it most likely was > a glitch. The driver was in an consistent state, and the NCR > seems to have missed the fact, that the bus was ready for the > requested command transfer, according to the SCSI control lines > printed in the error message. > I'll keep my eye out, and pull out the dvm the next time,, the machine is(has been) on a smartUPS, so my roommate's room heater only flickers my lights now;) > The timeout lead to a SCSI bus reset, but the generic SCSI code > should have resent the command to the hard disk, and if the > CDROM did not lock up internally, then it should have been able > to continue normal operation as well. > > Or did the system crash as a result ??? nope. the plextor was hung hard, with the orange and green lights on. the scsi bus was ok, and the disk sync'd right after. manual reboot soon followed. [new scsi bus described in next message] thanks! -rob > > > 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 Fri Dec 8 23:14:04 1995 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA01284 for freebsd-scsi-outgoing; Fri, 8 Dec 1995 23:14:04 -0800 (PST) Received: from wiley.csusb.edu (wiley.csusb.edu [139.182.2.2]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA01276 for ; Fri, 8 Dec 1995 23:13:58 -0800 (PST) Received: (from rmallory@localhost) by wiley.csusb.edu (8.6.11/8.6.11) id XAA08642; Fri, 8 Dec 1995 23:18:41 -0800 From: Rob Mallory Message-Id: <199512090718.XAA08642@wiley.csusb.edu> Subject: ncr[01] conflicts..? To: scsi@FreeBSD.org Date: Fri, 8 Dec 1995 23:18:41 -0800 (PST) Cc: se@freefall.FreeBSD.org X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.org Precedence: bulk OK, I took the "easy" way out,,throw more hardware at it apporach:) I finaly found (through a tech at symbios) how to successfully get both a ncr825 and 810 in my asus p55tp4xe with 3.07 ncr bios. the tyan 825 had a 3.04 rom, complete with geometry bugs which prevented me from installing slowaris-2.5 and freebsd on the same disk. the tech suggested that the 810 be installed in a lower slot than the 825 so it booted first. the 825, now romless, would 'use' the 3.07 bios which was incarnated by the 810 from the asus bios. it follows that the 810 would have to contain the boot drive. well, this is where it gets fun. the 810 has a 2 way jumper on it that says '2nd'. it does what it implies, and moves its mem-base(?) somewhere else(i guess). see the following boot messages: (chopped up for readability) [conflicting with the 825] Dec 8 21:58:16 kickme /kernel: Probing for devices on the PCI bus: Dec 8 21:58:16 kickme /kernel: chip0 rev 1 on pci0:0 Dec 8 21:58:16 kickme /kernel: ncr0 rev 1 int a irq ?? on pci 0:6 Dec 8 21:58:16 kickme /kernel: pci_map_mem failed: device's memrange 0xff00-0xf fff is incompatible with its bridge's memrange 0x4000000-0xffffffff Dec 8 21:58:16 kickme /kernel: CACHE TEST FAILED: reg dstat-sstat2 readback fff fffff. Dec 8 21:58:16 kickme /kernel: CACHE INCORRECTLY CONFIGURED. Dec 8 21:58:16 kickme /kernel: chip1 rev 2 on pci0:7 Dec 8 21:58:16 kickme /kernel: vga0 rev 0 int a Dec 8 08:45:56 kickme /kernel: ncr1 rev 2 int a irq 11 o n pci0:11 Dec 8 08:45:56 kickme /kernel: (ncr1:0:0): "TOSHIBA MK537FB 6261" type 0 fixed Dec 8 08:45:57 kickme /kernel: sd0(ncr1:0:0): Direct-Access Dec 8 08:45:57 kickme /kernel: sd0(ncr1:0:0): FAST SCSI-2 100ns (10 Mb/sec) off ...boots off ncr(1), the 825, sd0. [not conflicting boots off ncr1, but of course, the kernel says root on sd0] Dec 8 08:50:37 kickme /kernel: Probing for devices on the PCI bus: Dec 8 08:50:37 kickme /kernel: chip0 rev 1 on pci0:0 Dec 8 08:50:37 kickme /kernel: chip1 rev 2 on pci0:7 Dec 8 08:50:38 kickme /kernel: ncr0 rev 2 int a irq 11 o Dec 8 08:50:38 kickme /kernel: (ncr0:0:0): "TOSHIBA MK537FB 6261" type 0 fixed Dec 8 08:50:38 kickme /kernel: sd0(ncr0:0:0): Direct-Access ... Dec 8 08:50:40 kickme /kernel: ncr1 rev 1 int a irq 14 on pci 0:12 Dec 8 08:50:40 kickme /kernel: ncr1 waiting for scsi devices to settle Dec 8 08:50:40 kickme /kernel: (ncr1:0:0): "CONNER CFA540S 13B0" type 0 fixed S Dec 8 08:50:40 kickme /kernel: sd4(ncr1:0:0): Direct-Access Dec 8 08:50:40 kickme /kernel: sd4(ncr1:0:0): FAST SCSI-2 100ns (10 Mb/sec) off sd4 is a 2.1R disk which was probed by sdms at boot, and the bootblocks were read, a kernel read, and then tried to switch root to sd0. ... i noticed how they switch posisions when i jumper the '2nd' jumper.. my question is,, Why does the ncr probe look backwards to me? if the 810 is hooked first and booted, and the sd4 kernel is read that device, why does the kernel call the 810 ncr1? ...has anyone else run into this? is there a valid reason for this being default? ...give me a 'FLIP_NCR_PROBE' option flag! :-) Thanks, Rob Mallory [rmallory@csusb.edu] From owner-freebsd-scsi Sat Dec 9 15:46:28 1995 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA28650 for freebsd-scsi-outgoing; Sat, 9 Dec 1995 15:46:28 -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 PAA28638 for ; Sat, 9 Dec 1995 15:46:16 -0800 (PST) Received: by Sysiphos id AA17178 (5.67b/IDA-1.5 for scsi@freebsd.org); Sun, 10 Dec 1995 00:32:55 +0100 Message-Id: <199512092332.AA17178@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Sun, 10 Dec 1995 00:32:55 +0100 In-Reply-To: Rob Mallory "ncr[01] conflicts..?" (Dec 8, 23:18) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: Rob Mallory Subject: Re: ncr[01] conflicts..? Cc: scsi@freebsd.org Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk On Dec 8, 23:18, Rob Mallory wrote: } Subject: ncr[01] conflicts..? } OK, I took the "easy" way out,,throw more hardware at it apporach:) } } I finaly found (through a tech at symbios) how to successfully get } both a ncr825 and 810 in my asus p55tp4xe with 3.07 ncr bios. } } the tyan 825 had a 3.04 rom, complete with geometry bugs which } prevented me from installing slowaris-2.5 and freebsd on the same disk. } the tech suggested that the 810 be installed in a lower slot than the } 825 so it booted first. the 825, now romless, would 'use' the 3.07 } bios which was incarnated by the 810 from the asus bios. it follows } that the 810 would have to contain the boot drive. Why can't you update both SDMS ROMs to the same software release level ? I'd be surprised if the slot numbers would make any difference with respect to which ROM is choosen. But I guess you made sure it works as advertised ? (I.e.: Did the SDMS line show that the new BIOS was in fact the one being used ?) There was a message with regard to a mixed 810/825 system recently, and it claimed, that the BIOS did always prefer the 810 as the "MAIN" controller, i.e. no matter which slots the 810 and 825 are put into, the 810 should always get the DOS drive C: ... This is different from what the BSD init code does: The PCI bus is scanned from low to high bus numbers and from low to high slot numbers, and controllers are assigned to drivers in the order they are found. } well, this is where it gets fun. the 810 has a 2 way jumper on it that } says '2nd'. it does what it implies, and moves its mem-base(?) somewhere } else(i guess). see the following boot messages: } } (chopped up for readability) } [conflicting with the 825] } Dec 8 21:58:16 kickme /kernel: Probing for devices on the PCI bus: } Dec 8 21:58:16 kickme /kernel: chip0 rev 1 on pci0:0 } Dec 8 21:58:16 kickme /kernel: ncr0 rev 1 int a irq ?? on pci } 0:6 } Dec 8 21:58:16 kickme /kernel: pci_map_mem failed: device's memrange 0xff00-0xf } fff is incompatible with its bridge's memrange 0x4000000-0xffffffff There is something wrong ... !!! The NCR seems to have been mapped into the memory range of the last 256 bytes just below 64KB. This would be the fault of the BIOS. The FreeBSD PCI code does currently respect these values, even if it considers them badly choosen (and complains) ... * Could you please send **verbose** boot messages (obtained * by booting with "-v" entered at the "Boot: " prompt). * I need all lines starting at "pcibus_setup()" and until * the final PCI ressource report. } Dec 8 21:58:16 kickme /kernel: CACHE TEST FAILED: reg dstat-sstat2 readback fff } fffff. This is a sign, that the NCR does not see the same data as the CPU. That's not surprising, if the memory region 0xff00 to 0xffff in fact has been assigned to the NCR's registers. That region most likely is covered by a WB secondary cache, and the NCR doesn't see the data written before the corresponding cache lines get flushed to RAM. } Dec 8 21:58:16 kickme /kernel: CACHE INCORRECTLY CONFIGURED. } Dec 8 21:58:16 kickme /kernel: chip1 rev 2 on pci0:7 } Dec 8 21:58:16 kickme /kernel: vga0 rev 0 int a } Dec 8 08:45:56 kickme /kernel: ncr1 rev 2 int a irq 11 o } n pci0:11 } Dec 8 08:45:56 kickme /kernel: (ncr1:0:0): "TOSHIBA MK537FB 6261" type 0 fixed } Dec 8 08:45:57 kickme /kernel: sd0(ncr1:0:0): Direct-Access } Dec 8 08:45:57 kickme /kernel: sd0(ncr1:0:0): FAST SCSI-2 100ns (10 Mb/sec) off } } ...boots off ncr(1), the 825, sd0. Does it in fact work, even though the cache test warned about the lack of coherency ? ??? } [not conflicting boots off ncr1, but of course, the kernel says root on sd0] } Dec 8 08:50:37 kickme /kernel: Probing for devices on the PCI bus: } Dec 8 08:50:37 kickme /kernel: chip0 rev 1 on pci0:0 } Dec 8 08:50:37 kickme /kernel: chip1 rev 2 on pci0:7 } Dec 8 08:50:38 kickme /kernel: ncr0 rev 2 int a irq 11 o } Dec 8 08:50:38 kickme /kernel: (ncr0:0:0): "TOSHIBA MK537FB 6261" type 0 fixed } Dec 8 08:50:38 kickme /kernel: sd0(ncr0:0:0): Direct-Access } ... } Dec 8 08:50:40 kickme /kernel: ncr1 rev 1 int a irq 14 on pci } 0:12 } Dec 8 08:50:40 kickme /kernel: ncr1 waiting for scsi devices to settle } Dec 8 08:50:40 kickme /kernel: (ncr1:0:0): "CONNER CFA540S 13B0" type 0 fixed S } Dec 8 08:50:40 kickme /kernel: sd4(ncr1:0:0): Direct-Access } Dec 8 08:50:40 kickme /kernel: sd4(ncr1:0:0): FAST SCSI-2 100ns (10 Mb/sec) off } } sd4 is a 2.1R disk which was probed by sdms at boot, and the bootblocks } were read, a kernel read, and then tried to switch root to sd0. As I wrote above, the SDMS code will prefer the 810 as the boot controller. FreeBSD doesn't, it sees the 825 on PCI bus 0 slot 11 and the 810 on bus 0 slot 12 ... } i noticed how they switch posisions when i jumper the '2nd' jumper.. Do you know, what this "2nd" jumper is supposed to do ? Does it just disable accesses to the cards BIOS ROM ? } my question is,, Why does the ncr probe look backwards to me? } if the 810 is hooked first and booted, and the sd4 kernel is read that } device, why does the kernel call the 810 ncr1? That's because FreeBSD finds it in the higher numbered slot. } ...has anyone else run into this? is there a valid reason for this } being default? ...give me a 'FLIP_NCR_PROBE' option flag! :-) Hmmm, well, have you tried flipping the cards ? 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