date:20090909

Re: em driver input errors

2009-09-09 Thread Barney Cordoba



--- On Tue, 9/8/09, Mike Tancsa  wrote:

> From: Mike Tancsa 
> Subject: Re: em driver input errors
> To: "Barney Cordoba" 
> Cc: freebsd-net@freebsd.org
> Date: Tuesday, September 8, 2009, 6:21 PM
> At 05:42 PM 9/8/2009, Barney Cordoba
> wrote:
> > Manish What specific kinds of input errors are you
> getting? How many PPS are you doing, what is the size of the
> ring, and the interrupt modulation rate? Are the NICs PCIe
> or PCIx? Barney
> 
> In my case, our backup server (mix of dump via nfs and some
> dumps through ssh as well as writes via samba mounts) has a
> fairly low pps rate and starts to see input errors at about
> 100Mb.  Adding
> 
> hw.em.rxd=4096
> hw.em.txd=4096
> 
> and
> 
> net.inet.tcp.recvbuf_max=16777216
> net.inet.tcp.recvspace=131072
> net.inet.tcp.sendbuf_max=16777216
> net.inet.tcp.sendspace=131072
> net.inet.udp.recvspace=65536
> kern.ipc.somaxconn=1024
> kern.ipc.maxsockbuf=4194304
> net.inet.ip.redirect=0
> net.inet.ip.intr_queue_maxlen=4096
> net.route.netisr_maxqlen=1024
> kern.ipc.nmbclusters=655360
> 
> didnt seem to make a difference in the amount of errors I
> was seeing
> 
> 
> e...@pci0:7:5:0: class=0x02 card=0x348f8086
> chip=0x10768086 rev=0x05 hdr=0x00
>     vendor     = 'Intel
> Corporation'
>     device     = 'Gigabit
> Ethernet Controller (82541EI)'
>     class      = network
>     subclass   = ethernet
>     cap 01[dc] = powerspec 2  supports D0
> D3  current D0
>     cap 07[e4] = PCI-X supports 2048 burst read,
> 1 split transaction
> 
>  Core(TM)2 Quad CPU    Q6600  @ 2.40GHz,
> AMD64, RELENG_7 from Jun 18th
> 
> Plenty of disk IO left and the CPUs doent seem to be taxed
> that much.
> 
> Sep  8 00:02:01 backup3 kernel: em1: Excessive
> collisions = 0
> Sep  8 00:02:01 backup3 kernel: em1: Sequence errors =
> 0
> Sep  8 00:02:01 backup3 kernel: em1: Defer count = 0
> Sep  8 00:02:01 backup3 kernel: em1: Missed Packets =
> 61316
> Sep  8 00:02:01 backup3 kernel: em1: Receive No
> Buffers = 0
> Sep  8 00:02:01 backup3 kernel: em1: Receive Length
> Errors = 0
> Sep  8 00:02:01 backup3 kernel: em1: Receive errors =
> 0
> Sep  8 00:02:01 backup3 kernel: em1: Crc errors = 0
> Sep  8 00:02:01 backup3 kernel: em1: Alignment errors
> = 0
> Sep  8 00:02:01 backup3 kernel: em1: Collision/Carrier
> extension errors = 0
> Sep  8 00:02:01 backup3 kernel: em1: RX overruns =
> 22397
> Sep  8 00:02:01 backup3 kernel: em1: watchdog timeouts
> = 0
> Sep  8 00:02:01 backup3 kernel: em1: RX MSIX IRQ = 0
> TX MSIX IRQ = 0 LINK MSIX IRQ = 0
> Sep  8 00:02:01 backup3 kernel: em1: XON Rcvd = 0
> Sep  8 00:02:01 backup3 kernel: em1: XON Xmtd = 0
> Sep  8 00:02:01 backup3 kernel: em1: XOFF Rcvd = 0
> Sep  8 00:02:01 backup3 kernel: em1: XOFF Xmtd = 0
> Sep  8 00:02:01 backup3 kernel: em1: Good Packets Rcvd
> = 544276980
> Sep  8 00:02:01 backup3 kernel: em1: Good Packets Xmtd
> = 490475071
> Sep  8 00:02:01 backup3 kernel: em1: TSO Contexts Xmtd
> = 0
> Sep  8 00:02:01 backup3 kernel: em1: TSO Contexts
> Failed = 0
> 
> 
> pf is in the kernel as well
> 
> > ___
> > freebsd-net@freebsd.org
> mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
> 
> 
> Mike Tancsa,           
>                
>           tel +1 519 651 3400
> Sentex Communications,         
>                
>   m...@sentex.net
> Providing Internet since 1994       
>             www.sentex.net
> Cambridge, Ontario Canada         
>            
>    www.sentex.net/mike
> 
> 

The 8241GI may not be able to handle full gigabit flows if its only
wired at 32-bit 33Mhz, which is only capable of bursting to 1Gb/s. With
a single NIC it likely just fine, but it a bridged or firewall type 
config you may just be seeing bus failures.

Barney




___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: em driver input errors

2009-09-09 Thread Barney Cordoba



--- On Wed, 9/9/09, Barney Cordoba  wrote:

> From: Barney Cordoba 
> Subject: Re: em driver input errors
> To: "Mike Tancsa" 
> Cc: freebsd-net@freebsd.org
> Date: Wednesday, September 9, 2009, 7:40 AM
> 
> 
> --- On Tue, 9/8/09, Mike Tancsa 
> wrote:
> 
> > From: Mike Tancsa 
> > Subject: Re: em driver input errors
> > To: "Barney Cordoba" 
> > Cc: freebsd-net@freebsd.org
> > Date: Tuesday, September 8, 2009, 6:21 PM
> > At 05:42 PM 9/8/2009, Barney Cordoba
> > wrote:
> > > Manish What specific kinds of input errors are
> you
> > getting? How many PPS are you doing, what is the size
> of the
> > ring, and the interrupt modulation rate? Are the NICs
> PCIe
> > or PCIx? Barney
> > 
> > In my case, our backup server (mix of dump via nfs and
> some
> > dumps through ssh as well as writes via samba mounts)
> has a
> > fairly low pps rate and starts to see input errors at
> about
> > 100Mb.  Adding
> > 
> > hw.em.rxd=4096
> > hw.em.txd=4096
> > 
> > and
> > 
> > net.inet.tcp.recvbuf_max=16777216
> > net.inet.tcp.recvspace=131072
> > net.inet.tcp.sendbuf_max=16777216
> > net.inet.tcp.sendspace=131072
> > net.inet.udp.recvspace=65536
> > kern.ipc.somaxconn=1024
> > kern.ipc.maxsockbuf=4194304
> > net.inet.ip.redirect=0
> > net.inet.ip.intr_queue_maxlen=4096
> > net.route.netisr_maxqlen=1024
> > kern.ipc.nmbclusters=655360
> > 
> > didnt seem to make a difference in the amount of
> errors I
> > was seeing
> > 
> > 
> > e...@pci0:7:5:0: class=0x02 card=0x348f8086
> > chip=0x10768086 rev=0x05 hdr=0x00
> >     vendor     = 'Intel
> > Corporation'
> >     device     = 'Gigabit
> > Ethernet Controller (82541EI)'
> >     class      = network
> >     subclass   = ethernet
> >     cap 01[dc] = powerspec 2  supports D0
> > D3  current D0
> >     cap 07[e4] = PCI-X supports 2048 burst read,
> > 1 split transaction
> > 
> >  Core(TM)2 Quad CPU    Q6600  @ 2.40GHz,
> > AMD64, RELENG_7 from Jun 18th
> > 
> > Plenty of disk IO left and the CPUs doent seem to be
> taxed
> > that much.
> > 
> > Sep  8 00:02:01 backup3 kernel: em1: Excessive
> > collisions = 0
> > Sep  8 00:02:01 backup3 kernel: em1: Sequence errors
> =
> > 0
> > Sep  8 00:02:01 backup3 kernel: em1: Defer count = 0
> > Sep  8 00:02:01 backup3 kernel: em1: Missed Packets
> =
> > 61316
> > Sep  8 00:02:01 backup3 kernel: em1: Receive No
> > Buffers = 0
> > Sep  8 00:02:01 backup3 kernel: em1: Receive Length
> > Errors = 0
> > Sep  8 00:02:01 backup3 kernel: em1: Receive errors
> =
> > 0
> > Sep  8 00:02:01 backup3 kernel: em1: Crc errors = 0
> > Sep  8 00:02:01 backup3 kernel: em1: Alignment
> errors
> > = 0
> > Sep  8 00:02:01 backup3 kernel: em1:
> Collision/Carrier
> > extension errors = 0
> > Sep  8 00:02:01 backup3 kernel: em1: RX overruns =
> > 22397
> > Sep  8 00:02:01 backup3 kernel: em1: watchdog
> timeouts
> > = 0
> > Sep  8 00:02:01 backup3 kernel: em1: RX MSIX IRQ = 0
> > TX MSIX IRQ = 0 LINK MSIX IRQ = 0
> > Sep  8 00:02:01 backup3 kernel: em1: XON Rcvd = 0
> > Sep  8 00:02:01 backup3 kernel: em1: XON Xmtd = 0
> > Sep  8 00:02:01 backup3 kernel: em1: XOFF Rcvd = 0
> > Sep  8 00:02:01 backup3 kernel: em1: XOFF Xmtd = 0
> > Sep  8 00:02:01 backup3 kernel: em1: Good Packets
> Rcvd
> > = 544276980
> > Sep  8 00:02:01 backup3 kernel: em1: Good Packets
> Xmtd
> > = 490475071
> > Sep  8 00:02:01 backup3 kernel: em1: TSO Contexts
> Xmtd
> > = 0
> > Sep  8 00:02:01 backup3 kernel: em1: TSO Contexts
> > Failed = 0
> > 
> > 
> > pf is in the kernel as well
> > 
> > > ___
> > > freebsd-net@freebsd.org
> > mailing list
> > > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
> > 
> >
> 
> > Mike Tancsa,           
> >                
> >           tel +1 519 651 3400
> > Sentex Communications,         
> >                
> >   m...@sentex.net
> > Providing Internet since 1994       
> >             www.sentex.net
> > Cambridge, Ontario Canada         
> >            
> >    www.sentex.net/mike
> > 
> > 
> 
> The 8241GI may not be able to handle full gigabit flows if
> its only
> wired at 32-bit 33Mhz, which is only capable of bursting to
> 1Gb/s. With
> a single NIC it likely just fine, but it a bridged or
> firewall type 
> config you may just be seeing bus failures.
> 
> Barney

I meant 82541EI...Same answer.



___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

8.0-B4, Broadcom bge0 not working, HP Proliant DL385, amd64

2009-09-09 Thread stuart cur

In 8.0-B4 for amd64, bge does not recognize that there is an active 
ethernet connection on bge0.  Switching the cable to bge1 works correctly.


This seems to be the same issue as reported on July 21 by Oyvind Rakvag, 
but I saw no response to that report.


Attached are the dmesg.boot, /var/log/messages, and output of pciconf -lv 
from the very first boot.


stuSep  8 15:51:17  newsyslog[775]: logfile first created
Sep  8 15:51:17  syslogd: kernel boot file is /boot/kernel/kernel
Sep  8 15:51:17  kernel: Copyright (c) 1992-2009 The FreeBSD Project.
Sep  8 15:51:17  kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 
1991, 1992, 1993, 1994
Sep  8 15:51:17  kernel: The Regents of the University of California. All 
rights reserved.
Sep  8 15:51:17  kernel: FreeBSD is a registered trademark of The FreeBSD 
Foundation.
Sep  8 15:51:17  kernel: FreeBSD 8.0-BETA4 #0: Sun Sep  6 04:44:31 UTC 2009
Sep  8 15:51:17  kernel: r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
Sep  8 15:51:17  kernel: WARNING: WITNESS option enabled, expect reduced 
performance.
Sep  8 15:51:17  kernel: Timecounter "i8254" frequency 1193182 Hz quality 0
Sep  8 15:51:17  kernel: CPU: AMD Opteron(tm) Processor 270 (2004.55-MHz 
K8-class CPU)
Sep  8 15:51:17  kernel: Origin = "AuthenticAMD"  Id = 0x20f12  Stepping = 2
Sep  8 15:51:17  kernel: 
Features=0x178bfbff
Sep  8 15:51:17  kernel: Features2=0x1
Sep  8 15:51:17  kernel: AMD 
Features=0xe2500800
Sep  8 15:51:17  kernel: AMD Features2=0x2
Sep  8 15:51:17  kernel: real memory  = 2147483648 (2048 MB)
Sep  8 15:51:17  kernel: avail memory = 2054406144 (1959 MB)
Sep  8 15:51:17  kernel: ACPI APIC Table: 
Sep  8 15:51:17  kernel: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
Sep  8 15:51:17  kernel: FreeBSD/SMP: 1 package(s) x 2 core(s)
Sep  8 15:51:17  kernel: cpu0 (BSP): APIC ID:  0
Sep  8 15:51:17  kernel: cpu1 (AP): APIC ID:  1
Sep  8 15:51:17  kernel: ACPI Warning: Invalid length for Pm1aControlBlock: 32, 
using default 16 20090521 tbfadt-707
Sep  8 15:51:17  kernel: ACPI Warning: Invalid length for Pm1bControlBlock: 32, 
using default 16 20090521 tbfadt-707
Sep  8 15:51:17  kernel: MADT: Forcing active-low polarity and level trigger 
for SCI
Sep  8 15:51:17  kernel: ioapic0  irqs 0-23 on motherboard
Sep  8 15:51:17  kernel: ioapic1  irqs 24-27 on motherboard
Sep  8 15:51:17  kernel: ioapic2  irqs 28-31 on motherboard
Sep  8 15:51:17  kernel: ioapic3  irqs 32-35 on motherboard
Sep  8 15:51:17  kernel: ioapic4  irqs 36-39 on motherboard
Sep  8 15:51:17  kernel: kbd1 at kbdmux0
Sep  8 15:51:17  kernel: acpi0:  on motherboard
Sep  8 15:51:17  kernel: acpi0: [ITHREAD]
Sep  8 15:51:17  kernel: acpi0: Power Button (fixed)
Sep  8 15:51:17  kernel: Timecounter "ACPI-safe" frequency 3579545 Hz quality 
850
Sep  8 15:51:17  kernel: acpi_timer0: <32-bit timer at 3.579545MHz> port 
0x908-0x90b on acpi0
Sep  8 15:51:17  kernel: pcib0:  on acpi0
Sep  8 15:51:17  kernel: pci0:  on pcib0
Sep  8 15:51:17  kernel: pcib1:  at device 3.0 on pci0
Sep  8 15:51:17  kernel: pci1:  on pcib1
Sep  8 15:51:17  kernel: ohci0:  mem 
0xf7cf-0xf7cf0fff irq 19 at device 0.0 on pci1
Sep  8 15:51:17  kernel: ohci0: [ITHREAD]
Sep  8 15:51:17  kernel: usbus0:  on ohci0
Sep  8 15:51:17  kernel: ohci1:  mem 
0xf7ce-0xf7ce0fff irq 19 at device 0.1 on pci1
Sep  8 15:51:17  kernel: ohci1: [ITHREAD]
Sep  8 15:51:17  kernel: usbus1:  on ohci1
Sep  8 15:51:17  kernel: pci1:  at device 2.0 (no driver 
attached)
Sep  8 15:51:17  kernel: pci1:  at device 2.2 (no driver 
attached)
Sep  8 15:51:17  kernel: vgapci0:  port 0x4400-0x44ff 
mem 0xf600-0xf6ff,0xf5ff-0xf5ff0fff at device 3.0 on pci1
Sep  8 15:51:17  kernel: isab0:  at device 4.0 on pci0
Sep  8 15:51:17  kernel: isa0:  on isab0
Sep  8 15:51:17  kernel: atapci0:  port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x2000-0x200f at device 4.1 on pci0
Sep  8 15:51:17  kernel: ata0:  on atapci0
Sep  8 15:51:17  kernel: ata0: [ITHREAD]
Sep  8 15:51:17  kernel: ata1:  on atapci0
Sep  8 15:51:17  kernel: ata1: [ITHREAD]
Sep  8 15:51:17  kernel: pci0:  at device 4.3 (no driver attached)
Sep  8 15:51:17  kernel: pcib2:  at device 7.0 on pci0
Sep  8 15:51:17  kernel: pci2:  on pcib2
Sep  8 15:51:17  kernel: ciss0:  port 0x5000-0x50ff mem 
0xf7df-0xf7df1fff,0xf7d8-0xf7db irq 24 at device 4.0 on pci2
Sep  8 15:51:17  kernel: ciss0: PERFORMANT Transport
Sep  8 15:51:17  kernel: ciss0: [ITHREAD]
Sep  8 15:51:17  kernel: pcib3:  at device 8.0 on pci0
Sep  8 15:51:17  kernel: pci3:  on pcib3
Sep  8 15:51:17  kernel: bge0:  mem 0xf7ef-0xf7ef irq 28 at device 6.0 on pci3
Sep  8 15:51:17  kernel: miibus0:  on bge0
Sep  8 15:51:17  kernel: brgphy0:  PHY 1 on 
miibus0
Sep  8 15:51:17  kernel: brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 
100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
Sep  8 15:51:17  kernel: bge0: Ethernet address: 00:17:a4:a7:eb:e4
Sep  8 15:51:17  kernel: bge0: [ITHREAD]
Sep  8 15:51:17  kernel: bge1:  mem 0xf7ee-0xf7ee irq

Re: em driver input errors

2009-09-09 Thread Mike Tancsa


At 07:47 AM 9/9/2009, Barney Cordoba wrote:
   www.sentex.net/mike > > > > > > The 8241GI may not be able to 
handle full gigabit flows if > its only > wired at 32-bit 33Mhz, 
which is only capable of bursting to > 1Gb/s. With > a single NIC 
it likely just fine, but it a bridged or > firewall type > config 
you may just be seeing bus failures. > > Barney I meant 
82541EI...Same answer.



Both of the NICs on this motherboard are wired in.  I will see if 
there is a spare pcie slot and try a different em nic.  Its also a 
single nic. No bridge or forwarding as all the packets are destined 
to the machine itself.


---Mike


___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"



Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: em driver input errors

2009-09-09 Thread Barney Cordoba



--- On Wed, 9/9/09, Mike Tancsa  wrote:

> From: Mike Tancsa 
> Subject: Re: em driver input errors
> To: "Barney Cordoba" 
> Cc: freebsd-net@freebsd.org
> Date: Wednesday, September 9, 2009, 9:55 AM
> At 07:47 AM 9/9/2009, Barney Cordoba
> wrote:
> >    www.sentex.net/mike > > > >
> > > The 8241GI may not be able to handle full gigabit
> flows if > its only > wired at 32-bit 33Mhz, which is
> only capable of bursting to > 1Gb/s. With > a single
> NIC it likely just fine, but it a bridged or > firewall
> type > config you may just be seeing bus failures. >
> > Barney I meant 82541EI...Same answer.
> 
> 
> Both of the NICs on this motherboard are wired in.  I
> will see if there is a spare pcie slot and try a different
> em nic.  Its also a single nic. No bridge or forwarding
> as all the packets are destined to the machine itself.
> 
>         ---Mike
> 
> > ___
> > freebsd-net@freebsd.org
> mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
> 
> 
> Mike Tancsa,           
>                
>           tel +1 519 651 3400
> Sentex Communications,         
>                
>   m...@sentex.net
> Providing Internet since 1994       
>             www.sentex.net
> Cambridge, Ontario Canada         

A quick test would be to force it to 100Mb/s to see if the problem goes
away.  I see you are using em1 which implies another NIC...if you have
traffic on the other lan its not much different than

Also, realize that most pciX busses are shared. So your disk and other
devices may be sharing. Its really derilect for these MB manufacturers
to sell dual gig nic systems and them wire them to a slow bus. But its
what they do.

Barney



___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: kern/138652: TCP window scaling value calculated incorrectly?

2009-09-09 Thread gavin

Old Synopsis: TCP window scaling value
New Synopsis: TCP window scaling value calculated incorrectly?

State-Changed-From-To: feedback->open
State-Changed-By: gavin
State-Changed-When: Wed Sep 9 14:24:24 UTC 2009
State-Changed-Why: 
Over to maintainer(s) for investigation


Responsible-Changed-From-To: gavin->freebsd-net
Responsible-Changed-By: gavin
Responsible-Changed-When: Wed Sep 9 14:24:24 UTC 2009
Responsible-Changed-Why: 
Feedback was received, thanks!

http://www.freebsd.org/cgi/query-pr.cgi?pr=138652
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: kern/138660: [igb] igb driver troubles in 8.0-BETA4

2009-09-09 Thread linimon

Old Synopsis: igb driver troubles in 8.0-BETA4
New Synopsis: [igb] igb driver troubles in 8.0-BETA4

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Wed Sep 9 14:29:34 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=138660
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: kern/138652: TCP window scaling value

2009-09-09 Thread Gaurav Goel

The following reply was made to PR kern/138652; it has been noted by GNATS.

From: Gaurav Goel 
To: bug-follo...@freebsd.org
Cc:  
Subject: Re: kern/138652: TCP window scaling value
Date: Wed, 9 Sep 2009 19:19:58 +0530

 --000feaef6808cf00280473255b4d
 Content-Type: text/plain; charset=UTF-8
 
 Dear Gavin,
 
 Version- Revision *1.192.2.1 *(check it on link "
 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_usrreq.c";)
 File- "src/sys/netinet/tcp_usrreq.c"
 Line No- 1101
 
 Problem described as above
 
 Thanks,
 Gaurav Goel
 
 On Wed, Sep 9, 2009 at 6:13 PM,  wrote:
 
 > Synopsis: TCP window scaling value
 >
 > State-Changed-From-To: open->feedback
 > State-Changed-By: gavin
 > State-Changed-When: Wed Sep 9 12:38:16 UTC 2009
 > State-Changed-Why:
 > To submitter: Firstly, tcp_input.c-orig is not a file distributed with
 > FreeBSD.  I suspect this is left over from a failed patch attempt to
 > src/sys/netinet/tcp_input.c.  Can you confirm that the problem exists
 > in that file?  Can you also please give the version number of the copy
 > you are looking at, and the line numbers where the problem occurs?
 > Thanks!
 >
 >
 > Responsible-Changed-From-To: freebsd-bugs->gavin
 > Responsible-Changed-By: gavin
 > Responsible-Changed-When: Wed Sep 9 12:38:16 UTC 2009
 > Responsible-Changed-Why:
 > Track
 >
 > http://www.freebsd.org/cgi/query-pr.cgi?pr=138652
 >
 
 
 
 -- 
 Gaurav Goel
 
 --000feaef6808cf00280473255b4d
 Content-Type: text/html; charset=UTF-8
 Content-Transfer-Encoding: quoted-printable
 
 Dear Gavin,Version- Revision 1.192.2.1 (check it on link &qu=
 ot;http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_usr=
 req.c">http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_usrreq.c")
 File- "src/sys/netinet/tcp_usrreq.c"Line No- 1101Prob=
 lem described as aboveThanks,Gaurav GoelOn Wed, Sep 9, 2009 at 6:13 PM,  ga...@freebsd.org> wrote:
 Synopsis: TCP win=
 dow scaling value
 
 State-Changed-From-To: open->feedback
 State-Changed-By: gavin
 State-Changed-When: Wed Sep 9 12:38:16 UTC 2009
 State-Changed-Why:
 To submitter: Firstly, tcp_input.c-orig is not a file distributed with
 FreeBSD. =C2=A0I suspect this is left over from a failed patch attempt to
 src/sys/netinet/tcp_input.c. =C2=A0Can you confirm that the problem exists<=
 br>
 in that file? =C2=A0Can you also please give the version number of the copy=
 
 you are looking at, and the line numbers where the problem occurs?
 Thanks!
 
 
 Responsible-Changed-From-To: freebsd-bugs->gavin
 Responsible-Changed-By: gavin
 Responsible-Changed-When: Wed Sep 9 12:38:16 UTC 2009
 Responsible-Changed-Why:
 Track
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=3D138652"; target=3D"_=
 blank">http://www.freebsd.org/cgi/query-pr.cgi?pr=3D138652
 -- Gaurav Goel
 
 --000feaef6808cf00280473255b4d--
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: em driver input errors

2009-09-09 Thread Mike Tancsa


At 10:19 AM 9/9/2009, Barney Cordoba wrote:
test would be to force it to 100Mb/s to see if the problem goes 
away.  I see you are using em1 which implies another NIC...if you 
have traffic on the other lan its not much different than Also, 
realize that most pciX busses are shared. So your disk and other 
devices may be sharing. Its really derilect for these MB 
manufacturers to sell dual gig nic systems and them wire them to a 
slow bus. But its what they do. Barney



The other nic is not in use right now. I tried switching them so see 
if one would work better than the other, but I didnt see any difference.


The board is an intel

http://www.intel.com/support/motherboards/server/s3000ah/

Not sure if its wired as PCI-X or just a 32bit bus.  I am just 
popping in an em pcie nic to see if that makes a difference.  I have 
an igb as well as bge I can try later.


---Mike






___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"



Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: em driver input errors

2009-09-09 Thread Mike Tancsa


At 11:17 AM 9/9/2009, Mike Tancsa wrote:

The board is an intel

http://www.intel.com/support/motherboards/server/s3000ah/

Not sure if its wired as PCI-X or just a 32bit bus.  I am just 
popping in an em pcie nic to see if that makes a difference.  I have 
an igb as well as bge I can try later.


OK, now there is

e...@pci0:5:0:0: class=0x02 card=0xa01f8086 chip=0x10d38086 
rev=0x00 hdr=0x00

vendor = 'Intel Corporation'
class  = network
subclass   = ethernet
cap 01[c8] = powerspec 2  supports D0 D3  current D0
cap 05[d0] = MSI supports 1 message, 64 bit
cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)
cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled


em0:  port 0x3000-0x301f 
mem 0xea68-0xea69,0xea60-0xea67,0xea6a-0xea6a3fff 
irq 16 at device 0.0 on pci5

em0: Using MSIX interrupts
em0: [ITHREAD]
em0: [ITHREAD]
em0: [ITHREAD]
em0: Ethernet address: 

0[backup3]# vmstat -i
interrupt  total   rate
irq1: atkbd0   6  0
irq4: sio0   692  1
irq16: twa0 uhci3   3841 10
irq18: arcmsr0+ 7825 20
irq19: uhci1+  13144 34
irq23: uhci0 ehci0 1  0
cpu0: timer   73   1988
irq256: em0 3890 10
irq257: em0 3607  9
irq258: em01  0
cpu1: timer   745924   1962
cpu2: timer   747100   1966
cpu3: timer   747671   1967
Total3029255   7971


Lets see how it does :)

---Mike



Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

misc/138676: after buildworld not work local routes

2009-09-09 Thread Vladislav V. Prodan


Number: 138676
Category:   misc
Synopsis:   after buildworld not work local routes
Confidential:   no
Severity:   serious
Priority:   medium
Responsible:freebsd-bugs
State:  open
Quarter:
Keywords:   
Date-Required:

Class:  sw-bug
Submitter-Id:   current-users
Arrival-Date:   Wed Sep 09 19:00:04 UTC 2009
Closed-Date:
Last-Modified:
Originator: Vladislav V. Prodan
Release:FreeBSD 8.0-BETA4 #0: Wed Sep  9 00:53:41 EEST 2009 amd64
Organization:
Environment:
FreeBSD mary-teresa.otrada.od.ua 8.0-BETA4 FreeBSD 8.0-BETA4 #0: Wed Sep 
 9 00:53:41 EEST 2009 
vla...@mary-teresa.otrada.od.ua:/usr/obj/usr/src/sys/mary-teresa.17  amd64



Description:

home PC --> FreeBSD [ squid --> apache ]

These url are on the external interface of the server.
http://otrada.od.ua/blog/
http://otrada.od.ua/phpmyadmin/
http://otrada.od.ua/cacti/

After upgrade the system now gives the squid:
(51) Network is unreachable

In logs:
sep  9 18:39:10 128 10.0.0.10 TCP_MISS/503 1317 GET 
http://otrada.od.ua/blog/ - DIRECT/otrada.od.ua text/html
sep  9 18:39:18 126 10.0.0.10 TCP_MISS/503 1329 GET 
http://otrada.od.ua/phpmyadmin/ - DIRECT/otrada.od.ua text/html
sep  9 18:39:39 117 10.0.0.10 TCP_MISS/503 1319 GET 
http://otrada.od.ua/cacti/ - DIRECT/otrada.od.ua text/html


Out all three url normally give details.
At queries from outside, all url are working properly.

similar problem was previously:
http://lists.freebsd.org/pipermail/freebsd-current/2008-December/001581.html

How-To-Repeat:



Fix:




Release-Note:
Audit-Trail:
Unformatted:






___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

RE: misc/138676: after buildworld not work local routes

2009-09-09 Thread Li, Qing

Thanks for the report. I will work you off list for now.

-- Qing


> -Original Message-
> From: Vladislav V. Prodan [mailto:univers...@ukr.net]
> Sent: Wednesday, September 09, 2009 12:05 PM
> To: freebsd-curr...@freebsd.org; freebsd-net@freebsd.org
> Cc: Li, Qing
> Subject: misc/138676: after buildworld not work local routes
> 
> >Number: 138676
> >Category:   misc
> >Synopsis:   after buildworld not work local routes
> >Confidential:   no
> >Severity:   serious
> >Priority:   medium
> >Responsible:freebsd-bugs
> >State:  open
> >Quarter:
> >Keywords:
> >Date-Required:
> >Class:  sw-bug
> >Submitter-Id:   current-users
> >Arrival-Date:   Wed Sep 09 19:00:04 UTC 2009
> >Closed-Date:
> >Last-Modified:
> >Originator: Vladislav V. Prodan
> >Release:FreeBSD 8.0-BETA4 #0: Wed Sep  9 00:53:41 EEST 2009
> amd64
> >Organization:
> >Environment:
> FreeBSD mary-teresa.otrada.od.ua 8.0-BETA4 FreeBSD 8.0-BETA4 #0: Wed
> Sep
>   9 00:53:41 EEST 2009
> vla...@mary-teresa.otrada.od.ua:/usr/obj/usr/src/sys/mary-teresa.17
> amd64
> 
> >Description:
> home PC --> FreeBSD [ squid --> apache ]
> 
> These url are on the external interface of the server.
> http://otrada.od.ua/blog/
> http://otrada.od.ua/phpmyadmin/
> http://otrada.od.ua/cacti/
> 
> After upgrade the system now gives the squid:
>  (51) Network is unreachable
> 
> In logs:
> sep  9 18:39:10 128 10.0.0.10 TCP_MISS/503 1317 GET
> http://otrada.od.ua/blog/ - DIRECT/otrada.od.ua text/html
> sep  9 18:39:18 126 10.0.0.10 TCP_MISS/503 1329 GET
> http://otrada.od.ua/phpmyadmin/ - DIRECT/otrada.od.ua text/html
> sep  9 18:39:39 117 10.0.0.10 TCP_MISS/503 1319 GET
> http://otrada.od.ua/cacti/ - DIRECT/otrada.od.ua text/html
> 
> Out all three url normally give details.
> At queries from outside, all url are working properly.
> 
> similar problem was previously:
> http://lists.freebsd.org/pipermail/freebsd-current/2008-
> December/001581.html
> >How-To-Repeat:
> 
> >Fix:
> 
> 
> >Release-Note:
> >Audit-Trail:
> >Unformatted:
> 
> 
> 
> 

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: kern/138666: [multicast] [panic] not working multicast through igmpproxy

2009-09-09 Thread linimon

Old Synopsis: Do not working multicast through igmpproxy
New Synopsis: [multicast] [panic] not working multicast through igmpproxy

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Wed Sep 9 19:19:45 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=138666
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: kern/138676: [route] after buildworld not work local routes [regression]

2009-09-09 Thread linimon

Old Synopsis: after buildworld not work local routes
New Synopsis: [route] after buildworld not work local routes [regression]

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Wed Sep 9 19:23:00 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=138676
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

NFSROOT is broken after r196714

2009-09-09 Thread Oleksandr Tymoshenko


r196714 breaks NFSROOT in -CURRENT. When nfsclient tries to
initialize interface calling ifioctl at nfsclient/nfs_vfsops.c:466
it fails with EEXIST (because route is already present I guess).

I fixed it in my tree by checking for error code in mount_nfsroot,
but may be it's ifioctl(SIOCAIFADDR) that should handle this case.

--
gonzo
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

RE: NFSROOT is broken after r196714

2009-09-09 Thread Li, Qing

Do you know what IP address nfsclient/nfs_vfsops.c:466 is trying to 
insert and do you have an output of the "ifconfig" and route 
table you can send to me privately?

At the moment I am suspecting r196714 uncovered an issue that has
always been there. But that's an assumption at the moment.

Thanks,

-- Qing


> -Original Message-
> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
> n...@freebsd.org] On Behalf Of Oleksandr Tymoshenko
> Sent: Wednesday, September 09, 2009 12:19 PM
> To: freebsd-net@freebsd.org
> Subject: NFSROOT is broken after r196714
> 
> r196714 breaks NFSROOT in -CURRENT. When nfsclient tries to
> initialize interface calling ifioctl at nfsclient/nfs_vfsops.c:466
> it fails with EEXIST (because route is already present I guess).
> 
> I fixed it in my tree by checking for error code in mount_nfsroot,
> but may be it's ifioctl(SIOCAIFADDR) that should handle this case.
> 
> --
> gonzo
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: kern/138678: [lo] FreeBSD does not assign linklocal address to loopbacks >0

2009-09-09 Thread linimon

Old Synopsis: FreeBSD does not assign linklocal address to loopbacks >0
New Synopsis: [lo] FreeBSD does not assign linklocal address to loopbacks >0

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Wed Sep 9 20:05:49 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=138678
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: misc/138676: after buildworld not work local routes

2009-09-09 Thread Vladislav V. Prodan

The following reply was made to PR kern/138676; it has been noted by GNATS.

From: "Vladislav V. Prodan" 
To: "Li, Qing" , freebsd-curr...@freebsd.org
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: misc/138676: after buildworld not work local routes
Date: Wed, 09 Sep 2009 23:18:34 +0300

 Li, Qing Ð¿Ð¸ÑÐµÑ:
 > Okay, perhaps I didn't understand your issue correctly. In

 > http://lists.freebsd.org/pipermail/freebsd-current/2008-December/001581.html

 > the errors are route insertion related. Those routes are not
 > visible inside the kernel. Now these routes show up in the
 > table but Squid reports

 > " After upgrade the system now gives the squid:
 >  (51) Network is unreachable"

 > Which IP address is not reachable?

 Do not operate sites on IP 89.209.81.54, when you walk through the squid.
 If you go to the sites, bypassing squid, then everything works.

 It seems, squid does not "see" the table of the form:
 DestinationGatewayFlagsRefs  Use  Netif Expire
 89.209.81.54   link#4 UHS 030161lo0
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[patch] Multicast: uninited memory used in filter at IP_DROP_MEMBERSHIP + IP_ADD_MEMBERSHIP

2009-09-09 Thread Stef Walter

If a multicast caller does an IP_DROP_MEMBERSHIP followed by a
IP_ADD_MEMBERSHIP, often an uninitialized filter is used for the
in_mfilter passed to in_joingroup_locked() in netinet/in_mcast.c.

The IP_ADD_MEMBERSHIP and IP_DROP_MEMBERSHIP have simple in_mreq input,
and are not using SSM or any of the new IGMPv3 features.

This results in the following behavior shown by ifmcstat. Before the
drop + add you can see the following groups for the northstar1
interface. Note that 224.0.0.5 (ie: OSPF-ALL.MCAST.NET) is subscribed
with an empty exclude filter as you would expect from simple ASM mode:

> # ifmcstat -i northstar1
> northstar1:
>   inet 172.28.1.66
>   igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
>   group 224.0.0.5 mode exclude
>   group 224.0.0.1 mode exclude

After the drop + add, it looks like the following. Note that now
224.0.0.5 is subscribed with an empty *include* filter which results in
no packets received.

> # ifmcstat -i northstar1
> northstar1:
>   inet 172.28.1.66
>   igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
>   group 224.0.0.1 mode exclude
>   group 224.0.0.5 mode include

uname: FreeBSD portillo-gate.ws.local 8.0-BETA3 FreeBSD 8.0-BETA3 #24:
Wed Sep  9 15:01:39 UTC 2009
r...@portillo-gate.ws.local:/usr/src/sys/i386/compile/PORTILLO  i386

Patch is attached which fixes the problem. Is this the right approach?
If not, I hope it helps highlight the problem area.

Cheers,

Stef

--- sys/netinet/in_mcast.c.orig	2009-08-03 08:13:06.0 +
+++ sys/netinet/in_mcast.c	2009-09-09 15:01:24.0 +
@@ -2024,6 +2050,9 @@
 			error = ENOMEM;
 			goto out_imo_free;
 		}
+	} else if (is_new) {
+		/* Old style ASM filter mode is always exclude */
+		imf_init(imf, MCAST_UNDEFINED, MCAST_EXCLUDE);
 	}
 
 	/*

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: [patch] Multicast: uninited memory used in filter at IP_DROP_MEMBERSHIP + IP_ADD_MEMBERSHIP

2009-09-09 Thread Bruce Simpson


Stef Walter wrote:

...
Patch is attached which fixes the problem. Is this the right approach?
If not, I hope it helps highlight the problem area.
  


Good catch; thanks for the fix. I used to depend on imf being 
initialized to NULL in this function, however, I opted to keep the old 
vector-style allocation scheme for in_mfilter and track it with in_multi 
on the socket. If the descriptor slot got recycled, then the imf 
contents will be invalid as you saw.


I think this can probably go right in as-is. I'm supposed to be looking 
at other stuff now, so hopefully syrinx@ can check this in if I don't 
get around to it.


thanks,
BMS
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: [patch] Multicast: uninited memory used in filter at IP_DROP_MEMBERSHIP + IP_ADD_MEMBERSHIP

2009-09-09 Thread Stef Walter

Bruce Simpson wrote:
> I think this can probably go right in as-is. I'm supposed to be looking
> at other stuff now, so hopefully syrinx@ can check this in if I don't
> get around to it.

Great news. Should I just make a PR for this? Or is there somewhere I
should put it for the 8.0 BETA?

After these various (posted) multicast patches OSPF (with quagga) is now
far more stable on 8.0-BETA4. However I'm still seeing intermittent
problems. I need help in knowing how to debug the following. Once it's
figured out, I'd like to make a patch.

Specifically:

Quagga has a sockets open on em0, portillo1, and northstar1 below on the
224.0.0.5 group. ifmcstat output:

> em0:
>   inet 172.27.2.1
>   igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
>   group 224.0.0.5 mode exclude
>   mcast-macaddr 01:00:5e:00:00:05
>   group 224.0.0.1 mode exclude
>   mcast-macaddr 01:00:5e:00:00:01
> em1:
>   inet 189.162.25.187
>   igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
>   group 224.0.0.1 mode exclude
>   mcast-macaddr 01:00:5e:00:00:01
> lo0:
>   inet 127.0.0.1
>   igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
>   group 224.0.0.1 mode exclude
>   inet6 fe80::1%lo0
>   mldv2 flags=0<> rv 2 qi 125 qri 10 uri 3
>   group ff01::1%lo0 mode exclude
>   group ff02::2:10c2:bd48%lo0 mode exclude
>   group ff02::1%lo0 mode exclude
>   group ff02::1:ff00:1%lo0 mode exclude
> leaseweb0:
>   inet 10.94.75.3
>   igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
>   group 224.0.0.1 mode exclude
>   mcast-macaddr 01:00:5e:00:00:01
> portillo1:
>   inet 172.28.1.65
>   igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
>   group 224.0.0.5 mode exclude
>   group 224.0.0.1 mode exclude
> eaglecrest1:
>   inet 172.28.1.70
>   igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
>   group 224.0.0.5 mode exclude
>   group 224.0.0.1 mode exclude

After a while and a few interface ups and downs, quagga stops getting
OSPF packets on one of the interfaces. I can verify with tcpdump that
these packets are seen by the machine. For example, on em0:

> # tcpdump -pnti em0 proto ospf
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes
> IP 172.27.2.1 > 224.0.0.5: OSPFv2, Hello, length 44
> IP 172.27.2.2 > 224.0.0.5: OSPFv2, Hello, length 48
> IP 172.27.2.1 > 224.0.0.5: OSPFv2, Hello, length 44
> IP 172.27.2.2 > 224.0.0.5: OSPFv2, Hello, length 48
> IP 172.27.2.1 > 224.0.0.5: OSPFv2, Hello, length 44
> IP 172.27.2.2 > 224.0.0.5: OSPFv2, Hello, length 48
> IP 172.27.2.1 > 224.0.0.5: OSPFv2, Hello, length 44
> IP 172.27.2.2 > 224.0.0.5: OSPFv2, Hello, length 48

The packets from 172.27.2.2 are not being delivered to the ospfd process
socket (verified via userland debugging and logging). Even though, as
you can see above the em0 interface is part of the group.

Where and how could I see what's preventing these packets from being
delivered to the ospfd process socket? Which code is involved in the
dispatch?

Thanks for your help and time. Much appreciated.

Cheers,

Stef

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: kern/64556: [sis] if_sis short cable fix problems with NetGear FA311's

2009-09-09 Thread Bruce Cran

The following reply was made to PR kern/64556; it has been noted by GNATS.

From: Bruce Cran 
To: bug-follo...@freebsd.org, t...@hur.st
Cc:  
Subject: Re: kern/64556: [sis] if_sis short cable fix problems with NetGear
 FA311's
Date: Thu, 10 Sep 2009 02:24:17 +0100

 I'm still seeing this problem on 8.0-BETA4. Running two ttcp's (one rx,
 one tx) causes the system to print lots of "Applying short cable fix"
 messages.  I've had a look through the NetBSD driver, the original
 Linux driver from http://www.soekris.com/downloads.htm and also the
 latest Linux sources.  

 When the issue occurs, I see throughput drop to around 5Mb.  The first
 issues seems to be the 100ms delay. From the other code I've looked at,
 it looks like it should be 100us which would speed up the reset
 process. Secondly, it seems that only FreeBSD resets the chip when an
 RX overrun occurs; on NetBSD it does a printf and continues, and Linux
 increments the error statistics.  Both only apply the short cable fix
 when a media change occurs.

 -- 
 Bruce Cran
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Multicast SSM bug?

2009-09-09 Thread Stef Walter

Stef Walter wrote:
> The packets from 172.27.2.2 are not being delivered to the ospfd process
> socket (verified via userland debugging and logging). Even though, as
> you can see above the em0 interface is part of the group.

I've done more research on this.

Each time a packet is not delivered, I can see this counter being
incremented:

> # netstat -s -p ip | grep multicast
>   885 packets received for unknown multicast group

That counter originates from this block of code in raw_ip.c:

>   354   blocked = imo_multi_filter(inp->inp_moptions, ifp,
>   355   (struct sockaddr *)&group,
>   356   (struct sockaddr *)&ripsrc);
>   357   if (blocked != MCAST_PASS) {
>   358   IPSTAT_INC(ips_notmember);
>   359   continue;
>   360   }

After instrumenting it with this printf:

> printf("not member: group = %s, ", inet_ntoa (group.sin_addr));
> printf("src = %s, why = %d\n", inet_ntoa (ripsrc.sin_addr), (int)blocked);

Then wait, then up down some interfaces, etc quagga adds/drops
memberships, eventually I see the following output:

> not member: group = 224.0.0.5, src = 172.28.1.66, why = 2
> not member: group = 224.0.0.5, src = 172.28.1.66, why = 2
> not member: group = 224.0.0.5, src = 172.28.1.66, why = 2
> not member: group = 224.0.0.5, src = 172.28.1.66, why = 2
> not member: group = 224.0.0.5, src = 172.28.1.66, why = 2
> not member: group = 224.0.0.5, src = 172.28.1.66, why = 2

The why = 2 is MCAST_NOTSMEMBER. 172.28.1.66 is the tunnel peer sending
OSPF multicast packets. Somehow imo_multi_filter is limiting via packet
source for this membership. However, this is what the interface looks
like via ifmcstat (ie: no SSM memberships):

> portillo1:
>   inet 172.28.1.65
>   igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
>   group 224.0.0.5 mode exclude
>   group 224.0.0.1 mode exclude

Any of the above ring a bell? If not, I'll keep poking around and see
what I find.

Cheers,

Stef

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

forwarding when two rip defaults

2009-09-09 Thread Randy Bush

say i run routed and receive rip default from two routers, on the same
local ether.  what is the forwarding?  i presume it's not smart enough
to balance flows.  i hope not alternating packets.  clue, please?

fwiw, the routers each have full bgp exits.  vrrp would force all
traffic to one.  so i am looking at rip or quagga's isisd.

thanks.

randy
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: forwarding when two rip defaults

2009-09-09 Thread Julian Elischer


Randy Bush wrote:

say i run routed and receive rip default from two routers, on the same
local ether.  what is the forwarding?  i presume it's not smart enough
to balance flows.  i hope not alternating packets.  clue, please?

fwiw, the routers each have full bgp exits.  vrrp would force all
traffic to one.  so i am looking at rip or quagga's isisd.

thanks.

randy
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


I can't speak for routed but the base system, given two default routes 
would use a hashing schemem to send data to both.


more details depend on what options you have turned on.

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: forwarding when two rip defaults

2009-09-09 Thread Randy Bush

>> say i run routed and receive rip default from two routers, on the same
>> local ether.  what is the forwarding?  i presume it's not smart enough
>> to balance flows.  i hope not alternating packets.  clue, please?
> I can't speak for routed

routed is just the routing protocol used to garner the routes installed
in the fib.  so it should not be of concern.

> the base system, given two default routes would use a hashing schemem
> to send data to both.  more details depend on what options you have
> turned on.

is there a doc page somewhere?

thanks.

randy
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[patch] Multicast: Keep membership and filters in sync

2009-09-09 Thread Stef Walter

When removing multicast membership from a socket (ie:
IP_DROP_MEMBERSHIP) that has multiple multicast memberships, the
internal list of memberships and filters are not kept in sync.

This results in dropped packets that are not delivered to the socket
that has the multicast membership. This was experienced with OSPF
(running quagga).

Besides the obvious non-functional multicast, the following command is
another way to see an indication of the problem:

> # netstat -s -p ip | grep multicast
>   7 packets received for unknown multicast group

Patch attached which fixes the problem.

Cheers,

Stef
--- sys/netinet/in_mcast.c.orig	2009-09-09 19:33:22.0 +
+++ sys/netinet/in_mcast.c	2009-09-10 05:28:20.0 +
@@ -2280,7 +2292,9 @@
 
 	if (is_final) {
-		/* Remove the gap in the membership array. */
-		for (++idx; idx < imo->imo_num_memberships; ++idx)
+		/* Remove the gap in the membership and filter array. */
+		for (++idx; idx < imo->imo_num_memberships; ++idx) {
 			imo->imo_membership[idx-1] = imo->imo_membership[idx];
+			imo->imo_mfilters[idx-1] = imo->imo_mfilters[idx];
+		}
 		imo->imo_num_memberships--;
 	}
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

RE: forwarding when two rip defaults

2009-09-09 Thread Li, Qing

What release are you running ?

-- Qing

> -Original Message-
> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
> n...@freebsd.org] On Behalf Of Randy Bush
> Sent: Wednesday, September 09, 2009 10:22 PM
> To: freebsd-net
> Subject: forwarding when two rip defaults
> 
> say i run routed and receive rip default from two routers, on the same
> local ether.  what is the forwarding?  i presume it's not smart enough
> to balance flows.  i hope not alternating packets.  clue, please?
> 
> fwiw, the routers each have full bgp exits.  vrrp would force all
> traffic to one.  so i am looking at rip or quagga's isisd.
> 
> thanks.
> 
> randy
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: em driver input errors

Re: em driver input errors

8.0-B4, Broadcom bge0 not working, HP Proliant DL385, amd64

Re: em driver input errors

Re: em driver input errors

Re: kern/138652: TCP window scaling value calculated incorrectly?

Re: kern/138660: [igb] igb driver troubles in 8.0-BETA4

Re: kern/138652: TCP window scaling value

Re: em driver input errors

Re: em driver input errors

misc/138676: after buildworld not work local routes

RE: misc/138676: after buildworld not work local routes

Re: kern/138666: [multicast] [panic] not working multicast through igmpproxy

Re: kern/138676: [route] after buildworld not work local routes [regression]

NFSROOT is broken after r196714

RE: NFSROOT is broken after r196714

Re: kern/138678: [lo] FreeBSD does not assign linklocal address to loopbacks >0

Re: misc/138676: after buildworld not work local routes

[patch] Multicast: uninited memory used in filter at IP_DROP_MEMBERSHIP + IP_ADD_MEMBERSHIP

Re: [patch] Multicast: uninited memory used in filter at IP_DROP_MEMBERSHIP + IP_ADD_MEMBERSHIP

Re: [patch] Multicast: uninited memory used in filter at IP_DROP_MEMBERSHIP + IP_ADD_MEMBERSHIP

Re: kern/64556: [sis] if_sis short cable fix problems with NetGear FA311's

Re: Multicast SSM bug?

forwarding when two rip defaults

Re: forwarding when two rip defaults

Re: forwarding when two rip defaults

[patch] Multicast: Keep membership and filters in sync

RE: forwarding when two rip defaults

28 matches

Site Navigation

Mail list logo

Footer information