From owner-freebsd-current Mon Oct 30 05:01:23 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA21551 for current-outgoing; Mon, 30 Oct 1995 05:01:23 -0800 Received: from hda.com (hda.com [199.232.40.182]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA21546 for ; Mon, 30 Oct 1995 05:01:18 -0800 Received: (from dufault@localhost) by hda.com (8.6.11/8.6.9) id IAA17865; Mon, 30 Oct 1995 08:04:04 -0500 From: Peter Dufault Message-Id: <199510301304.IAA17865@hda.com> Subject: Should 1540A be de-supported? To: julian@ref.tfs.com (Julian Elischer) Date: Mon, 30 Oct 1995 08:04:04 -0500 (EST) Cc: uhclem%nemesis@fw.ast.com, current@freebsd.org In-Reply-To: <199510300339.TAA09588@ref.tfs.com> from "Julian Elischer" at Oct 29, 95 07:39:37 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1510 Sender: owner-current@freebsd.org Precedence: bulk > > Apart from lots of issues with SCSI hardware that SCO took in stride and > > FreeBSD hated ("unknown board" errors for an Adaptec 1540A, which is one > > of the non-thru-hole, 2nd generation surface-mount boards, > > I BELIEVE this is fixed, they bumped the board-id code and we didn't > recognise it (3 line fix). The 1540A should still not work as poorly as it has in recent (post clustering) kernels. I don't think the 1540A is usable without fixes, and should probably be de-supported until it works properly It doesn't support as many scatter gather pages (I'm a little fuzzy on this) as the other boards, and newer versions of the OS generate large transfers that fail. 2.1: probably it should be de-supported in 2.1, since if it is going to trash people they are better off just not having it work. Here is some of what we recognize directly: ... > case 0x31: return "AHA-1540"; /* '1' */ > case 0x41: return "AHA-154x[AB]"; /* 'A' */ > case 0x42: return "AHA-1640"; ... There is a hole between 0x31 and 0x41 where odd revs of the 1540A's could sneak in. (We now treat anything from 0x47 and 0x56 as probably some kind of a newly released 1542.) If Frank is willing it would be useful to recompile aha1542.c with AHADEBUG and then boot verbosely and see what is going on. -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267