Prolems with tulip driver

[Chris Leavoy]

> > >> kernel: eth0: interrupt  csr5=0xfc274014 new csr5=0xfc264010.
> > >> kernel: eth0: exiting interrupt, csr5=0xfc264010.
> >
> > >That looks like normal operation.
> >
> > That error message is put out on the screen at the fastest rate at which
my
> > system can handle it.  I seriously doubt that is normal considering that
it
> > continues for 2 minutes after i have stopped transfering of a 1meg or so
> > file.  Now the part i forgot to include in the other message was that
after
>
> You turned debugging on, and didn't enabled write-behind in the
> /etc/syslog.conf.

It is enabled. The problem is not with my system.  I think that there is
something different with my nic that is causing problems with the tulip
driver

> > a few minutes of transfering data over the card the system would hang.
I
> > would check syslogd and it reported that the kernel has paniced.  I read
up
> > a few lines more and i get an error message saying, "unable to handle
paging
> > requests to virtual address 0xfc264010" or something close to that, i
cant
> > get a print out of it because the system requires a hard reboot after
this
> > happens.
>
> What process died?  Try running ksymoops.
> This doesn't sound like a typical Ethernet driver problem.

No process died. The kernel paniced. The system locked hard, *nothing* would
respond. I just tried it again, but this time i turned off debuging mode
(debug=0). After a few minutes of transfering the card locked. With the same
error as before, "unable to handle paging requests to virtual address blah".
The cards dos diag problem and network test feature that says the card is
working perfectly in 100mbit full duplex mode.

> I just tried my Comet PCI card and it seems to work fine.  I'm in the
> process of putting a bunch of packet through the system.  I have about a
> million packets through it so far, and I'll run it overnight.
>
> I have updated the v92 tulip driver to correctly handle the built-in MII
> transceiver of the Centaur (Comet on CardBus), but the change is minor so
> I'll wait for a few more changes before doing a new test release.

./tulip-diag -p 0xec00 -t 12 -aa -e -mm

tulip-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com)
 http://www.scyld.com/diag/index.html
Assuming a ADMtek AL981 Comet adapter at 0xec00.
ADMtek AL981 Comet chip registers at 0xec00:
  fff98000 ffffffff ffffffff 015c1000 015c1200 fc06c812 ffb70115 fffe4010
  fffe0000 fff0dff8 00000000 fffe0000 00000000 00000200 00000000 c40ffec8
  2006c812 804c0004 00000000 015c1010 f0000000 ffff0f5c 00000000 00000000
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 Port selection is 100mbps-SYM/PCS 100baseTx scrambler, half-duplex.
 Transmit stopped, Receive stopped, half-duplex.
  The Rx process state is 'Waiting for packets'.
  The Tx process state is 'Stopped'.
  The transmit unit is set to store-and-forward.
 Interrupt sources are pending!  CSR5 is fc06c812.
   Tx complete indication.
   Link passed indication.
   Timer expired indication.
   Early Rx indication.
 The Comet MAC registers are 01782000 ffff0f5c filter 8000000000000000.
EEPROM size is 8.
 A simplifed EEPROM data table was found.
 The EEPROM does not contain transceiver control information.
   No MII transceivers found!

I find the last line of that output very interesting.

-------------------------------------------------------------------
To unsubscribe send a message body containing "unsubscribe"
to linux-tulip-request@beowulf.org