From owner-freebsd-scsi Sun Jan 17 00:03:37 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA16741 for freebsd-scsi-outgoing; Sun, 17 Jan 1999 00:03:37 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from scotty.masternet.it (scotty.masternet.it [194.184.65.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA16736; Sun, 17 Jan 1999 00:03:34 -0800 (PST) (envelope-from gmarco@scotty.masternet.it) Received: from suzy (modem32.masternet.it [194.184.65.42]) by scotty.masternet.it (8.8.8/8.8.8) with SMTP id JAA15555; Sun, 17 Jan 1999 09:03:02 +0100 (CET) (envelope-from gmarco@scotty.masternet.it) Message-Id: <4.1.19990117085758.009d2ee0@194.184.65.4> X-Sender: gmarco@scotty.masternet.it X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sun, 17 Jan 1999 09:06:46 +0100 To: Andrew Kenneth Milton , merlin@ghostwheel.com (Christopher Knight) From: Gianmarco Giovannelli Subject: Re: Problem booting from aic7890/91 Ultra2 SCSI Cc: current@FreeBSD.ORG, scsi@FreeBSD.ORG In-Reply-To: <199901170256.MAA01382@zeus.theinternet.com.au> References: <4.1.19990116180852.00a9aea0@pop.ghostwheel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 12.56 17/01/99 +1000, Andrew Kenneth Milton wrote: >+----[ Christopher Knight ]--------------------------------------------- >| At 12:49 AM 1/17/99 +0100, Gianmarco Giovannelli wrote: >| > >| >Ok, first the conclusion... >| > >| >I am not able to boot anymore from a 3.0-current system while I can boot >| >quite nicely from the 3.0-RELEASE generic kernel. >| > >| >The system hangs on checking the scsi chain and remains stopped here. The >| >last thing I can see on the screen is the : >| >Waiting 3 seconds for SCSI devices to settle >| > >| >And nothing else happens anymore. So I have to hard reset the box. >| >| >| I have been seeing this for the two weeks or so. A shutdown -r will always >| hang. A complete powerdown has been the only way I can reboot my box of >late. > >I recently (last night) added USB support to my kernel (just to see :-) >and it hung at the same place. Removing the USB entries fixed it. > >This was also at the same time as the syscons/atkbd changeover for me as well >so I wasn't expecting it really to be the USB driver (since I have no >USB devices). > >If you have USB support compiled in try removing it. > I have no USB support compiled, as you can see in my kernel configuration I sent with my last message. Perhaps it's a timing problem or an intrusive check. boh ? Who knows what is changed in the (scsi|cam|adaptec) in the last mounth or so ? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jan 17 04:20:37 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA11383 for freebsd-scsi-outgoing; Sun, 17 Jan 1999 04:20:37 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA11374 for ; Sun, 17 Jan 1999 04:20:33 -0800 (PST) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.1/frmug-2.3/nospam) with UUCP id NAA21873 for freebsd-scsi@FreeBSD.ORG; Sun, 17 Jan 1999 13:20:26 +0100 (CET) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id 5818F1573; Sun, 17 Jan 1999 12:37:26 +0100 (CET) Date: Sun, 17 Jan 1999 12:37:26 +0100 From: Ollivier Robert To: freebsd-scsi@FreeBSD.ORG Subject: Re: Symbios 875 activity LED? Message-ID: <19990117123726.A73895@keltia.freenix.fr> Mail-Followup-To: freebsd-scsi@FreeBSD.ORG References: <199901170401.WAA00625@nospam.hiwaay.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199901170401.WAA00625@nospam.hiwaay.net>; from David Kelly on Sat, Jan 16, 1999 at 10:01:49PM -0600 X-Operating-System: FreeBSD 3.0-CURRENT/ELF ctm#4931 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to David Kelly: > member of group "operator") that /etc/nologin was not being deleted. It has been moved recently to /var/run/nologin: -=-=- asami 1999/01/11 01:07:42 PST Modified files: etc login.conf rc include paths.h sbin/shutdown shutdown.8 usr.bin/login login.1 Log: Move nologin from /etc to /var/run. This means one less file that has to be written to /etc. The only essential change is in paths.h, so any third-party software written correctly will pick it up in the next rebuild. -=-=- > You mean this is all there was to it and I've been without a blinking > light all this time? You mean all they had to do was smack one tiny tiny > little bit? Yes. > Doesn't seem worth and ifdef. :-) Can only assume somebody > knows more than I do and this is really important to keep from breaking > something. Well, I've been using it for more than one year without any problem. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #67: Tue Dec 29 20:24:02 CET 1998 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jan 17 12:40:44 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA26359 for freebsd-scsi-outgoing; Sun, 17 Jan 1999 12:40:44 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from cidaut4.eis.uva.es (cidaut4.eis.uva.es [157.88.142.104]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA26352 for ; Sun, 17 Jan 1999 12:40:38 -0800 (PST) (envelope-from sanper@pcfa.es.eu.org) Received: (from uucp@localhost) by cidaut4.eis.uva.es (8.8.5/8.8.5) with UUCP id VAA11098 for freebsd-scsi@freebsd.org; Sun, 17 Jan 1999 21:40:28 +0100 (CET) Received: from localhost (sanper@localhost) by ergopc.pcfa.es.eu.org (8.8.8/8.8.8) with SMTP id VAA05017 for ; Sun, 17 Jan 1999 21:36:41 +0100 (CET) (envelope-from sanper@ergopc.pcfa.es.eu.org) Date: Sun, 17 Jan 1999 21:36:40 +0100 (CET) From: "Santiago Perez-Cacho Jr." To: freebsd-scsi@FreeBSD.ORG Subject: Strange disk deaths Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, everyone! This question is probably off-topic, but I can think of no better place to ask ;-) Last Friday the power supply of one of the Alphas I administer (a 4 year old DEC 3000 600) died, so I took out its two disk drives and put them on an identical machine, but the only thing I got was a lot of beeps from the drives. So I took them out again and put one of them on a FreeBSD 3.0-CURRENT system (buildworld made on January 4th) with a Symbios 53c810 SCSI card to see what I could find out. Here are the relevant dmesg lines: [snip] FreeBSD 3.0-CURRENT #2: Fri Jan 15 21:36:04 CET 1999 [snip] ncr0: rev 0x12 int a irq 9 on pci0.11.0 [snip] da0 at ncr0 bus 0 target 2 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 10.0MB/s transfers (10.0MHz, offset 8), Tagged Queueing Enabled da0: 1001MB (2050860 512 byte sectors: 64H 32S/T 1001C) But whenever I issue a command that tries to access the disk, I get an I/O error, a concert of beeps from the drive when it tries to spin up, and this kind of messages on the console (this one is from issuing a disklabel -r /dev/rda0c) (da0:ncr0:0:2:0): READ(06). CDB: 8 0 0 0 1 0 (da0:ncr0:0:2:0): HARDWARE FAILURE info:300d00f8 asc:40,83 (da0:ncr0:0:2:0): Diagnostic failure: ASCQ = Component ID field replaceable unit: 2 da0: error reading primary partition table reading fsbn 0 I haven't tried the same with the other drive, a DEC RZ28, but symptoms were the same... My questions are: - Has anybody experienced this kind of disk failure, and if so, what has failed? - Is there anything I can try to bring them back to life or, as I suspect, their only utility is to hold the papers on my desk? :-( Thanks in advance for any piece of advice, Santi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jan 17 15:40:49 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA21107 for freebsd-scsi-outgoing; Sun, 17 Jan 1999 15:40:49 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA21079; Sun, 17 Jan 1999 15:40:36 -0800 (PST) (envelope-from se@dialup124.zpr.uni-koeln.de) Received: from dialup124.zpr.Uni-Koeln.DE (dialup124.zpr.Uni-Koeln.DE [134.95.219.124]) by Sisyphos.MI.Uni-Koeln.DE (8.8.7/8.8.7) with ESMTP id AAA13974; Mon, 18 Jan 1999 00:40:30 +0100 (MET) Received: (from se@localhost) by dialup124.zpr.Uni-Koeln.DE (8.9.1/8.6.9) id MAA00546; Sun, 17 Jan 1999 12:31:43 +0100 (CET) Date: Sun, 17 Jan 1999 12:31:42 +0100 From: Stefan Esser To: David Kelly Cc: freebsd-scsi@FreeBSD.ORG, Stefan Esser Subject: Re: Symbios 875 activity LED? Message-ID: <19990117123142.B492@dialup124.mi.uni-koeln.de> Reply-To: se@FreeBSD.ORG References: <199901170401.WAA00625@nospam.hiwaay.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199901170401.WAA00625@nospam.hiwaay.net>; from David Kelly on Sat, Jan 16, 1999 at 10:01:49PM -0600 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 1999-01-16 22:01 -0600, David Kelly wrote: > #ifdef SCSI_NCR_SYMBIOS_COMPAT > if (!(np->rv_gpcntl & 0x01)) > np->features |= FE_LED0; Symbios uses bit 0 of the GPIO register to control the busy LED, and this test just makes sure, that the GPIO control register defines this bit as an output. Bit 0 and 1 are dual function, by the way, also used to control a serial EEPROM, if present. But since you can't tell whether a card follows the Symbios SDMS convention of connecting the LED to bit 0 of GPIO (some cards use the SCSI bus busy line to drive the LED, for example), of whether some other GPIO bit is used, I'm not going to make SCSI_NCR_SYMBIOS_COMPAT defined by default, or even suggest it's use to people that are not sure whether their SCSI card follows the NCR/Symbios convention. If PCI subvendor IDs were actually used, then I could make the FE_LED0 bit depend on the card vendor and model. But as of now, even scanning for the presense of an SDMS BIOS is not safe, since a system may have SDMS in the mainboard BIOS, and some card-specific BIOS on the SCSI card (and GPIO pin 0 used for some other purpose, most likely to control writing of the Flash SCSI BIOS ROM). It is simple to positively detect the Tekram SCSI cards, and I know those don't follow the SDMS convention (and because of Tekram's policy to support free operating systems, we even know exactly how to make best use of their cards!). But as long as I'm not able to *positively* detect SDMS compatible cards, it's just to dangerous to make any assumptions about what GPIO<0> does or doesn't ... ;-) Regards, STefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jan 17 15:40:58 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA21134 for freebsd-scsi-outgoing; Sun, 17 Jan 1999 15:40:58 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA21084; Sun, 17 Jan 1999 15:40:37 -0800 (PST) (envelope-from se@dialup124.zpr.uni-koeln.de) Received: from dialup124.zpr.Uni-Koeln.DE (dialup124.zpr.Uni-Koeln.DE [134.95.219.124]) by Sisyphos.MI.Uni-Koeln.DE (8.8.7/8.8.7) with ESMTP id AAA13971; Mon, 18 Jan 1999 00:40:29 +0100 (MET) Received: (from se@localhost) by dialup124.zpr.Uni-Koeln.DE (8.9.1/8.6.9) id MAA00526; Sun, 17 Jan 1999 12:15:39 +0100 (CET) Date: Sun, 17 Jan 1999 12:15:38 +0100 From: Stefan Esser To: freebsd-scsi@FreeBSD.ORG Cc: Stefan Esser Subject: Re: Symbios 875 activity LED? Message-ID: <19990117121538.A492@dialup124.mi.uni-koeln.de> Reply-To: se@FreeBSD.ORG References: <199901162125.PAA00326@nospam.hiwaay.net> <19990117012550.A71523@keltia.freenix.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <19990117012550.A71523@keltia.freenix.fr>; from Ollivier Robert on Sun, Jan 17, 1999 at 01:25:50AM +0100 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 1999-01-17 01:25 +0100, Ollivier Robert wrote: > According to David Kelly: > > otherwise unused "Turbo LED" wires. Observed the internal LED works at > > boot time. And lights the external too. But still not under FreeBSD. > > There was some talk of this long time ago. Did it not make it into the > > distribution? > > Add the following to your config. file. Why it is not the default just > escape me... Very simple: Because the driver can't read the vendor print on your card, and it might be from, say, Tekram, and the GPIO pins might have been wired differently, and may, for example, attempt to write some undefined values to your Flash BIOS on the card ;-) > options SCSI_NCR_SYMBIOS_COMPAT # for LEDs Be aware that this works only with cards with SDMS BIOS (and I'm not even sure, whether it works with all of them). Regards, STefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jan 17 16:14:27 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA28540 for freebsd-scsi-outgoing; Sun, 17 Jan 1999 16:14:27 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA28531; Sun, 17 Jan 1999 16:14:20 -0800 (PST) (envelope-from dkelly@nospam.hiwaay.net) Received: from nospam.hiwaay.net (tnt2-38.HiWAAY.net [208.147.148.38]) by mail.HiWAAY.net (8.9.1a/8.9.0) with ESMTP id SAA17227; Sun, 17 Jan 1999 18:14:13 -0600 (CST) Received: from nospam.hiwaay.net (localhost [127.0.0.1]) by nospam.hiwaay.net (8.9.2/8.9.1) with ESMTP id SAA11049; Sun, 17 Jan 1999 18:14:11 -0600 (CST) (envelope-from dkelly@nospam.hiwaay.net) Message-Id: <199901180014.SAA11049@nospam.hiwaay.net> X-Mailer: exmh version 2.0.2 2/24/98 To: se@FreeBSD.ORG cc: freebsd-scsi@FreeBSD.ORG From: David Kelly Subject: Re: Symbios 875 activity LED? In-reply-to: Message from Stefan Esser of "Sun, 17 Jan 1999 12:31:42 +0100." <19990117123142.B492@dialup124.mi.uni-koeln.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 17 Jan 1999 18:14:11 -0600 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Stefan Esser writes: > It is simple to positively detect the Tekram SCSI cards, and I > know those don't follow the SDMS convention (and because of > Tekram's policy to support free operating systems, we even know > exactly how to make best use of their cards!). That's nice to know. Have heard Tekram cards have formatting and bad block scanning support in their BIOS config much like Adaptec and unlike my Asus SC875. Street prices for Tekram 390F's are lower than I've seen for an SC875. Problem is I'm not in the market for another SCSI card at the moment. :-( Excuses, excuses, that didn't stop me from buying an extra Matrox Millenium II 4MB yesterday for $45. While we can positively ID a Tekram card, just how else is one superior to other Symbios based cards? > But as long as I'm not able to *positively* detect SDMS compatible > cards, it's just to dangerous to make any assumptions about what > GPIO<0> does or doesn't ... ;-) I felt pretty confident that the #ifdef was there for a good reason. But the only way I found it was via mention on these mail lists. Once Upon A Time thought my SCSI card was broken because the LED didn't work. Is this option too petty or trivial to be added to LINT and config(8)? Config complains about it but kernels compile anyhow. -- David Kelly N4HHE, dkelly@nospam.hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jan 17 16:28:57 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA00729 for freebsd-scsi-outgoing; Sun, 17 Jan 1999 16:28:57 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from schuimpje.snt.utwente.nl (schuimpje.snt.utwente.nl [130.89.238.4]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA00722 for ; Sun, 17 Jan 1999 16:28:53 -0800 (PST) (envelope-from gelderen@mediaport.org) Received: from wit395301.student.utwente.nl ([130.89.235.121]:11524 "HELO deskfix" ident: "NO-IDENT-SERVICE[2]") by schuimpje.snt.utwente.nl with SMTP id <8002-10514>; Mon, 18 Jan 1999 01:28:43 +0100 Message-ID: <000301be4279$667e93c0$0d79eb0a@deskfix.local> From: "Jeroen C. van Gelderen" To: Subject: Disk dying Date: Mon, 18 Jan 1999 01:27:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, Today I saw these messages scrolling over my screen. The last line worries me a bit. Is this likely an indicator of a failing disk? Or is there something else wrong? Cheers, Jeroen Jan 18 00:03:20 wit395301 /kernel: (da0:ahc0:0:0:0): tagged openings now 31 Jan 18 00:05:19 wit395301 /kernel: (da0:ahc0:0:0:0): SCB 0xe - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x9 Jan 18 00:05:20 wit395301 /kernel: (da0:ahc0:0:0:0): Queuing a BDR SCB Jan 18 00:05:20 wit395301 /kernel: (da0:ahc0:0:0:0): Bus Device Reset Message Sent Jan 18 00:05:20 wit395301 /kernel: (da0:ahc0:0:0:0): no longer in timeout, status = 353 Jan 18 00:05:20 wit395301 /kernel: Unexpected busfree. LASTPHASE == 0xa0 Jan 18 00:05:20 wit395301 /kernel: SEQADDR == 0x14f Jan 18 00:06:17 wit395301 /kernel: (da0:ahc0:0:0:0): SCB 0x12 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x9 Jan 18 00:06:17 wit395301 /kernel: (da0:ahc0:0:0:0): Queuing a BDR SCB Jan 18 00:06:17 wit395301 /kernel: (da0:ahc0:0:0:0): Bus Device Reset Message Sent Jan 18 00:06:17 wit395301 /kernel: (da0:ahc0:0:0:0): no longer in timeout, status = 353 Jan 18 00:06:17 wit395301 /kernel: Unexpected busfree. LASTPHASE == 0xa0 Jan 18 00:06:17 wit395301 /kernel: SEQADDR == 0x14f Jan 18 00:07:17 wit395301 /kernel: (da0:ahc0:0:0:0): SCB 0x18 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x9 Jan 18 00:07:17 wit395301 /kernel: (da0:ahc0:0:0:0): Queuing a BDR SCB Jan 18 00:07:17 wit395301 /kernel: (da0:ahc0:0:0:0): Bus Device Reset Message Sent Jan 18 00:07:17 wit395301 /kernel: (da0:ahc0:0:0:0): no longer in timeout, status = 353 Jan 18 00:07:17 wit395301 /kernel: Unexpected busfree. LASTPHASE == 0xa0 Jan 18 00:07:17 wit395301 /kernel: SEQADDR == 0x14f Jan 18 00:08:17 wit395301 /kernel: (da0:ahc0:0:0:0): SCB 0x15 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0xb Jan 18 00:08:17 wit395301 /kernel: (da0:ahc0:0:0:0): Queuing a BDR SCB Jan 18 00:08:17 wit395301 /kernel: (da0:ahc0:0:0:0): Bus Device Reset Message Sent Jan 18 00:08:17 wit395301 /kernel: (da0:ahc0:0:0:0): no longer in timeout, status = 353 Jan 18 00:08:17 wit395301 /kernel: Unexpected busfree. LASTPHASE == 0xa0 Jan 18 00:08:17 wit395301 /kernel: SEQADDR == 0x14f Jan 18 00:09:17 wit395301 /kernel: (da0:ahc0:0:0:0): SCB 0x18 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x9 Jan 18 00:09:17 wit395301 /kernel: (da0:ahc0:0:0:0): Queuing a BDR SCB Jan 18 00:09:17 wit395301 /kernel: (da0:ahc0:0:0:0): Bus Device Reset Message Sent Jan 18 00:09:17 wit395301 /kernel: (da0:ahc0:0:0:0): no longer in timeout, status = 353 Jan 18 00:09:17 wit395301 /kernel: Unexpected busfree. LASTPHASE == 0xa0 Jan 18 00:09:17 wit395301 /kernel: SEQADDR == 0x14f Jan 18 00:10:17 wit395301 /kernel: (da0:ahc0:0:0:0): SCB 0x6 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x9 Jan 18 00:10:17 wit395301 /kernel: (da0:ahc0:0:0:0): Queuing a BDR SCB Jan 18 00:10:17 wit395301 /kernel: (da0:ahc0:0:0:0): Bus Device Reset Message Sent Jan 18 00:10:17 wit395301 /kernel: (da0:ahc0:0:0:0): no longer in timeout, status = 353 Jan 18 00:10:17 wit395301 /kernel: Unexpected busfree. LASTPHASE == 0xa0 Jan 18 00:10:17 wit395301 /kernel: SEQADDR == 0x14f Jan 18 00:11:17 wit395301 /kernel: (da0:ahc0:0:0:0): SCB 0x13 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x9 Jan 18 00:11:17 wit395301 /kernel: (da0:ahc0:0:0:0): Queuing a BDR SCB Jan 18 00:11:17 wit395301 /kernel: (da0:ahc0:0:0:0): Bus Device Reset Message Sent Jan 18 00:11:17 wit395301 /kernel: (da0:ahc0:0:0:0): no longer in timeout, status = 353 Jan 18 00:11:17 wit395301 /kernel: Unexpected busfree. LASTPHASE == 0xa0 Jan 18 00:11:17 wit395301 /kernel: SEQADDR == 0x14f Jan 18 00:12:17 wit395301 /kernel: (da0:ahc0:0:0:0): SCB 0xa - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0xc Jan 18 00:12:17 wit395301 /kernel: (da0:ahc0:0:0:0): Queuing a BDR SCB Jan 18 00:12:17 wit395301 /kernel: (da0:ahc0:0:0:0): Bus Device Reset Message Sent Jan 18 00:12:17 wit395301 /kernel: (da0:ahc0:0:0:0): no longer in timeout, status = 353 Jan 18 00:12:17 wit395301 /kernel: Unexpected busfree. LASTPHASE == 0xa0 Jan 18 00:12:17 wit395301 /kernel: SEQADDR == 0x14f Jan 18 00:13:17 wit395301 /kernel: (da0:ahc0:0:0:0): SCB 0x19 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x9 Jan 18 00:13:17 wit395301 /kernel: (da0:ahc0:0:0:0): Queuing a BDR SCB Jan 18 00:13:17 wit395301 /kernel: (da0:ahc0:0:0:0): Bus Device Reset Message Sent Jan 18 00:13:17 wit395301 /kernel: (da0:ahc0:0:0:0): no longer in timeout, status = 353 Jan 18 00:13:17 wit395301 /kernel: Unexpected busfree. LASTPHASE == 0xa0 Jan 18 00:13:17 wit395301 /kernel: SEQADDR == 0x14f Jan 18 00:14:17 wit395301 /kernel: (da0:ahc0:0:0:0): SCB 0xf - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x9 Jan 18 00:14:17 wit395301 /kernel: (da0:ahc0:0:0:0): Queuing a BDR SCB Jan 18 00:14:17 wit395301 /kernel: (da0:ahc0:0:0:0): Bus Device Reset Message Sent Jan 18 00:14:17 wit395301 /kernel: (da0:ahc0:0:0:0): no longer in timeout, status = 353 Jan 18 00:14:17 wit395301 /kernel: Unexpected busfree. LASTPHASE == 0xa0 Jan 18 00:14:17 wit395301 /kernel: SEQADDR == 0x14f Jan 18 00:15:17 wit395301 /kernel: (da0:ahc0:0:0:0): SCB 0xc - timed out in message in phase, SEQADDR == 0x101 Jan 18 00:15:17 wit395301 /kernel: (da0:ahc0:0:0:0): BDR message in message buffer Jan 18 00:15:18 wit395301 /kernel: (da0:ahc0:0:0:0): no longer in timeout, status = 34b Jan 18 00:15:18 wit395301 /kernel: ahc0: Bus Device Reset on A:0. 31 SCBs aborted Jan 18 00:15:18 wit395301 /kernel: /: got error 0 while accessing filesystem ------------- Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.0-CURRENT #22: Wed Jan 13 23:33:13 CET 1999 root@wit395301.student.utwente.nl:/usr/src/sys/compile/SERVIX Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 99716476 Hz CPU: Pentium/P54C (99.72-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x525 Stepping=5 Features=0x1bf real memory = 67108864 (65536K bytes) config> quit avail memory = 62595072 (61128K bytes) Preloaded elf kernel "kernel" at 0xf0288000. Probing for devices on PCI bus 0: chip0: rev 0x01 on pci0.0.0 chip1: rev 0x02 on pci0.7.0 ahc0: rev 0x01 int a irq 5 on pci0.13.0 ahc0: aic7860 Single Channel A, SCSI Id=7, 3/255 SCBs vga0: rev 0x54 int a irq 11 on pci0.15.0 xl0: <3Com 3c905 Fast Etherlink XL 10/100BaseTX> rev 0x00 int a irq 3 on pci0.16.0 xl0: Ethernet address: 00:60:08:e8:46:98 xl0: autoneg complete, link status good (half-duplex, 10Mbps) Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <16 virtual consoles, flags=0x0> ed0 at 0x300-0x31f irq 10 on isa ed0: address 00:20:18:72:93:4e, type NE2000 (16 bit) atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa npx0 on motherboard npx0: INT 16 interface Intel Pentium detected, installing workaround for F00F bug IP packet filtering initialized, divert enabled, rule-based forwarding disabled, logging disabled Waiting 10 seconds for SCSI devices to settle pass1 at ahc0 bus 0 target 3 lun 0 pass1: Removable CD-ROM SCSI-2 device pass1: 3.300MB/s transfers da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 5.0MB/s transfers (5.0MHz, offset 15), Tagged Queueing Enabled da0: 4096MB (8388608 512 byte sectors: 255H 63S/T 522C) WARNING: / was not properly dismounted ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates (da0:ahc0:0:0:0): tagged openings now 31 -- Jeroen C. van Gelderen -- gelderen@mediaport.org -- &[8-D}~<= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jan 17 23:40:47 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA04143 for freebsd-scsi-outgoing; Sun, 17 Jan 1999 23:40:47 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from unter.encoding.com ([216.32.0.8]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA04137 for ; Sun, 17 Jan 1999 23:40:46 -0800 (PST) (envelope-from led@unter.encoding.com) Received: (from led@localhost) by unter.encoding.com (8.8.8/8.9.1) id HAA00692 for scsi@freebsd.org; Mon, 18 Jan 1999 07:40:42 GMT (envelope-from led) Date: Mon, 18 Jan 1999 07:40:42 GMT From: led Message-Id: <199901180740.HAA00692@unter.encoding.com> To: scsi@FreeBSD.ORG Subject: Adaptec 7860 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm considering building some servers based on the Dell 6300 box which apparently has 3 7860's built in (two ultra-2/LVD and one ultra/narrow). The FreeBSD handbook doesn't mention these devices. Is support planned? Thanks! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 18 02:12:55 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA21055 for freebsd-scsi-outgoing; Mon, 18 Jan 1999 02:12:55 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from opi.flirtbox.ch ([62.48.0.50]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id CAA21041 for ; Mon, 18 Jan 1999 02:12:45 -0800 (PST) (envelope-from oppermann@pipeline.ch) Received: (qmail 1346 invoked from network); 18 Jan 1999 10:12:34 -0000 Received: from unknown (HELO pipeline.ch) (62.48.0.53) by opi.flirtbox.ch with SMTP; 18 Jan 1999 10:12:34 -0000 Message-ID: <36A3093A.5B2DCC71@pipeline.ch> Date: Mon, 18 Jan 1999 11:13:14 +0100 From: Andre Oppermann Organization: Internet Business Solutions Ltd. X-Mailer: Mozilla 4.07 [en] (Win98; U) MIME-Version: 1.0 To: freebsd-scsi@FreeBSD.ORG Subject: DPT SmartRAID V Century Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Just one question: Is the DPT SmartRAID V Century also supported by the FreeBSD DPT driver? If no, which DPT controllers are supportet? TIA -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 18 03:21:13 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA27642 for freebsd-scsi-outgoing; Mon, 18 Jan 1999 03:21:13 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id DAA27621 for ; Mon, 18 Jan 1999 03:20:37 -0800 (PST) (envelope-from dwmalone@maths.tcd.ie) Received: from synge.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 18 Jan 99 11:20:26 +0000 (GMT) To: led cc: scsi@FreeBSD.ORG Subject: Re: Adaptec 7860 In-reply-to: Your message of "Mon, 18 Jan 1999 07:40:42 GMT." <199901180740.HAA00692@unter.encoding.com> Date: Mon, 18 Jan 1999 11:20:25 +0000 From: David Malone Message-ID: <9901181120.aa13818@salmon.maths.tcd.ie> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I'm considering building some servers based on the Dell 6300 box > which apparently has 3 7860's built in (two ultra-2/LVD and one > ultra/narrow). The FreeBSD handbook doesn't mention these devices. > Is support planned? We're using -CURRENT with the machine and it works fine. You'll need something more recent than 3.0-RELEASE though 'cos the NX chipset support wasn't added until more recently that that. It actually seems to have 1*7860 and 2*7890 (the first controller is a 2940 card we put in it). We've just a tape drive on the 7860, but it seems to work. David. ahc0: rev 0x01 int a irq 11 on pci0.10.0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc1: rev 0x00 int a irq 21 on pci1.4.0 ahc1: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc2: rev 0x00 int a irq 22 on pci1.6.0 ahc2: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc3: rev 0x03 int a irq 20 on pci1.8.0 ahc3: aic7860 Single Channel A, SCSI Id=7, 3/255 SCBs To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 18 05:38:57 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA10867 for freebsd-scsi-outgoing; Mon, 18 Jan 1999 05:38:57 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from birdland.rhein-neckar.de (birdland.rhein-neckar.de [193.197.88.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA10857; Mon, 18 Jan 1999 05:38:46 -0800 (PST) (envelope-from bsd@birdland.rhein-neckar.de) Received: from localhost (bsd@localhost) by birdland.rhein-neckar.de (8.8.7/8.8.3) with SMTP id OAA28278; Mon, 18 Jan 1999 14:38:35 +0100 (MET) Date: Mon, 18 Jan 1999 14:38:34 +0100 (MET) From: Martin Jangowski To: Stefan Esser cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Symbios 875 activity LED? In-Reply-To: <19990117123142.B492@dialup124.mi.uni-koeln.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 17 Jan 1999, Stefan Esser wrote: > It is simple to positively detect the Tekram SCSI cards, and I > know those don't follow the SDMS convention (and because of > Tekram's policy to support free operating systems, we even know > exactly how to make best use of their cards!). Does it make sense to use Tekrams's FBSD-driver or is it better to use the generic ncr0 driver supplied with FBSD? The generic driver works flawlessly, one of my machines with 3.0-RELEASE and a Tekram DC-390F runs nonstop since 3.0 came out... Martin | Martin Jangowski E-Mail: maja@birdland.rhein-neckar.de | | Voice: +49 621/53 95 06 Fax: +49 621/53 95 07 | | Snail Mail: Koenigsbacher Str. 16 D-67067 Ludwigshafen Germany | | RNInet e.V. Rhein-Neckar Internet | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 18 07:02:33 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA20937 for freebsd-scsi-outgoing; Mon, 18 Jan 1999 07:02:33 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from serenity.mcc.ac.uk (serenity.mcc.ac.uk [130.88.200.93]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA20931 for ; Mon, 18 Jan 1999 07:02:16 -0800 (PST) (envelope-from ip@albatross.mcc.ac.uk) Received: from albatross.mcc.ac.uk ([130.88.202.16]) by serenity.mcc.ac.uk with esmtp (Exim 1.92 #2) id 102GBR-0007XL-00; Mon, 18 Jan 1999 15:01:41 +0000 Received: (from ip@localhost) by albatross.mcc.ac.uk (8.9.1/8.9.1) id PAA13704; Mon, 18 Jan 1999 15:01:40 GMT (envelope-from ip) From: Ian Pallfreeman Message-Id: <199901181501.PAA13704@albatross.mcc.ac.uk> Subject: Re: CAM doesn't like my DAT any more In-Reply-To: from Matthew Jacob at "Jan 15, 99 07:11:50 pm" To: mjacob@feral.com Date: Mon, 18 Jan 1999 15:01:40 +0000 (GMT) Cc: scsi@FreeBSD.ORG Reply-To: ip@mcc.ac.uk X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Matt, > Hmm. That was probably me that broke it for you-although I don't see how > as the changes I made didn't affect the probe time stuff. > > If you could revert to the previous version of scsi_sa.c and let me > know if that works better for you, I'd appreciate it. Argh. After a cvsup this morning, I tried scsi_sa.c 1.16, 1.15 and 1.14 and they _all_ worked fine. Somebody fixed something else over the weekend? Anyways, thanks for your reply. Cheers, Ian. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 18 08:40:04 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA02699 for freebsd-scsi-outgoing; Mon, 18 Jan 1999 08:40:04 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from quark.ChrisBowman.com (crbowman.erols.com [209.122.47.155]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA02588; Mon, 18 Jan 1999 08:39:53 -0800 (PST) (envelope-from crb@ChrisBowman.com) Received: from fermion (fermion.ChrisBowman.com [10.0.1.2]) by quark.ChrisBowman.com (8.8.8/8.8.8) with SMTP id LAA00477; Mon, 18 Jan 1999 11:38:13 -0500 (EST) (envelope-from crb@ChrisBowman.com) Message-Id: <199901181638.LAA00477@quark.ChrisBowman.com> X-Sender: crb@quark X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Mon, 18 Jan 1999 11:35:17 -0500 To: Martin Jangowski From: "Christopher R. Bowman" Subject: Re: Symbios 875 activity LED? Cc: Stefan Esser , freebsd-scsi@FreeBSD.ORG In-Reply-To: References: <19990117123142.B492@dialup124.mi.uni-koeln.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 02:38 PM 1/18/99 +0100, Martin Jangowski wrote: >On Sun, 17 Jan 1999, Stefan Esser wrote: > >> It is simple to positively detect the Tekram SCSI cards, and I >> know those don't follow the SDMS convention (and because of >> Tekram's policy to support free operating systems, we even know >> exactly how to make best use of their cards!). > >Does it make sense to use Tekrams's FBSD-driver or is it better to use the >generic ncr0 driver supplied with FBSD? The generic driver works >flawlessly, one of my machines with 3.0-RELEASE and a Tekram DC-390F runs >nonstop since 3.0 came out... I think the Tekram driver is based on a different chip than the ncr0 driver runs on. For the Tekram DC390F use the ncr driver. -------- Christopher R. Bowman crb@ChrisBowman.com http://www.ChrisBowman.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 18 09:15:09 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA06543 for freebsd-scsi-outgoing; Mon, 18 Jan 1999 09:15:09 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from unter.encoding.com ([216.32.0.8]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA06533 for ; Mon, 18 Jan 1999 09:15:08 -0800 (PST) (envelope-from led@unter.encoding.com) Received: (from led@localhost) by unter.encoding.com (8.8.8/8.9.1) id RAA04152; Mon, 18 Jan 1999 17:14:14 GMT (envelope-from led) Date: Mon, 18 Jan 1999 17:14:14 GMT From: led Message-Id: <199901181714.RAA04152@unter.encoding.com> To: dwmalone@maths.tcd.ie, led@unter.encoding.com Subject: Re: Adaptec 7860 Cc: scsi@FreeBSD.ORG In-Reply-To: <9901181120.aa13818@salmon.maths.tcd.ie> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Excellent. I've been using 3.0-980627 with good results; Is -CURRENT reasonably stable? Thanks again re: > From dwmalone@maths.tcd.ie Mon Jan 18 11:21:15 1999 > To: led > cc: scsi@freebsd.org > Subject: Re: Adaptec 7860 > Date: Mon, 18 Jan 1999 11:20:25 +0000 > From: David Malone > > > I'm considering building some servers based on the Dell 6300 box > > which apparently has 3 7860's built in (two ultra-2/LVD and one > > ultra/narrow). The FreeBSD handbook doesn't mention these devices. > > Is support planned? > > We're using -CURRENT with the machine and it works fine. You'll need > something more recent than 3.0-RELEASE though 'cos the NX chipset > support wasn't added until more recently that that. > > It actually seems to have 1*7860 and 2*7890 (the first controller is a > 2940 card we put in it). We've just a tape drive on the 7860, but it > seems to work. > > David. > > ahc0: rev 0x01 int a irq 11 on pci0.10.0 > ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs > ahc1: rev 0x00 int a irq 21 on pci1.4.0 > ahc1: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs > ahc2: rev 0x00 int a irq 22 on pci1.6.0 > ahc2: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs > ahc3: rev 0x03 int a irq 20 on pci1.8.0 > ahc3: aic7860 Single Channel A, SCSI Id=7, 3/255 SCBs > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 18 10:44:38 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA17645 for freebsd-scsi-outgoing; Mon, 18 Jan 1999 10:44:38 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from feral-gw.feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA17640 for ; Mon, 18 Jan 1999 10:44:36 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral-gw.feral.com (8.8.7/8.8.7) with ESMTP id KAA15898; Mon, 18 Jan 1999 10:44:04 -0800 Date: Mon, 18 Jan 1999 10:44:03 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: ip@mcc.ac.uk cc: scsi@FreeBSD.ORG Subject: Re: CAM doesn't like my DAT any more In-Reply-To: <199901181501.PAA13704@albatross.mcc.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Hi Matt, > > > Hmm. That was probably me that broke it for you-although I don't see how > > as the changes I made didn't affect the probe time stuff. > > > > If you could revert to the previous version of scsi_sa.c and let me > > know if that works better for you, I'd appreciate it. > > Argh. After a cvsup this morning, I tried scsi_sa.c 1.16, 1.15 and 1.14 and > they _all_ worked fine. Somebody fixed something else over the weekend? Maybe. I've been busy taking fixes from others who've caught me being stupid. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 18 11:05:22 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA20838 for freebsd-scsi-outgoing; Mon, 18 Jan 1999 11:05:22 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from news2.du.gtn.com (news2.du.gtn.com [194.77.9.57]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA20831 for ; Mon, 18 Jan 1999 11:05:18 -0800 (PST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely.de [194.231.9.142]) by news2.du.gtn.com (8.8.6/8.8.6) with ESMTP id UAA13299; Mon, 18 Jan 1999 20:04:58 +0100 (MET) Received: (from ticso@localhost) by cicely7.cicely.de (8.9.0/8.9.0) id UAA86450; Mon, 18 Jan 1999 20:04:58 +0100 (CET) Message-ID: <19990118200458.29368@cicely.de> Date: Mon, 18 Jan 1999 20:04:58 +0100 From: Bernd Walter To: "Jeroen C. van Gelderen" , freebsd-scsi@FreeBSD.ORG Subject: Re: Disk dying (Conner CFP and Tagged Queueing Probs) References: <000301be4279$667e93c0$0d79eb0a@deskfix.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <000301be4279$667e93c0$0d79eb0a@deskfix.local>; from Jeroen C. van Gelderen on Mon, Jan 18, 1999 at 01:27:58AM +0100 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Jan 18, 1999 at 01:27:58AM +0100, Jeroen C. van Gelderen wrote: > Hello, > > Today I saw these messages scrolling over my screen. The last line worries > me a bit. Is this likely an indicator of a failing disk? Or is there > something else wrong? > > Cheers, > Jeroen > > Jan 18 00:03:20 wit395301 /kernel: (da0:ahc0:0:0:0): tagged openings now 31 > Jan 18 00:05:19 wit395301 /kernel: (da0:ahc0:0:0:0): SCB 0xe - timed out > while idle, LASTPHASE == 0x1, SEQADDR == 0x9 > Jan 18 00:05:20 wit395301 /kernel: (da0:ahc0:0:0:0): Queuing a BDR SCB > Jan 18 00:05:20 wit395301 /kernel: (da0:ahc0:0:0:0): Bus Device Reset > Message Sent > Jan 18 00:05:20 wit395301 /kernel: (da0:ahc0:0:0:0): no longer in timeout, > status = 353 > Jan 18 00:05:20 wit395301 /kernel: Unexpected busfree. LASTPHASE == 0xa0 > Jan 18 00:05:20 wit395301 /kernel: SEQADDR == 0x14f > Jan 18 00:06:17 wit395301 /kernel: (da0:ahc0:0:0:0): SCB 0x12 - timed out > while idle, LASTPHASE == 0x1, SEQADDR == 0x9 > Jan 18 00:06:17 wit395301 /kernel: (da0:ahc0:0:0:0): Queuing a BDR SCB > Jan 18 00:06:17 wit395301 /kernel: (da0:ahc0:0:0:0): Bus Device Reset > Message Sent > Jan 18 00:06:17 wit395301 /kernel: (da0:ahc0:0:0:0): no longer in timeout, > status = 353 [...] > Jan 18 00:14:17 wit395301 /kernel: Unexpected busfree. LASTPHASE == 0xa0 > Jan 18 00:14:17 wit395301 /kernel: SEQADDR == 0x14f > Jan 18 00:15:17 wit395301 /kernel: (da0:ahc0:0:0:0): SCB 0xc - timed out in > message in phase, SEQADDR == 0x101 > Jan 18 00:15:17 wit395301 /kernel: (da0:ahc0:0:0:0): BDR message in message > buffer > Jan 18 00:15:18 wit395301 /kernel: (da0:ahc0:0:0:0): no longer in timeout, > status = 34b > Jan 18 00:15:18 wit395301 /kernel: ahc0: Bus Device Reset on A:0. 31 SCBs > aborted > Jan 18 00:15:18 wit395301 /kernel: /: got error 0 while accessing filesystem > ------------- [...] > pass1 at ahc0 bus 0 target 3 lun 0 > pass1: Removable CD-ROM SCSI-2 device > pass1: 3.300MB/s transfers > da0 at ahc0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 5.0MB/s transfers (5.0MHz, offset 15), Tagged Queueing Enabled > da0: 4096MB (8388608 512 byte sectors: 255H 63S/T 522C) > WARNING: / was not properly dismounted > ffs_mountfs: superblock updated for soft updates > ffs_mountfs: superblock updated for soft updates > (da0:ahc0:0:0:0): tagged openings now 31 > Looks exactly the same like on my I had mentioned in this list earlier. You should be very carefully with this problem it damaged me sometimes the fs on it. With a quirk entry disabling tagged command queueing the drive is running without any problems for several days. Sound like there are more than just my drive broken. Can someone please check and commit an entry? I use the following in sys/cam/cam_xpt.c: { /* Broken tagged queuing drive */ { T_DIRECT, SIP_MEDIA_FIXED, "CONNER", "CFP*", "*" }, /*quirks*/0, /*mintags*/0, /*maxtags*/0 }, Interestingly the following is already there: { /* Broken tagged queuing drive */ { T_DIRECT, SIP_MEDIA_REMOVABLE, "CONNER", "CFP2107*", "*" }, /*quirks*/0, /*mintags*/0, /*maxtags*/0 }, Is his realy a removeable drive? If yes it sounds as there might be some conflicts using both. > -- > Jeroen C. van Gelderen -- gelderen@mediaport.org -- &[8-D}~<= > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message -- B.Walter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 18 11:43:41 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA27017 for freebsd-scsi-outgoing; Mon, 18 Jan 1999 11:43:41 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from schuimpje.snt.utwente.nl (schuimpje.snt.utwente.nl [130.89.238.4]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA27009 for ; Mon, 18 Jan 1999 11:43:37 -0800 (PST) (envelope-from gelderen@mediaport.org) Received: from wit395301.student.utwente.nl ([130.89.235.121]:58118 "HELO deskfix" ident: "NO-IDENT-SERVICE[2]") by schuimpje.snt.utwente.nl with SMTP id <8071-10507>; Mon, 18 Jan 1999 20:43:14 +0100 Message-ID: <00d601be431a$af6b2d40$0d79eb0a@deskfix.local> From: "Jeroen C. van Gelderen" To: "Bernd Walter" , Cc: "Kenneth D. Merry" Subject: Re: Disk dying (Conner CFP and Tagged Queueing Probs) Date: Mon, 18 Jan 1999 20:42:29 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00D3_01BE4323.10E4D0A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_00D3_01BE4323.10E4D0A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit From: Bernd Walter >> Today I saw these messages scrolling over my screen. The last line worries >> me a bit. Is this likely an indicator of a failing disk? Or is there >> something else wrong? > >Looks exactly the same like on my I had >mentioned in this list earlier. >You should be very carefully with this problem it damaged me >sometimes the fs on it. Yeah. Root and usr were hosed :( >With a quirk entry disabling tagged command queueing the drive >is running without any problems for several days. > >Sound like there are more than just my drive broken. >Can someone please check and commit an entry? > >I use the following in sys/cam/cam_xpt.c: > { > /* Broken tagged queuing drive */ > { T_DIRECT, SIP_MEDIA_FIXED, "CONNER", "CFP*", "*" }, > /*quirks*/0, /*mintags*/0, /*maxtags*/0 > }, > >Interestingly the following is already there: > { > /* Broken tagged queuing drive */ > { T_DIRECT, SIP_MEDIA_REMOVABLE, "CONNER", "CFP2107*", "*" }, > /*quirks*/0, /*mintags*/0, /*maxtags*/0 > }, Well, I've run -CURRENT with this drive for almost a year now, without any problems except for one: I had to use the following quirk entry to shut up a nasty error on shutdown: ==== //depot/cam/sys/cam/scsi/scsi_da.c#89 - /usr/home/ken/perforce/cam/sys/cam/scsi/scsi_da.c ==== *** /tmp/tmp.29245.0 Thu Nov 5 17:28:11 1998 --- /usr/home/ken/perforce/cam/sys/cam/scsi/scsi_da.c Thu Nov 5 17:27:35 1998 *************** *** 146,151 **** --- 146,155 ---- */ {T_DIRECT, SIP_MEDIA_FIXED, "NEC", "D3847*", "*"}, /*quirks*/ DA_Q_NO_SYNC_CACHE + }, + { + {T_DIRECT, SIP_MEDIA_FIXED, "CONNER", "CFP4207*", "*"}, + /*quirks*/ DA_Q_NO_SYNC_CACHE } }; I think I might have added a custom maxtags with a value of around 30 to this patch (to shut up the annoying 'tagged openings now xxx' messages) but I don't have that kernel source anymore... Another strange thing can be found in the attached message. Kenneth: you did never follow up on this one but it might be important anyway. Cheers, Jeroen ------=_NextPart_000_00D3_01BE4323.10E4D0A0 Content-Type: message/rfc822; name="Re .... Illegal request asc20,0 .....eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Re .... Illegal request asc20,0 .....eml" Received: from mediaport.org ([194.229.42.32])by cal007109.student.utwente.nl with esmtp (Exim 2.05 #1)id 0zbva0-0005dr-00for gelderen@djo.nl; Sat, 7 Nov 1998 00:46:12 +0100 Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125])by mediaport.org (8.8.5/8.8.5/3i-1.0) with ESMTP id AAA12971for ; Sat, 7 Nov 1998 00:44:52 +0100 Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id QAA03656 for gelderen@mediaport.org; Fri, 6 Nov 1998 16:46:06 -0700 (MST) From: "Kenneth D. Merry" Message-ID: <199811062346.QAA03656@panzer.plutotech.com> Subject: Re: .... Illegal request asc:20,0 .... In-Reply-To: <003a01be0987$eebab140$1400000a@deskfix.local> from "Jeroen C. van Gelderen" at "Nov 6, 98 02:18:23 pm" To: "Jeroen C. van Gelderen" Date: Fri, 6 Nov 1998 16:46:05 -0700 (MST) X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Jeroen C. van Gelderen wrote... > From: Kenneth D. Merry > >*sigh* That is truly perplexing. The attached patch for scsi_da.c should > >disable the messages. > > It fixes them alright. Thanks! Drop me a line if you need more > testing/patching. > > ! if (sense_key != SSD_KEY_ILLEGAL_REQUEST) { > ! printf("dashutdown: printing error " > ! "message\n"); > scsi_sense_print(&ccb.csio); > > sense_key == 0 in my case... Are you sure?? That doesn't make any sense... Did you print out the value or something? The reason it doesn't make sense is becuase in the subsequent error message, the sense key is decoded as "ILLEGAL REQUEST", which is 5, not 0. > >> Another request: my computer keeps complaining about the tagged openings > >> being adjusted. I know it's a harmless diagnostic, but to have those > >> messages garble my screen several times a day is very annoying. Those > >> messages are AFAIK not something important, so at the very least they > should > >> not end up on my screen by default... > > > >They are important, in a sense. They've helped us find numerous bugs, both > >in drive firmware, and in the CAM code itself. They also tell you how many > >transactions your drive can handle at a time. > > Ok, but I know how many transactions my drive can handle after the first > time. I reboot few times a day, so these messages get really annoying. Isn't > it possible to show them in -v mode only? Yeah, go to about line 2939 in cam_xpt.c (that's in -current, the line number in 3.0 release will be different). You'll see an if statement like this: if (bootverbose || 1) { xpt_print_path(crs->ccb_h.path); printf("tagged openings " "now %d\n", crs->openings); } Just remove the '|| 1' part and recompile. You'll only see the messages when you boot with -v. > >They stop appearing once your drive stops reporting the queue full > >condition. > > I know, but see above... The messages show up on my console (not running X). Ahh. Ken -- Kenneth Merry ken@plutotech.com ------=_NextPart_000_00D3_01BE4323.10E4D0A0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 18 12:02:40 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA00783 for freebsd-scsi-outgoing; Mon, 18 Jan 1999 12:02:40 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA00761 for ; Mon, 18 Jan 1999 12:02:36 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id NAA02592; Mon, 18 Jan 1999 13:01:54 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199901182001.NAA02592@panzer.plutotech.com> Subject: Re: Disk dying (Conner CFP and Tagged Queueing Probs) In-Reply-To: <19990118200458.29368@cicely.de> from Bernd Walter at "Jan 18, 99 08:04:58 pm" To: ticso@cicely.de (Bernd Walter) Date: Mon, 18 Jan 1999 13:01:54 -0700 (MST) Cc: gelderen@mediaport.org, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Bernd Walter wrote... > Looks exactly the same like on my I had mentioned in this list > earlier. > You should be very carefully with this problem it damaged me sometimes the fs on it. > > With a quirk entry disabling tagged command queueing the drive is running without > any problems for several days. > > Sound like there are more than just my drive broken. > Can someone please check and commit an entry? > > I use the following in sys/cam/cam_xpt.c: > { > /* Broken tagged queuing drive */ > { T_DIRECT, SIP_MEDIA_FIXED, "CONNER", "CFP*", "*" }, > /*quirks*/0, /*mintags*/0, /*maxtags*/0 > }, That sounds reasonable, I think. I'll probably just go ahead and commit it. > Interestingly the following is already there: > { > /* Broken tagged queuing drive */ > { T_DIRECT, SIP_MEDIA_REMOVABLE, "CONNER", "CFP2107*", "*" }, > /*quirks*/0, /*mintags*/0, /*maxtags*/0 > }, > > Is his realy a removeable drive? No, it's not a removable disk drive. I fixed that problem in revision 1.34 of cam_xpt.c. > If yes it sounds as there might be some conflicts using both. Well, the first quirk entry that matches a given device will be used. So, things should work okay. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 18 12:27:01 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA04900 for freebsd-scsi-outgoing; Mon, 18 Jan 1999 12:27:01 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from solex.unistar.si (spika.unistar.si [193.77.132.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA04408; Mon, 18 Jan 1999 12:24:08 -0800 (PST) (envelope-from anonimno@gov.si) From: anonimno@gov.si Received: from korina (cyber2.k4.sou.uni-lj.si [193.2.98.244]) by solex.unistar.si (8.9.0/8.9.0) with SMTP id UAA13085; Mon, 18 Jan 1999 20:47:46 +0100 (MET) Message-Id: <199901181947.UAA13085@solex.unistar.si> Date: Mon, 18 Jan 1999 20:46:01 +0100 (GMT+01:00) To: anonimno@sigov.si Subject: Krivice zapisane v slovenski ustavi Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id MAA04617 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Najprej bi se vam rad opravičil, ker sem za način obveščanja javnosti uporabil nenaročeno pošto (angl. spam), ki ste jo nekateri prejeli tudi večkrat. Na izbiro pa nisem imel druge možnosti, saj me slovenski javni mediji niso podprli. Javnim medijem sem poslal svoje prvo pismo, ki je v celoti objavljeno tudi v tem (v drugem delu pisma). Slovensko javnost bi želel upozoriti na krivice, ki so zapisane v naši ustavi in zakonih. Opozoril bi na krivico, ki doleti vse moške - služenje vojaškega roka. Prosim, da moje pisanje vzamete skrajno resno, saj lahko skupaj to državo naredimo res demokratično. In kaj če se vas to ne tiče? Če ste že odslužili vojaški rok? Če niste moškega spola? Potem pomislite na svoje otroke. Če pa jih že imate in če so dovolj stari, pa jih vprašajte, če si oni želijo služiti vojaški rok. Pogovarjal sem se tudi z že precej moškimi, ki so že odslužili vojaščino, pa so rekli, da jim ni bilo nič hudega. Pa ne vem, koliko so bili njihovi odgovori iskreni, saj so na vprašanje, če bi šli služiti vojaščino še enkrat, kot iz topa vsi odgovorili: "Ne.". To pismo je bilo poslano na približno 50000 naslovov elektronske pošte slovenskih državljanov. Prosim vas, da ga posredujete naprej, da bo za to izvedelo čim več ljudi. Če pa je v vaši moči, da ga objavite v javnem mediju, ali na kakšen drug način pomagate pri spreminjanju ustave, se vam tudi za to že v naprej najlepše zahvaljujem. Če bi radi stopili v stik z mano, mi lahko pišete na elektronski naslov vojaskiobveznik@yahoo.com. Srečno novo leto 1999 in upam, da bomo do novega tisočletja živeli že v pravičnejši državi. Pozdravlja vas Vojaški Obveznik V nadaljevanju pisma je objavljena tudi ustavna pritožba, ki je bila poslana na dva elektronska naslova ustavnega sodišča (arne.mavcic@usd.sigov.mail.si, robert.mozina@usd.sigov.mail.si). Ustavna pritožba mora biti vložena pisno, nikjer pa ne piše, da je ne morem vložiti s pomočjo elektronske pošte. Javno jo objavljam zato, ker bo brez vaše podpore enostavno preslišana. --------------------------------------------------------------------- USTAVNA PRITOŽBA Vlagam ustavno pritožbo, saj menim, da je v ustavo in zakone zapisana krivica, ki se izvršuje nad vsemi moškimi državljani. V ustavi je zapisano: 14. člen: (enakost pred zakonom) V Sloveniji so vsakomur zagotovljene enake človekove pravice in temeljne svoboščine, ne glede na narodnost, raso spol, jezik, vero, politično ali drugo prepričanje, gmotno stanje, rojstvo, izobrazbo, družbeni položaj ali katerokoli drugo osebno okoliščino. 32. člen: (svoboda gibanja) Vsakdo ima pravico, da se prosto giblje in si izbira prebivališče, da zapusti državo in se vanjo kadarkoli vrne. Ta pravica se sme omejiti z zakonom, vendar samo, če je to potrebno, da bi se zagotovil potek kazenskega postopka, da bi se preprečilo širjenje nalezljivih bolezni, se zavaroval javni red, ali če to zahtevajo interesi obrambe države. Tujcem se na podlagi zakona lahko omeji vstop v državo in čas bivanja v njej. 53. člen: (zakonska zveza in družina) Zakonska zveza temelji na enakopravnosti zakoncev. Sklene se pred pristojnim državnim organom. Zakonsko zvezo in pravna razmerja v njej, v družini in v zunajzakonski skupnosti ureja zakon. Država varuje družino, materinstvo, očetovstvo, otroke in mladino ter ustvarja za to varstvo potrebne razmere. V zakonu o vojaški dolžnosti je zapisano: 1. člen: Vojaško dolžnost izvršujejo v miru in v vojni moški državljani pod pogoji, ki jih določa ta zakon. Pri izvrševanju vojaške dolžnosti v skladu s tem zakonom lahko sodelujejo tudi ženske. 31. člen: Služenje vojaškega roka se na nabornikovo prošnjo odloži: - 1. odstavek, 7. točka: naborniku, ki po predpisih, ki urejajo varstvo družin oseb na obvezni vojaški službi, izpolnjuje pogoje za pridobitev statusa edinega hranilca družine, če bi z njegovim odhodom na služenje vojaškega roka njegova dužina zašla v težak materialni položaj, dokler te okoliščine trajajo, najdlje pa do konca septembra koledarskega leta, v katerem dopolnijo 27 let; 38. člen: Nabornik, ki nasprotuje uporabi orožja v vseh okoliščinah, lahko uveljavlja ugovor vesti vojaški dolžnosti in vojaški rok služi brez orožja ali opravi nadomestno civilno službo. Nabornik lahko ugovor vesti vojaški službi uveljavlja zaradi religioznih, filozofskih ali humanitarnih razlogov. Razloge, zaradi katerih nabornik uveljavlja ugovor vesti, mora potrjevati splošni način življenja in ravnanja nabornika. Ugovor vesti vojaški dolžnosti pod pogoji iz prvega in prejšnjega odstavka lahko uveljavlja tudi vojaški obveznik med služenjem ali po služenju vojaškega roka v skladu s tem zakonom. Državljan, ki mu je priznan ugovor vesti vojaški dolžnosti po odsluženem vojaškem roku, je dolžan opraviti 30 dnevno usposabljanje za opravljanje nalog zaščite in reševanja. Program usposabljanja za opravljanje nalog zaščite in reševanja iz prejšnjega odstavka predpiše minister, pristojen za varstvo pred naravnimi in drugimi nesrečami. Kot pravi 14. člen ustave, so v Sloveniji vsakomur zagotovljene enake človekove pravice in temeljne svoboščine. S 1. členom zakona o vojaški dolžnosti pa država dela razlike med moškim in ženskim spolom, saj vojaško dolžnost izvajajo v miru in vojni moški državljani, skladno z zakonom pa lahko sodelujejo tudi ženske. 38. člen zakona o vojaški dolžnosti omogoča tudi civilno služenje vojaškega roka, kar pa ni nič drugega, kot prisilno delo, saj mora delo posameznik opravljati proti svoji volji in brez ustreznega finančnega nadomestila. Država s tem priznava, da je prostovoljnih vojakov premalo, če ne kar nič. 53. člen ustave pravi, da država varuje družino, v 31. členu zakona o vojaški dolžnosti pa piše, da se služenje vojaškega roka lahko odloži, če je vojaški obveznik edini hranilec družine, zaradi tega pa bi njegova družina zašla v težak materialni položaj, vendar najkasneje do konca septembra. In kako varuje država družino po septembru? Vsakemu človeku, ki proti svoji volji služi vojaški rok (kar po naši zakonodaji ni mogoče za ženske), so storjene naslednje krivice: - omejevanje svobode; - vsiljevanje proti volji posameznika; - izguba prihodka. Torej problema ni mogoče rešiti na način, da bi uvedli obvezno služenje vojaščine tudi za ženske, saj bi s tem število ljudi, katerim je bila storjena krivica, le povečali. Zato predlagam sledeče spremembe v ustavi in zakonodaji naše države: - vsak posameznik se lahko prostovoljno odloči za služenje vojaškega roka; - država organizira profesionalno vojsko. Predlagam pa še naslednjo rešitev, kako financirati profesionalno vojsko. Država lahko uvede poseben davek na NEsluženje vojaškega roka, katerega bi plačevali vsi državljani (ne glede na spol), ki (še) niso služili vojaškega roka. Ta rešitev je pravična, saj je državljan, ki se je odločil za služenje vojaškega roka, utrpel izgubo prihodka - se pravi je svoj čas (čas pa je denar), poklonil državi in tako ta davek plačal v enem kosu. Na ta način bi vsi državljani prispevali k obarmabi države - na tak ali drugačen način, imeli pa bi svobodno voljo izbire. Seveda pa tisti, ki prostovoljno odslužijo vojaški rok, ostanejo v rezervni sestavi vojske in so zaradi tega doživljensko oproščeni plačevanja tega davka. Na ta način bi sredstva za potrebe profesionalne vojske porazdelili na ramena vseh državljanov (in to na obroke in ne v enem kosu), razen na tiste, ki se odločijo za služenje vojaškega roka (oziroma so ga že odslužili) - za te pa novi zakon ne bi predstavljal nobene razlike glede na sedanjega. Na ta način torej ne bi posamezniku ničesar vsiljevali, njegova svoboda ne bi bila omejena (kdor bi se odločil za služenje vojaščine, bi se prostovoljno), financirali pa bi vojsko vsi državljani enakomerno. Država bi imela profesionalno vojsko, ki bi bila toliko večja, kolikor manj državljanov bi se odločilo za prostovoljno služenje - sredstva pa bi bila zagotovljena, saj bi se s tem avtomatsko povečalo tudi število plačevalcev davka na nesluženje vojaškega roka. 1.1.1999 v Sloveniji, Vojaški Obveznik --------------------------------------------------------------------- Prilagam še svoje prvo pismo, s katerim sem želel javnost obvestiti s pomočjo javnih medijev, ki pa mojega pisanja niso vzeli ravno resno. To pismo pišem z namenom, da opozorim na krivice v naši državi, saj je že skrajni čas, da se glede tega kaj ukrene. Pokazal bi rad na diskriminacijo spolov, in na nasprotja zapisana v naši ustavi. Ustava pravi: 1. člen: Slovenija je demokratična republika. 14. člen: (enakost pred zakonom) V Sloveniji so vsakomur zagotovljene enake človekove pravice in temeljne svoboščine, ne glede na narodnost, raso spol, jezik, vero, politično ali drugo prepričanje, gmotno stanje, rojstvo, izobrazbo, družbeni položaj ali katerokoli drugo osebno okoliščino. 32. člen: (svoboda gibanja) Vsakdo ima pravico, da se prosto giblje in si izbira prebivališče, da zapusti državo in se vanjo kadarkoli vrne. Ta pravica se sme omejiti z zakonom, vendar samo, če je to potrebno, da bi se zagotovil potek kazenskega postopka, da bi se preprečilo širjenje nalezljivih bolezni, se zavaroval javni red, ali če to zahtevajo interesi obrambe države. Tujcem se na podlagi zakona lahko omeji vstop v državo in čas bivanja v njej. 53. člen: (zakonska zveza in družina) Zakonska zveza temelji na enakopravnosti zakoncev. Sklene se pred pristojnim državnim organom. Zakonsko zvezo in pravna razmerja v njej, v družini in v zunajzakonski skupnosti ureja zakon. Država varuje družino, materinstvo, očetovstvo, otroke in mladino ter ustvarja za to varstvo potrebne razmere. Na vse člene se bom skliceval v nadaljevanju tega pisma, v nasprotju pa sta si že 14. in 32. člen, saj naj bi bili v državi vsi ljudje enakopravni, nekaterim ljudem pa se omeji pravica gibanja, če je to v interesu obrambe države. In komu se omejijo te pravice - najpogostejši primer so vojaki, ki služijo vojaški rok. Kot pravi zakon, vojaščino morajo služiti moški, ženske pa jo lahko. Torej si spola v naši državi nista enakopravna. Moškim je tako odvzeta svoboda gibanja (in še katera druga), pri čemer je edini zločin, ki so ga storili le ta, da so se rodili kot moški. Služenje vojaščine je: - omejevanje svobode; - vsiljevanje proti volji posameznika (kar sklepam po tem, da je služenje vojaščine omogočeno ženskam, pa jih ravno ne srečujemo mnogo po vojašnicah); - izguba prihodka posameznika - gmotna škoda (53. člen ustave zavezuje državo k varstvu družine, ki kaj hitro lahko postane socialno ogožena pri izgubi morda edinega prihodka v družini). Pri sprejemanju ustave ni bila upoštevana volja manjšine - vojaških obveznikov, ki po večini nočejo služiti vojaškega roka. Če drži 1. člen ustave in z njim demokracija, bi morali upoštevati tudi voljo te manjšine. Država skrbi za etnične manjšine, za starostne pa ne. Ker bi s tem, da za ženske uvedemo služenje vojaščine (konec koncev je tudi civilno služenje le slab izgovor države za prisilno delo njenih moških prebivalcev, saj tudi ženske zmorejo opravljati veliko večino teh del), pridobili enakopravnost državljanov, pa zločin nad posameznikom ne bi bil nič manjši. Rešitvi za to situacijo sta torej le dve (ali kombinacija obeh): - vsak posameznik se lahko prostovoljno odloči za služenje vojaškega roka; - profesionalna vojska. Naj poudarim, da v času pred Napoleonom ni bilo obvezne vojaščine, torej vedno ni bilo tako in nikjer ne piše, da mora vedno ostati tako. Prav tako je tudi sklicevanje na druge države, kjer imajo podobna določila v ustavi, le slab izgovor, saj obstajajo tudi države s smrtno kaznijo, pa se ne zgledujemo po njih. Raje se zgledujmo po državah, ki že imajo profesionalno vojsko. Seveda imamo v Sloveniji tudi varuha človekovih pravic in zakon o varuhu človekovih pravic, ki pa je napisan s figo v žepu, kar je logično, saj mora delovati v interesu države, ne pa človeka, kateremu je namenjen. Gotovo pa je največji krivec za zakon, ki diskriminira moške, škodoželjnost ljudi. Zakone in ustavo so pisali po večini moški, ki so vsi že odslužili vojaški rok. In "če sem jaz moral skozi to, potem naj gredo še drugi". Ker se v naši državi vse prepočasi dogajajo spremembe, sem se odločil za boj proti krivicam v ustavi s pomočjo: - obveščanja prek javnih medijev; - ustavne pritožbe; - študentskega parlamenta; - študentskih demonstracij; - množičnega bojkota služenja vojaščine. Moram priznati, da sem tudi sam vojaški obveznik, saj se ljudje le redko lotimo reševanja problemov, ki se nas ne tičejo. Morda je razlog za to prekratko bivanje posameznika na tem svetu. Pismo sem poslal na naslednje naslove, saj je v rokah vseh vas moč spreminjanja države: - Dijaška organizacija Slovenije (dijaki@sou.uni-lj.si) - Študentska organizacija Slovenije, Študentska vlada, Študentski parlament (upravitelju webmaster@sou.uni-lj.si, ki ga prosim, da to pismo posreduje predsednikom teh organizacij) - Ustavno sodišče (robert.mozina@usd.sigov.mail.si) - Ministrstvo za obrambo (soj@pub.mo-rs.si) - Vladi RS, Parlamentu RS, g. Milanu Kučanu, g. Janezu Drnovšku, Ministrstvu za pravosodje (upraviteljema pavla.lah@gov.si, miran.zeljko@gov.si, katera prosim, da jim to pismo posredujeta) - Varuhu človekovih pravic (upravitelju zoran.perse@varuh-rs.si, ki ga prosim, da to pismo posreduje g. Ivu Bizjaku) ČASOPISI: - Večer (slovenija@czp-vecer.si) - Tednik Družina (info@druzina.si) - Slovenske Novice (novice@delo.si) - Delo (upravitelju webmaster@delo.si, ki ga prosim, da to pismo posreduje glavnemu uredniku) - Dnevnik (info@dnevnik.si) - Mladina (desk@mladina.si) RADIJSKE POSTAJE: - Marš (radio.mars@guest.arnes.si) - Radio Ognjišče (public@ognjisce.si) - Radio Študent (upravitelju webmaster@radiostudent.si, ki ga prosim, da to pismo posreduje glavnemu uredniku) - Gama MM (info-gama@gamamm.si) TELEVIZIJSKE POSTAJE: - RTV Slovenija (webmaster@rtvslo.si) - POP TV (info@pop-tv.si) - Gajba TV (gajbatv@pop-tv.si) POLITIČNIE STRANKE: - Liberalna stranka (ls@ls-sl.si) - Republikanci Slovenije (res@siol.net) - Slovenski krščanski demokrati (skd@eunet.si) - Socialdemokratska stranka Slovenije (sds@eunet.si) - Liberalna demokracija Slovenije (lds@lds.si) - Nova stranka (blaz.babic@amis.net) - Demokrati Slovenije (tone.persak@siol.net) - Združena lista socialnih demokratov (info@zlsd.si) Vojaški Obveznik To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 18 17:16:23 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA15184 for freebsd-scsi-outgoing; Mon, 18 Jan 1999 17:16:23 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA15141 for ; Mon, 18 Jan 1999 17:16:18 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id LAA00703; Tue, 19 Jan 1999 11:46:11 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.2/8.9.0) id LAA04316; Tue, 19 Jan 1999 11:46:09 +1030 (CST) Date: Tue, 19 Jan 1999 11:46:09 +1030 From: Greg Lehey To: Andre Oppermann Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: DPT SmartRAID V Century Message-ID: <19990119114609.B474@freebie.lemis.com> References: <36A3093A.5B2DCC71@pipeline.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <36A3093A.5B2DCC71@pipeline.ch>; from Andre Oppermann on Mon, Jan 18, 1999 at 11:13:14AM +0100 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Monday, 18 January 1999 at 11:13:14 +0100, Andre Oppermann wrote: > Hi > > Just one question: Is the DPT SmartRAID V Century also supported by > the FreeBSD DPT driver? No. > If no, which DPT controllers are supportet? SmartRAID III and SmartRAID IV. Shimon's working on a driver for the V, but it'll be a while yet. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 18 19:43:20 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA04111 for freebsd-scsi-outgoing; Mon, 18 Jan 1999 19:43:20 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA04106 for ; Mon, 18 Jan 1999 19:43:17 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.1/8.9.1) id EAA33595; Tue, 19 Jan 1999 04:43:09 +0100 (CET) (envelope-from des) To: scsi@FreeBSD.ORG Subject: Fireball woes (continued) From: Dag-Erling Smorgrav Date: 19 Jan 1999 04:43:08 +0100 Message-ID: Lines: 74 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Some of you may remember that I had a nearly brand-new Fireball act up on me last fall... well, it's acting up again: Jan 19 04:12:59 niobe /kernel: (da1:ahc0:0:4:0): READ(06). CDB: 8 2 57 0 10 0 Jan 19 04:12:59 niobe /kernel: (da1:ahc0:0:4:0): MEDIUM ERROR info:2570d asc:11,0 Jan 19 04:12:59 niobe /kernel: (da1:ahc0:0:4:0): Unrecovered read error Jan 19 04:12:59 niobe /kernel: /: got error 5 while accessing filesystem Jan 19 04:12:59 niobe /kernel: Lost type inodedep Jan 19 04:12:59 niobe last message repeated 12 times Jan 19 04:12:59 niobe /kernel: /: got error 5 while accessing filesystem Jan 19 04:12:59 niobe /kernel: Lost type inodedep Jan 19 04:12:59 niobe last message repeated 4 times Jan 19 04:12:59 niobe /kernel: /: got error 5 while accessing filesystem Jan 19 04:12:59 niobe /kernel: Lost type inodedep At that point, the system froze for about a minute, maybe less, then rebooted (it *may* have dropped into DDB; I tried typing "panic" and "continue" blind since I was in X at the time, and it rebooted at about the time I finished typing "continue" and hit enter) A short time after reboot, I get: Jan 19 04:31:19 niobe /kernel: (da1:ahc0:0:4:0): READ(06). CDB: 8 3 68 60 48 0 Jan 19 04:31:19 niobe /kernel: (da1:ahc0:0:4:0): MEDIUM ERROR info:36866 asc:11,1 Jan 19 04:31:19 niobe /kernel: (da1:ahc0:0:4:0): Read retries exhausted Jan 19 04:31:19 niobe /kernel: /usr/release: got error 5 while accessing filesystem Jan 19 04:31:19 niobe /kernel: Lost type pagedep Jan 19 04:31:19 niobe /kernel: /usr/release: got error 5 while accessing filesystem Jan 19 04:31:19 niobe /kernel: Lost type pagedep Jan 19 04:31:19 niobe /kernel: /usr/release: got error 5 while accessing filesystem Jan 19 04:31:19 niobe /kernel: Lost type pagedep Jan 19 04:31:19 niobe /kernel: /usr/release: got error 5 while accessing filesystem Jan 19 04:31:19 niobe /kernel: Lost type indirdep Jan 19 04:31:19 niobe /kernel: /usr/release: got error 5 while accessing filesystem Jan 19 04:31:19 niobe /kernel: Lost type pagedep Jan 19 04:31:19 niobe /kernel: spec_getpages: I/O read failure: (error code=5) Jan 19 04:31:19 niobe /kernel: size: 36864, resid: 36864, a_count: 36864, valid: 0x0 Jan 19 04:31:19 niobe /kernel: nread: 0, reqpage: 0, pindex: 80, pcount: 9 Jan 19 04:31:19 niobe /kernel: vm_fault: pager read error, pid 5406 (install) and make release which is running with CHROOTDIR=/usr/release dies with the following: ===> gnu/usr.bin/cc/cc1 install -c -s -o root -g wheel -m 555 cc1 /usr/release/usr/libexec install: /usr/release/usr/libexec/cc1: Bad address *** Error code 71 Stop. (which coincides with the message from vm_fault). "camcontrol defects -n da -u 1 -f block -G" gives me 15 defects, and the following log message as a bonus: Jan 19 04:39:33 niobe /kernel: (pass1:ahc0:0:4:0): READ DEFECT DATA(10). CDB: 37 0 8 0 0 0 0 fd e8 0 Jan 19 04:39:33 niobe /kernel: (pass1:ahc0:0:4:0): RECOVERED ERROR asc:1c,0 Jan 19 04:39:33 niobe /kernel: (pass1:ahc0:0:4:0): Defect list not found The permanent defect list has >600 entries. The disk is a six-months-old Quantum Fireball: an 19 04:18:58 niobe /kernel: da1 at ahc0 bus 0 target 4 lun 0 Jan 19 04:18:58 niobe /kernel: da1: Fixed Direct Access SCSI-2 device Jan 19 04:18:58 niobe /kernel: da1: 20.0MB/s transfers (20.0MHz, offset 15), Tagged Queueing Enabled Jan 19 04:18:58 niobe /kernel: da1: 6180MB (12657717 512 byte sectors: 255H 63S/T 787C) Can anybody tell me what error 5 means, and how serious the disk's condition is? DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 18 20:31:23 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA09590 for freebsd-scsi-outgoing; Mon, 18 Jan 1999 20:31:23 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA09584 for ; Mon, 18 Jan 1999 20:31:21 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id VAA05784; Mon, 18 Jan 1999 21:31:01 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199901190431.VAA05784@panzer.plutotech.com> Subject: Re: Fireball woes (continued) In-Reply-To: from Dag-Erling Smorgrav at "Jan 19, 99 04:43:08 am" To: des@flood.ping.uio.no (Dag-Erling Smorgrav) Date: Mon, 18 Jan 1999 21:31:01 -0700 (MST) Cc: scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dag-Erling Smorgrav wrote... > Some of you may remember that I had a nearly brand-new Fireball act up > on me last fall... well, it's acting up again: > > Jan 19 04:12:59 niobe /kernel: (da1:ahc0:0:4:0): READ(06). CDB: 8 2 57 0 10 0 > Jan 19 04:12:59 niobe /kernel: (da1:ahc0:0:4:0): MEDIUM ERROR info:2570d asc:11,0 > Jan 19 04:12:59 niobe /kernel: (da1:ahc0:0:4:0): Unrecovered read error > Jan 19 04:12:59 niobe /kernel: /: got error 5 while accessing filesystem > Jan 19 04:12:59 niobe /kernel: Lost type inodedep > Jan 19 04:12:59 niobe last message repeated 12 times > Jan 19 04:12:59 niobe /kernel: /: got error 5 while accessing filesystem > Jan 19 04:12:59 niobe /kernel: Lost type inodedep > Jan 19 04:12:59 niobe last message repeated 4 times > Jan 19 04:12:59 niobe /kernel: /: got error 5 while accessing filesystem > Jan 19 04:12:59 niobe /kernel: Lost type inodedep Hmm, medium error. That's not good at all. My guess is that the info field is probably the block that it had trouble with. Yeah, looks like it was probably part-way into the read request when it blew up. > At that point, the system froze for about a minute, maybe less, then > rebooted (it *may* have dropped into DDB; I tried typing "panic" and > "continue" blind since I was in X at the time, and it rebooted at > about the time I finished typing "continue" and hit enter) > > A short time after reboot, I get: > > Jan 19 04:31:19 niobe /kernel: (da1:ahc0:0:4:0): READ(06). CDB: 8 3 68 60 48 0 > Jan 19 04:31:19 niobe /kernel: (da1:ahc0:0:4:0): MEDIUM ERROR info:36866 asc:11,1 > Jan 19 04:31:19 niobe /kernel: (da1:ahc0:0:4:0): Read retries exhausted Yep, another medium error, different block. > ===> gnu/usr.bin/cc/cc1 > install -c -s -o root -g wheel -m 555 cc1 /usr/release/usr/libexec > install: /usr/release/usr/libexec/cc1: Bad address > *** Error code 71 > > Stop. > > (which coincides with the message from vm_fault). Yeah, if the disk your swap partition is on goes south, you'll have trouble. > "camcontrol defects -n da -u 1 -f block -G" gives me 15 defects, and > the following log message as a bonus: > > Jan 19 04:39:33 niobe /kernel: (pass1:ahc0:0:4:0): READ DEFECT DATA(10). CDB: 37 0 8 0 0 0 0 fd e8 0 > Jan 19 04:39:33 niobe /kernel: (pass1:ahc0:0:4:0): RECOVERED ERROR asc:1c,0 > Jan 19 04:39:33 niobe /kernel: (pass1:ahc0:0:4:0): Defect list not found That's normal for some drives. If they don't support the defect list format that you ask for, they'll spew a non-standard error back. Sometimes they'll return the defect list in a different format, sometimes they won't return it at all. camcontrol will handle the case where they return the defect list in a different format. Most every drive that I've seen will give you the defect list in 'phys' format. > The permanent defect list has >600 entries. Don't worry about the permanent defect list. > The disk is a six-months-old Quantum Fireball: > > an 19 04:18:58 niobe /kernel: da1 at ahc0 bus 0 target 4 lun 0 > Jan 19 04:18:58 niobe /kernel: da1: Fixed Direct Access SCSI-2 device > Jan 19 04:18:58 niobe /kernel: da1: 20.0MB/s transfers (20.0MHz, offset 15), Tagged Queueing Enabled > Jan 19 04:18:58 niobe /kernel: da1: 6180MB (12657717 512 byte sectors: 255H 63S/T 787C) > > Can anybody tell me what error 5 means, and how serious the disk's > condition is? Error 5 is EIO (from sys/errno.h): #define EIO 5 /* Input/output error */ Do you have read/write reallocation turned on for that disk? If not, edit mode page 1 and turn them on. Then, back up whatever you can get off the disk. Then try writing to the entire disk, to try to force it to remap any bad blocks it has on the disk. Then read from every block on the disk and see if you get any errors. (dd is probably the best for both) If you still have trouble, you can try formatting the disk. The following command will probably do the trick: camcontrol cmd -v -t 7200 -n da -u 1 -c "4 0 0 0 0 0" You might need a longer timeout. I've heard rumors, though, that Quantum doesn't do anything for the format unit command. (specifically, that they just wait 5 minutes and return the command) I haven't tried to format a Quantum disk in a long, long time, though, so I can't say whether that's true or not. I do know, however, that the 0F0C firmware for the Fireball ST is buggy, and you're likely to see it hang up in certain situations under high load. You'll probably be happier if you can get the 0F0J firmware (the 0FS1 firmware may also work okay). Of course, you shouldn't bother if the disk is going south. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 18 20:41:51 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA11468 for freebsd-scsi-outgoing; Mon, 18 Jan 1999 20:41:51 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA11460 for ; Mon, 18 Jan 1999 20:41:49 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.1/8.9.1) id FAA33837; Tue, 19 Jan 1999 05:41:36 +0100 (CET) (envelope-from des) To: "Kenneth D. Merry" Cc: scsi@FreeBSD.ORG Subject: Re: Fireball woes (continued) References: <199901190431.VAA05784@panzer.plutotech.com> From: Dag-Erling Smorgrav Date: 19 Jan 1999 05:41:35 +0100 In-Reply-To: "Kenneth D. Merry"'s message of "Mon, 18 Jan 1999 21:31:01 -0700 (MST)" Message-ID: Lines: 49 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Kenneth D. Merry" writes: > Dag-Erling Smorgrav wrote... > Yeah, if the disk your swap partition is on goes south, you'll have trouble. No, I don't have swap there. I suspect the binaries 'make release' installed on /usr/release got corrupted. > Do you have read/write reallocation turned on for that disk? If not, edit > mode page 1 and turn them on. Then, back up whatever you can get off the > disk. Did that last time. root@niobe ~# camcontrol modepage -n da -u 1 -m 1 AWRE (Auto Write Reallocation Enbld): 1 ARRE (Auto Read Reallocation Enbld): 1 There's nothing important there anyway: root@niobe ~# df | grep da1 /dev/da1e 254063 211793 21945 91% /usr/obj /dev/da1g 5116967 3612584 1095026 77% /mp3 /dev/da1f 762223 28696 672550 4% /usr/release > Then try writing to the entire disk, to try to force it to remap any bad > blocks it has on the disk. Then read from every block on the disk and see > if you get any errors. (dd is probably the best for both) Wilco. > If you still have trouble, you can try formatting the disk. The following > command will probably do the trick: > > camcontrol cmd -v -t 7200 -n da -u 1 -c "4 0 0 0 0 0" OK. > I do know, however, that the 0F0C firmware for the Fireball ST is buggy, > and you're likely to see it hang up in certain situations under high load. > You'll probably be happier if you can get the 0F0J firmware (the 0FS1 > firmware may also work okay). Of course, you shouldn't bother if the disk > is going south. I'm considering turning the disk in for a refund and buying an IBM UltraStar instead. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 18 22:42:13 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA24951 for freebsd-scsi-outgoing; Mon, 18 Jan 1999 22:42:13 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from dfw-ix3.ix.netcom.com (dfw-ix3.ix.netcom.com [206.214.98.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA24946 for ; Mon, 18 Jan 1999 22:42:12 -0800 (PST) (envelope-from phate1@ix.netcom.com) Received: (from smap@localhost) by dfw-ix3.ix.netcom.com (8.8.4/8.8.4) id AAA10662 for ; Tue, 19 Jan 1999 00:42:04 -0600 (CST) Received: from nyc-ny71-34.ix.netcom.com(209.109.226.226) by dfw-ix3.ix.netcom.com via smap (V1.3) id rma010623; Tue Jan 19 00:41:51 1999 Message-ID: <36A429FC.D8B22391@ix.netcom.com> Date: Tue, 19 Jan 1999 01:45:16 -0500 From: Mike Organization: Integration Soft. X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: scsi@FreeBSD.ORG Subject: does freebsd support ultra2 lvd (aic 7896) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Does freebsd's cam support ultra2 lvd with an onboard controller adaptec aic7896? The newest tyan motherboard comes with that controller, so i'm wondering whether to pick it or not. Thanks, Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 18 23:06:57 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA27282 for freebsd-scsi-outgoing; Mon, 18 Jan 1999 23:06:57 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA27277 for ; Mon, 18 Jan 1999 23:06:54 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id AAA06964; Tue, 19 Jan 1999 00:04:55 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199901190704.AAA06964@panzer.plutotech.com> Subject: Re: does freebsd support ultra2 lvd (aic 7896) In-Reply-To: <36A429FC.D8B22391@ix.netcom.com> from Mike at "Jan 19, 99 01:45:16 am" To: phate1@ix.netcom.com (Mike) Date: Tue, 19 Jan 1999 00:04:55 -0700 (MST) Cc: scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mike wrote... > Hi > > Does freebsd's cam support ultra2 lvd with an onboard controller adaptec > aic7896? Yes, it is supported. It is basically a dual-channel version of the 7890/7891. > The newest tyan motherboard comes with that controller, so i'm wondering > whether to pick it or not. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jan 19 10:04:22 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA17493 for freebsd-scsi-outgoing; Tue, 19 Jan 1999 10:04:22 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA17487 for ; Tue, 19 Jan 1999 10:04:16 -0800 (PST) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.1/frmug-2.3/nospam) with UUCP id TAA09646 for freebsd-scsi@FreeBSD.ORG; Tue, 19 Jan 1999 19:04:06 +0100 (CET) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id 7961F1574; Tue, 19 Jan 1999 08:22:37 +0100 (CET) Date: Tue, 19 Jan 1999 08:22:37 +0100 From: Ollivier Robert To: freebsd-scsi@FreeBSD.ORG Subject: Re: Disk dying (Conner CFP and Tagged Queueing Probs) Message-ID: <19990119082237.A9340@keltia.freenix.fr> Mail-Followup-To: freebsd-scsi@FreeBSD.ORG References: <19990118200458.29368@cicely.de> <199901182001.NAA02592@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199901182001.NAA02592@panzer.plutotech.com>; from Kenneth D. Merry on Mon, Jan 18, 1999 at 01:01:54PM -0700 X-Operating-System: FreeBSD 3.0-CURRENT/ELF ctm#4994 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ setting tags to 0 for Conner CFP* drives ] According to Kenneth D. Merry: > That sounds reasonable, I think. I'll probably just go ahead and commit > it. I don't think tags are broken in every CFP drive. Mine seems to run perfectly with 31 of them. It is connected to a NCR-810 (ASUS SC-200). Please back it out. da12 at ncr1 bus 0 target 2 lun 0 da12: Fixed Direct Access SCSI-2 device da12: 10.0MB/s transfers (10.0MHz, offset 8), Tagged Queueing Enabled da12: 1030MB (2110812 512 byte sectors: 255H 63S/T 131C) [...] (da12:ncr1:0:2:0): tagged openings now 31 -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #69: Mon Jan 18 02:02:12 CET 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jan 19 15:07:19 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA21630 for freebsd-scsi-outgoing; Tue, 19 Jan 1999 15:07:19 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from hawkwind.ncsa.uiuc.edu (hawkwind.ncsa.uiuc.edu [141.142.21.154]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA21625 for ; Tue, 19 Jan 1999 15:07:17 -0800 (PST) (envelope-from koziol@hawkwind.ncsa.uiuc.edu) Received: (from koziol@localhost) by hawkwind.ncsa.uiuc.edu (8.9.1/8.9.1) id RAA00468 for freebsd-scsi@freebsd.org; Tue, 19 Jan 1999 17:07:10 -0600 (CST) (envelope-from koziol) Message-Id: <199901192307.RAA00468@hawkwind.ncsa.uiuc.edu> Subject: DPT problems To: freebsd-scsi@FreeBSD.ORG Date: Tue, 19 Jan 1999 17:07:10 -0600 (CST) From: koziol@ncsa.uiuc.edu Reply-To: koziol@ncsa.uiuc.edu X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Howdy, I'm running 3.0-release (and impatiently waiting for the 3.0-stable release tomorrow.. :-) on an SMP box with an Adaptec 3940AUW on the Tyan S1836DLUAN motherboard. I've installed a DPT PM2654U2-R with 16MB of cache RAM in the system also, but I can't get the kernel to recognize my hard drive when it is trying to mount root, near the end of the booting process. It gets as far as saying "changing root device to da0s1a" and then whines about not finding the drive to mount as root. This is weird to me, since it's gotten this far by reading the kernel from the drive.. :-? I've attached my kernel config file below, can anyone point out any obvious problems? Perhaps this is already fixed in the current->stable tree and I can just download the stable source tomorrow when it's released? (knock on wood :-) I'm currently running fine (but slower than I want) from the on-board Adaptec controller. Thanks for any help, Quincey Koziol koziol@ncsa.uiuc.edu # # SMP-GENERIC -- Smp machine with WD/AHx/NCR/BTx family disks # # For more information read the handbook part System Administration -> # Configuring the FreeBSD Kernel -> The Configuration File. # The handbook is available in /usr/share/doc/handbook or online as # latest version from the FreeBSD World Wide Web server # # # An exhaustive list of options and more detailed explanations of the # device lines is present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $Id: SMP-GENERIC,v 1.17 1998/10/16 04:44:05 peter Exp $ machine "i386" # SMP does NOT support 386/486 CPUs. #cpu "I386_CPU" #cpu "I486_CPU" #cpu "I586_CPU" cpu "I686_CPU" ident SMP-Hawkwind maxusers 32 # Options for the VM subsystem #options PQ_NOOPT # No coloring options PQ_LARGECACHE # color for 512k/16k cache #options PQ_HUGECACHE # color for 1024k/16k cache # # Allow user-mode programs to manipulate their local descriptor tables. # This option is required for the WINE Windows(tm) emulator, and is # not used by anything else (that we know of). # options USER_LDT #allow user-level control of i386 ldt # # This option includes a MD5 routine in the kernel, this is used for # various authentication and privacy uses. # options "MD5" # # Allow processes to switch to vm86 mode, as well as enabling direct # user-mode access to the I/O port space. This option is necessary for # the doscmd emulator to run. # options "VM86" # # PERFMON causes the driver for Pentium/Pentium Pro performance counters # to be compiled. See perfmon(4) for more information. # options PERFMON # Create a SMP capable kernel (mandatory options): options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O # Optional, these are the defaults: #options NCPU=2 # number of CPUs options NBUS=5 # number of busses #options NAPIC=1 # number of IO APICs #options NINTR=24 # number of INTs # Lets always enable the kernel debugger for SMP. #options DDB # SMP shouldn't need x87 emulation, disable by default. #options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options MFS #Memory Filesystem options MFS_ROOT #MFS usable as root device, "MFS" req'ed options NFS #Network Filesystem options NFS_ROOT #NFS usable as root device, "NFS" req'ed #options MSDOSFS #MSDOS Filesystem options "CD9660" #ISO 9660 Filesystem options "CD9660_ROOT" #CD-ROM usable as root. "CD9660" req'ed options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=5000 #Be pessimistic about Joe SCSI device options UCONSOLE #Allow users to grab the console #options FAILSAFE #Be conservative options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor config kernel root on da0 controller isa0 controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 disk fd1 at fdc0 drive 1 # No IDE disks in hawkwind currently - QAK - 1/13/99 #options "CMD640" # work around CMD640 chip deficiency #controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr #disk wd0 at wdc0 drive 0 #disk wd1 at wdc0 drive 1 # A single entry for any of these controllers (ncr, ahb, ahc, amd) is # sufficient for any number of installed devices. controller ahc0 # The 'dpt' driver provides support for DPT controllers (http://www.dpt.com/). # These have hardware RAID-{0,1,5} support, and do multi-initiator I/O. # The DPT controllers are commonly re-licensed under other brand-names - # some controllers by Olivetti, Dec, HP, AT&T, SNI, AST, Alphatronic, NEC and # Compaq are actually DPT controllers. # # See sys/dev/dpt for debugging and other subtle options. # DPT_VERIFY_HINTR Performs some strict hardware interrupts testing. # Only use if you suspect PCI bus corruption problems # DPT_RESTRICTED_FREELIST Normally, the freelisat used by the DPT for queue # will grow to accomodate increased use. This growth # will NOT shrink. To restrict the number of queue # slots to exactly what the DPT can hold at one time, # enable this option. # DPT_MEASURE_PERFORMANCE Enables a set of (semi)invasive metrics. Various # instruments are enabled. The tools in # /usr/sbin/dpt_* assume these to be enabled. # DPT_FREELIST_IS_STACK For optimal L{1,2} CPU cache utilization, enable # this option. Otherwise, the transaction queue is # a LIFO. I cannot measure the performance gain. # DPT_HANDLE_TIMEOUTS Normally device timeouts are handled by the DPT. # If you ant the driver to handle timeouts, enable # this option. If your system is very busy, this # option will create more trouble than solve. # DPT_TIMEOUT_FACTOR Used to compute the excessive amount of time to # wait when timing out with the above option. # DPT_DEBUG_xxxx These are controllable from sys/dev/dpt/dpt.h # DPT_LOST_IRQ When enabled, will try, once per second, to catch # any interrupt that got lost. Seems to help in some # DPT-firmware/Motherboard combinations. Minimal # cost, great benefit. # DPT_RESET_HBA Make "reset" actually reset the controller # instead of fudging it. Only enable this if you # are 100% certain you need it. # DPT_SHUTDOWN_SLEEP Reset controller if a request take more than # this number of seconds. Do NOT enable this # unless you are really, really, really certain # you need it. You are advised to call Simon (the # driver author) before setting it, and NEVER, # EVER set it to less than 300s (5 minutes). controller dpt0 # DPT options #options DPT_VERIFY_HINTR options DPT_RESTRICTED_FREELIST #!CAM# options DPT_MEASURE_PERFORMANCE options DPT_FREELIST_IS_STACK #!CAM# options DPT_HANDLE_TIMEOUTS options DPT_TIMEOUT_FACTOR=4 options DPT_INTR_DELAY=200 # Some motherboards need that options DPT_LOST_IRQ #options DPT_RESET_HBA # Don't EVER set this without having talked to Simon Shapiro on the phone # first. #options DPT_SHUTDOWN_SLEEP=500 controller scbus2 at ahc0 bus 0 controller scbus3 at ahc0 bus 1 controller scbus0 at dpt0 bus 0 controller scbus1 at dpt0 bus 1 device da0 #SCSI direct access devices (aka disks) device pass0 #CAM passthrough driver device cd0 #SCSI CD-ROMs # syscons is the default console driver, resembling an SCO console device sc0 at isa? port "IO_KBD" conflicts tty irq 1 vector scintr device npx0 at isa? port "IO_NPX" irq 13 vector npxintr # # Other standard PC hardware: `lpt', `mse', `psm', `sio', etc. # # lpt: printer port # lpt specials: # port can be specified as ?, this will cause the driver to scan # the BIOS port list; # the irq and vector clauses may be omitted, this # will force the port into polling mode. # mse: Logitech and ATI InPort bus mouse ports # psm: PS/2 mouse port [note: conflicts with sc0/vt0, thus "conflicts" keywd] # sio: serial ports (see sio(4)) device sio0 at isa? port "IO_COM1" flags 0x10 tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr device lpt0 at isa? port? tty irq 7 vector lptintr device psm0 at isa? port "IO_KBD" conflicts tty irq 12 vector psmintr # Order is important here due to intrusive probes, do *not* alphabetize # this list of network interfaces until the probes have been fixed. # Right now it appears that the ie0 must be probed before ep0. See # revision 1.20 of this file. device fxp0 pseudo-device loop pseudo-device ether pseudo-device sl 1 pseudo-device ppp 1 pseudo-device tun 1 options PPP_BSDCOMP #PPP BSD-compress support options PPP_DEFLATE #PPP zlib/deflate/gzip support options PPP_FILTER #enable bpf filtering (needs bpfilter) ##################################################################### # MISCELLANEOUS DEVICES AND OPTIONS # The `pty' device usually turns out to be ``effectively mandatory'', # as it is required for `telnetd', `rlogind', `screen', `emacs', and # `xterm', among others. pseudo-device pty 16 pseudo-device gzip # Exec gzipped a.out's # KTRACE enables the system-call tracing facility ktrace(2). # This adds 4 KB bloat to your kernel, and slightly increases # the costs of each syscall. #options KTRACE #kernel tracing # This provides support for System V shared memory, semaphores & messages. # options SYSVSHM options SYSVSEM options SYSVMSG # The `bpfilter' pseudo-device enables the Berkeley Packet Filter. Be # aware of the legal and administrative consequences of enabling this # option. The number of devices determines the maximum number of # simultaneous BPF clients programs runnable. pseudo-device bpfilter 4 #Berkeley packet filter # Enable PnP support in the kernel. This allows you to automaticly # attach to PnP cards for drivers that support it and allows you to # configure cards from USERCONFIG. See pnp(4) for more info. controller pnp0 # Luigi's snd code (use INSTEAD of snd0 and all VOXWARE drivers!). # You may also wish to enable the pnp controller with this, for pnp # sound cards. # device pcm0 at isa? port ? tty irq 10 drq 1 flags 0x0 vector pcmintr # Not controlled by `snd' device pca0 at isa? port IO_TIMER1 tty To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jan 19 15:22:17 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA23589 for freebsd-scsi-outgoing; Tue, 19 Jan 1999 15:22:17 -0800 (PST) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA23571; Tue, 19 Jan 1999 15:22:11 -0800 (PST) (envelope-from se@dialup124.zpr.uni-koeln.de) Received: from dialup124.zpr.Uni-Koeln.DE (dialup124.zpr.Uni-Koeln.DE [134.95.219.124]) by Sisyphos.MI.Uni-Koeln.DE (8.8.7/8.8.7) with ESMTP id AAA06501; Wed, 20 Jan 1999 00:22:03 +0100 (MET) Received: (from se@localhost) by dialup124.zpr.Uni-Koeln.DE (8.9.1/8.6.9) id XAA00666; Tue, 19 Jan 1999 23:21:29 +0100 (CET) Date: Tue, 19 Jan 1999 23:21:28 +0100 From: Stefan Esser To: David Kelly Cc: freebsd-scsi@FreeBSD.ORG, Stefan Esser Subject: Re: Symbios 875 activity LED? Message-ID: <19990119232128.D363@dialup124.mi.uni-koeln.de> Reply-To: se@FreeBSD.ORG References: <199901180014.SAA11049@nospam.hiwaay.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199901180014.SAA11049@nospam.hiwaay.net>; from David Kelly on Sun, Jan 17, 1999 at 06:14:11PM -0600 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 1999-01-17 18:14 -0600, David Kelly wrote: > Stefan Esser writes: > > It is simple to positively detect the Tekram SCSI cards, and I > > know those don't follow the SDMS convention (and because of > > Tekram's policy to support free operating systems, we even know > > exactly how to make best use of their cards!). > > That's nice to know. Have heard Tekram cards have formatting and bad > block scanning support in their BIOS config much like Adaptec and > unlike my Asus SC875. Street prices for Tekram 390F's are lower than > I've seen for an SC875. Problem is I'm not in the market for another > SCSI card at the moment. :-( Excuses, excuses, that didn't stop me > from buying an extra Matrox Millenium II 4MB yesterday for $45. I'd love to be able to get them at that price! > While we can positively ID a Tekram card, just how else is one > superior to other Symbios based cards? There is not much of a difference, actually. All NCR cards currently come with active terminators, AFAIK, and there is not much else on the card (besides the actual SCSI chip). I don't think that firmware differences are that important, actually. The Tekram cards ar every high quality, as are the Symbios cards. (I have never used one from any other vendor.) > > But as long as I'm not able to *positively* detect SDMS compatible > > cards, it's just to dangerous to make any assumptions about what > > GPIO<0> does or doesn't ... ;-) > > I felt pretty confident that the #ifdef was there for a good reason. But > the only way I found it was via mention on these mail lists. Once Upon A > Time thought my SCSI card was broken because the LED didn't work. Yes. I understand that you had wanted to find some hint at the option, but in fact, I do not want to take the chance, that there is a card from some vendor I never heard of, that does some very nasty things if GPIO<0> is toggled ... I do not understand, why the LED is not connected to the SCSI bus BUSY signal. (Ok, it takes an external driver, while the GPIO output drivers are able to sink the LED current ....) > Is this option too petty or trivial to be added to LINT and config(8)? It is trivial to make this a supported option. > Config complains about it but kernels compile anyhow. The option is not in /sys/conf/options (nor in /sys/i386/options.i386). Just add it to the end of the other SCSI_NCR_* options in the "options" file, and config will stop to complain. As long as the option is not in that file, config will add a -D