Re: [ed] link state constantly going down and up

2009/4/29 M. Warner Losh > : I have a problem with a D-Link DFE-670TXD which is handled by if_ed : > : the link state is constantly going down and up : > : Apr 28 14:21:33 iut-mir-o kernel: ed0: link state changed to DOWN > : Apr 28 14:21:35 iut-mir-o kernel: ed0: link state changed to UP > ... >

Re: [ed] link state constantly going down and up

In message: <261c2970090434k4bc02635m2729a0a54c09c...@mail.gmail.com> Miki writes: : 2009/4/29 M. Warner Losh : : > : I have a problem with a D-Link DFE-670TXD which is handled by if_ed : : > : the link state is constantly going down and up : : > : Apr 28 14:21:33 iut-mir-o kerne

Re: [ed] link state constantly going down and up

2009/4/30 M. Warner Losh > In message: <261c2970090434k4bc02635m2729a0a54c09c...@mail.gmail.com> >Miki writes: > : 2009/4/29 M. Warner Losh > : > : > : I have a problem with a D-Link DFE-670TXD which is handled by if_ed : > : > : the link state is constantly going down and up :

Re: [ed] link state constantly going down and up

In message: <261c29700904300029s6757d39ei86fbf69ef816f...@mail.gmail.com> Miki writes: : 2009/4/30 M. Warner Losh : : > In message: <261c2970090434k4bc02635m2729a0a54c09c...@mail.gmail.com> : >Miki writes: : > : 2009/4/29 M. Warner Losh : > : : > : > : I have a prob

bce(4) and lagg(4) fix [was: bce(4) sees all incoming frames as 2026 bytes in length]

On Apr 30, 2009, at 2:56 PM, Nikolay Denev wrote: On Apr 29, 2009, at 7:04 PM, pluknet wrote: 2009/4/29 Niki Denev : bce1: mem 0xf800-0xf9ff irq 16 at device 0.0 on pci3 bce1: Ethernet address: 00:22:19:xx:xx:xx bce1: [ITHREAD] bce1: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit,

Re: bce(4) sees all incoming frames as 2026 bytes in length

On Apr 29, 2009, at 7:04 PM, pluknet wrote: 2009/4/29 Niki Denev : bce1: mem 0xf800-0xf9ff irq 16 at device 0.0 on pci3 bce1: Ethernet address: 00:22:19:xx:xx:xx bce1: [ITHREAD] bce1: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (0x04040105); Flags( MFW MSI ) bce1: f

Re: bce(4) and lagg(4) fix [was: bce(4) sees all incoming frames as 2026 bytes in length]

On Apr 30, 2009, at 3:04 PM, Nikolay Denev wrote: [snip] I think I got it. It seems that the mbuf fields m_pkthdr.len and m_len are not updated to the real packet size pkt_len. Well, actually they are updated, but only if we have ZERO_COPY_SOCKETS defined. After I added this : m0->m_p

Re: bce(4) sees all incoming frames as 2026 bytes in length

2009/4/30 Nikolay Denev : > On Apr 29, 2009, at 7:04 PM, pluknet wrote: > >> 2009/4/29 Niki Denev : >> >>> bce1: mem >>> 0xf800-0xf9ff irq 16 at device 0.0 on pci3 >>> bce1: Ethernet address: 00:22:19:xx:xx:xx >>> bce1: [ITHREAD] >>> bce1: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 1

Re: [ed] link state constantly going down and up

2009/4/30 M. Warner Losh > In message: <261c29700904300029s6757d39ei86fbf69ef816f...@mail.gmail.com> > Miki writes: > : 2009/4/30 M. Warner Losh > : > : > In message: < > 261c2970090434k4bc02635m2729a0a54c09c...@mail.gmail.com> > : >Miki writes: > : > : 2009/4/29 M.

Re: bce(4) and lagg(4) fix [was: bce(4) sees all incoming frames as 2026 bytes in length]

2009/4/30 Nikolay Denev : > On Apr 30, 2009, at 3:04 PM, Nikolay Denev wrote: > [snip] >>> >>> I think I got it. >>> >>> It seems that the mbuf fields m_pkthdr.len and m_len are not updated to >>> the real packet size pkt_len. >>> Well, actually they are updated, but only if we have ZERO_COPY_SOCKE

Re: Interrupts + Polling mode (similar to Linux's NAPI)

2009/4/29 Erik Trulsson : > That appearance is probably due to the fact the the FreeBSD project actually > is a bunch of dudes working on what they feel like doing (or in a few cases > on what they get paid for doing), and that there is very little centralized > planning being done. (And even if th

Re: Interrupts + Polling mode (similar to Linux's NAPI)

2009/4/30 Barney Cordoba : > Its one of the sad truths of FreeBSD. You'd think with such a large number > of commercial users you'd be able to get plenty of funding for the things > that really need to be done, rather then taking whatever bread crumbs > are thrown your way. Perhaps you need fewer b

Re: Interrupts + Polling mode (similar to Linux's NAPI)

2009/4/30 Adrian Chadd : > 2009/4/29 Erik Trulsson : >> That appearance is probably due to the fact the the FreeBSD project actually >> is a bunch of dudes working on what they feel like doing (or in a few cases >> on what they get paid for doing), and that there is very little centralized >> plann

Re: Problem with lagg failover (using bge0 and wpi0 interfaces)

Anyone know if my problem[1] is related by this PR? http://www.freebsd.org/cgi/query-pr.cgi?pr=133178 [1]: http://lists.freebsd.org/pipermail/freebsd-net/2009-April/021873.html Tks, Vinicius ___ freebsd-net@freebsd.org mailing list http://lists.freebs

lagg LACP between two hosts

Hello everybody, I have a strange curiosity maybe you can clarify me :-) Is it possible to do a LACP lagg connection directly between two hosts using two gigalan and two crossed cables? Or maybe three... ;-) Thanks ;-) ___ freebsd-net@freebsd.org mail

Re: lagg LACP between two hosts

On Thu, Apr 30, 2009 at 09:14:04PM +0200, and...@brancatelli.it wrote: > > Hello everybody, > > I have a strange curiosity maybe you can clarify me :-) > > Is it possible to do a LACP lagg connection directly between two hosts > using two gigalan and two crossed cables? Or maybe three... ;-) Ye

Re: lagg LACP between two hosts

and...@brancatelli.it wrote: > Hello everybody, > > I have a strange curiosity maybe you can clarify me :-) > > Is it possible to do a LACP lagg connection directly between two hosts > using two gigalan and two crossed cables? Or maybe three... ;-) I've done it with two GigE nics, and it works p

Signal sensitivity problem with if_rum

Hi, I think this is right place to post, if it is not, please let me know. I'm experiencing problems with two different devices using if_rum. One is a Hercules Guillemot and the other is a Linksys Cisco WUSB54GC The first one is about sensitivity, which is very low: for example, I'm detec