|
Francis,
>>1. We suspect a conflict of system resources happens when ever there
>>are FDDI frames for the card (unicast and broadcast). We simulated this
>>by putting a protocol analyser directly to the card and generated the
>>various pattern of traffic. If no traffic is generated, the problem
>>disappear.
If you're seeing data corruption, and then you remove the traffic, I
would suspect that the corruption would go away as well since there
is no data to corrupt.
>>2. The AST pc automatically assigned an IRQ of 11 and it is indicated
>>as shared. We understand that the card require a non-shared interrupt.
That's not exactly right. The DEFPA.COM driver adheres to the
Novell DOS ODI Specification v4.0 which does *not* support shared
interrupts. Other drivers, such as the DEFPA.LAN driver support
shared interrupts. In other words, shared interrupt support is
based on the operating system and driver, not the hardware.
>>We put the card into a AST Pentium pc and IRQ=11(shared) and the
>>problem did not occur no matter what we did to it.
You may have just been lucky.
Are there two PCI devices actually sharing the interrupt in the
Pentium system? Just because it is configured as being shared
doesn't mean that two PCI devices are actually sharing the interrupt.
>>3. Even we only loaded the lsl.com and defpa.com (nw4.1), it is enough
>>to replicate the problem.
This is strange, but I guess it's possible. With no protocol bound,
you are probably not receiving much traffic other than broadcast
packets.
>>4. The AST pc cannot be configured to assigned a dedicated IRQ
>>(according to AST engineer). They provide an ICU utility to view the
>>system resouce utilisation.
Well, that's a problem. Most PCI BIOS vendors give you the
opportunity to alter the IRQ settings. Usually it is only necessary
to alter the IRQ settings when you're configuring hardware and
installing drivers that do not support shared interrupts.
If you can not change the IRQ, and you must have two PCI devices
sharing an interrupt, then you should not be using the DOSODI
DEFPA driver. You should try using another system or another
NOS/driver that supports shared interrupts.
>>1. How are interrupts, I/O addresses and other resources assigned to
>>PCI cards?
On Intel-based systems, it's done by the PCI BIOS during POST.
>>2. Could the FDDI file-copying problem be related to a conflict in PC
>>resources (IRQ, I/O addr)?
Yes. The DEFPA.COM driver requires unique (ie, not shared) IRQ
and I/O port address range assignments. A older (buggy) PCI BIOS
might make the same assignment to more than one device. This is
very bad. In the case of IRQ's, some PCI BIOSs assign the
same IRQ to multiple devices. Again, this is bad and you should
consider upgrading your BIOS or your system. Alternatively, you may
be able to run a NOS/driver combination that supports shared
interrupts.
>>3. What are the implications of running the DEFPA on a shared interrupt
>>with the DOS ODI driver?
The DOS ODI Specification 4.0 does *NOT* support IRQ sharing.
Novell has IRQ sharing support in the ODI Server Driver Assembly HSM
Specification. The implications of sharing interrupts between a
DOS ODI driver and another device are unknown. You'll be
lucky to simply get a system hang. You'll probably get unpredictable
behavior, device timeouts, memory corruption, etc.
>>4. Can the DEFPA operates on all interrupts assigned by BIOS/System?
All PCI devices, by definition, do not use IRQs. PCI devices have
four interrupt lines (INTA, INTB, INTC, and INTD) which *can* map to
IRQs on Intel-based systems, or map to Alpha interrupt lines on
Alpha-based systems, etc. Most single-function PCI devices (including
DEFPA) use INTA for interrupts.
So, to answer your question, the DEFPA can operate on any IRQ assigned
by the BIOS or system since it doesn't really care what IRQ is
assigned. As for the driver, it simply reads the IRQ that the BIOS
assigned and registers it with LSL.COM. Whether that configuration
works or not is dependent on your system.
>>5. Why does the DEFPA driver hangs when the card is allocated IRQ10?
It doesn't. If you're having driver hangs when configured for IRQ10,
then you have a resource conflict in the system. The DEFPA hardware
itself doesn't even know about IRQ's. As for the device driver, it
simply registers the IRQ with LSL.COM, it doesn't care whether it's 10,
11, 5, 7, 15, or anything. Which IRQs work in a specific system
configuration depends on the system hardware and installed options.
>>6. Why does the DEFPA hangs sometimes when the driver is being loaded?
It shouldn't. If you have a specific problem report to make with a
DEFPA driver, please escalate it.
>>7. What are the implications of running the DEFPA DOS ODI driver with
>>an older version of LSL.COM (dated 11 oct 94)?
The latest DEFPA.COM driver (v2.09) adheres to the DOS ODI
Specification 4.0. You should use LSL.COM v2.16 or later, IPXODI.COM
v3.02 or later, and VLM.EXE v1.20 Rev B. or later. You can get these
files from VLMUP4.EXE or later and should upgrade if you are not
presently using them.
>>8. Some PCs with the cards frequently encountered General Protection
>>Faults and EMM386 errors while running different Windows applications.
>>Could this be related to the card?
You can certainly run into trouble using a memory manager that assumes
various sections of upper memory are available, when they are not.
This is NOT a problem specific to the DEFPA or to any LAN adapter.
Note: You should be running v4.49 or later of EMM386.EXE on PCI
systems. Earlier versions have a problem with PCI devices.
>>9. Does DEFPA work with Netware Client 32: 16 and 32 bit driver modes?
Yes. Both DEFPA.LAN and DEFPA.COM are supported under Novell's
Client32 for Windows 95 product. As you are probably aware, the
DOS ODI driver is 16 bit, while the Server ODI driver is 32 bit.
>>10. Does the DEFPA card works with Windows 95? Microsoft TCP/IP?
>>Microsoft Client for NDS? Novell client for NDS?
Yes, you can use the Windows 95 driver for DEFPA (DEFPA.SYS) or any of
the DOS-based drivers (eg. DEFPA.DOS or DEFPA.COM). Whether the
Microsoft or Novell software support the various FDDI drivers (NDIS 3,
NDIS 2, and DOS ODI) depends on their software.
>>11. Does the DEFPA card works with Windows NT 4.0? Microsoft TCP/IP?
>>Microsoft Client for NDS? Novell client for NDS?
Yes, you can use the NDIS 3 driver for DEFPA which is available in the
latest DEFPA driver kit or use the driver that's bundled in Windows NT
4.0. The Novell client for Windows NT 4.0 is still BETA and should
support either the NDIS 3 driver or the DEFPA.LAN ODI server driver.
-Brenda
|