2.2.11 and tulip.c issues

[Aron Griffis]

Hello Robert,

Thanks for the response.  I have investigated further and here is what
I have found.

On Wed, Aug 18, 1999 at 04:35:10PM -0400, Robert G. Brown wrote:
> IIRC, the tulip very rarely has interrupt/ioport conflicts with mmap
> video cards.  You might try the following:
> 
>   a) Look carefully at /proc/pci to see if you can see anything obvious
> that appears to be a conflict;

I don't see a conflict here but somebody with more understanding of
this might see something.

PCI devices found:
  Bus  0, device   3, function  0:
    Ethernet controller: DEC DC21142 (rev 48).
      Medium devsel.  Fast back-to-back capable.  IRQ 24.  Master Capable.  Latency=255.  Min Gnt=20.Max Lat=40.
      I/O at 0x8000 [0x8001].
      Non-prefetchable 32 bit memory at 0x9000000 [0x9000000].
  Bus  0, device   4, function  0:
    IDE interface: CMD 646 (rev 1).
      Medium devsel.  Fast back-to-back capable.  Master Capable.  Latency=248.  Min Gnt=2.Max Lat=4.
      I/O at 0x8800 [0x8801].
  Bus  0, device   7, function  0:
    Non-VGA device: Intel 82378IB (rev 67).
      Medium devsel.  Master Capable.  No bursts.  
  Bus  0, device  12, function  0:
    VGA compatible controller: S3 Inc. Trio32/Trio64 (rev 0).
      Medium devsel.  IRQ 32.  
      Non-prefetchable 32 bit memory at 0x9800000 [0x9800000].
  Bus  0, device  20, function  0:
    PCI bridge: DEC DC21152 (rev 1).
      Medium devsel.  Fast back-to-back capable.  Master Capable.  Latency=255.  Min Gnt=4.
  Bus  1, device   9, function  0:
    SCSI storage controller: Q Logic ISP1020 (rev 5).
      Medium devsel.  IRQ 40.  Master Capable.  Latency=248.  
      I/O at 0x9000 [0x9001].
      Non-prefetchable 32 bit memory at 0xa000000 [0xa000000].

>   b) Move the NIC to a different PCI slot.  I know, this shouldn't
> matter (especially with 2.2.x and IO-APIC, although it was fairly common
> with 2.0.x kernels) but I've definitely had it resolve problems with
> tulip cards in the past.

The NIC is integrated on the motherboard.  I tried moving the video
card around but it changed nothing.

>   c) Finally (and most likely) there is an affliction that MANY tulip
> cards of years past have had in which they basically lie when they pass
> their PCI configuration back to the kernel.  The lie involved a
> dysfunctional ioport.  The characteristic of this bug is that it was
> repaired with exactly the same sequence of unloading and reloading the
> module you describe above.  In those cards, the ioport shifted between
> the first load and the second -- this was one characteristic of the bug.

In my case, the ioport hasn't changed when I've unloaded and reloaded
the module.  Additionally, although the bug is "repaired", if I
re-enter X, the interface breaks again.

> I wrote a patch to solve this problem for 0.89H that I include below.
> Note that according to Don this patch "should" not be necessary, but the
> sad fact is that for many systems it works to solve the problem (both
> for the tulip and de4x5 drivers) regardless of where the problem REALLY
> lies.  It isn't entirely without documentary support -- the algorithm
> employed I adopted from something given in Rubini's Linux Device Drivers
> (O'Reilly bronco) book.

I will give the patch a try.  Thanks.

-- 
Aron Griffis            Compaq Computer Corporation, ZKO3-3/T30
Tru64 Hardware Support  110 Spitbrook Rd, Nashua, NH  03062
603/884-1276            http://bigfoot.com/~agriffis/