Subject: Re: sip(4) MII probe change made two weeks ago
To: None <current-users@NetBSD.org, christianbiere@gmx.de>
From: None <cube@cubidou.net>
List: current-users
Date: 05/27/2004 16:20:22
On Thu, May 27, 2004 at 03:02:37PM +0200, Christian Biere wrote:
> Bill Studenmund wrote:
> > > sip0 at pci0 dev 3 function 0: SiS 900 10/100 Ethernet, rev 0x90
> > > sip0: interrupting at ioapic0 pin 22 (irq 10)
> > > sip0: Ethernet address 00:07:95:a9:a5:7f
> > > ukphy0 at sip0 phy 1: Generic IEEE 802.3u media interface
> > > ukphy0: OUI 0x000004, model 0x0020, rev. 1
> > > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
>  
> > Is your interface stable under load? Mine always falls over if I do 
> > serious NFS.
> 
> It has been pretty stable until I applied the patch from kern/25110.

It should be read 'since' instead of 'until', right?

> Since then I haven't had a single problem with it. Before that I
> often got "sip0: device timeout" and had to reboot the machine to
> make it work again. Though, the highest traffic the interface sees is
> about 200 Kilobyte/s over scp because the remote machine is rather slow.
> I also use 10BaseT because 100BaseTX gains worse rates here. That could
> be the wire or the RealTek on the remote side, of course.

I haven't committed the patch in kern/25110 yet because I'm not entirely
satisfied with it.  The whole point of having tresholds is to be able to
change them depending on load to reduce CPU usage and such.

In revision 1.53, sc_tx_drain_thresh was set to 1024, but I think it was
a wrong fix.  The sip(4) driver wasn't following the docs over the value
for sc_tx_fill_thresh, which has to be set to at least the maximum size
of DMA transfers.  This is according to the DP83815 documentations, this
there isn't any public documentation about the SiS chips.

The thing is, still according to the docs, drain_tresh+fill_tresh must
not exceed 2016.  That is 1504+512.  That means that with the patch in
kern/25110 the tresholds cannot be changed anymore, and that code in the
ISR is useless.

Since kern/16010 describes a gsip issue, I'd rather compare the docs
for DP83151 and DP83820 on that point, to see if there are any
differences in how those values (not only the initial ones, but also
when they're changed) should be handled.

Quentin Garnier.