Too many collision errors with Full Duplex auto negotiation

Alas, my troubles have brought me to this list.  

I have a special configuration of computers that run a fluorescent based
microscope.  First I have a Win98 box with an Intel Pro100 VE NIC that
controls the various sub-systems of hardware that run the microscope
system.  The user interface and data acquisition/collection box is a
stock Red Hat 7.2 system running 2.4.7-10smp kernel.  This kernel still
uses eepro100 v1.09j-t:rev1.36 for both of its Intel ethernet interfaces
(one is on the motherboard while the other is a PCI card.)

To facilitate unrestricted bandwidth between the acquisition box (linux)
and the hardware control box (win98), I use a custom cross-over cable
connecting the two boxes.  When both boxes are configured to auto
negotiate, the results are random.  Using mii-diag on the linux box
always gives the negotiated speed as 100baseTX-FD, however it has become
apparent that communication speeds are often much slower, shown most
easily by file transfer.  Here is the output from ifconfig after typical
data collection:

eth1      Link encap:Ethernet  HWaddr 00:30:48:41:58:A7  
          inet addr:159.159.159.1  Bcast:159.159.255.255
Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1459651 errors:0 dropped:0 overruns:0 frame:5
          TX packets:1410763 errors:0 dropped:0 overruns:0 carrier:88
          collisions:61207 txqueuelen:100 
          RX bytes:819117597 (781.1 MB)  TX bytes:92219776 (87.9 Mb)
          Interrupt:10 Base address:0x7000

Occasionally, the communication is initialized without collisions or
errors and the system as a whole functions properly for a while.  Even
then--it seems that spontaneous re-negotiation occurs or something
happens to change the configuration and collisions start to happen
again.

In all instances, using mii-tool -R corrects the problem for a
non-specific amount of time.  Doing the same type of command on the
win98 box does not correct the problem, though I am not to confident the
command is actually doing anything.

I have tried several different cross-over cables without any significant
change in performance.  Isolating the different boxes has led me to
believe the problems are on the linux side (using system isolation and
comparison). When I tried a hub instead of the cross-over cable, it
appears that these problems go away.  I would just go with the isolated
hub, however I am trying to keep cost down and if I don't understand the
original problem, I can't guarantee I have fixed it with the hub.

I obviously have tried the latest driver set available from scyld
(v1.27), however it segmentation faults when loading:

Aug 21 16:33:48 dv kernel: pci-scan.c:v1.11 8/31/2002  Donald Becker
<[email protected]> http://www.scyld.com/linux/drivers.html
Aug 21 16:33:48 dv kernel: eepro100.c:v1.27c 4/15/2003 Donald Becker
<[email protected]>
Aug 21 16:33:44 dv network: Setting network parameters:  succeeded
Aug 21 16:33:44 dv logger: punching nameserver through the firewall
Aug 21 16:33:44 dv logger: punching nameserver through the firewall
Aug 21 16:33:48 dv kernel:   http://www.scyld.com/network/eepro100.html
Aug 21 16:33:44 dv network: Bringing up interface lo:  succeeded
Aug 21 16:33:48 dv sshd:  succeeded
Aug 21 16:33:48 dv kernel: eth0: OEM Intel i82559 rev 8 at 0xf89b5000,
00:30:48:41:58:A9, IRQ 11.
Aug 21 16:33:48 dv sshd:
Aug 21 16:33:48 dv kernel:   Board assembly 000000-000, Physical
connectors present: RJ45
Aug 21 16:33:48 dv rc: Starting sshd:  succeeded
Aug 21 16:33:48 dv kernel:   Primary interface chip i82555 PHY #1.
Aug 21 16:33:49 dv kernel: Unable to handle kernel NULL pointer
dereference at virtual address 00000010
Aug 21 16:33:49 dv kernel:  printing eip:
Aug 21 16:33:49 dv kernel: f89b1d23
Aug 21 16:33:49 dv kernel: *pde = 00000000
Aug 21 16:33:49 dv kernel: Oops: 0002
Aug 21 16:33:49 dv kernel: CPU:    1
Aug 21 16:33:49 dv kernel: EIP:
0010:[eepro100:__insmod_eepro100_S.text_L11820+11459/11904]
Aug 21 16:33:49 dv kernel: EIP:    0010:[<f89b1d23>]
Aug 21 16:33:49 dv kernel: EFLAGS: 00010206
Aug 21 16:33:49 dv kernel: eax: 08200000   ebx: 00000004   ecx: 00000000
edx: 00200000
Aug 21 16:33:49 dv kernel: esi: 00000280   edi: f7724000   ebp: f6873c28
esp: f6873c10
Aug 21 16:33:49 dv kernel: ds: 0018   es: 0018   ss: 0018
Aug 21 16:33:49 dv kernel: Process modprobe (pid: 667,
stackpage=f6873000)
Aug 21 16:33:49 dv kernel: Stack: 0000002c 00000246 f6873ea8 00000004
f6873c80 00003e80 f6873ea8 f89af407
Aug 21 16:33:49 dv kernel:        f7724000 00000001 00000000 00000004
00400000 00000040 01800000 baba2000
Aug 21 16:33:49 dv kernel:        00000000 ffffffff f7724000 c0107268
f6873c68 00000002 00000000 0000025e
Aug 21 16:33:49 dv kernel: Call Trace:
[eepro100:__insmod_eepro100_S.text_L11820+935/11904] [error_code+56/64]
[eepro100:i82558_config_c
md+5056/5212] [eepro100:i82558_config_cmd+5062/5212]
[eepro100:i82558_config_cmd+5067/5212]
Aug 21 16:33:49 dv kernel: Call Trace: [<f89af407>] [<c0107268>]
[<f89b3324>] [<f89b332a>] [<f89b332f>]
Aug 21 16:33:49 dv kernel:    [eepro100:i82558_config_cmd+5072/5212]
[_wrapped_alloc_pages+116/640] [__alloc_pages+15/160] [wakeup_bdflu
sh+37/64] [req_new_io+73/96] [account_io_start+68/80]
Aug 21 16:33:49 dv kernel:    [<f89b3334>] [<c0135924>] [<c0135b3f>]
[<c0140f85>] [<c018b609>] [<c018b564>]
Aug 21 16:33:49 dv kernel:    [wakeup_bdflush+37/64]
[eepro100:__insmod_eepro100_O/lib/modules/2.4.7-10smp/kernel/drivers/+-1
761598/96]
[eepro100:__insmod_eepro100_O/lib/modules/2.4.7-10smp/kernel/drivers/+-1
759785/96] [pci_read_config_byte+41/64] [pci_find_capability+163/192]
 [pci_read_config_word+55/80]
Aug 21 16:33:49 dv kernel:    [<c0140f85>] [<f8800ec2>] [<f88015d7>]
[<c01ae919>] [<c01addf3>] [<c01ae967>]
Aug 21 16:33:49 dv kernel:
[eepro100:__insmod_eepro100_O/lib/modules/2.4.7-10smp/kernel/drivers/+-7
111/96] [<f89b6000>] [<f89b5000>]
[__ioremap+208/240] [<f8c00000>]
[eepro100:__insmod_eepro100_O/lib/modules/2.4.7-10smp/kernel/drivers/+-7
456/96]
Aug 21 16:33:49 dv kernel:    [<f89ad439>] [<f89b6000>] [<f89b5000>]
[<c0117850>] [<f8c00000>] [<f89ad2e0>]
Aug 21 16:33:49 dv kernel:    [<f89b5000>]
[call_console_drivers+235/256] [<f89b5000>]
[eepro100:__insmod_eepro100_S.data_L896+144/768]
[eepro100:__insmod_eepro100_S.rodata_L224+0/110]
[eepro100:__insmod_eepro100_S.text_L11820+11637/11904]
Aug 21 16:33:49 dv kernel:    [<f89b5000>] [<c011aeeb>] [<f89b5000>]
[<f89b3450>] [<f89b1ee0>] [<f89b1dd5>]
Aug 21 16:33:49 dv kernel:    [<f89b36c0>]
[eepro100:__insmod_eepro100_S.rodata_L224+64/110]
[eepro100:__insmod_eepro100_O/lib/modules/2
.4.7-10smp/kernel/drivers/+0/96]
[eepro100:__insmod_eepro100_O/lib/modules/2.4.7-10smp/kernel/drivers/+0/
96] [sys_init_module+1365/1600] [<f8
9b3838>]
Aug 21 16:33:49 dv kernel:    [<f89b36c0>] [<f89b1f20>] [<f89af000>]
[<f89af000>] [<c011be65>] [<f89b3838>]
Aug 21 16:33:49 dv kernel:
[eepro100:__insmod_eepro100_O/lib/modules/2.4.7-10smp/kernel/drivers/+-8
192/96] [eepro100:__insmod_eepro10
0_S.text_L11820+0/11904] [system_call+51/56]

Any help or suggestions would be greatly appreciated.

Mark Cavelero
[email protected]