--- Исходное сообщение --- От кого: [email protected] Кому: [email protected] Дата: Jun 19, 2009 15:00:24 Тема: freebsd-net Digest, Vol 324, Issue 5
Send freebsd-net mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 ([email protected]) > 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 <[email protected]> > Subject: Re: bge interrupt coalescing sysctls > To: Bruce Evans <[email protected]> > Cc: [email protected] > Message-ID: <[email protected]> > 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: "[email protected]" <[email protected]> > Subject: PRESSRELEASE MARK VOXX FEAT. MC GRACE ?? SUBMISSION?? -->> > OUTNOW > To: [email protected] > Message-ID: <[email protected]> > 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 <[email protected]> > Subject: Re: hostapd with 802.1X EAP-TLS/TTLS support > To: Vladimir Terziev <[email protected]> > Cc: [email protected], "Paul B. Mahol" <[email protected]> > Message-ID: <[email protected]> > 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 <[email protected]> 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. > > > > > > _______________________________________________ > > [email protected] mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "[email protected]" > > > > > > > > ------------------------------ > > Message: 4 > Date: Thu, 18 Jun 2009 21:10:19 +0200 (CEST) > From: Axel Reinhold <[email protected]> > Subject: Bridging and using the interfaces concurrently > To: [email protected] > Message-ID: <[email protected]> > 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 <[email protected]> > Subject: [msk] watchdog timeout (missed Tx interrupts) -- recovering > To: Pyun YongHyeon <[email protected]> > Cc: [email protected] > Message-ID: <[email protected]> > 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 <[email protected]> > Subject: Re: [msk] watchdog timeout (missed Tx interrupts) -- > recovering > To: Karim Fodil-Lemelin <[email protected]> > Cc: [email protected] > Message-ID: <[email protected]> > 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 <[email protected]> > Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx > interrupts) -- recovering > To: [email protected] > Message-ID: <[email protected]> > > The following reply was made to PR kern/124127; it has been noted by GNATS. > > From: Pyun YongHyeon <[email protected]> > To: Duckhawk <[email protected]> > Cc: [email protected] > 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 <[email protected]> > > To: [email protected], [email protected] > > 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 > > ms...@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 <[email protected]> > Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx > interrupts) -- recovering > To: [email protected] > Message-ID: <[email protected]> > > The following reply was made to PR kern/124127; it has been noted by GNATS. > > From: Pyun YongHyeon <[email protected]> > To: sam <[email protected]> > Cc: [email protected], [email protected] > 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 r...@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 <[email protected]> > Subject: Re: kern/132107: [carp] carp(4) advskew setting ignored when > carp IP used on a gif(4) interface > To: [email protected] > Message-ID: <[email protected]> > > The following reply was made to PR kern/132107; it has been noted by GNATS. > > From: Daniel Duerr <[email protected]> > To: [email protected], > [email protected] > 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 <[email protected]> > Subject: Re: Bridging and using the interfaces concurrently > To: Axel Reinhold <[email protected]> > Cc: [email protected] > Message-ID: <UpQ8uo5BGw7KTQV8lE1mo6DN/b...@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 <[email protected]> > Subject: mbuf layout optimizations > To: [email protected], [email protected] > Message-ID: <alpine.bsf.2.00.0906182307470.1...@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 <[email protected]> > Subject: Re: hostapd with 802.1X EAP-TLS/TTLS support > To: Sam Leffler <[email protected]> > Cc: [email protected], "Paul B. Mahol" <[email protected]> > Message-ID: <[email protected]> > 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 <[email protected]> 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. > > > > > > > > > _______________________________________________ > > > [email protected] mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > > To unsubscribe, send any mail to > > "[email protected]" > > > > > > > > > > > > > > > > > ------------------------------ > > _______________________________________________ > [email protected] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[email protected]" > > End of freebsd-net Digest, Vol 324, Issue 5 > ******************************************* > > С Уважением, Валерий. Сисадмин: Linux&FreeBSD 4+ mailto: [email protected] <a href ="http://madrid.in.ua";>Я все печатаю в типографии Мадрид</a> <a href ="http://skm.net.ua";>Мой провайдер Skyhome</a> _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[email protected]"
