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 [EMAIL PROTECTED] Hamburg, Europe
We all live in a yellow subroutine, yellow subroutine, yellow subroutine ...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
