Date: Mon, 21 Jan 2002 18:01:48 -0600 From: Jonathan Lemon <jlemon@flugsvamp.com> To: Marko Zec <zec@tel.fer.hr> Cc: "jlemon@freebsd.org" <jlemon@freebsd.org>, Jun Kuriyama <kuriyama@imgsrc.co.jp>, freebsd-stable@freebsd.org Subject: Re: if_fxp.c typo? Message-ID: <20020121180148.U59128@prism.flugsvamp.com> In-Reply-To: <3C4CA33C.BAD0F33B@tel.fer.hr> References: <86y9kzqjlr.wl@keiichi01.osaka.iij.ad.jp> <7mn10ebxbp.wl@waterblue.imgsrc.co.jp> <3C4CA33C.BAD0F33B@tel.fer.hr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 22, 2002 at 12:24:44AM +0100, Marko Zec wrote:
> Hope this patch properly resolves the problem of unwanted resets of mcast
> filters. However, when unloading the microcode, it is unavoidable to clear
> the mcast filters, without making the code really complicated. This should
> be probably stated in man-page as a kind of disclaimer...
> Also, by this diff I suggest imposing a little bit more sane range limits
> for int_delay and bundle_max.
The multicast filter problem has already been resolved in r1.126 of
the driver, by reloading the multicast filters on initialization.
The value for bundle_max is explicitly allowed to go to 0xffff, from
the Intel rcvbundl.h documentations:
* .... If you do not want to put
* a limit on the bundle size, set this value to xFFFF.
The value for int_range is also correct, again from the Intel code:
* .... The current default is either x600 or x800;
* experiments show that the value probably should stay within the
* range of x200 - x1000.
There is an internal multiplier of 1.5 for the values, so a range of
300 - 3000 translates into 0x1C2 - 0x1194, with a default value of 0x5DC,
which is "close enough".
--
Jonathan
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020121180148.U59128>