From freaky@voi.aagh.net  Sun Mar 21 20:23:52 2004
Return-Path: <freaky@voi.aagh.net>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id B9D2616A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Sun, 21 Mar 2004 20:23:52 -0800 (PST)
Received: from mta06-svc.ntlworld.com (mta06-svc.ntlworld.com [62.253.162.46])
	by mx1.FreeBSD.org (Postfix) with ESMTP id CF54543D45
	for <FreeBSD-gnats-submit@freebsd.org>; Sun, 21 Mar 2004 20:23:51 -0800 (PST)
	(envelope-from freaky@voi.aagh.net)
Received: from voi.aagh.net ([81.104.55.176]) by mta06-svc.ntlworld.com
          (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP
          id <20040322042352.HFDM19383.mta06-svc.ntlworld.com@voi.aagh.net>
          for <FreeBSD-gnats-submit@freebsd.org>;
          Mon, 22 Mar 2004 04:23:52 +0000
Received: from freaky by voi.aagh.net with local (Exim 4.30; FreeBSD)
	id 1B5Gyc-000BPg-IA
	for FreeBSD-gnats-submit@freebsd.org; Mon, 22 Mar 2004 04:23:50 +0000
Message-Id: <E1B5Gyc-000BPg-IA@voi.aagh.net>
Date: Mon, 22 Mar 2004 04:23:50 +0000
From: Thomas Hurst <tom@hur.st>
Sender: Thomas Hurst <freaky@voi.aagh.net>
Reply-To: Thomas Hurst <tom@hur.st>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: if_sis short cable fix problems with NetGear FA311's
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         64556
>Category:       kern
>Synopsis:       [sis] [patch] if_sis short cable fix problems with NetGear FA311's
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    brucec
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Mar 21 20:30:21 PST 2004
>Closed-Date:    Sat Sep 11 14:48:34 UTC 2010
>Last-Modified:  Sat Sep 11 14:48:34 UTC 2010
>Originator:     Thomas Hurst
>Release:        FreeBSD 5.2.1-RELEASE-p3 i386
>Organization:
>Environment:
System: FreeBSD voi.aagh.net 5.2.1-RELEASE-p3 FreeBSD 5.2.1-RELEASE-p3 #0: Wed Mar 17 21:29:20 GMT 2004 root@voi.aagh.net:/usr/obj/usr/src/sys/VOI i386

	This is a 512MB BP6 running dual 533MHz Celerons, dual NetGear FA311 NIC's,
	and has been running reliably for years, although I recently upgraded the
	CPU's.
>Description:
I'm running a pair of NetGear FA311's on FreeBSD 5.2.1-RELEASE-p3,
updated about 5 days ago.  These have been fine on 4-STABLE for the past
couple of years, except for one or two issues which I'm happy to blame
on my Motorola SB4100 cable modem, although I'm now wondering if this is
wise (symptoms were dialup-like performance not related to ISP; temporarily
dropping to 10Mbps seemed to resolve it).

My last reboot was down to an odd network issue where, basically, my
cable modem (on sis1) stopped responding to requests; I first thought it
was an issue with my provider, but moving the CM to another machine was
fine.  Checking /var/log/all, I found:

 all.5.bz2:Mar 16 07:58:34 voi kernel: sis1: Applying short cable fix (reg=e8)
 all.5.bz2:Mar 16 07:59:03 voi kernel: sis1: Applying short cable fix (reg=0)
 all.5.bz2:Mar 16 07:59:10 voi kernel: sis1: Applying short cable fix (reg=0)
[repeat lots of times]
 all.5.bz2:Mar 16 08:36:29 voi kernel: sis1: Applying short cable fix (reg=0)
 all.5.bz2:Mar 16 08:37:00 voi kernel: sis1: Applying short cable fix (reg=b)
 all.5.bz2:Mar 16 08:37:05 voi kernel: sis1: Applying short cable fix (reg=e8)
 all.5.bz2:Mar 16 08:37:12 voi kernel: sis1: Applying short cable fix (reg=e8)
 all.5.bz2:Mar 16 08:37:22 voi kernel: sis1: Applying short cable fix (reg=0)
[repeat lots of times]
 all.5.bz2:Mar 16 08:39:16 voi kernel: sis1: Applying short cable fix (reg=0)
 all.5.bz2:Mar 16 08:41:26 voi kernel: sis0: Applying short cable fix (reg=f3)
 all.5.bz2:Mar 16 08:41:34 voi kernel: sis1: Applying short cable fix (reg=23)
 all.5.bz2:Mar 16 08:41:42 voi kernel: sis1: Applying short cable fix (reg=0)
[repeat a few more times]
 all.5.bz2:Mar 16 08:42:12 voi kernel: sis1: Applying short cable fix (reg=0)
 all.5.bz2:Mar 16 08:43:43 voi kernel: sis0: Applying short cable fix (reg=f7)
 all.5.bz2:Mar 16 08:43:43 voi kernel: sis1: Applying short cable fix (reg=23)
 all.5.bz2:Mar 16 08:43:43 voi kernel: sis1: Applying short cable fix (reg=e8)

I finally rebooted in exasperation, although next time I'll try dropping
to 10Mbit again.

e8 seems to be the normal value for reg for sis1 (my CM), btw.

Now, earlier today I was playing a FLAC file in foobar 2000; I
ReplayGained it happily at 4M/s, then gawped as I saw the update
operation write back at 400-900k/s, while my console on FreeBSD was
filled with:

 Mar 22 00:20:23 voi kernel: sis0: Applying short cable fix (reg=e8)
 Mar 22 00:20:54 voi last message repeated 21 times
 Mar 22 00:21:09 voi last message repeated 11 times

Things seem fine now, no reboot or any other change other than the
removal of the QoS packet scheduler in my Windows XP desktop.
>How-To-Repeat:
	Use one or two FA311's for an extended period using short cables. Not tested
	on longer cables.
>Fix:
	Tempt me to get some Intel NIC's?  Mmmm, GigE... :o
>Release-Note:
>Audit-Trail:

From: Volker <volker@vwsoft.com>
To: bug-followup@FreeBSD.org, tom@hur.st
Cc:  
Subject: Re: kern/64556: [sis] if_sis short cable fix problems with NetGear
 FA311's
Date: Tue, 12 Feb 2008 22:48:15 +0100

 Thomas,
 
 have you seen the incorrect behavior with releases > 5.2.1?
 
State-Changed-From-To: open->feedback 
State-Changed-By: linimon 
State-Changed-When: Tue Feb 12 22:59:39 UTC 2008 
State-Changed-Why:  
Note that submitter has been asked for feedback. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=64556 

From: Thomas Hurst <tom@hur.st>
To: Volker <volker@vwsoft.com>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/64556: [sis] if_sis short cable fix problems with NetGear
	FA311's
Date: Tue, 12 Feb 2008 23:59:17 +0000

 * Volker (volker@vwsoft.com) wrote:
 
 > Thomas,
 > 
 > have you seen the incorrect behavior with releases > 5.2.1?
 
 Hmm, been a while since I retired this system, and even longer since I
 retired the cards, but I think I still saw them in 5.3 at least
 
 I still have the motherboard and 2 or 3 cards.. somewhere; I can see
 about resurrecting it and seeing if I can reproduce with 6.3 or 7.  With
 the weeks or months between failures, though, it might be difficult
 giving a conclusive answer.  Hopefully heavy load will bring it on
 quicker if it's still an issue.
 
 -- 
 Thomas 'Freaky' Hurst
     http://hur.st/

From: Thomas Hurst <tom@hur.st>
To: Volker <volker@vwsoft.com>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/64556: [sis] if_sis short cable fix problems with NetGear
	FA311's
Date: Sat, 16 Feb 2008 16:20:50 +0000

 I've revived the machine; it's now running FreeBSD 7.0-RC2.
 
 I'm seeing "short cable fix (reg=e8)" when loading a card.
 Bidirectional activity seems to be the culprit; I can send or receive at
 93Mbps for seemingly as long as I like, but as soon as I'm doing both
 they start almost immediately.
 
 Receiving seems to suffer most; I'm seeing averages of 75Mbps sending
 and 55Mbps receiving.  Throughput drops considerably when the messages
 occur; 40Mbps and 15Mbps respectively.  They could be complete
 throughput stops; iftop isn't really fine grained enough to say.
 
 After about 10 minutes of activity I see connection drops on the
 receiving side:
 
 -<freaky@oldvoi:~>-
 -% ttcp -s -r -n 100000000
 ttcp-r: buflen=8192, nbuf=100000000, align=16384/0, port=5001  tcp
 ttcp-r: socket
 ttcp-r: accept from 10.0.1.1
 ttcp-r: IO: Network is down
 errno=50
 Real: 11:02.94 CPU: 26.2% (170.933/2.876) Page: 0 Swap: 0 I/O: (0/0)
 
 -<freaky@voi:~>-
 -% ttcp -s -t -n100000000 10.0.1.122
 ttcp-t: buflen=8192, nbuf=100000000, align=16384/0, port=5001  tcp  ->
 10.0.1.122
 ttcp-t: socket
 ttcp-t: connect
 ttcp-t: IO: Broken pipe
 errno=32
 
 The cards certainly don't seem to be any more reliable than they were 4
 years ago.  I'll try Linux next; perhaps the hardware just sucks.
 
 I guess I should dig out a longer cable too.  And maybe try !SMP.
 
 -- 
 Thomas 'Freaky' Hurst
     http://hur.st/
State-Changed-From-To: feedback->open 
State-Changed-By: linimon 
State-Changed-When: Sat Feb 16 16:51:39 UTC 2008 
State-Changed-Why:  
Feedback received. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=64556 

From: Thomas Hurst <tom@hur.st>
To: Volker <volker@vwsoft.com>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/64556: [sis] if_sis short cable fix problems with NetGear
	FA311's
Date: Mon, 18 Feb 2008 14:07:27 +0000

 Testing with Linux shows that receive seems to be throttled during
 bidirectional activity.  Unidirectional sees 93Mbps in either direction,
 bidirectional sees 93Mbps sending and 35-60Mbps (50 average) receiving.
 
 There's no sign of connection dropping in an hour of testing.
 
 Linux is spewing APIC errors at me, not sure what, if anything, they're
 related to.
 
 A quick glance at the FreeBSD driver shows a DELAY(100000); which
 probably accounts for the performance drops; each burst of 'short cable
 fix' messages basically leaves the card idle for 300ms or so.  The Linux
 driver (drivers/net/natsemi.c) has no sign of such a delay.
 
 This all happens during card setup, sis_initl(), shouldn't this be only
 happening once when it aquires the link, not randomly during operation?
 Watchdog timeouts excepted, but there's no sign of them.
 
 -- 
 Thomas 'Freaky' Hurst
     http://hur.st/

From: Volker <volker@vwsoft.com>
To: Thomas Hurst <tom@hur.st>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/64556: [sis] if_sis short cable fix problems with NetGear
 FA311's
Date: Mon, 18 Feb 2008 21:35:24 +0100

 Thomas,
 
 On 02/18/08 15:07, Thomas Hurst wrote:
 > Testing with Linux shows that receive seems to be throttled during
 > bidirectional activity.  Unidirectional sees 93Mbps in either direction,
 > bidirectional sees 93Mbps sending and 35-60Mbps (50 average) receiving.
 > 
 > There's no sign of connection dropping in an hour of testing.
 > 
 > Linux is spewing APIC errors at me, not sure what, if anything, they're
 > related to.
 > 
 > A quick glance at the FreeBSD driver shows a DELAY(100000); which
 > probably accounts for the performance drops; each burst of 'short cable
 > fix' messages basically leaves the card idle for 300ms or so.  The Linux
 > driver (drivers/net/natsemi.c) has no sign of such a delay.
 
 well, I'll leave it for the net-team to check if this DELAY can be
 shortened (it's 100 msec delay).
 
 > This all happens during card setup, sis_initl(), shouldn't this be only
 > happening once when it aquires the link, not randomly during operation?
 
 sis_initl is being called not just for initializing the card once, but
 whenever RX errors or state changes are detected.
 
 I'm wondering if you can give us the following information as I think
 this will be needed for the net folks to further analyze your problem:
 
 pciconf -lv
 dmesg
 
 and the following when a bunch of network traffic has been generated:
 
 vmstat -ia
 netstat -i
 
 Also just a wild guess as the problems might be related: PR kern/112179
 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/112179 contains a patch,
 can you try if you see any difference with that patch applied?
 
 Thanks a lot!
 
Responsible-Changed-From-To: freebsd-bugs->freebsd-net 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Mon Feb 18 21:45:18 UTC 2008 
Responsible-Changed-Why:  
Assign to -net.  Note: submitter has provided some feedback. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=64556 

From: Thomas Hurst <tom@hur.st>
To: Volker <volker@vwsoft.com>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/64556: [sis] if_sis short cable fix problems with NetGear
	FA311's
Date: Tue, 19 Feb 2008 00:03:12 +0000

 * Volker (volker@vwsoft.com) wrote:
 
 > > A quick glance at the FreeBSD driver shows a DELAY(100000); which
 > > probably accounts for the performance drops; each burst of 'short cable
 > > fix' messages basically leaves the card idle for 300ms or so.  The Linux
 > > driver (drivers/net/natsemi.c) has no sign of such a delay.
 > 
 > well, I'll leave it for the net-team to check if this DELAY can be
 > shortened (it's 100 msec delay).
 
 Yes, but they happen in clusters of 3 or so.
 
 > > This all happens during card setup, sis_initl(), shouldn't this be only
 > > happening once when it aquires the link, not randomly during operation?
 > 
 > sis_initl is being called not just for initializing the card once, but
 > whenever RX errors or state changes are detected.
 
 Ah.
 
 Linux showed a pretty high number of errors.  Maybe it's worth being
 less aggressive.
 
 > I'm wondering if you can give us the following information as I think
 > this will be needed for the net folks to further analyze your problem:
 > 
 > pciconf -lv
 > dmesg
 
 hostb0@pci0:0:0:0:      class=0x060000 card=0x00000000 chip=0x71908086 rev=0x03 hdr=0x00
     vendor     = 'Intel Corporation'
     device     = '82443BX/ZX 440BX/ZX CPU to PCI Bridge (AGP Implemented)'
     class      = bridge
     subclass   = HOST-PCI
 pcib1@pci0:0:1:0:       class=0x060400 card=0x00000000 chip=0x71918086 rev=0x03 hdr=0x01
     vendor     = 'Intel Corporation'
     device     = '82443BX/ZX 440BX/ZX AGPset PCI-to-PCI bridge'
     class      = bridge
     subclass   = PCI-PCI
 isab0@pci0:0:7:0:       class=0x060100 card=0x00000000 chip=0x71108086 rev=0x02 hdr=0x00
     vendor     = 'Intel Corporation'
     device     = '82371AB/EB/MB PIIX4/4E/4M ISA Bridge'
     class      = bridge
     subclass   = PCI-ISA
 atapci0@pci0:0:7:1:     class=0x010180 card=0x00000000 chip=0x71118086 rev=0x01 hdr=0x00
     vendor     = 'Intel Corporation'
     device     = '82371AB/EB/MB PIIX4/4E/4M IDE Controller'
     class      = mass storage
     subclass   = ATA
 uhci0@pci0:0:7:2:       class=0x0c0300 card=0x00000000 chip=0x71128086 rev=0x01 hdr=0x00
     vendor     = 'Intel Corporation'
     device     = '82371AB/EB/MB PIIX4/4E/4M USB Interface'
     class      = serial bus
     subclass   = USB
 none0@pci0:0:7:3:       class=0x068000 card=0x00000000 chip=0x71138086 rev=0x02 hdr=0x00
     vendor     = 'Intel Corporation'
     device     = '82371AB/EB/MB PIIX4/4E/4M Power Management Controller'
     class      = bridge
 sis0@pci0:0:15:0:       class=0x020000 card=0xf3111385 chip=0x0020100b rev=0x00 hdr=0x00
     vendor     = 'National Semiconductors'
     device     = 'DP83815/16 Fast Ethernet Adapter (MacPhyter/MacPhyter-II)'
     class      = network
     subclass   = ethernet
 sis1@pci0:0:17:0:       class=0x020000 card=0xf3111385 chip=0x0020100b rev=0x00 hdr=0x00
     vendor     = 'National Semiconductors'
     device     = 'DP83815/16 Fast Ethernet Adapter (MacPhyter/MacPhyter-II)'
     class      = network
     subclass   = ethernet
 atapci1@pci0:0:19:0:    class=0x018000 card=0x00000000 chip=0x00041103 rev=0x01 hdr=0x00
     vendor     = 'Triones Technologies Inc. (HighPoint)'
     device     = 'HPT3xx UDMA66/100/133 EIDE Controller'
     class      = mass storage
 atapci2@pci0:0:19:1:    class=0x018000 card=0x00000000 chip=0x00041103 rev=0x01 hdr=0x00
     vendor     = 'Triones Technologies Inc. (HighPoint)'
     device     = 'HPT3xx UDMA66/100/133 EIDE Controller'
     class      = mass storage
 vgapci0@pci0:1:0:0:     class=0x030000 card=0xff03102b chip=0x0521102b rev=0x01 hdr=0x00
     vendor     = 'Matrox Electronic Systems Ltd.'
     device     = 'Matrox lnc MGA-G200B Eclipse/Calao'
     class      = display
     subclass   = VGA
 
 Copyright (c) 1992-2008 The FreeBSD Project.
 Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
         The Regents of the University of California. All rights reserved.
 FreeBSD is a registered trademark of The FreeBSD Foundation.
 FreeBSD 7.0-RC2 #0: Fri Feb  8 00:09:57 UTC 2008
     root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
 Timecounter "i8254" frequency 1193182 Hz quality 0
 CPU: Pentium II/Pentium II Xeon/Celeron (534.55-MHz 686-class CPU)
   Origin = "GenuineIntel"  Id = 0x665  Stepping = 5
   Features=0x183fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR>
 real memory  = 805240832 (767 MB)
 avail memory = 774074368 (738 MB)
 ACPI APIC Table: <ABIT   >
 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
  cpu0 (BSP): APIC ID:  0
  cpu1 (AP): APIC ID:  1
 ioapic0 <Version 1.1> irqs 0-23 on motherboard
 kbd1 at kbdmux0
 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
 acpi0: <ABIT AWRDACPI> on motherboard
 acpi0: [ITHREAD]
 acpi0: Power Button (fixed)
 acpi0: reservation of 0, a0000 (3) failed
 acpi0: reservation of 100000, 2fef0000 (3) failed
 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0
 cpu0: <ACPI CPU> on acpi0
 cpu1: <ACPI CPU> on acpi0
 acpi_button0: <Power Button> on acpi0
 pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff,0x4000-0x4041,0x5000-0x500f on acpi0
 pci0: <ACPI PCI bus> on pcib0
 agp0: <Intel 82443BX (440 BX) host to PCI bridge> on hostb0
 pcib1: <PCI-PCI bridge> at device 1.0 on pci0
 pci1: <PCI bus> on pcib1
 vgapci0: <VGA-compatible display> mem 0xdc000000-0xdcffffff,0xd8000000-0xd8003fff,0xd9000000-0xd97fffff irq 16 at device 0.0 on pci1
 isab0: <PCI-ISA bridge> at device 7.0 on pci0
 isa0: <ISA bus> on isab0
 atapci0: <Intel PIIX4 UDMA33 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 7.1 on pci0
 ata0: <ATA channel 0> on atapci0
 ata0: [ITHREAD]
 ata1: <ATA channel 1> on atapci0
 ata1: [ITHREAD]
 uhci0: <Intel 82371AB/EB (PIIX4) USB controller> port 0xc000-0xc01f irq 19 at device 7.2 on pci0
 uhci0: [GIANT-LOCKED]
 uhci0: [ITHREAD]
 usb0: <Intel 82371AB/EB (PIIX4) USB controller> on uhci0
 usb0: USB revision 1.0
 uhub0: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
 uhub0: 2 ports with 2 removable, self powered
 pci0: <bridge> at device 7.3 (no driver attached)
 sis0: <NatSemi DP8381[56] 10/100BaseTX> port 0xc400-0xc4ff mem 0xde000000-0xde000fff irq 16 at device 15.0 on pci0
 sis0: Silicon Revision: DP83815D
 miibus0: <MII bus> on sis0
 ukphy0: <Generic IEEE 802.3u media interface> PHY 0 on miibus0
 ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
 sis0: Ethernet address: 00:02:e3:16:ed:b0
 sis0: [ITHREAD]
 sis1: <NatSemi DP8381[56] 10/100BaseTX> port 0xc800-0xc8ff mem 0xde001000-0xde001fff irq 19 at device 17.0 on pci0
 sis1: Silicon Revision: DP83815D
 miibus1: <MII bus> on sis1
 ukphy1: <Generic IEEE 802.3u media interface> PHY 0 on miibus1
 ukphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
 sis1: Ethernet address: 00:09:5b:04:10:f8
 sis1: [ITHREAD]
 atapci1: <HighPoint HPT366 UDMA66 controller> port 0xcc00-0xcc07,0xd000-0xd003,0xd400-0xd4ff irq 18 at device 19.0 on pci0
 atapci1: [ITHREAD]
 ata2: <ATA channel 0> on atapci1
 ata2: [ITHREAD]
 atapci2: <HighPoint HPT366 UDMA66 controller> port 0xd800-0xd807,0xdc00-0xdc03,0xe000-0xe0ff irq 18 at device 19.1 on pci0
 atapci2: [ITHREAD]
 ata3: <ATA channel 0> on atapci2
 ata3: [ITHREAD]
 acpi_tz0: <Thermal Zone> on acpi0
 fdc0: <floppy drive controller> port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0
 fdc0: [FILTER]
 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
 sio0: type 16550A
 sio0: [FILTER]
 sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0
 sio1: type 16550A
 sio1: [FILTER]
 atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
 atkbd0: <AT Keyboard> irq 1 on atkbdc0
 kbd0 at atkbd0
 atkbd0: [GIANT-LOCKED]
 atkbd0: [ITHREAD]
 pmtimer0 on isa0
 orm0: <ISA Option ROMs> at iomem 0xc0000-0xc7fff,0xef000-0xeffff pnpid ORM0000 on isa0
 ppc0: parallel port not found.
 sc0: <System console> at flags 0x100 on isa0
 sc0: VGA <16 virtual consoles, flags=0x300>
 vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
 ums0: <Microsoft Microsoft Wheel Mouse Optical\M-., class 0/0, rev 1.10/1.21, addr 2> on uhub0
 ums0: 3 buttons and Z dir.
 Timecounters tick every 1.000 msec
 acd0: CDROM <SAMSUNG CD-ROM SC-148F/PS05> at ata0-master PIO4
 ad2: 38166MB <Seagate ST340016A 3.19> at ata1-master UDMA33
 SMP: AP CPU #1 Launched!
 Trying to mount root from ufs:/dev/ad2s1a
 sis0: Applying short cable fix (reg=ef)
 sis0: Applying short cable fix (reg=e8)
 sis0: Applying short cable fix (reg=e8)
 sis0: Applying short cable fix (reg=e8)
 sis0: Applying short cable fix (reg=e8)
 sis0: Applying short cable fix (reg=e8)
 
 > and the following when a bunch of network traffic has been generated:
 > 
 > vmstat -ia
 > netstat -i
 
 After 9 minutes of bidirectional activity, culminating in the receiving
 side failing:
 
 interrupt                          total       rate
 ???                                    0          0
 irq1: atkbd0                           0          0
 stray irq1                             0          0
 irq0:                                  0          0
 stray irq0                             0          0
 irq3: sio1                             0          0
 stray irq3                             0          0
 irq4: sio0                             0          0
 stray irq4                             0          0
 irq5:                                  0          0
 stray irq5                             0          0
 irq6: fdc0                             0          0
 stray irq6                             0          0
 irq7:                                  0          0
 stray irq7                             0          0
 irq8:                                  0          0
 stray irq8                             0          0
 irq9: acpi0                            0          0
 stray irq9                             0          0
 irq10:                                 0          0
 stray irq10                            0          0
 irq11:                                 0          0
 stray irq11                            0          0
 irq12:                                 0          0
 stray irq12                            0          0
 irq13:                                 0          0
 stray irq13                            0          0
 irq14: ata0                           57          0
 stray irq14                            0          0
 irq15: ata1                         1329          1
 stray irq15                            0          0
 irq16: sis0                      8296315       6285
 stray irq16                            0          0
 irq17:                                 0          0
 stray irq17                            0          0
 irq18: atapci1+                        0          0
 stray irq18                            0          0
 irq19: sis1 uhci0                      4          0
 stray irq19                            0          0
 irq20:                                 0          0
 stray irq20                            0          0
 irq21:                                 0          0
 stray irq21                            0          0
 irq22:                                 0          0
 stray irq22                            0          0
 irq23:                                 0          0
 stray irq23                            0          0
 cpu0: timer                      2637855       1998
 cpu1: timer                      2635648       1996
 Total                           13571208      10281
 
 Name    Mtu Network       Address              Ipkts Ierrs    Opkts Oerrs  Coll
 sis0   1500 <Link#1>      00:02:e3:16:ed:b0  5465231     0  5759894     0     0
 sis0   1500 10.0.1.0      10.0.1.122         5465224     -  5760193     -     -
 sis1*  1500 <Link#2>      00:09:5b:04:10:f8        0     0        0     0     0
 lo0   16384 <Link#3>                               0     0        0     0     0
 lo0   16384 fe80:3::1     fe80:3::1                0     -        0     -     -
 lo0   16384 localhost     ::1                      0     -        0     -     -
 lo0   16384 your-net      localhost                0     -        0     -     -
 
 > Also just a wild guess as the problems might be related: PR
 > kern/112179 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/112179
 > contains a patch, can you try if you see any difference with that
 > patch applied?
 
 Will do.
 
 -- 
 Thomas 'Freaky' Hurst
     http://hur.st/

From: Thomas Hurst <tom@hur.st>
To: Volker <volker@vwsoft.com>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/64556: [sis] if_sis short cable fix problems with NetGear
	FA311's
Date: Tue, 19 Feb 2008 02:04:34 +0000

 * Volker (volker@vwsoft.com) wrote:
 
 > Also just a wild guess as the problems might be related: PR
 > kern/112179 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/112179
 > contains a patch, can you try if you see any difference with that
 > patch applied?
 
 The patch doesn't appear to help at all, my last two runs failed in 4
 and 7.5 minutes, so potentially worse than it was.
 
 The short cable fix messages are different now:
 
 Feb 19 01:26:56 oldvoi kernel: sis0: Applying short cable fix (reg=f)
 Feb 19 01:26:56 oldvoi kernel: sis0: Applying short cable fix (reg=e)
 Feb 19 01:26:56 oldvoi last message repeated 2 times
 Feb 19 01:33:37 oldvoi kernel: sis0: Applying short cable fix (reg=ee)
 Feb 19 01:34:29 oldvoi kernel: sis0: Applying short cable fix (reg=e)
 Feb 19 01:35:28 oldvoi kernel: sis0: Applying short cable fix (reg=10)
 Feb 19 01:37:32 oldvoi kernel: sis0: Applying short cable fix (reg=e)
 Feb 19 01:39:03 oldvoi kernel: sis0: Applying short cable fix (reg=ec)
 Feb 19 01:40:02 oldvoi kernel: sis0: Applying short cable fix (reg=f)
 Feb 19 01:40:16 oldvoi kernel: sis0: Applying short cable fix (reg=ee)
 Feb 19 01:40:28 oldvoi kernel: sis0: Applying short cable fix (reg=ec)
 
 Note the lack of bursty several-in-a-second and the changing reg=
 values.  Compared with pre-patch:
 
 Feb 16 15:23:50 oldvoi kernel: sis0: Applying short cable fix (reg=e8)
 Feb 16 15:24:27 oldvoi last message repeated 2 times
 Feb 16 15:26:20 oldvoi last message repeated 11 times
 Feb 16 15:34:01 oldvoi last message repeated 26 times
 
 -- 
 Thomas 'Freaky' Hurst
     http://hur.st/

From: Bruce Cran <bruce@cran.org.uk>
To: bug-followup@FreeBSD.org, tom@hur.st
Cc:  
Subject: Re: kern/64556: [sis] if_sis short cable fix problems with NetGear
 FA311's
Date: Thu, 10 Sep 2009 02:24:17 +0100

 I'm still seeing this problem on 8.0-BETA4. Running two ttcp's (one rx,
 one tx) causes the system to print lots of "Applying short cable fix"
 messages.  I've had a look through the NetBSD driver, the original
 Linux driver from http://www.soekris.com/downloads.htm and also the
 latest Linux sources.  
 
 When the issue occurs, I see throughput drop to around 5Mb.  The first
 issues seems to be the 100ms delay. From the other code I've looked at,
 it looks like it should be 100us which would speed up the reset
 process. Secondly, it seems that only FreeBSD resets the chip when an
 RX overrun occurs; on NetBSD it does a printf and continues, and Linux
 increments the error statistics.  Both only apply the short cable fix
 when a media change occurs.
 
 -- 
 Bruce Cran

From: Bruce Cran <bruce.cran@gmail.com>
To: bug-followup@FreeBSD.org, tom@hur.st
Cc:  
Subject: Re: kern/64556: [sis] if_sis short cable fix problems with NetGear 
	FA311's
Date: Sat, 19 Sep 2009 13:52:43 +0100

 --0016e6dd98d78297b20473edb9f4
 Content-Type: text/plain; charset=ISO-8859-1
 
 The problem is caused when the CPU can't keep up with packet
 processing, causing an RX overrun to occur.  On a 1.2GHz AthlonXP
 based system I can get errors to occur if for example I run a grep
 over /usr/src - with a 500MHz CPU I guess it would have trouble
 keeping up at all.  With both ttcp's running, 50% of the CPU time is
 taken up processing interrupts from the card.  Not resetting the card
 when an error occurs seems to have no detrimental effect, so I've put
 together a patch which just logs the error in the if_ierrors interface
 field.   The patch also reduces the delay when setting the short cable
 fix from 100ms to 100us.
 
 -- 
 Bruce Cran
 
 --0016e6dd98d78297b20473edb9f4
 Content-Type: text/plain; charset=US-ASCII; name="if_sis.c.diff.txt"
 Content-Disposition: attachment; filename="if_sis.c.diff.txt"
 Content-Transfer-Encoding: base64
 X-Attachment-Id: f_fzscswvn0
 
 LS0tIHN5cy9kZXYvc2lzL2lmX3Npcy5jLm9yaWcJMjAwOS0wOS0xOCAyMDozMTo1My4wMDAwMDAw
 MDAgKzAxMDAKKysrIHN5cy9kZXYvc2lzL2lmX3Npcy5jCTIwMDktMDktMTkgMDI6NDI6NTcuMDAw
 MDAwMDAwICswMTAwCkBAIC0xNDgzLDE1ICsxNDgzLDYgQEAKIAlyZXR1cm4gKHJ4X25wa3RzKTsK
 IH0KIAotc3RhdGljIHZvaWQKLXNpc19yeGVvYyhzdHJ1Y3Qgc2lzX3NvZnRjICpzYykKLXsKLQot
 CVNJU19MT0NLX0FTU0VSVChzYyk7Ci0Jc2lzX3J4ZW9mKHNjKTsKLQlzaXNfaW5pdGwoc2MpOwot
 fQotCiAvKgogICogQSBmcmFtZSB3YXMgZG93bmxvYWRlZCB0byB0aGUgY2hpcC4gSXQncyBzYWZl
 IGZvciB1cyB0byBjbGVhbiB1cAogICogdGhlIGxpc3QgYnVmZmVycy4KQEAgLTE2MTQsNyArMTYw
 NSw3IEBACiAJCXN0YXR1cyA9IENTUl9SRUFEXzQoc2MsIFNJU19JU1IpOwogCiAJCWlmIChzdGF0
 dXMgJiAoU0lTX0lTUl9SWF9FUlJ8U0lTX0lTUl9SWF9PRkxPVykpCi0JCQlzaXNfcnhlb2Moc2Mp
 OworCQkJaWZwLT5pZl9pZXJyb3JzKys7CiAKIAkJaWYgKHN0YXR1cyAmIChTSVNfSVNSX1JYX0lE
 TEUpKQogCQkJU0lTX1NFVEJJVChzYywgU0lTX0NTUiwgU0lTX0NTUl9SWF9FTkFCTEUpOwpAQCAt
 MTY3Miw3ICsxNjYzLDcgQEAKIAkJCXNpc19yeGVvZihzYyk7CiAKIAkJaWYgKHN0YXR1cyAmIFNJ
 U19JU1JfUlhfT0ZMT1cpCi0JCQlzaXNfcnhlb2Moc2MpOworCQkJaWZwLT5pZl9pZXJyb3JzKys7
 CiAKIAkJaWYgKHN0YXR1cyAmIChTSVNfSVNSX1JYX0lETEUpKQogCQkJU0lTX1NFVEJJVChzYywg
 U0lTX0NTUiwgU0lTX0NTUl9SWF9FTkFCTEUpOwpAQCAtMjAxNyw3ICsyMDA4LDcgQEAKIAkJQ1NS
 X1dSSVRFXzQoc2MsIE5TX1BIWV9QQUdFLCAweDAwMDEpOwogCQlyZWcgPSBDU1JfUkVBRF80KHNj
 LCBOU19QSFlfRFNQQ0ZHKSAmIDB4ZmZmOwogCQlDU1JfV1JJVEVfNChzYywgTlNfUEhZX0RTUENG
 RywgcmVnIHwgMHgxMDAwKTsKLQkJREVMQVkoMTAwMDAwKTsKKwkJREVMQVkoMTAwKTsKIAkJcmVn
 ID0gQ1NSX1JFQURfNChzYywgTlNfUEhZX1REQVRBKSAmIDB4ZmY7CiAJCWlmICgocmVnICYgMHgw
 MDgwKSA9PSAwIHx8IChyZWcgPiAweGQ4ICYmIHJlZyA8PSAweGZmKSkgewogCQkJZGV2aWNlX3By
 aW50ZihzYy0+c2lzX2RldiwK
 --0016e6dd98d78297b20473edb9f4--

From: Bruce Cran <bruce.cran@gmail.com>
To: bug-followup@FreeBSD.org, tom@hur.st
Cc:  
Subject: Re: kern/64556: [sis] [patch] if_sis short cable fix problems with 
	NetGear FA311's
Date: Sat, 19 Sep 2009 14:21:58 +0100

 The patch is available from http://www.cran.org.uk/~brucec/freebsd/if_sis.c.diff
Responsible-Changed-From-To: freebsd-net->brucec  
Responsible-Changed-By: brucec 
Responsible-Changed-When: Fri Mar 5 19:17:55 UTC 2010 
Responsible-Changed-Why:  
Take. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=64556 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/64556: commit references a PR
Date: Tue, 20 Apr 2010 19:30:24 +0000 (UTC)

 Author: brucec
 Date: Tue Apr 20 19:30:12 2010
 New Revision: 206909
 URL: http://svn.freebsd.org/changeset/base/206909
 
 Log:
   It's not necessary to reset the chip every time an input overflow event
   occurs. In addition, the delay when programming the short cable fix
   should be 100us, not 100ms.
   
   PR:	kern/64556
   Submitted by:	Thomas Hurst <tom at hur.st>
   Approved by:	rrs (mentor)
   MFC after:	1 week
 
 Modified:
   head/sys/dev/sis/if_sis.c
 
 Modified: head/sys/dev/sis/if_sis.c
 ==============================================================================
 --- head/sys/dev/sis/if_sis.c	Tue Apr 20 18:46:00 2010	(r206908)
 +++ head/sys/dev/sis/if_sis.c	Tue Apr 20 19:30:12 2010	(r206909)
 @@ -1483,15 +1483,6 @@ sis_rxeof(struct sis_softc *sc)
  	return (rx_npkts);
  }
  
 -static void
 -sis_rxeoc(struct sis_softc *sc)
 -{
 -
 -	SIS_LOCK_ASSERT(sc);
 -	sis_rxeof(sc);
 -	sis_initl(sc);
 -}
 -
  /*
   * A frame was downloaded to the chip. It's safe for us to clean up
   * the list buffers.
 @@ -1614,7 +1605,7 @@ sis_poll(struct ifnet *ifp, enum poll_cm
  		status = CSR_READ_4(sc, SIS_ISR);
  
  		if (status & (SIS_ISR_RX_ERR|SIS_ISR_RX_OFLOW))
 -			sis_rxeoc(sc);
 +			ifp->if_ierrors++;
  
  		if (status & (SIS_ISR_RX_IDLE))
  			SIS_SETBIT(sc, SIS_CSR, SIS_CSR_RX_ENABLE);
 @@ -1672,7 +1663,7 @@ sis_intr(void *arg)
  			sis_rxeof(sc);
  
  		if (status & SIS_ISR_RX_OFLOW)
 -			sis_rxeoc(sc);
 +			ifp->if_ierrors++;
  
  		if (status & (SIS_ISR_RX_IDLE))
  			SIS_SETBIT(sc, SIS_CSR, SIS_CSR_RX_ENABLE);
 @@ -2017,7 +2008,7 @@ sis_initl(struct sis_softc *sc)
  		CSR_WRITE_4(sc, NS_PHY_PAGE, 0x0001);
  		reg = CSR_READ_4(sc, NS_PHY_DSPCFG) & 0xfff;
  		CSR_WRITE_4(sc, NS_PHY_DSPCFG, reg | 0x1000);
 -		DELAY(100000);
 +		DELAY(100);
  		reg = CSR_READ_4(sc, NS_PHY_TDATA) & 0xff;
  		if ((reg & 0x0080) == 0 || (reg > 0xd8 && reg <= 0xff)) {
  			device_printf(sc->sis_dev,
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: open->patched 
State-Changed-By: brucec 
State-Changed-When: Tue Apr 20 19:43:40 UTC 2010 
State-Changed-Why:  
A fix to remove the chip reset and reduce the delay  
has been committed to HEAD.  This should improve  
throughput, though the connection does still  
occasionally disconnect. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=64556 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/64556: commit references a PR
Date: Sat, 11 Sep 2010 14:18:37 +0000 (UTC)

 Author: brucec
 Date: Sat Sep 11 14:18:30 2010
 New Revision: 212468
 URL: http://svn.freebsd.org/changeset/base/212468
 
 Log:
   MFC r206909:
   
   It's not necessary to reset the chip every time an input overflow event
   occurs. In addition, the delay when programming the short cable fix
   should be 100us, not 100ms.
   
   PR:		kern/64556
   Approved by:	rrs (mentor)
 
 Modified:
   stable/8/sys/dev/sis/if_sis.c
 Directory Properties:
   stable/8/sys/   (props changed)
   stable/8/sys/amd64/include/xen/   (props changed)
   stable/8/sys/cddl/contrib/opensolaris/   (props changed)
   stable/8/sys/contrib/dev/acpica/   (props changed)
   stable/8/sys/contrib/pf/   (props changed)
   stable/8/sys/dev/xen/xenpci/   (props changed)
 
 Modified: stable/8/sys/dev/sis/if_sis.c
 ==============================================================================
 --- stable/8/sys/dev/sis/if_sis.c	Sat Sep 11 14:15:50 2010	(r212467)
 +++ stable/8/sys/dev/sis/if_sis.c	Sat Sep 11 14:18:30 2010	(r212468)
 @@ -1483,15 +1483,6 @@ sis_rxeof(struct sis_softc *sc)
  	return (rx_npkts);
  }
  
 -static void
 -sis_rxeoc(struct sis_softc *sc)
 -{
 -
 -	SIS_LOCK_ASSERT(sc);
 -	sis_rxeof(sc);
 -	sis_initl(sc);
 -}
 -
  /*
   * A frame was downloaded to the chip. It's safe for us to clean up
   * the list buffers.
 @@ -1614,7 +1605,7 @@ sis_poll(struct ifnet *ifp, enum poll_cm
  		status = CSR_READ_4(sc, SIS_ISR);
  
  		if (status & (SIS_ISR_RX_ERR|SIS_ISR_RX_OFLOW))
 -			sis_rxeoc(sc);
 +			ifp->if_ierrors++;
  
  		if (status & (SIS_ISR_RX_IDLE))
  			SIS_SETBIT(sc, SIS_CSR, SIS_CSR_RX_ENABLE);
 @@ -1672,7 +1663,7 @@ sis_intr(void *arg)
  			sis_rxeof(sc);
  
  		if (status & SIS_ISR_RX_OFLOW)
 -			sis_rxeoc(sc);
 +			ifp->if_ierrors++;
  
  		if (status & (SIS_ISR_RX_IDLE))
  			SIS_SETBIT(sc, SIS_CSR, SIS_CSR_RX_ENABLE);
 @@ -2017,7 +2008,7 @@ sis_initl(struct sis_softc *sc)
  		CSR_WRITE_4(sc, NS_PHY_PAGE, 0x0001);
  		reg = CSR_READ_4(sc, NS_PHY_DSPCFG) & 0xfff;
  		CSR_WRITE_4(sc, NS_PHY_DSPCFG, reg | 0x1000);
 -		DELAY(100000);
 +		DELAY(100);
  		reg = CSR_READ_4(sc, NS_PHY_TDATA) & 0xff;
  		if ((reg & 0x0080) == 0 || (reg > 0xd8 && reg <= 0xff)) {
  			device_printf(sc->sis_dev,
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/64556: commit references a PR
Date: Sat, 11 Sep 2010 14:21:08 +0000 (UTC)

 Author: brucec
 Date: Sat Sep 11 14:21:02 2010
 New Revision: 212469
 URL: http://svn.freebsd.org/changeset/base/212469
 
 Log:
   MFC r206909:
   
   It's not necessary to reset the chip every time an input overflow event
   occurs. In addition, the delay when programming the short cable fix
   should be 100us, not 100ms.
   
   PR:		kern/64556
   Submitted by:	Thomas Hurst <tom at hur.st>
   Approved by:	rrs (mentor)
 
 Modified:
   stable/7/sys/dev/sis/if_sis.c
 Directory Properties:
   stable/7/sys/   (props changed)
   stable/7/sys/cddl/contrib/opensolaris/   (props changed)
   stable/7/sys/contrib/dev/acpica/   (props changed)
   stable/7/sys/contrib/pf/   (props changed)
 
 Modified: stable/7/sys/dev/sis/if_sis.c
 ==============================================================================
 --- stable/7/sys/dev/sis/if_sis.c	Sat Sep 11 14:18:30 2010	(r212468)
 +++ stable/7/sys/dev/sis/if_sis.c	Sat Sep 11 14:21:02 2010	(r212469)
 @@ -1480,15 +1480,6 @@ sis_rxeof(struct sis_softc *sc)
  	sc->sis_rx_pdsc = cur_rx;
  }
  
 -static void
 -sis_rxeoc(struct sis_softc *sc)
 -{
 -
 -	SIS_LOCK_ASSERT(sc);
 -	sis_rxeof(sc);
 -	sis_initl(sc);
 -}
 -
  /*
   * A frame was downloaded to the chip. It's safe for us to clean up
   * the list buffers.
 @@ -1610,7 +1601,7 @@ sis_poll(struct ifnet *ifp, enum poll_cm
  		status = CSR_READ_4(sc, SIS_ISR);
  
  		if (status & (SIS_ISR_RX_ERR|SIS_ISR_RX_OFLOW))
 -			sis_rxeoc(sc);
 +			ifp->if_ierrors++;
  
  		if (status & (SIS_ISR_RX_IDLE))
  			SIS_SETBIT(sc, SIS_CSR, SIS_CSR_RX_ENABLE);
 @@ -1667,7 +1658,7 @@ sis_intr(void *arg)
  			sis_rxeof(sc);
  
  		if (status & SIS_ISR_RX_OFLOW)
 -			sis_rxeoc(sc);
 +			ifp->if_ierrors++;
  
  		if (status & (SIS_ISR_RX_IDLE))
  			SIS_SETBIT(sc, SIS_CSR, SIS_CSR_RX_ENABLE);
 @@ -2012,7 +2003,7 @@ sis_initl(struct sis_softc *sc)
  		CSR_WRITE_4(sc, NS_PHY_PAGE, 0x0001);
  		reg = CSR_READ_4(sc, NS_PHY_DSPCFG) & 0xfff;
  		CSR_WRITE_4(sc, NS_PHY_DSPCFG, reg | 0x1000);
 -		DELAY(100000);
 +		DELAY(100);
  		reg = CSR_READ_4(sc, NS_PHY_TDATA) & 0xff;
  		if ((reg & 0x0080) == 0 || (reg > 0xd8 && reg <= 0xff)) {
  			device_printf(sc->sis_dev,
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: patched->closed  
State-Changed-By: brucec 
State-Changed-When: Sat Sep 11 14:48:15 UTC 2010 
State-Changed-Why:  
Merged to stable/7 and stable/8. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=64556 
>Unformatted:
