freebsd-net Digest, Vol 324, Issue 5
Системный администратор
valeranew at ukr.net
Sat Jun 20 08:48:51 UTC 2009
--- Исходное сообщение ---
От кого: freebsd-net-request at freebsd.org
Кому: freebsd-net at freebsd.org
Дата: Jun 19, 2009 15:00:24
Тема: freebsd-net Digest, Vol 324, Issue 5
Send freebsd-net mailing list submissions to
> freebsd-net at freebsd.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> or, via email, send a message with subject or body 'help' to
> freebsd-net-request at freebsd.org
>
> You can reach the person managing the list at
> freebsd-net-owner at freebsd.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of freebsd-net digest..."
>
> Today's Topics:
>
> 1. Re: bge interrupt coalescing sysctls (Igor Sysoev)
> 2. PRESSRELEASE MARK VOXX FEAT. MC GRACE ?? SUBMISSION?? -->>
> OUTNOW (news at markvoxx.com)
> 3. Re: hostapd with 802.1X EAP-TLS/TTLS support (Sam Leffler)
> 4. Bridging and using the interfaces concurrently (Axel Reinhold)
> 5. [msk] watchdog timeout (missed Tx interrupts) -- recovering
> (Karim Fodil-Lemelin)
> 6. Re: [msk] watchdog timeout (missed Tx interrupts) --
> recovering (Pyun YongHyeon)
> 7. Re: kern/124127: [msk] watchdog timeout (missed Tx
> interrupts) -- recovering (Pyun YongHyeon)
> 8. Re: kern/124127: [msk] watchdog timeout (missed Tx
> interrupts) -- recovering (Pyun YongHyeon)
> 9. Re: kern/132107: [carp] carp(4) advskew setting ignored when
> carp IP used on a gif(4) interface (Daniel Duerr)
> 10. Re: Bridging and using the interfaces concurrently
> (Eygene Ryabinkin)
> 11. mbuf layout optimizations (Jeff Roberson)
> 12. Re: hostapd with 802.1X EAP-TLS/TTLS support (Vladimir Terziev)
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 18 Jun 2009 18:19:25 +0400
> From: Igor Sysoev <is at rambler-co.ru>
> Subject: Re: bge interrupt coalescing sysctls
> To: Bruce Evans <brde at optusnet.com.au>
> Cc: freebsd-net at FreeBSD.org
> Message-ID: <20090618141925.GG60354 at rambler-co.ru>
> Content-Type: text/plain; charset=koi8-r
>
> On Thu, Jun 11, 2009 at 11:54:29AM +1000, Bruce Evans wrote:
>
> > On Wed, 10 Jun 2009, Igor Sysoev wrote:
> >
> > >For a long time I used Bruce Evans' patch to tune bge interrupt coalescing:
> > >http://lists.freebsd.org/pipermail/freebsd-net/2007-November/015956.html
> > >However, recent commit SVN r192478 in 7-STABLE (r192127 in HEAD) had broken
> > >the patch. I'm not sure how to fix the collision, and since I do not
> > >use dynamic tuning
> >
> > That commit looked ugly (lots of internal API changes and bloat in interrupt
> > handlers in many network drivers to support polling which mostly shouldn't
> > be supported at all and mostly doesn't use the interrupt handlers).
> >
> > >I has left only static coalescing parameters in the patch
> > >and has added a loader tunable to set number of receive descriptors and
> > >read only sysctl to read the tunable. I usually use these parameters:
> > >
> > >/boot/loader.conf:
> > >hw.bge.rxd=512
> > >
> > >/etc/sysctl.conf:
> > >dev.bge.0.rx_coal_ticks=500
> > >dev.bge.0.tx_coal_ticks=10000
> > >dev.bge.0.rx_max_coal_bds=64
> >
> > These rx settings give to high a latency for me.
>
> Probably, however, I use this on a host that has 6000 packets/s.
>
> > >dev.bge.0.tx_max_coal_bds=128
> > ># apply the above parameters
> > >dev.bge.0.program_coal=1
> > >
> > >Could anyone commit it ?
> >
> > Not me, sorry.
> >
> > The patch is quite clean. If I committed then I would commit the
> > dynamic coalescing configuration separately anyway.
>
> So have you any objections if some one else will commit this patch ?
>
> > You can probably make hw.bge.rxd a sysctl too (it would take a down/up
> > to get it changed, but that is already needed for too many parameters
> > in network drivers anyway). I should use a sysctl for the ifq length
> > too. This could be done at a high level for each driver. Limiting
> > queue lengths may be a good way to reduce cache misses, while increasing
> > them is sometimes good for reducing packet loss.
>
> Do you mean simple command sequence:
>
> sysctl hw.bge.rxd=512
> ifconfig down
> ifconfig up
>
> or SYSCTL_ADD_PROC for hw.bge.rxd ?
>
> --
> Igor Sysoev
> http://sysoev.ru/en/
>
> ------------------------------
>
> Message: 2
> Date: Thu, 18 Jun 2009 16:52:30 +0100
> From: "news at markvoxx.com" <news at markvoxx.com>
> Subject: PRESSRELEASE MARK VOXX FEAT. MC GRACE ?? SUBMISSION?? -->>
> OUTNOW
> To: freebsd-net at freebsd.org
> Message-ID: <505656668421844159 at smtpa.netcabo.pt>
> Content-Type: text/plain ; charset="ISO-8859-1"
>
> Clica na imagem para ir para a loja do BeatPort <https://www.beatport.com/pt-BR/html/content/release/detail/172721/submission>!
> Click on the image to go to BeatPort <https://www.beatport.com/pt-BR/html/content/release/detail/172721/submission> Shop!
>
> <https://www.beatport.com/pt-BR/html/content/release/detail/172721/submission>
>
> <http://www.youtube.com/watch?v=QXG-bfjZb3s>
>
> www.myspace.com/djmarkvoxxproducer <http://www.myspace.com/djmarkvoxxproducer>
> www.myspace.com/themcgracespace <http://www.myspace.com/themcgracespace>
>
>
>
> To cancel your subscription to this newsletter, please reply to this message with the word REMOVE in the Subject line.
> Para cancelar a subscriзгo desta newsletter, por favor responde a esta mensagem com a palavra REMOVER no assunto.
>
> ------------------------------
>
> Message: 3
> Date: Thu, 18 Jun 2009 10:36:04 -0700
> From: Sam Leffler <sam at freebsd.org>
> Subject: Re: hostapd with 802.1X EAP-TLS/TTLS support
> To: Vladimir Terziev <vladimirt at partygaming.com>
> Cc: freebsd-net at freebsd.org, "Paul B. Mahol" <onemda at gmail.com>
> Message-ID: <4A3A7B04.2020906 at freebsd.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> EAP/TLS and TTLS should be configured by default in HEAD. Not sure what
> is done in RELENG_7. Regardless you can trivially rebuild hostapd w/
> the functionality you want by definitions to your src.conf:
>
> HOSTAPD_CFLAGS
> HOSTAPD_DPADD
> HOSTAPD_LDADD
>
> (looks like you use WPA_SUPPLICANT_* knobs in RELENG_7, check
> usr.sbin/wpa/hostapd/Makefile).
>
> As to what should be enabled by default, I can only say that I tried to
> choose the most common setup as the default. Choosing this
> configuration also balances between bloat and inclusion of code that
> might not be as well audited and/or tested as other code. Hence the
> default setup used to be WPA-PSK only but has since grown to include
> various EAP flavors. My assumption was that anyone building a system
> using these tools would want to go through and choose what they wanted
> anyway so enabling everything was a bad idea.
>
> Sam
>
> Vladimir Terziev wrote:
> > Hi Paul,
> >
> > is there some special reason behind this? Why the server is made part of
> > the main distribution with stripped functionality ?
> >
> > Also, how can i enable it ?
> >
> > Thanks,
> >
> > Vladimir
> >
> >
> > On Thu, 2009-06-18 at 13:55 +0300, Paul B. Mahol wrote:
> >
> >> On 6/18/09, Vladimir Terziev <vladimirt at partygaming.com> wrote:
> >>
> >>> Hi,
> >>>
> >>> i try to setup wireless access point at home, based on FreeBSD
> >>> 7.2R-i386, ral(4) wireless card and hostpad(8).
> >>>
> >>> I want my wireless AP to support 802.1x EAP-TLS/TTLS authentication.
> >>>
> >> I
> >>
> >>> issued a custom SSL certificate for the hostapd(8) and put the
> >>>
> >> following
> >>
> >>> directives in hostapd.conf:
> >>>
> >>> eap_server=0
> >>> ca_cert=/usr/local/etc/myCA.crt.pem
> >>> server_cert=/usr/local/etc/hostapd.server.crt.pem
> >>> private_key=/usr/local/etc/hostapd.server.key.pem
> >>> private_key_passwd=some_pass
> >>>
> >>> When i tried to start the hostapd(8) i got the following errors:
> >>>
> >>> Line 15: unknown configuration item 'eap_server'
> >>> Line 16: unknown configuration item 'ca_cert'
> >>> Line 17: unknown configuration item 'server_cert'
> >>> Line 18: unknown configuration item 'private_key'
> >>> Line 19: unknown configuration item 'private_key_passwd'
> >>>
> >>> Does the stock FreeBSD's hostapd(8) support 802.1X EAP-TLS/TTLS at
> >>>
> >> all
> >>
> >>> and if "not" why ?
> >>>
> >> 802.1X EAP-TLS/TTLS is not enabled by default on FreeBSD's hostapd(8).
> >>
> >> --
> >> Paul
> >>
> >>
> >>
> >
> > This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system.
> >
> > Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk.
> >
> >
> > _______________________________________________
> > freebsd-net at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
> >
> >
> >
>
> ------------------------------
>
> Message: 4
> Date: Thu, 18 Jun 2009 21:10:19 +0200 (CEST)
> From: Axel Reinhold <axel at freakout.de>
> Subject: Bridging and using the interfaces concurrently
> To: freebsd-net at freebsd.org
> Message-ID: <200906181910.n5IJAJ2u007974 at bongo.freakout.de>
> Content-Type: text/plain; format=text; x-action=sign;
> charset="US-ASCII"
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I have two FreeBSD-7.1 servers in a data-center hosted.
>
> Both servers have two em[01] gigabit network links.
> First server's (call it "first") em0 is connected to the data-centers
> internet uplink - the em1 is connected to the seconds servers
> (call it "second") em1.
>
> first's /etc/rc.conf:
> ifconfig_em0="inet 212.144.103.230 netmask 255.255.254.0"
> defaultrouter="212.144.102.1"
> ifconfig_em1="inet 192.168.102.1 netmask 255.255.255.0"
>
> seconds's /etc/rc.conf:
> ifconfig_em1="inet 192.168.102.131 netmask 255.255.255.0"
>
> In this way the 192.168.102/24 network is for private
> connection between the two servers and "second" is not connected
> to the internet at all.
>
> Since i would have to pay extra charges to get the "second"
> server also connected to the internet, i thought of bridging
> the em0 and em1 of "first" and to alias another ip for the
> second server (i have more ip's in the data-center left) on
> "seconds" em1.
>
> Is this possible? What would i have to setup?
> The private 192.168.102/24 network should remain intakt!
> I just want to bridge "seconds" em1-MAC to the data-centers
> switch-port which is connected to "first" em0.
>
> Any help? Or is this not possible?
>
> Axel
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9-PB (GNU/Linux)
>
> iD8DBQFKOpEIHQ9JwE2bDw0RAh9mAKCy2R7DAZYzqLfU/wKlwHiZWsQfAwCfUGne
> 7nsmXfuWgxyo+HAM76VRU6w=
> =LKp+
> -----END PGP SIGNATURE-----
>
> ------------------------------
>
> Message: 5
> Date: Thu, 18 Jun 2009 16:18:32 -0400
> From: Karim Fodil-Lemelin <kfl at xiplink.com>
> Subject: [msk] watchdog timeout (missed Tx interrupts) -- recovering
> To: Pyun YongHyeon <pyunyh at gmail.com>
> Cc: freebsd-net at freebsd.org
> Message-ID: <4A3AA118.9020609 at xiplink.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hello,
>
> Concerning this pr:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/124127, Given that I
> have one of those 'strange' silicon here:
>
> FreeBSD 7.1-RELEASE-p5 FreeBSD 7.1-RELEASE-p5
>
> kernel: mskc2: <Marvell Yukon 88E8052 Gigabit Ethernet> port 0xee00-0xeeff mem 0xfdafc000-0xfdafffff irq 18 at device 0.0 on pci3
> kernel: msk2: <Marvell Technology Group Ltd. Yukon EC Id 0xb6 Rev 0x02> on mskc2
> kernel: msk2: Ethernet address: 00:03:2d:10:4e:26
> kernel: miibus2: <MII bus> on msk2
> kernel: e1000phy2: <Marvell 88E1111 Gigabit PHY> PHY 0 on miibus2
> kernel: e1000phy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto
>
> Adding the entry: hw.msk.legacy_intr="1"to the loader.conf file solved
> the problem. But applying the attached patch (written by Pyun I believe)
> also solved the problem.
>
> I think your patch should be committed for others to benefit.
>
> Best regards,
>
> Karim.
>
> -------------- next part --------------
> Index: sys/dev/msk/if_msk.c
> ===================================================================
> --- sys/dev/msk/if_msk.c (revision 186497)
> +++ sys/dev/msk/if_msk.c (working copy)
> @@ -1355,27 +1355,25 @@
> CSR_WRITE_4(sc, STAT_LIST_ADDR_HI, MSK_ADDR_HI(addr));
> /* Set the status list last index. */
> CSR_WRITE_2(sc, STAT_LAST_IDX, MSK_STAT_RING_CNT - 1);
> - if (sc->msk_hw_id == CHIP_ID_YUKON_EC &&
> - sc->msk_hw_rev == CHIP_REV_YU_EC_A1) {
> - /* WA for dev. #4.3 */
> - CSR_WRITE_2(sc, STAT_TX_IDX_TH, ST_TXTH_IDX_MASK);
> - /* WA for dev. #4.18 */
> - CSR_WRITE_1(sc, STAT_FIFO_WM, 0x21);
> - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x07);
> - } else {
> - CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a);
> - CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10);
> - if (sc->msk_hw_id == CHIP_ID_YUKON_XL &&
> - sc->msk_hw_rev == CHIP_REV_YU_XL_A0)
> - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04);
> - else
> - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10);
> - CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, 0x0190);
> - }
> /*
> - * Use default value for STAT_ISR_TIMER_INI, STAT_LEV_TIMER_INI.
> + * Interrupt moderation and coalescing frames should be
> + * controllable with sysctl variables or loader tunables
> + * but the relationship between status updates and
> + * interrupt moderation are not clear. Some hardware
> + * revisions seem to very sensitive to these parameters
> + * and could be resulted in poor performance as well as
> + * non-working situation if improper values were chosen.
> */
> + CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a);
> + CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10);
> + if (sc->msk_hw_id == CHIP_ID_YUKON_XL &&
> + sc->msk_hw_rev == CHIP_REV_YU_XL_A0)
> + CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04);
> + else
> + CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10);
> CSR_WRITE_4(sc, STAT_TX_TIMER_INI, MSK_USECS(sc, 1000));
> + CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, MSK_USECS(sc, 30));
> + CSR_WRITE_4(sc, STAT_LEV_TIMER_INI, MSK_USECS(sc, 50));
>
> /* Enable status unit. */
> CSR_WRITE_4(sc, STAT_CTRL, SC_STAT_OP_ON);
> @@ -3586,6 +3584,10 @@
> domore = msk_handle_events(sc);
> if ((status & Y2_IS_STAT_BMU) != 0)
> CSR_WRITE_4(sc, STAT_CTRL, SC_STAT_CLR_IRQ);
> + if (CSR_READ_1(sc, STAT_TX_TIMER_CTRL) == TIM_START) {
> + CSR_WRITE_1(sc, STAT_TX_TIMER_CTRL, TIM_STOP);
> + CSR_WRITE_1(sc, STAT_TX_TIMER_CTRL, TIM_START);
> + }
>
> if (ifp0 != NULL && (ifp0->if_drv_flags & IFF_DRV_RUNNING) != 0 &&
> !IFQ_DRV_IS_EMPTY(&ifp0->if_snd))
>
> ------------------------------
>
> Message: 6
> Date: Fri, 19 Jun 2009 09:37:09 +0900
> From: Pyun YongHyeon <pyunyh at gmail.com>
> Subject: Re: [msk] watchdog timeout (missed Tx interrupts) --
> recovering
> To: Karim Fodil-Lemelin <kfl at xiplink.com>
> Cc: freebsd-net at freebsd.org
> Message-ID: <20090619003709.GF93360 at michelle.cdnetworks.co.kr>
> Content-Type: text/plain; charset=us-ascii
>
> On Thu, Jun 18, 2009 at 04:18:32PM -0400, Karim Fodil-Lemelin wrote:
> > Hello,
> >
>
> Hi,
>
> > Concerning this pr:
> > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/124127, Given that I
> > have one of those 'strange' silicon here:
> >
> > FreeBSD 7.1-RELEASE-p5 FreeBSD 7.1-RELEASE-p5
> >
> > kernel: mskc2: <Marvell Yukon 88E8052 Gigabit Ethernet> port 0xee00-0xeeff
> > mem 0xfdafc000-0xfdafffff irq 18 at device 0.0 on pci3
> > kernel: msk2: <Marvell Technology Group Ltd. Yukon EC Id 0xb6 Rev 0x02> on
> > mskc2
> > kernel: msk2: Ethernet address: 00:03:2d:10:4e:26
> > kernel: miibus2: <MII bus> on msk2
> > kernel: e1000phy2: <Marvell 88E1111 Gigabit PHY> PHY 0 on miibus2
> > kernel: e1000phy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX,
> > 1000baseTX-FDX, auto
> >
> > Adding the entry: hw.msk.legacy_intr="1"to the loader.conf file solved
> > the problem. But applying the attached patch (written by Pyun I believe)
> > also solved the problem.
> >
> > I think your patch should be committed for others to benefit.
> >
>
> Thanks a lot! I'll write a follow-up mail to the PR.
>
> > Best regards,
> >
> > Karim.
> >
> >
>
> ------------------------------
>
> Message: 7
> Date: Fri, 19 Jun 2009 00:40:05 GMT
> From: Pyun YongHyeon <pyunyh at gmail.com>
> Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx
> interrupts) -- recovering
> To: freebsd-net at FreeBSD.org
> Message-ID: <200906190040.n5J0e519069495 at freefall.freebsd.org>
>
> The following reply was made to PR kern/124127; it has been noted by GNATS.
>
> From: Pyun YongHyeon <pyunyh at gmail.com>
> To: Duckhawk <archi.kun at gmail.com>
> Cc: bug-followup at FreeBSD.org
> Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering
> Date: Fri, 19 Jun 2009 09:43:05 +0900
>
> --47eKBCiAZYFK5l32
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Sun, Feb 22, 2009 at 07:50:03AM +0000, Duckhawk wrote:
> > The following reply was made to PR kern/124127; it has been noted by GNATS.
> >
> > From: Duckhawk <archi.kun at gmail.com>
> > To: bug-followup at FreeBSD.org, skylord at linkline.ru
> > Cc:
> > Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) --
> > recovering
> > Date: Sun, 22 Feb 2009 12:26:51 +0500
> >
> > --001636c5a26744f2de04637ccfc6
> > Content-Type: text/plain; charset=ISO-8859-1
> > Content-Transfer-Encoding: 7bit
> >
> > also, same problem. D-Link DGE-560T
> >
> > %uname -a
> > FreeBSD 7.1-STABLE FreeBSD 7.1-STABLE #2: Sat Feb 21 08:32:29 YEKT 2009
> > duckhawk@:/usr/obj/usr/src/sys/GENERIC i386
> >
> > %dmesg | grep "msk"
> > mskc0: <D-Link 560T Gigabit Ethernet> port 0x7000-0x70ff mem
> > 0xfb000000-0xfb003fff irq 16 at device 0.0 on pci1
> > msk0: <Marvell Technology Group Ltd. Yukon EC Id 0xb6 Rev 0x02> on mskc0
> > msk0: Ethernet address: 00:1b:11:79:53:eb
> > miibus0: <MII bus> on msk0
> > mskc0: [FILTER]
> >
> > %pciconf -lv
> > mskc0 at pci0:1:0:0: class=0x020000 card=0x4b001186 chip=0x4b001186
> > rev=0x13 hdr=0x00
> > vendor = 'D-Link System Inc'
> > device = 'DGE-560T PCIe Gigabit Ethernet Adapter'
> > class = network
> > subclass = ethernet
>
> Please try the following patch.
>
> --47eKBCiAZYFK5l32
> Content-Type: text/x-diff; charset=us-ascii
> Content-Disposition: attachment; filename="msk.EC.patch"
>
> Index: sys/dev/msk/if_msk.c
> ===================================================================
> --- sys/dev/msk/if_msk.c (revision 194467)
> +++ sys/dev/msk/if_msk.c (working copy)
> @@ -1387,27 +1387,26 @@
> CSR_WRITE_4(sc, STAT_LIST_ADDR_HI, MSK_ADDR_HI(addr));
> /* Set the status list last index. */
> CSR_WRITE_2(sc, STAT_LAST_IDX, MSK_STAT_RING_CNT - 1);
> - if (sc->msk_hw_id == CHIP_ID_YUKON_EC &&
> - sc->msk_hw_rev == CHIP_REV_YU_EC_A1) {
> - /* WA for dev. #4.3 */
> - CSR_WRITE_2(sc, STAT_TX_IDX_TH, ST_TXTH_IDX_MASK);
> - /* WA for dev. #4.18 */
> - CSR_WRITE_1(sc, STAT_FIFO_WM, 0x21);
> - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x07);
> - } else {
> - CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a);
> - CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10);
> - if (sc->msk_hw_id == CHIP_ID_YUKON_XL &&
> - sc->msk_hw_rev == CHIP_REV_YU_XL_A0)
> - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04);
> - else
> - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10);
> - CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, 0x0190);
> - }
> /*
> - * Use default value for STAT_ISR_TIMER_INI, STAT_LEV_TIMER_INI.
> + * XXX
> + * Interrupt moderation and coalescing frames should be
> + * controllable with sysctl variables or loader tunables
> + * but the relationship between status updates and
> + * interrupt moderation are not clear to me. Some hardware
> + * revisions seem to very sensitive to these parameters
> + * and could be resulted in poor performance as well as
> + * non-working situation if improper values were chosen.
> */
> + CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a);
> + CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10);
> + if (sc->msk_hw_id == CHIP_ID_YUKON_XL &&
> + sc->msk_hw_rev == CHIP_REV_YU_XL_A0)
> + CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04);
> + else
> + CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10);
> CSR_WRITE_4(sc, STAT_TX_TIMER_INI, MSK_USECS(sc, 1000));
> + CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, MSK_USECS(sc, 30));
> + CSR_WRITE_4(sc, STAT_LEV_TIMER_INI, MSK_USECS(sc, 50));
>
> /* Enable status unit. */
> CSR_WRITE_4(sc, STAT_CTRL, SC_STAT_OP_ON);
>
> --47eKBCiAZYFK5l32--
>
> ------------------------------
>
> Message: 8
> Date: Fri, 19 Jun 2009 00:50:06 GMT
> From: Pyun YongHyeon <pyunyh at gmail.com>
> Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx
> interrupts) -- recovering
> To: freebsd-net at FreeBSD.org
> Message-ID: <200906190050.n5J0o6PN076484 at freefall.freebsd.org>
>
> The following reply was made to PR kern/124127; it has been noted by GNATS.
>
> From: Pyun YongHyeon <pyunyh at gmail.com>
> To: sam <samflanker at gmail.com>
> Cc: yongari at freebsd.org, bug-followup at FreeBSD.org
> Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering
> Date: Fri, 19 Jun 2009 09:40:46 +0900
>
> --pQhZXvAqiZgbeUkD
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Thu, Jul 31, 2008 at 04:06:42PM +0400, sam wrote:
> > -----------------------------------------------
> > Jul 30 11:13:47 moon3 kernel: msk0: watchdog timeout (missed Tx
> > interrupts) -- recovering
> > Jul 30 11:14:44 moon3 kernel: msk0: watchdog timeout (missed Tx
> > interrupts) -- recovering
> > -----------------------------------------------
> >
> > -----------------------------------------------
> > Jul 29 23:18:28 moon3 kernel: mskc0: <Marvell Yukon 88E8050 Gigabit
> > Ethernet> port 0xdf00-0xdfff mem 0xdeefc000-0xdeefffff irq 16 at device
> > 0.0 on pci2
> > Jul 29 23:18:28 moon3 kernel: msk0: <Marvell Technology Group Ltd.
> > Yukon EC Id 0xb6 Rev 0x02> on mskc0
> >
> > Jul 29 23:18:28 moon3 kernel: miibus0: <MII bus> on msk0
> > -----------------------------------------------
> >
> > -----------------------------------------------
> > FreeBSD moon3 7.0-RELEASE-p2 FreeBSD 7.0-RELEASE-p2 #5: Wed Jul 27
> > 15:00:14 MSD 2008 root at moon3:/usr/src/sys/i386/compile/MOON3 i386
> > -----------------------------------------------
> >
> > I confirm this problem.
> >
> > /Vladimir Ermakov
> >
> >
>
> Would you try attached patch and let me know hot it goes?
>
> --pQhZXvAqiZgbeUkD
> Content-Type: text/x-diff; charset=us-ascii
> Content-Disposition: attachment; filename="msk.EC.patch"
>
> Index: sys/dev/msk/if_msk.c
> ===================================================================
> --- sys/dev/msk/if_msk.c (revision 194467)
> +++ sys/dev/msk/if_msk.c (working copy)
> @@ -1387,27 +1387,26 @@
> CSR_WRITE_4(sc, STAT_LIST_ADDR_HI, MSK_ADDR_HI(addr));
> /* Set the status list last index. */
> CSR_WRITE_2(sc, STAT_LAST_IDX, MSK_STAT_RING_CNT - 1);
> - if (sc->msk_hw_id == CHIP_ID_YUKON_EC &&
> - sc->msk_hw_rev == CHIP_REV_YU_EC_A1) {
> - /* WA for dev. #4.3 */
> - CSR_WRITE_2(sc, STAT_TX_IDX_TH, ST_TXTH_IDX_MASK);
> - /* WA for dev. #4.18 */
> - CSR_WRITE_1(sc, STAT_FIFO_WM, 0x21);
> - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x07);
> - } else {
> - CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a);
> - CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10);
> - if (sc->msk_hw_id == CHIP_ID_YUKON_XL &&
> - sc->msk_hw_rev == CHIP_REV_YU_XL_A0)
> - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04);
> - else
> - CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10);
> - CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, 0x0190);
> - }
> /*
> - * Use default value for STAT_ISR_TIMER_INI, STAT_LEV_TIMER_INI.
> + * XXX
> + * Interrupt moderation and coalescing frames should be
> + * controllable with sysctl variables or loader tunables
> + * but the relationship between status updates and
> + * interrupt moderation are not clear to me. Some hardware
> + * revisions seem to very sensitive to these parameters
> + * and could be resulted in poor performance as well as
> + * non-working situation if improper values were chosen.
> */
> + CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a);
> + CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10);
> + if (sc->msk_hw_id == CHIP_ID_YUKON_XL &&
> + sc->msk_hw_rev == CHIP_REV_YU_XL_A0)
> + CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04);
> + else
> + CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10);
> CSR_WRITE_4(sc, STAT_TX_TIMER_INI, MSK_USECS(sc, 1000));
> + CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, MSK_USECS(sc, 30));
> + CSR_WRITE_4(sc, STAT_LEV_TIMER_INI, MSK_USECS(sc, 50));
>
> /* Enable status unit. */
> CSR_WRITE_4(sc, STAT_CTRL, SC_STAT_OP_ON);
>
> --pQhZXvAqiZgbeUkD--
>
> ------------------------------
>
> Message: 9
> Date: Fri, 19 Jun 2009 07:10:02 GMT
> From: Daniel Duerr <dd at justlinuxhosting.com>
> Subject: Re: kern/132107: [carp] carp(4) advskew setting ignored when
> carp IP used on a gif(4) interface
> To: freebsd-net at FreeBSD.org
> Message-ID: <200906190710.n5J7A2cD078751 at freefall.freebsd.org>
>
> The following reply was made to PR kern/132107; it has been noted by GNATS.
>
> From: Daniel Duerr <dd at justlinuxhosting.com>
> To: bug-followup at FreeBSD.org,
> adaugherity at tamu.edu
> Cc:
> Subject: Re: kern/132107: [carp] carp(4) advskew setting ignored when carp IP used on a gif(4) interface
> Date: Thu, 18 Jun 2009 23:51:09 -0700
>
> Having the same issue here and the workaround isn't working for me --
> it preserves the advskew but the vpn doesn't seem to work without the
> devd attach event. Hope someone will fix this soon.
>
>
>
>
> ------------------------------
>
> Message: 10
> Date: Fri, 19 Jun 2009 12:55:03 +0400
> From: Eygene Ryabinkin <rea-fbsd at codelabs.ru>
> Subject: Re: Bridging and using the interfaces concurrently
> To: Axel Reinhold <axel at freakout.de>
> Cc: freebsd-net at freebsd.org
> Message-ID: <UpQ8uo5BGw7KTQV8lE1mo6DN/bA at hJhSod24P8TdBWT2Rda0vGnf2ew>
> Content-Type: text/plain; charset=us-ascii
>
> Axel, good day.
>
> Thu, Jun 18, 2009 at 09:10:19PM +0200, Axel Reinhold wrote:
> > Since i would have to pay extra charges to get the "second"
> > server also connected to the internet, i thought of bridging
> > the em0 and em1 of "first" and to alias another ip for the
> > second server (i have more ip's in the data-center left) on
> > "seconds" em1.
> >
> > Is this possible? What would i have to setup?
> > The private 192.168.102/24 network should remain intakt!
>
> NAT the "second" box on your "first" one and that's it. Bridging
> won't help much here, because your "second"s IPs are unroutable, so
> someone will still need to translate them. If your intention is to
> provide only client-level connectivity to the "second" box (when it
> initiates all connections), simple NAT will work. If you need some
> port to be opened at the "second" host and the should be reachable
> from the outside, then you'll additionally need port mirroring.
>
> Or, if you really want to spend an extra IP for the second box, then
> just binat (in the terms of pf.conf(5)) your private address to the
> second IP on the "first" server.
>
> The exact solution for NAT depends on the firewall type you're using on
> the "first" server. For ipfw you probably should look at the natd(8),
> for ipfilter -- at ipnat(8), for pf -- at pf(4) and pf.conf(5). May be
> netgraph(4) will be of some help, but this adds some extra complexity
> for people who aren't familiar with Netgraph concepts and tools.
>
> If you really want bridging, then the easiest thing will be to create
> two VLAN (if_vlan(4)) interfaces on your link between two servers: one
> VLAN for the 192.168.102/24 network and one for the public network.
> After this, packets from 192.168 will flow as they flowed before, and
> you should bridge your "first"'s external interface with the second VLAN
> interface on this host. Put your extra external IP to the other side of
> the VLAN interface and it should do what you need.
>
> NAT should be easier, bridging should be faster, but the difference
> strongly depends on the type of traffic and usage of the inter-server
> link.
> --
> Eygene
> _ ___ _.--. #
> \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard
> / ' ` , __.--' # to read the on-line manual
> )/' _/ \ `-_, / # while single-stepping the kernel.
> `-'" `"\_ ,_.-;_.-\_ ', fsc/as #
> _.-'_./ {_.' ; / # -- FreeBSD Developers handbook
> {_.-``-' {_/ #
>
> ------------------------------
>
> Message: 11
> Date: Thu, 18 Jun 2009 23:12:45 -1000 (HST)
> From: Jeff Roberson <jroberson at jroberson.net>
> Subject: mbuf layout optimizations
> To: net at freebsd.org, current at freebsd.org
> Message-ID: <alpine.BSF.2.00.0906182307470.1025 at desktop>
> Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
>
> http://people.freebsd.org/~jeff/mbuf2.diff
>
> Hello,
>
> This is a call for testers and feedback on my mbuf layout improvements.
> I'm trying to decide whether I will push to have these included in 8.0.
> After reducing the scope slightly from my last patch, I have not
> encountered any problems. Kip Macy has also been using it for the past
> few weeks without issue.
>
> You should not expect any functional changes from this patch. The goal
> is mostly to pave the way fors more sensible mbuf handling in the future,
> although it does offer a few performance benefits.
>
> The only issue is that cxgb support requires another set of patches from
> Kip. If anyone needs those I will prod him to reply with that diff.
>
> Thanks,
> Jeff
>
> ------------------------------
>
> Message: 12
> Date: Fri, 19 Jun 2009 13:55:26 +0300
> From: Vladimir Terziev <vladimirt at partygaming.com>
> Subject: Re: hostapd with 802.1X EAP-TLS/TTLS support
> To: Sam Leffler <sam at freebsd.org>
> Cc: freebsd-net at freebsd.org, "Paul B. Mahol" <onemda at gmail.com>
> Message-ID: <1245408926.31855.26.camel at daemon2.partygaming.local>
> Content-Type: text/plain
>
> Thanks Sam,
>
> What should i put for HOSTAPD_CFLAGS, HOSTAPD_DPADD, HOSTAPD_LDADD or
> WPA_SUPPLICANT_* (not sure which ones i should use) in order to get
> hostapd rebuilt with the functionality i want ?
>
> Regards,
>
> Vladimir
>
> On Thu, 2009-06-18 at 20:36 +0300, Sam Leffler wrote:
> > EAP/TLS and TTLS should be configured by default in HEAD. Not sure
> > what
> > is done in RELENG_7. Regardless you can trivially rebuild hostapd w/
> > the functionality you want by definitions to your src.conf:
> >
> > HOSTAPD_CFLAGS
> > HOSTAPD_DPADD
> > HOSTAPD_LDADD
> >
> > (looks like you use WPA_SUPPLICANT_* knobs in RELENG_7, check
> > usr.sbin/wpa/hostapd/Makefile).
> >
> > As to what should be enabled by default, I can only say that I tried
> > to
> > choose the most common setup as the default. Choosing this
> > configuration also balances between bloat and inclusion of code that
> > might not be as well audited and/or tested as other code. Hence the
> > default setup used to be WPA-PSK only but has since grown to include
> > various EAP flavors. My assumption was that anyone building a system
> > using these tools would want to go through and choose what they wanted
> > anyway so enabling everything was a bad idea.
> >
> > Sam
> >
> >
> > Vladimir Terziev wrote:
> > > Hi Paul,
> > >
> > > is there some special reason behind this? Why the server is made
> > part of
> > > the main distribution with stripped functionality ?
> > >
> > > Also, how can i enable it ?
> > >
> > > Thanks,
> > >
> > > Vladimir
> > >
> > >
> > > On Thu, 2009-06-18 at 13:55 +0300, Paul B. Mahol wrote:
> > >
> > >> On 6/18/09, Vladimir Terziev <vladimirt at partygaming.com> wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> i try to setup wireless access point at home, based on FreeBSD
> > >>> 7.2R-i386, ral(4) wireless card and hostpad(8).
> > >>>
> > >>> I want my wireless AP to support 802.1x EAP-TLS/TTLS
> > authentication.
> > >>>
> > >> I
> > >>
> > >>> issued a custom SSL certificate for the hostapd(8) and put the
> > >>>
> > >> following
> > >>
> > >>> directives in hostapd.conf:
> > >>>
> > >>> eap_server=0
> > >>> ca_cert=/usr/local/etc/myCA.crt.pem
> > >>> server_cert=/usr/local/etc/hostapd.server.crt.pem
> > >>> private_key=/usr/local/etc/hostapd.server.key.pem
> > >>> private_key_passwd=some_pass
> > >>>
> > >>> When i tried to start the hostapd(8) i got the following errors:
> > >>>
> > >>> Line 15: unknown configuration item 'eap_server'
> > >>> Line 16: unknown configuration item 'ca_cert'
> > >>> Line 17: unknown configuration item 'server_cert'
> > >>> Line 18: unknown configuration item 'private_key'
> > >>> Line 19: unknown configuration item 'private_key_passwd'
> > >>>
> > >>> Does the stock FreeBSD's hostapd(8) support 802.1X EAP-TLS/TTLS at
> > >>>
> > >> all
> > >>
> > >>> and if "not" why ?
> > >>>
> > >> 802.1X EAP-TLS/TTLS is not enabled by default on FreeBSD's
> > hostapd(8).
> > >>
> > >> --
> > >> Paul
> > >>
> > >>
> > >>
> > >
> > > This email and any attachments are confidential, and may be legally
> > privileged and protected by copyright. If you are not the intended
> > recipient dissemination or copying of this email is prohibited. If you
> > have received this in error, please notify the sender by replying by
> > email and then delete the email completely from your system.
> > >
> > > Any views or opinions are solely those of the sender. This
> > communication is not intended to form a binding contract unless
> > expressly indicated to the contrary and properly authorised. Any
> > actions taken on the basis of this email are at the recipient's own
> > risk.
> > >
> > >
> > > _______________________________________________
> > > freebsd-net at freebsd.org mailing list
> > > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > > To unsubscribe, send any mail to
> > "freebsd-net-unsubscribe at freebsd.org"
> > >
> > >
> > >
> >
> >
> >
>
> ------------------------------
>
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>
> End of freebsd-net Digest, Vol 324, Issue 5
> *******************************************
>
>
С Уважением, Валерий.
Сисадмин: Linux&FreeBSD 4+
mailto: wel at skm.net.ua
<a href ="http://madrid.in.ua">Я все печатаю в типографии Мадрид</a>
<a href ="http://skm.net.ua">Мой провайдер Skyhome</a>
More information about the freebsd-net
mailing list