freebsd-net

• Date Index

---

• Re: kern/162110: Releng_9 panics on boot in IGB driver - regression from 8.2, Gleb Smirnoff
• Re: misc/162201: [patch] multicast forwarding cache hash always allocated with size 0, resulting in buffer overrun, Gleb Smirnoff
  • <Possible follow-ups>
  • RE: misc/162201: [patch] multicast forwarding cache hash always allocated with size 0, resulting in buffer overrun, Stevan_Markovic
  • Re: misc/162201: [patch] multicast forwarding cache hash always allocated with size 0, resulting in buffer overrun, Marko Zec
• Re: kern/162201: [ip] [patch] multicast forwarding cache hash always allocated with size 0, resulting in buffer overrun, linimon
• Re: kern/162153: [em] intel em driver 7.2.4 don't compile, linimon
• Re: kern/162028: [ixgbe] [patch] misplaced #endif in ixgbe.c, linimon
  • <Possible follow-ups>
  • Re: kern/162028: [ixgbe] [patch] misplaced #endif in ixgbe.c, Sergey Kandaurov
  • Re: kern/162028: [ixgbe] [patch] misplaced #endif in ixgbe.c, Hooman Fazaeli
• Re: kern/162068: [msk] Marvell Yukon GE onboard card does not work in 1000baseTX mode, linimon
  • <Possible follow-ups>
  • Re: kern/162068: [msk] Marvell Yukon GE onboard card does not work in 1000baseTX mode, yongari
• Re: kern/162110: [igb] [panic] RELENG_9 panics on boot in IGB driver - [regression] from 8.2, linimon
• ipfw reass brakes ipv6 operation, Emil Muratov
  • Re: ipfw reass brakes ipv6 operation, Sergey Matveychuk
• multiple ISP, nyoman.bogi@xxxxxxxxx
  • Re: multiple ISP, Julian Elischer
    • Re: multiple ISP, nyoman.bogi@xxxxxxxxx
      • Re: multiple ISP, Julian Elischer
  • Re: multiple ISP, Adrian Minta
  • Re: multiple ISP, Rémy Sanchez
• Does "Transparent TCP-to-SCTP Translation Shim Layer" available?, jyl_2006
• FreeBSD 9 IPv6 conformance test report, Qing Li
  • Re: FreeBSD 9 IPv6 conformance test report, Mark Atkinson
• bce huge amount of input errors, Bojidara Marinchovska
  • Re: bce huge amount of input errors, Damien Fleuriot
    • Re: bce huge amount of input errors, Bojidara Marinchovska
• [PATCH] Have netstat test for sctp kernel support, Sean Mahood
• PCI-E VT6130 NIC (if_vge) hang system with gigabit link, Andrey Smagin
  • Re: PCI-E VT6130 NIC (if_vge) hang system with gigabit link, YongHyeon PYUN
    • Re[2]: PCI-E VT6130 NIC (if_vge) hang system with gigabit link, Andrey Smagin
      • Re: PCI-E VT6130 NIC (if_vge) hang system with gigabit link, YongHyeon PYUN
      • Re[2]: PCI-E VT6130 NIC (if_vge) hang system with gigabit link, Andrey Smagin
      • Re: PCI-E VT6130 NIC (if_vge) hang system with gigabit link, Andrey Smagin
      • Re: PCI-E VT6130 NIC (if_vge) hang system with gigabit link, YongHyeon PYUN
      • Re[2]: PCI-E VT6130 NIC (if_vge) hang system with gigabit link, Andrey Smagin
      • Re[2]: PCI-E VT6130 NIC (if_vge) hang system with gigabit link, Andrey Smagin
• carp over openvpn?, alexander lunyov
• Possible sge(4)/atphy(4) regression on RELENG_9?, Nikolay Denev
  • Re: Possible sge(4)/atphy(4) regression on RELENG_9?, YongHyeon PYUN
    • Re: Possible sge(4)/atphy(4) regression on RELENG_9?, Nikolay Denev
• Too much interrupts on ixgbe, Sergey Saley
  • Re: Too much interrupts on ixgbe, Jack Vogel
    • Re: Too much interrupts on ixgbe, Sergey Saley
      • Re: Too much interrupts on ixgbe, Jack Vogel
      • Re: Too much interrupts on ixgbe, Sergey Saley
      • Re: Too much interrupts on ixgbe, Ryan Stone
      • Re: Too much interrupts on ixgbe, Sergey Saley
      • Re: Too much interrupts on ixgbe, Ryan Stone
      • Re: Too much interrupts on ixgbe, Arnaud Lacombe
      • Re: Too much interrupts on ixgbe, Sergey Saley
      • Re: Too much interrupts on ixgbe, Sergey Saley
      • Re: Too much interrupts on ixgbe, Jack Vogel
      • Re: Too much interrupts on ixgbe, Sergey Saley
  • Re: Too much interrupts on ixgbe, Andrew Boyer
• Re: kern/161908: [netgraph] [patch] ng_vlan update for QinQ support, eadler
  • <Possible follow-ups>
  • Re: kern/161908: [netgraph] [patch] ng_vlan update for QinQ support, rozhuk . im
• How can I create and use a Tap device&In-Reply, g.achari@xxxxxxxxx
• SCTP : problems in sending ASCONF chunks, jyl_2006
  • Re: SCTP : problems in sending ASCONF chunks, Michael Tuexen
    • Re: SCTP : problems in sending ASCONF chunks, jyl_2006
      • Re: SCTP : problems in sending ASCONF chunks, Michael Tuexen
      • Re: SCTP : problems in sending ASCONF chunks, Michael Tüxen
• IPFW shows me Strangeness in fresh 8.2-RELEASE system, Ronald F. Guilmette
  • RE: IPFW shows me Strangeness in fresh 8.2-RELEASE system, Li, Qing
  • Re: IPFW shows me Strangeness in fresh 8.2-RELEASE system, Barney Wolff
  • <Possible follow-ups>
  • RE: IPFW shows me Strangeness in fresh 8.2-RELEASE system, Ronald F. Guilmette
    • Re: IPFW shows me Strangeness in fresh 8.2-RELEASE system, David DeSimone
      • Re: IPFW shows me Strangeness in fresh 8.2-RELEASE system, Ryan Stone
• Re: kern/161899: [route] Repeating RTM_MISS packets causing high CPU load for ntpd, linimon
• How to set interface description containing space in 8.x, sthaug
  • Re: How to set interface description containing space in 8.x, Jeremy Chadwick
    • Re: How to set interface description containing space in 8.x, Jeremy Chadwick
      • Re: How to set interface description containing space in 8.x, sthaug
      • Re: How to set interface description containing space in 8.x, Doug Barton
• 9.0-RC1 panic in tcp_input: negative winow., Pawel Jakub Dawidek
  • Re: 9.0-RC1 panic in tcp_input: negative winow., Garrett Cooper
  • Re: 9.0-RC1 panic in tcp_input: negative winow., Lawrence Stewart
    • Re: 9.0-RC1 panic in tcp_input: negative winow., Garrett Cooper
    • Re: 9.0-RC1 panic in tcp_input: negative winow., Pawel Jakub Dawidek
      • Re: 9.0-RC1 panic in tcp_input: negative winow., Kostik Belousov
      • Re: 9.0-RC1 panic in tcp_input: negative winow., Pawel Jakub Dawidek
      • Re: 9.0-RC1 panic in tcp_input: negative winow., John Baldwin
      • Re: 9.0-RC1 panic in tcp_input: negative winow., Pawel Jakub Dawidek
      • Re: 9.0-RC1 panic in tcp_input: negative winow., John Baldwin
      • Re: 9.0-RC1 panic in tcp_input: negative winow., Lawrence Stewart
      • Re: 9.0-RC1 panic in tcp_input: negative winow., Pawel Jakub Dawidek
      • Re: 9.0-RC1 panic in tcp_input: negative winow., John Baldwin
      • Re: 9.0-RC1 panic in tcp_input: negative winow., Julian Elischer
• patch for route deletion issue, Li, Qing
• very strange arp problem after ip move - icmp works udp doesn't, Steven Hartland
  • RE: very strange arp problem after ip move - icmp works udp doesn't, Li, Qing
    • Re: very strange arp problem after ip move - icmp works udp doesn't, Steven Hartland
      • Re: very strange arp problem after ip move - icmp works udp doesn't, Li, Qing
      • Re: very strange arp problem after ip move - icmp works udp doesn't, Steven Hartland
      • Re: very strange arp problem after ip move - icmp works udp doesn't, Mike Tancsa
      • Re: very strange arp problem after ip move - icmp works udp doesn't, Steven Hartland
      • RE: very strange arp problem after ip move - icmp works udp doesn't, Li, Qing
• Subscribe request result (ruby-core ML), ruby-core-admin
• kern/161805 - patch is on its way, Li, Qing
  • Re: kern/161805 - patch is on its way, Eugene Grosbein
• IPv6 Redirects & local destinations, Fernando Gont
  • Re: IPv6 Redirects & local destinations, Bjoern A. Zeeb
    • Re: IPv6 Redirects & local destinations, Fernando Gont
      • RE: IPv6 Redirects & local destinations, Li, Qing
• Patch to enable our tcpdump to handle CARP, George Neville-Neil
  • Re: Patch to enable our tcpdump to handle CARP, Dan Nelson
  • Re: Patch to enable our tcpdump to handle CARP, Kevin Wilcox
    • Re: Patch to enable our tcpdump to handle CARP, Arnaud Lacombe
      • Re: Patch to enable our tcpdump to handle CARP, Kevin Wilcox
  • Re: Patch to enable our tcpdump to handle CARP, Peter Jeremy
• Possible bug in recent L2 modifications to in.c, Larry Baird
  • <Possible follow-ups>
  • Possible bug in recent L2 modifications to in.c, Larry Baird
• ether_demux does not handle frames with embedded vlan tags, Ryan Stone
  • RE: ether_demux does not handle frames with embedded vlan tags, rozhuk . im
    • Re: ether_demux does not handle frames with embedded vlan tags, Ryan Stone
      • RE: ether_demux does not handle frames with embedded vlan tags, rozhuk . im
      • Re: ether_demux does not handle frames with embedded vlan tags, Ryan Stone
      • Re: ether_demux does not handle frames with embedded vlan tags, Juli Mallett
      • Re: ether_demux does not handle frames with embedded vlan tags, Ryan Stone
      • Re: ether_demux does not handle frames with embedded vlan tags, Juli Mallett
• misplaced #endif in ixgbe, Hooman Fazaeli
• kern/155604: [flowtable] Flowtable excessively caches dest MAC addresses for outgoing traffic, Gleb Smirnoff
  • <Possible follow-ups>
  • Re: kern/155604: [flowtable] Flowtable excessively caches dest MAC addresses for outgoing traffic, Steve Polyack
  • Re: kern/155604: [flowtable] Flowtable excessively caches dest MAC addresses for outgoing traffic, Gleb Smirnoff
• Re: TSO broken with jumbo MTU, Ben Hutchings
  • Re: TSO broken with jumbo MTU, Andre Oppermann
    • Re: TSO broken with jumbo MTU, Ben Hutchings
      • Re: TSO broken with jumbo MTU, Bjoern A. Zeeb
      • Re: TSO broken with jumbo MTU, Ben Hutchings
      • Re: TSO broken with jumbo MTU, Ben Hutchings
• Call for testers : ALi/ULi M5261/M5263 ethernet controller, YongHyeon PYUN
  • Re: Call for testers : ALi/ULi M5261/M5263 ethernet controller, YongHyeon PYUN
• Re: kern/161708: [re] re0 unknown hardware revision with onboard Realtek 8111E, linimon
• Re: kern/149643: [rum] device not sending proper beacon frames in ap mode, Steven Chamberlain
  • Re: kern/149643: [rum] device not sending proper beacon frames in ap mode, Adrian Chadd
    • Re: kern/149643: [rum] device not sending proper beacon frames in ap mode, Steven Chamberlain
      • Re: kern/149643: [rum] device not sending proper beacon frames in ap mode, Steven Chamberlain
      • Re: kern/149643: [rum] device not sending proper beacon frames in ap mode, Adrian Chadd
      • Re: kern/149643: [rum] device not sending proper beacon frames in ap mode, Steven Chamberlain
      • Re: kern/149643: [rum] device not sending proper beacon frames in ap mode, Steven Chamberlain
      • Re: kern/149643: [rum] device not sending proper beacon frames in ap mode, Adrian Chadd
      • Re: kern/149643: [rum] device not sending proper beacon frames in ap mode, Adrian Chadd
      • Re: kern/149643: [rum] device not sending proper beacon frames in ap mode, Steven Chamberlain
      • Re: kern/149643: [rum] device not sending proper beacon frames in ap mode, Steven Chamberlain
      • Re: kern/149643: [rum] device not sending proper beacon frames in ap mode, Adrian Chadd
  • Re: kern/149643: [rum] device not sending proper beacon frames in ap mode, Adrian Chadd
  • <Possible follow-ups>
  • Re: kern/149643: [rum] device not sending proper beacon frames in ap mode, Steven Chamberlain
  • Re: kern/149643: [rum] device not sending proper beacon frames in ap mode, Adrian Chadd
• kern/155030: [igb] igb(4) DEVICE_POLLING does not work with carp(4), Gleb Smirnoff
• Re: kern/127050: [carp] ipv6 does not work on carp interfaces [regression], glebius
• Re: kern/125816: [carp] [if_bridge] carp stuck in init when using bridge interface, glebius
• kern/144572: [carp] CARP preemption mode traffic partially goes to backup node, Gleb Smirnoff
  • <Possible follow-ups>
  • Re: kern/144572: [carp] CARP preemption mode traffic partially goes to backup node, glebius
  • Re: kern/144572: [carp] CARP preemption mode traffic partially goes to backup node, glebius
• Re: kern/141023: [carp] CARP arp replays with wrong src mac, glebius
• Re: kern/133218: [carp] [hang] use of carp(4) causes system to freeze, glebius
• Re: kern/132285: [carp] alias gives incorrect hash in dmesg, glebius
• Re: kern/132107: [carp] carp(4) advskew setting ignored when carp IP used on a gif(4) interface, glebius
• Re: kern/129508: [carp] [panic] Kernel panic with EtherIP (may be related to SVN commit 178025), glebius
  • <Possible follow-ups>
  • kern/129508: [carp] [panic] Kernel panic with EtherIP (may be related to SVN commit 178025), Gleb Smirnoff
• Re: kern/126945: [carp] CARP interface destruction with ifconfig destroy causes kernel panic, glebius
• Re: kern/126714: [carp] CARP interface renaming makes system no longer respond on the virtual IP address, glebius
• Re: kern/125442: [carp] [lagg] CARP combined with LAGG causes system panic - 7.0/amd64, glebius
• Re: kern/120130: [carp] [panic] carp causes kernel panics in any constellation, glebius
• Re: kern/117448: [carp] 6.2 kernel crash [regression], glebius
• PR contributor mix-up, Qing Li
• QinQ support: implement details - need help!, rozhuk . im
  • RE: QinQ support: implement details - need help!, rozhuk . im
• father of unix and C dies, justino garcia
• Re: kern/157418: [em] em driver lockup during boot on Supermicro X9SCM-F, Wojciech A. Koszek
• Re: new CARP implementation, Gleb Smirnoff
  • Re: new CARP implementation, Andre Oppermann
    • Re: new CARP implementation, Gleb Smirnoff
      • Re: new CARP implementation, Andre Oppermann
      • Re: new CARP implementation, Gleb Smirnoff
      • Re: new CARP implementation, Andre Oppermann
      • Re: new CARP implementation, Gleb Smirnoff
      • Re: new CARP implementation, Andre Oppermann
  • Re: new CARP implementation, Gleb Smirnoff
• Re: kern/159602: [netinet] [patch] arp_ifscrub() is called even if IFF_NOARP flag is set, Svatopluk Kraus
  • <Possible follow-ups>
  • Re: kern/159602: [netinet] [patch] arp_ifscrub() is called even if IFF_NOARP flag is set, linimon
• Re: kern/159603: [netinet] [patch] in_ifscrubprefix() - network route can be installed for interfaces marked down, Svatopluk Kraus
• Re: kern/159601: [netinet] [patch] in_scrubprefix() - loopback route refcount malfunction, Svatopluk Kraus
• recoomendations to a box, Sami Halabi
• Re: kern/145600: TCP/ECN behaves different to CE/CWR than ns2 reference, remko
• Re: kern/161483: [carp] [patch] when preemption is enabled carp interface assumes MASTERship immediately even with higher advbase/advskew, linimon
  • <Possible follow-ups>
  • Re: kern/161483: [carp] [patch] when preemption is enabled carp interface assumes MASTERship immediately even with higher advbase/advskew, glebius
• if_msk.c link negotiation / packet drops, Karim
  • Re: if_msk.c link negotiation / packet drops, YongHyeon PYUN
    • Re: if_msk.c link negotiation / packet drops, Kevin Oberman
      • Re: if_msk.c link negotiation / packet drops, Karim
      • Re: if_msk.c link negotiation / packet drops, Arnaud Lacombe
      • Re: if_msk.c link negotiation / packet drops, Karim
      • Re: if_msk.c link negotiation / packet drops, Karim
      • Re: if_msk.c link negotiation / packet drops, YongHyeon PYUN
      • Re: if_msk.c link negotiation / packet drops, Karim
      • Re: if_msk.c link negotiation / packet drops, YongHyeon PYUN
      • Re: if_msk.c link negotiation / packet drops, Karim
      • Re: if_msk.c link negotiation / packet drops, YongHyeon PYUN
      • Re: if_msk.c link negotiation / packet drops [solved!], Karim
      • Re: if_msk.c link negotiation / packet drops [solved!], YongHyeon PYUN
      • Re: if_msk.c link negotiation / packet drops, perryh
      • Re: if_msk.c link negotiation / packet drops, YongHyeon PYUN
      • Re: if_msk.c link negotiation / packet drops, Arnaud Lacombe
      • Re: if_msk.c link negotiation / packet drops, YongHyeon PYUN
      • Re: if_msk.c link negotiation / packet drops, Arnaud Lacombe
  • Re: if_msk.c link negotiation / packet drops, Adrian Chadd
• strange ipv6 on 9.0-BETA3, dikshie
  • Re: strange ipv6 on 9.0-BETA3, Mike Tancsa
    • Re: strange ipv6 on 9.0-BETA3, dikshie
• CARP - immediate INIT-MASTER transition when preempt enabled , bug from openbsd38, Damien Fleuriot
• RADIX_MPATH Documentation Feedback Request, Jason Hellenthal
  • Re: RADIX_MPATH Documentation Feedback Request, Qing Li
    • Re: RADIX_MPATH Documentation Feedback Request, Jason Hellenthal
  • <Possible follow-ups>
  • Re: RADIX_MPATH Documentation Feedback Request, Larry Baird
    • Re: RADIX_MPATH Documentation Feedback Request, Qing Li
• Re: kern/159603: commit references a PR, dfilter service
• Re: Error - mysql_connect: Operation not permitted., Remko Lodder
• panic in tcp_drop (and fix for it), Navdeep Parhar
  • Re: panic in tcp_drop (and fix for it), Andre Oppermann
• Re: kern/161123: [carp] [patch] when preemption is enabled carp interface assumes MASTERship immediately even with higher advbase/advskew, linimon
  • <Possible follow-ups>
  • Re: kern/161123: [carp] [patch] when preemption is enabled carp interface assumes MASTERship immediately even with higher advbase/advskew, glebius
• Re: kern/159602: commit references a PR, dfilter service
  • <Possible follow-ups>
  • Re: kern/159602: commit references a PR, dfilter service
  • Re: kern/159602: commit references a PR, dfilter service
• wireless lor with ath chip., Koop Mast
  • Re: wireless lor with ath chip., Adrian Chadd
• Re: kern/161381: [re] RTL8169SC - re0: PHY write failed, linimon
• Re: kern/159601: commit references a PR, dfilter service
  • Re: kern/159601: commit references a PR, Arnaud Lacombe
    • RE: kern/159601: commit references a PR, Li, Qing
      • RE: kern/159601: commit references a PR, Li, Qing
  • <Possible follow-ups>
  • Re: kern/159601: commit references a PR, dfilter service
  • Re: kern/159601: commit references a PR, dfilter service
• [PATCH] Don't have ICMP Echo Replies copy fragmentation flags from Echo Request, Ryan Stone
  • Re: [PATCH] Don't have ICMP Echo Replies copy fragmentation flags from Echo Request, Mike Tancsa
  • Re: [PATCH] Don't have ICMP Echo Replies copy fragmentation flags from Echo Request, Andre Oppermann
• Question about GPIO bitbang MII, dave jones
  • Re: Question about GPIO bitbang MII, Aleksandr Rybalko
    • Re: Question about GPIO bitbang MII, dave jones
  • Re: Question about GPIO bitbang MII, Juli Mallett
  • Re: Question about GPIO bitbang MII, Marius Strobl
    • Re: Question about GPIO bitbang MII, dave jones
    • Re: Question about GPIO bitbang MII, YongHyeon PYUN
      • Re: Question about GPIO bitbang MII, Marius Strobl
      • Re: Question about GPIO bitbang MII, YongHyeon PYUN
      • Re: Question about GPIO bitbang MII, Marius Strobl
      • Re: Question about GPIO bitbang MII, YongHyeon PYUN
      • Re: Question about GPIO bitbang MII, Marius Strobl
      • Re: Question about GPIO bitbang MII, YongHyeon PYUN
      • Re: Question about GPIO bitbang MII, Marius Strobl
      • Re: Question about GPIO bitbang MII, YongHyeon PYUN
      • nge(4), tl(4), wb(4) and rl(4) 8129 testers wanted [Re: Question about GPIO bitbang MII], Marius Strobl
      • Re: nge(4), tl(4), wb(4) and rl(4) 8129 testers wanted [Re: Question about GPIO bitbang MII], Damien Fleuriot
      • Re: nge(4), tl(4), wb(4) and rl(4) 8129 testers wanted [Re: Question about GPIO bitbang MII], Marius Strobl
      • Re: nge(4), tl(4), wb(4) and rl(4) 8129 testers wanted [Re: Question about GPIO bitbang MII], andrew bliznak
      • Re: nge(4), tl(4), wb(4) and rl(4) 8129 testers wanted [Re: Question about GPIO bitbang MII], Marius Strobl
• Re: bce(4) with IPMI [puzzling and puzzling], Sean Bruno
  • Re: bce(4) with IPMI [puzzling and puzzling], Sean Bruno
    • Re: bce(4) with IPMI [puzzling and puzzling], YongHyeon PYUN
      • RE: bce(4) with IPMI [puzzling and puzzling], David Christensen
      • Re: bce(4) with IPMI [puzzling and puzzling], YongHyeon PYUN
      • RE: bce(4) with IPMI [puzzling and puzzling], David Christensen
      • Re: bce(4) with IPMI [puzzling and puzzling], YongHyeon PYUN
      • RE: bce(4) with IPMI [puzzling and puzzling], David Christensen
  • RE: bce(4) with IPMI [puzzling and puzzling], David Christensen
• Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Jason Wolfe
  • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Jack Vogel
    • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Jason Wolfe
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Arnaud Lacombe
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Jason Wolfe
  • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Mike Tancsa
    • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Jason Wolfe
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Mike Tancsa
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Arnaud Lacombe
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Mike Tancsa
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Arnaud Lacombe
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Mike Tancsa
      • Message not available
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Jason Wolfe
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Jason Wolfe
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Jason Wolfe
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Jason Wolfe
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Hooman Fazaeli
      • Message not available
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Jason Wolfe
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Mike Tancsa
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Emil Muratov
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Adrian Chadd
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Emil Muratov
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Hooman Fazaeli
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Emil Muratov
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Hooman Fazaeli
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Emil Muratov
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Hooman Fazaeli
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Ryan Stone
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Hooman Fazaeli
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Jack Vogel
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, YongHyeon PYUN
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Jason Wolfe
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Jack Vogel
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Hooman Fazaeli
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Emil Muratov
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Hooman Fazaeli
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Emil Muratov
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Hooman Fazaeli
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Arnaud Lacombe
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Emil Muratov
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Arnaud Lacombe
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Jason Wolfe
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Hooman Fazaeli
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Jason Wolfe
    • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled, Lev Serebryakov
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIXenabled, Steven Hartland
      • Re: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIXenabled, Lev Serebryakov
• [driver port request] OpenBSD's otus driver., Chuck Burns
• carp on bridge interface: INIT, alexander lunyov
  • Re: carp on bridge interface: INIT, alexander lunyov
• Re: kern/161277: [em] [patch] BMC cannot receive IPMI traffic after loading or enabling the if_em driver, linimon
• Apologies for the recent spam..., Chuck Burns
• [urtw] Wifi link dying randomly. reboot required to reconnect., Chuck Burns
  • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Arnaud Lacombe
    • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Chuck Burns
      • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Chuck Burns
      • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Arnaud Lacombe
      • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Chuck Burns
      • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Arnaud Lacombe
      • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Adrian Chadd
      • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Chuck Burns
      • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Adrian Chadd
      • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Chuck Burns
      • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Chuck Burns
      • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Adrian Chadd
      • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Chuck Burns
      • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Adrian Chadd
      • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Chuck Burns
      • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Gary Palmer
      • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Chuck Burns
      • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Gary Palmer
      • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Chuck Burns
      • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Gary Palmer
      • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Arnaud Lacombe
      • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Chuck Burns
  • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Chuck Burns
    • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Adrian Chadd
      • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Chuck Burns
      • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Adrian Chadd
      • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Chuck Burns
      • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Arnaud Lacombe
      • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Chuck Burns
      • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Chuck Burns
      • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Adrian Chadd
  • <Possible follow-ups>
  • [urtw] Wifi link dying randomly. reboot required to reconnect., Chuck Burns
  • [urtw] Wifi link dying randomly. reboot required to reconnect., Chuck Burns
  • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., PseudoCylon
    • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Chuck Burns
      • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., Chuck Burns
      • Re: [urtw] Wifi link dying randomly. reboot required to reconnect., PseudoCylon
• Re: em(4) hang [Was: Re: igb(4) won't start with "igb0: Could not setup receive structures"], Arnaud Lacombe
• Re: em driver support for Intel 82579LM still buggy in FreeBSD 9.0-BETA1, Arnaud Lacombe
• RE: bce(4) with IPMI, Sean Bruno
  • Re: bce(4) with IPMI, YongHyeon PYUN
    • Re: bce(4) with IPMI, Arnaud Lacombe
      • Re: bce(4) with IPMI, YongHyeon PYUN
    • Re: bce(4) with IPMI, Sean Bruno
      • Re: bce(4) with IPMI, YongHyeon PYUN
      • Re: bce(4) with IPMI, Sean Bruno
      • Re: bce(4) with IPMI, YongHyeon PYUN
      • Re: bce(4) with IPMI, Sean Bruno
      • Re: bce(4) with IPMI, YongHyeon PYUN
      • Re: bce(4) with IPMI, Sean Bruno
      • Re: bce(4) with IPMI, YongHyeon PYUN
      • RE: bce(4) with IPMI, David Christensen
      • RE: bce(4) with IPMI, Sean Bruno
      • Re: bce(4) with IPMI, YongHyeon PYUN
      • Re: bce(4) with IPMI, Sean Bruno
      • Re: bce(4) with IPMI, YongHyeon PYUN
      • Re: bce(4) with IPMI, Sean Bruno
      • RE: bce(4) with IPMI, David Christensen
      • RE: bce(4) with IPMI, Sean Bruno
      • Re: bce(4) with IPMI, John Baldwin
      • RE: bce(4) with IPMI, David Christensen
      • Re: bce(4) with IPMI, YongHyeon PYUN
      • RE: bce(4) with IPMI, David Christensen
• RE: gif interface not passing IPv6 packets, Li, Qing
  • Re: gif interface not passing IPv6 packets, Matt Smith
    • RE: gif interface not passing IPv6 packets, Li, Qing
      • Re: gif interface not passing IPv6 packets, Hiroki Sato
      • Re: gif interface not passing IPv6 packets, Matt Smith
      • Re: gif interface not passing IPv6 packets, Matt Smith
      • RE: gif interface not passing IPv6 packets, Li, Qing
      • RE: gif interface not passing IPv6 packets, Li, Qing
      • Re: gif interface not passing IPv6 packets, Matt Smith
      • RE: gif interface not passing IPv6 packets, Li, Qing
• Broadcom Docs, Sean Bruno
  • Re: Broadcom Docs, Arnaud Lacombe
    • Re: Broadcom Docs, Matthias Apitz
      • Re: Broadcom Docs, Adrian Chadd
      • Re: Broadcom Docs, Matthias Apitz
      • Re: Broadcom Docs, Adrian Chadd
      • Re: Broadcom Docs, Arnaud Lacombe
      • b43 driver (was: Re: Broadcom Docs), Matthias Apitz
      • Re: Broadcom Docs, Gary Palmer
      • Re: Broadcom Docs, Adrian Chadd
      • Re: Broadcom Docs, Arnaud Lacombe
      • Re: Broadcom Docs, Erik Trulsson
  • Re: Broadcom Docs, Aldis Berjoza
• Current problem reports assigned to freebsd-net@FreeBSD.org, FreeBSD bugmaster
  • <Possible follow-ups>
  • Current problem reports assigned to freebsd-net@FreeBSD.org, FreeBSD bugmaster
  • Current problem reports assigned to freebsd-net@FreeBSD.org, FreeBSD bugmaster
  • Current problem reports assigned to freebsd-net@FreeBSD.org, FreeBSD bugmaster
  • Current problem reports assigned to freebsd-net@FreeBSD.org, FreeBSD bugmaster
• Re: em(4) high latency w/o msix, Jack Vogel
  • Re: em(4) high latency w/o msix, Arnaud Lacombe
    • Re: em(4) high latency w/o msix, Jack Vogel
    • Re: em(4) high latency w/o msix, Arnaud Lacombe
  • Message not available
    • Re: em(4) high latency w/o msix, Jack Vogel
      • Re: em(4) high latency w/o msix, Sami Halabi
  • <Possible follow-ups>
  • Re: em(4) high latency w/o msix, Hooman Fazaeli
• Re: strange ping on local address, Andrey Zonov
• Re: Intel NIC stops working, Andrey Zonov
  • Re: Intel NIC stops working, Johannes
• Re: IPv6 multicast listener discovery, Hiroki Sato
  • <Possible follow-ups>
  • RE: IPv6 multicast listener discovery, Li, Qing
  • Re: IPv6 multicast listener discovery, Rainer Bredehorn
  • RE: IPv6 multicast listener discovery, Rainer Bredehorn
  • RE: IPv6 multicast listener discovery, Rainer Bredehorn
• Re: ipfw - accessing DMZ from LAN, Marek Salwerowicz
  • Re: ipfw - accessing DMZ from LAN, Freddie Cash
• Re: Kernel panic on FreeBSD 9.0-beta2, dave jones
  • Re: Kernel panic on FreeBSD 9.0-beta2, Mikolaj Golub
    • Re: Kernel panic on FreeBSD 9.0-beta2, dave jones
      • Re: Kernel panic on FreeBSD 9.0-beta2, dave jones
      • Re: Kernel panic on FreeBSD 9.0-beta2, Mikolaj Golub
      • Re: Kernel panic on FreeBSD 9.0-beta2, dave jones

• Security
• UNIX
• Linux
• Coding
• Usenet

• Mailing-Lists
• Newsgroups
• About
• Privacy
• Search
• Imprint

unix.derkeiler.com  > Mailing-Lists  > FreeBSD  > net  > 2011-10