2002-03-24 09:16:48

by Andreas Hartmann

[permalink] [raw]
Subject: [2.4.18] Problems with sis900.c [solution?]

Hello all,

This night, I tested kernel 2.4.18 on my server. All seems to be good.
This morning, after rebooting the server and the connected client, I
couldn't launch the server no more :-(, because of connection problems.
Pinging the server shows a lot of missing packets or they take too much
time - but other packets are transmitted well.
A connection with ssh isn't possible (client doesn't connect).

The machines are connected with a crosslink-cable.
I'm using kernel 2.4.18 on the client and on the server.

server <---------> client
2.4.18
2.4.18
sis900.c
sis900.c
same NIC on server and client



First, I tried to reboot the server - no change.



Next, I tried to change the NIC on the client (I've got two NIC's in the
client), but the problem stayed.
The error-messages in /var/log/messages are always the same:
Mar 24 08:44:19 susi kernel: eth0: Media Link Off
Mar 24 08:44:28 susi kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 24 08:44:28 susi kernel: eth0: Transmit timeout, status 00000004
00000000
Mar 24 08:44:29 susi kernel: eth0: Media Link On 100mbps full-duplex
Mar 24 08:45:10 susi kernel: eth0: Media Link Off
Mar 24 08:45:20 susi kernel: eth0: Media Link On 100mbps full-duplex
Mar 24 08:45:31 susi kernel: eth0: Media Link Off
Mar 24 08:45:46 susi kernel: eth0: Media Link On 100mbps full-duplex

The green LED on the NIC's often went off and went on after some time again.



Third, I tried to reboot the server with kernel 2.4.17 - this is working
fine.



Now, I patched sis900.c on the server [2.4.18], recompiled modules and
rebooted the server.

server <---------> client
2.4.18
2.4.18
patched
sis900.c
sis900.c
same NIC on server and client

I applied this patch:

-------------------------------------------------------------------------
--- sis900.c.orig Sun Mar 24 09:28:52 2002
+++ sis900.c Sun Mar 24 09:21:21 2002
@@ -1420,11 +1420,11 @@
unsigned long flags;

/* Don't transmit data before the complete of auto-negotiation */
- if(!sis_priv->autong_complete){
+/* if(!sis_priv->autong_complete){
netif_stop_queue(net_dev);
return 1;
}
-
+*/
spin_lock_irqsave(&sis_priv->lock, flags);

/* Calculate the next Tx descriptor entry. */
--------------------------------------------------------------------------


(I uncommented the not sending of datas before complete of autonegotiation.)
With this patch on the server, the NIC is working fine again.




My NIC on the server (and the client eth0):
00:0b.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900
10/100 Ethernet (rev 02)
Subsystem: Silicon Integrated Systems [SiS] SiS900 10/100
Ethernet Adapter
Flags: bus master, medium devsel, latency 32, IRQ 10
I/O ports at b800 [size=256]
Memory at e2800000 (32-bit, non-prefetchable) [size=4K]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [40] Power Management version 1



I have to emphasis, that on the client works an unpatched 2.4.18
sis900.c. But the connect with the "unpatched" server to the other NIC
on the client, didn't work, too. It showed up the same problems.
The other NIC (eth1) on the client is:

00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139
(rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. RT8139
Flags: bus master, medium devsel, latency 32, IRQ 11
I/O ports at ec00 [size=256]
Memory at d9001000 (32-bit, non-prefetchable) [size=256]
Expansion ROM at <unassigned> [disabled] [size=64K]

eth0 is switched to autonegotiation, eth1 is forced to 100MBit / FD.



Last, I tried the connect with eth1 and the patched 2.4.18-kernel. It
has been working fine, too.



Regards,
Andreas Hartmann


2002-04-02 13:43:52

by Rene Rebe

[permalink] [raw]
Subject: Re: [2.4.18] Problems with sis900.c [solution?]

Hi all.

I only want to note that there is really a problem with
autonegotiation with the sis900.c driver. We have a sis630 based
Laptop and SiS730 based Workstation using the integrated NIC. They
only autonegotiate once after power-on. When the cable is unplugged
and replugged into a hup/switch/whatever the driver doesn't work
anymore and generates this:

NETDEV WATCHDOG: eth0: transmit timed out
eth0: Transmit timeout, status 00000004 00000000
eth0: Media Link On 100mbps full-duplex
eth0: Media Link Off

error messages. Although I do not know if the posted patch is the
right fix.

On: Sun, 24 Mar 2002 10:17:19 +0100,
andreas <[email protected]> wrote:
> Hello all,
>
> This night, I tested kernel 2.4.18 on my server. All seems to be good.
> This morning, after rebooting the server and the connected client, I
> couldn't launch the server no more :-(, because of connection problems.
> Pinging the server shows a lot of missing packets or they take too much
> time - but other packets are transmitted well.
> A connection with ssh isn't possible (client doesn't connect).
>
> The machines are connected with a crosslink-cable.
> I'm using kernel 2.4.18 on the client and on the server.

[... some more examples ...]

> Regards,
> Andreas Hartmann

k33p h4ck1n6
Ren?

--
Ren? Rebe (Registered Linux user: #248718 <http://counter.li.org>)

eMail: [email protected]
[email protected]

Homepage: http://drocklinux.dyndns.org/rene/

Anyone sending unwanted advertising e-mail to this address will be
charged $25 for network traffic and computing time. By extracting my
address from this message or its header, you agree to these terms.

2002-04-02 16:48:10

by Andreas Hartmann

[permalink] [raw]
Subject: Re: [2.4.18] Problems with sis900.c [solution?]

Hi!

Rene Rebe wrote:
> Hi all.
>

[...]

> Although I do not know if the posted patch is the
> right fix.

I don't think it's the correct fix - but it's working for me. It's nothing
more than a workaround, that may work or not.


Regards,
Andreas Hartmann

2002-10-23 16:53:37

by Richard.Petrie

[permalink] [raw]
Subject: Re: [2.4.18] Problems with sis900.c [solution?]

Hi,
you will notice that in kernel 2.4.18-3 there is an sis900_old.o in
addition to the sis900.o.
I have found this old version works fine and does not give the message.

eth0: Transmit timeout, status 00000004 00000000

Can anyone advise of any reasons why I should not use this?

thanks

Richard


__________________________________________________________________________

Trend Communications Ltd.
Knaves Beech Estate, Loudwater, Bucks, HP10 9QZ, United Kingdom.
Tel: +44 1628 524977.
Fax: +44 1628 810094 (not for confidential documents).

Web: http://www.trendcomms.com

No liability is accepted by Trend Communications Ltd for any loss or damage
incurred through use of this email.