From owner-freebsd-isdn  Sun Feb 20  5:22:43 2000
Delivered-To: freebsd-isdn@freebsd.org
Received: from mail.ppp.net (mail.ppp.net [194.64.12.35])
	by hub.freebsd.org (Postfix) with ESMTP
	id DB00737BD69; Sun, 20 Feb 2000 05:22:35 -0800 (PST)
	(envelope-from hm@kts.org)
Received: from mailstore.ppp.net (pop3.ppp.net [212.18.80.90])
	by mail.ppp.net (8.8.8/8.8.8) with ESMTP id OAA15855;
	Sun, 20 Feb 2000 14:22:22 +0100
Received: (from uucp@localhost)
	by mailstore.ppp.net (8.9.3/8.9.3/Debian/GNU) with UUCP id OAA13294;
	Sun, 20 Feb 2000 14:19:56 +0100
Received: from bert.kts.org (bert.kts.org [194.55.156.2])
	by ernie.kts.org (Postfix) with ESMTP
	id AAB6352AA3; Sun, 20 Feb 2000 14:15:00 +0100 (CET)
Received: by bert.kts.org (Postfix, from userid 100)
	id 479301F17; Sun, 20 Feb 2000 14:14:55 +0100 (CET)
Subject: Re: Big ATA problems
In-Reply-To: <200002201210.MAA78505@hak.lan.Awfulhak.org> from Brian Somers at "Feb 20, 2000 12:10: 5 pm"
To: brian@Awfulhak.org (Brian Somers)
Date: Sun, 20 Feb 2000 14:14:55 +0100 (CET)
Cc: dfr@nlsystems.com, hm@kts.org, current@FreeBSD.ORG,
	freebsd-isdn@FreeBSD.ORG, brian@hak.lan.Awfulhak.org
Organization: Kitchen Table Systems
Reply-To: hm@kts.org
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <20000220131455.479301F17@bert.kts.org>
From: hm@kts.org (Hellmuth Michaelis)
Sender: owner-freebsd-isdn@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Brian Somers wrote:

> > So you are saying that what we really have here is a simple i/o conflict
> > and possibly the ISDN card can be reconfigured to use a non-conflicting
> > address? If so, then everything is working correctly and the resource
> > manager has pointed a possible hardware problem :-).
> 
> So it would seem, *but*, before moving from wd to ata I had both 
> working 100% reliably.  I had to move the Teles card to get it to 
> work (allocate resources successfully) once I changed to ata.
> 
> I would be pretty sure that the Teles S0/16.3 doesn't actually go 
> near the I/O range @ 0x170.

It depends. Assuming that the 16.3 allocates 0x40 bytes from 0x160 on,
it has 32 bytes r/w fifo from 0x160. This fifo may be accessed directly
at each location or indirectly in autoincrement mode. The isic driver
(IIRC) accesses it in autoincrement mode, this results in using only
the first byte for read/write of the fifo. This may be the reason why
it succeeds until now.

Anyhow - the fifo in non-autoincrement mode is _still_ there (it might
also be, that Teles does not decode the last 30 bytes of this range,
but i have no idea since the chance to get docs is nearly equal to zero)
how this behaves cannot be predicted for shure, so IMHO there is a
resource clash and the isic driver behaves correctly unless i overlooked
something.

hellmuth
-- 
Hellmuth Michaelis                hm@kts.org                   Hamburg, Europe
 We all live in a yellow subroutine, yellow subroutine, yellow subroutine ...



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-isdn" in the body of the message