From owner-freebsd-hackers Tue Mar 30 23:27:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gidgate.gid.co.uk (gidgate.gid.co.uk [193.123.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 88BC014DBF for ; Tue, 30 Mar 1999 23:27:55 -0800 (PST) (envelope-from rb@gid.co.uk) Received: (from rb@localhost) by gidgate.gid.co.uk (8.8.8/8.8.7) id IAA21575; Wed, 31 Mar 1999 08:25:58 +0100 (BST) (envelope-from rb) Message-Id: <3.0.6.32.19990331082524.007ad810@192.168.255.1> X-Sender: rbmail@192.168.255.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Wed, 31 Mar 1999 08:25:24 +0100 To: Matthew Dillon , Peter Jeremy From: Bob Bishop Subject: Re: another ufs panic.. Cc: hackers@FreeBSD.ORG In-Reply-To: <99Mar31.114807est.40597@border.alcanet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > Nobody in their right mind turns off parity checking on a SCSI bus. Correct; but plenty of people have gone temporarily insane trying to diagnose SCSI cabling problems. It's the easiest thing in the world in extremis to dick around with the controller settings and fail to restore them afterwards. Peter Jeremy >Sounds like it would be useful for the kernel to warn if a SCSI target >(including the controller) has parity disabled. Also correct; but I don't see any device-independent way to find out in the SCSI specs. Few people are going to go poking around in device code pages, it's the controller settings that are at risk. Maybe the best you can hope for is to read the controller settings on the host interface in some controller-dependent way. -- Bob Bishop +44 118 977 4017 rb@gid.co.uk fax +44 118 989 4254 (0800-1800 UK) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message