Pesky transmit time out

Bob recbo@erols.com
Mon Jan 3 10:06:35 2000


--------------B4905D6E16F1D4A981121BE3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stephen Host wrote:

> Ahh.. i didn't know they were doing letter-revisions on the versions of
> tulip.c .. i have 0.91 not 0.91g ..
>
> Time to remove all drivers and go module-only (where applicable) and
> upgrade =)
>
> Thanks again..
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Steve Host - Engineering Systems & Computing Student, University of Guelph
>        godiva.eos.uoguelph.ca/~shost/shost.html - shost@uoguelph.ca
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> On Fri, 31 Dec 1999, Jason Thomas wrote:
>
> > if this is a default redhat kernel, I suggest you get a newer kernel or get
> > the same kerenel sources, and the tulip.c sources from the website.

Very often new code is more stable than old, contrary to
what some tend to think, so if you need stability for your ip
aliasing gateway use 91u. I've been using it with PNIC and
21143 cards. You don't just compile tulip.c any more. Get all
files at the url.

-Bob

tulip.c:v0.91u 10/15/99 and other files from---

ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/kern-2.3

Use the README there.

Place those files in /usr/src/linux/drivers/net.

Also helpful--

#pushd /usr/src/linux/drivers/net
cat Makefile | gawk --source '{
  if ( $3 ~ /auto_irq.o/ print $1 "  " $2 "  " $3 " pci-netif.o ;
  else print $0}' > /tmp/gawk.out
#mv /tmp/gawk.out Makefile
#popd

make tulip



> and
> > compile a new kernel. Alot of people have been having similiar problems with
> > the older tulip diver.
> >
> > Stephen Host [shost@uoguelph.ca] wrote:
> > > I run a Masq server for my housemates. It has been up for 56 days now but,
> > > unfortunately, one of my netcards (the primary intranet card) has decided
> > > to hang completely on me.  I noticed this 2 weeks ago, when my quake 3
> > > server behing my firewall would stop recieving packets for about 3
> > > seconds.
> > > It turns out the tramit problem would  surface on this particular DEC
> > > 21041 card and re-set itself.
> > > Currently, it is re-setting consistantly and NOT allowing any packets
> > > through this segment of my network. (thus the problem has worsened)
> > >
> > > My hardware is:
> > > 3 X D-link  w/Dec 21041 cards. Both the other cards are solid (seemingly)
> > > as there are no errors associated with eth0/eth2 since last reboot.
> > >
> > > Relevant software: Kernel 2.2.10, Tulip version 0.91, Redhat 5.X upgraded.
> > >
> > > Here is some possible information that could be helpful..
> > >
> > > eth1: 21041 transmit timed out, status fc260010, CSR12 000050c8, CSR13 ffffef09,
> > >  CSR14 fffff7fd, resetting...
> > > eth1: 21041 transmit timed out, status fc260010, CSR12 000000c8, CSR13 ffffef05,
> > >  CSR14 ffffff3f, resetting...
> > > [toast-@darkwing toast]$
> > >
> > >
> > > /sbin/ifconfig eth1
> > > eth1      Link encap:Ethernet  HWaddr 00:80:C8:F6:EF:86
> > >           inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
> > >           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> > >           RX packets:60480489 errors:679 dropped:0 overruns:0
> > >           TX packets:0 errors:2140872330 dropped:75892738 overruns:29850
> > >           Interrupt:10 Base address:0x6100
> > >
> > > I'm aware that re-booting may be a solution but in the quest for a stable
> > > server rebooting is not an option unless the very last issue =)
> > >
> > > Further, since only one card is affected, it seems this could be a
> > > hardware issue, but i'd like to nail down a software issue first..
> > >
> > > Thanks for your help!
> > >
> > >
> > >
> > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > > Steve Host - Engineering Systems & Computing Student, University of Guelph
> > >        godiva.eos.uoguelph.ca/~shost/shost.html - shost@uoguelph.ca
> > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > >
> > > -------------------------------------------------------------------
> > > To unsubscribe send a message body containing "unsubscribe"
> > > to linux-tulip-request@beowulf.org
> >
> > --
> > Jason Thomas                           Phone:  +61 2 6257 7111
> > System Administrator  -  UID 0         Fax:    +61 2 6257 7311
> > tSA Consulting Group Pty. Ltd.         Mobile: 0418 29 66 81
> > 1 Hall Street Lyneham ACT 2602        http://www.topic.com.au/
> >
>
> -------------------------------------------------------------------
> To unsubscribe send a message body containing "unsubscribe"
> to linux-tulip-request@beowulf.org

--

druggingamerica.com

copvcia.com

dci a.com

madcowprod.com

JFK


--------------B4905D6E16F1D4A981121BE3
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
Stephen Host wrote:
Ahh.. i didn't know they were doing letter-revisions on the versions of
tulip.c .. i have 0.91 not 0.91g ..

Time to remove all drivers and go module-only (where applicable) and
upgrade =)

Thanks again..

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steve Host - Engineering Systems & Computing Student, University of Guelph
       godiva.eos.uoguelph.ca/~shost/shost.html - shost@uoguelph.ca
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

On Fri, 31 Dec 1999, Jason Thomas wrote:

> if this is a default redhat kernel, I suggest you get a newer kernel or get
> the same kerenel sources, and the tulip.c sources from the website.

Very often new code is more stable than old, contrary to
what some tend to think, so if you need stability for your ip
aliasing gateway use 91u. I've been using it with PNIC and
21143 cards. You don't just compile tulip.c any more. Get all
files at the url.

-Bob

tulip.c:v0.91u 10/15/99 and other files from---

ftp://cesdis.gsfc.nasa.gov/pub/linux/drivers/kern-2.3

Use the README there.

Place those files in /usr/src/linux/drivers/net.

Also helpful--

#pushd /usr/src/linux/drivers/net
cat Makefile | gawk --source '{
  if ( $3 ~ /auto_irq.o/ print $1 "  " $2 "  " $3 " pci-netif.o ;
  else print $0}' > /tmp/gawk.out
#mv /tmp/gawk.out Makefile
#popd

make tulip
 
 

and
> compile a new kernel. Alot of people have been having similiar problems with
> the older tulip diver.
>
> Stephen Host [shost@uoguelph.ca] wrote:
> > I run a Masq server for my housemates. It has been up for 56 days now but,
> > unfortunately, one of my netcards (the primary intranet card) has decided
> > to hang completely on me.  I noticed this 2 weeks ago, when my quake 3
> > server behing my firewall would stop recieving packets for about 3
> > seconds.
> > It turns out the tramit problem would  surface on this particular DEC
> > 21041 card and re-set itself.
> > Currently, it is re-setting consistantly and NOT allowing any packets
> > through this segment of my network. (thus the problem has worsened)
> >
> > My hardware is:
> > 3 X D-link  w/Dec 21041 cards. Both the other cards are solid (seemingly)
> > as there are no errors associated with eth0/eth2 since last reboot.
> >
> > Relevant software: Kernel 2.2.10, Tulip version 0.91, Redhat 5.X upgraded.
> >
> > Here is some possible information that could be helpful..
> >
> > eth1: 21041 transmit timed out, status fc260010, CSR12 000050c8, CSR13 ffffef09,
> >  CSR14 fffff7fd, resetting...
> > eth1: 21041 transmit timed out, status fc260010, CSR12 000000c8, CSR13 ffffef05,
> >  CSR14 ffffff3f, resetting...
> > [toast-@darkwing toast]$
> >
> >
> > /sbin/ifconfig eth1
> > eth1      Link encap:Ethernet  HWaddr 00:80:C8:F6:EF:86
> >           inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
> >           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> >           RX packets:60480489 errors:679 dropped:0 overruns:0
> >           TX packets:0 errors:2140872330 dropped:75892738 overruns:29850
> >           Interrupt:10 Base address:0x6100
> >
> > I'm aware that re-booting may be a solution but in the quest for a stable
> > server rebooting is not an option unless the very last issue =)
> >
> > Further, since only one card is affected, it seems this could be a
> > hardware issue, but i'd like to nail down a software issue first..
> >
> > Thanks for your help!
> >
> >
> >
> > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > Steve Host - Engineering Systems & Computing Student, University of Guelph
> >        godiva.eos.uoguelph.ca/~shost/shost.html - shost@uoguelph.ca
> > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> >
> > -------------------------------------------------------------------
> > To unsubscribe send a message body containing "unsubscribe"
> > to linux-tulip-request@beowulf.org
>
> --
> Jason Thomas                           Phone:  +61 2 6257 7111
> System Administrator  -  UID 0         Fax:    +61 2 6257 7311
> tSA Consulting Group Pty. Ltd.         Mobile: 0418 29 66 81
> 1 Hall Street Lyneham ACT 2602        http://www.topic.com.au/
>

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


--

druggingamerica.com

copvcia.com

dci a.com

madcowprod.com

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