Modem + Network in Xircom cards, and maybe others

[Bruce Evans]

On Wed, 5 May 2004, Carlos Velasco wrote:

> On 02/05/2004 at 22:24 Carlos Velasco wrote:
>
> >On 02/05/2004 at 9:14 M. Warner Losh wrote:
> >
> >>: sio4: 118 more interrupt-level buffer overflows (total 118)
> >>: sio4: 162 more interrupt-level buffer overflows (total 280)
> >>
> >>That may be due to the MFC interrupt issue that I talked about.  But
> >>it could be something else...
> >
> >I have tried playing with pccard_intr but it doesn't work.
> >I'm reading about a patch for sio.c in the list, i don't know if it can
> >helps into this I will try it in near future and see the results.
>
> Well... this didn't work.
>
> However I googled and found this:
> http://lists.freebsd.org/pipermail/freebsd-bugs/2003-May/000687.html
>
> Applying it solves problem for me.
> Could we commit this in sio.c until GIANT solve work is done?
>
> This is my complete patch (it works for me), including sio change and also
> pccard 64k alignment:

It seems like a patch for MFC sincd it has mfc's in it (what is a MFC?).

> diff -ru sys/dev/sio/sio.c sysnew/dev/sio/sio.c
> --- sys/dev/sio/sio.c	Mon May  3 22:35:28 2004
> +++ sysnew/dev/sio/sio.c	Wed May  5 13:04:14 2004
> @@ -2374,7 +2374,7 @@
>  	 * (about 3 ticks if input flow control is not used or not honoured,
>  	 * but a bit less for CS5-CS7 modes).
>  	 */
> -	cp4ticks = speed / 10 / hz * 4;
> +	cp4ticks = speed / 10 / hz * 40;
>  	for (ibufsize = 128; ibufsize < cp4ticks;)
>  		ibufsize <<= 1;
>  	if (ibufsize == com->ibufsize) {

However, you may need only this part of it.  This part permits software
interrupts to be delayed by 38 ticks instead of the expected maximim
of 2 ticks.  I keep forgetting to fix this.  Scaling by hz is not quite
right, because hz may be set to values that are too small to work all
the time or even most of the time.  There is a clamp to 128 (min), but
this is a bit small.  E.g., with hz = 1000 and speed = 115200, the
original code in the above gives cp4ticks = 44 and ibufsize = 128.  If
hz = 1000 actually worked, then the buffer would be drained every 1
msec and would never have more than 12 characters in it, but the
software interrupt latency is apparently sometimes >= 12 msec so the
buffer overflows.  There are some mii Giant hogs which sometimes delay
timeout processing for that long or nearly so (each).

sio's software interrupt[s] should have a priority higher than timeouts,
but sio now has 2 software interrupts with one of them having the same
low priority as timeouts.  This priority should work (in fact, old
versions of sio just use timeouts), but in RELENG_4 the priority is
much higher than that as a side effect of having only only the correct
number of SWIs (1).  RELENG_4 may now depend on this.

Bruce