2.2.11 and tulip.c issues
Thu Aug 19 10:32:52 1999
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