Summary: ATMworks 350 adapter caused problem

From: Ray Stell <stellr_at_ngw.cns.vt.edu>
Date: Thu, 3 Jul 1997 10:26:28 -0400 (EDT)

Original Problem:
=================
Added a atm nic 350 to my alphastation 255, du v4.0 (rev 564).
Added kernel support for the atm stuff.
Got the atm nic configed and going, but noticed that boot process
was complaining about the tu0, but I figured that this was
something to do with the atm nic being added and went on.
After taking the atm nic out, doconfig still refuses to
add support in the kernel for tu0. I added it by hand,
still fails with the message from uerf:

shared_intr_add: attemp to share _non-sharable interupts, index
0x5


Solution:
=========
I pulled pci cards out and the conflict went
away. I added the cards back and stuff is fine.
It is like there is a dynamic interrupt table and
it got stuck. Someone here suggested using an alternate
console mode available from the firmware boot disk
to eval the interrupts. I did not do this, being
the slash and burn sort, but it certainly would have
been more elegant.


Interesting list responses:
===========================
Dr. Tom Blinn, 603-881-0646" <tpb_at_zk3.dec.com>
----------------------------------------------
There is a restriction in V4.0 (I think it's lifted in V4.0B or so) on
sharing PCI interrupts -- or maybe it's still a restriction, I don't recall.

In any case, it sounds like the console firmware is programming both the ATM
card and the Ethernet (tulip hence tu) card to the same PCI interrupt. This
won't work. It may be a restriction on that system, I don't know.

You *might* get lucky if you move cards around in slots; that might change
the way the firmware assigns interrupts to devices.

It *is* the console firmware that configures the PCI devices and sets up the
interrupts they will use; the operating system reads the information out of
PCI config space at boot time. If there's a conflict, the OS can't do much
about it except refuse to configure the option, which is what you're seeing.


Andreas Heckwolf <andreas_at_tm.informatik.uni-frankfurt.de>
---------------------------------------------------------
I had the same problem. The solution was to juggle a bit with pci
adapters. The final working configuration is :

tga0 at pci0 slot 11
pci1000 at pci0 slot 12 # this is the atm-adapter
jv0 at pci0 slot 13 # a frame-grabber
tu0 at pci0 slot 14 # can't change this
===============================================================
Ray Stell stellr_at_vt.edu (540) 231-4109 KE4TJC 28^D
Received on Thu Jul 03 1997 - 16:59:18 NZST

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:36 NZDT