Re: kern/153594: [iwn] Network keeps disconnecting when /etc/rc.d/netif restart is run
On Tuesday, January 04, 2011 09:08:24 Eugene Grosbein wrote: > > There is race in devd and our rc-subsystem if wpa_supplicant is involved > > effectivly resulting in starting wpa_supplicant twice. Both instances try > > to take over the wlan device which results in what you are seeing. > > I have no idea how to fix this right now, so this has to wait until I'm > > able to think of proper fix. > > Perhaps, wrapping wpa_supplicant invocation into "lockf -t0" would help > to eliminate race? Possibly, but I don't think this is the way to go. Currently wpa_supplicant has this code: /* * Mark the interface as down to ensure wpa_supplicant has exclusive * access to the net80211 state machine, do this before opening the * route socket to avoid a false event that the interface disappeared. */ if (getifflags(drv, &flags) == 0) (void) setifflags(drv, flags &~ IFF_UP); This code works such that it will send an event to already running wpa_supplicant instances which will then terminate. This does indeed work if there's enough delay between invocations, though, if there is just a small delay (~100ms or something), that event doesn't get passed probably. I think we should start looking into possible solution at that point, trying to figure out why the the event doesn't get passed (probably because the interface is not yet up at that point) will get us closer to proper solution. -- Bernhard ___ 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/153594: [iwn] Network keeps disconnecting when /etc/rc.d/netif restart is run
On 04.01.2011 15:06, Bernhard Schmidt wrote: >> Perhaps, wrapping wpa_supplicant invocation into "lockf -t0" would help >> to eliminate race? > > Possibly, but I don't think this is the way to go. > > Currently wpa_supplicant has this code: > /* > * Mark the interface as down to ensure wpa_supplicant has exclusive > * access to the net80211 state machine, do this before opening the > * route socket to avoid a false event that the interface disappeared. > */ > if (getifflags(drv, &flags) == 0) > (void) setifflags(drv, flags &~ IFF_UP); > > This code works such that it will send an event to already running > wpa_supplicant instances which will then terminate. This does indeed work if > there's enough delay between invocations, though, if there is just a small > delay (~100ms or something), that event doesn't get passed probably. I think > we should start looking into possible solution at that point, trying to > figure > out why the the event doesn't get passed (probably because the interface is > not yet up at that point) will get us closer to proper solution. Proper fine-grained locking was always good solution for race problem :-) How about using flock(2) in wpa_supplicant source code? Eugene Grosbein ___ 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/153594: [iwn] Network keeps disconnecting when /etc/rc.d/netif restart is run
On Tuesday, January 04, 2011 10:09:15 Eugene Grosbein wrote: > On 04.01.2011 15:06, Bernhard Schmidt wrote: > >> Perhaps, wrapping wpa_supplicant invocation into "lockf -t0" would help > >> to eliminate race? > > > > Possibly, but I don't think this is the way to go. > > > > Currently wpa_supplicant has this code: > > /* > > > > * Mark the interface as down to ensure wpa_supplicant has > > exclusive * access to the net80211 state machine, do this > > before opening the * route socket to avoid a false event that > > the interface disappeared. */ > > > > if (getifflags(drv, &flags) == 0) > > > > (void) setifflags(drv, flags &~ IFF_UP); > > > > This code works such that it will send an event to already running > > wpa_supplicant instances which will then terminate. This does indeed work > > if there's enough delay between invocations, though, if there is just a > > small delay (~100ms or something), that event doesn't get passed > > probably. I think we should start looking into possible solution at that > > point, trying to figure out why the the event doesn't get passed > > (probably because the interface is not yet up at that point) will get us > > closer to proper solution. > > Proper fine-grained locking was always good solution for race problem :-) > How about using flock(2) in wpa_supplicant source code? I don't see any flock'able resource shared between instances, do you? -- Bernhard ___ 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/153594: [iwn] Network keeps disconnecting when /etc/rc.d/netif restart is run
On 04.01.2011 15:39, Bernhard Schmidt wrote: >> Proper fine-grained locking was always good solution for race problem :-) >> How about using flock(2) in wpa_supplicant source code? > > I don't see any flock'able resource shared between instances, do you? Just use pidfile(3) :-) ___ 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"
tcp implementation source code
I would like to know where I can find the source code for the TCP implementation so I can do some hacking on it. ___ 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: please review my ppp(8) patch
*bump* On 10/29/10 02:17, Aragon Gouveia wrote: http://www.freebsd.org/cgi/query-pr.cgi?pr=151400 ___ 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: tcp implementation source code
On 01/04/2011 04:46, Mickey Harvey wrote: > I would like to know where I can find the source code for the TCP > implementation so I can do some hacking on it. Have you looked through the repository at all ? http://svn.freebsd.org/ -- Regards, jhell,v JJH48-ARIN ___ 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: igb watchdog timeouts
I get them as well... on my em devices. I was just thinking of upgrading to a dual port igb I have kicking around, but your email is not encouraging. :) # grep watchdog /var/log/message Jan 2 21:13:38 turtle kernel: em5: watchdog timeout -- resetting Jan 3 04:31:37 turtle kernel: em4: watchdog timeout -- resetting Jan 3 09:41:09 turtle kernel: em4: watchdog timeout -- resetting Jan 3 12:05:05 turtle kernel: em4: watchdog timeout -- resetting Jan 4 10:29:58 turtle kernel: em1: watchdog timeout -- resetting Jan 4 15:36:19 turtle kernel: em5: watchdog timeout -- resetting Jan 4 16:09:51 turtle kernel: em5: watchdog timeout -- resetting Jan 4 18:28:48 turtle kernel: em5: watchdog timeout -- resetting Jan 4 18:33:41 turtle kernel: em5: watchdog timeout -- resetting Jan 4 19:18:35 turtle kernel: em4: watchdog timeout -- resetting Jan 4 19:26:21 turtle kernel: em5: watchdog timeout -- resetting Jan 4 19:27:25 turtle kernel: em5: watchdog timeout -- resetting Jan 4 19:33:33 turtle kernel: em5: watchdog timeout -- resetting Jan 4 19:40:54 turtle kernel: em5: watchdog timeout -- resetting Jan 4 19:50:45 turtle kernel: em5: watchdog timeouts = 129 Jan 4 19:54:33 turtle kernel: em0: watchdog timeouts = 0 Jan 4 19:54:39 turtle kernel: em1: watchdog timeouts = 13 Jan 4 19:54:41 turtle kernel: em2: watchdog timeouts = 0 Jan 4 19:54:44 turtle kernel: em3: watchdog timeouts = 0 Jan 4 19:54:46 turtle kernel: em4: watchdog timeouts = 121 stats info: Jan 4 19:50:45 turtle kernel: em5: Excessive collisions = 0 Jan 4 19:50:45 turtle kernel: em5: Sequence errors = 0 Jan 4 19:50:45 turtle kernel: em5: Defer count = 0 Jan 4 19:50:45 turtle kernel: em5: Missed Packets = 2280947 Jan 4 19:50:45 turtle kernel: em5: Receive No Buffers = 0 Jan 4 19:50:45 turtle kernel: em5: Receive Length Errors = 0 Jan 4 19:50:45 turtle kernel: em5: Receive errors = 0 Jan 4 19:50:45 turtle kernel: em5: Crc errors = 0 Jan 4 19:50:45 turtle kernel: em5: Alignment errors = 0 Jan 4 19:50:45 turtle kernel: em5: Collision/Carrier extension errors = 0 Jan 4 19:50:45 turtle kernel: em5: RX overruns = 115 Jan 4 19:50:45 turtle kernel: em5: watchdog timeouts = 129 Jan 4 19:50:45 turtle kernel: em5: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 Jan 4 19:50:45 turtle kernel: em5: XON Rcvd = 0 Jan 4 19:50:45 turtle kernel: em5: XON Xmtd = 0 Jan 4 19:50:45 turtle kernel: em5: XOFF Rcvd = 0 Jan 4 19:50:45 turtle kernel: em5: XOFF Xmtd = 0 Jan 4 19:50:45 turtle kernel: em5: Good Packets Rcvd = 23188157965 Jan 4 19:50:45 turtle kernel: em5: Good Packets Xmtd = 42184614153 Jan 4 19:50:45 turtle kernel: em5: TSO Contexts Xmtd = 52043 Jan 4 19:50:45 turtle kernel: em5: TSO Contexts Failed = 0 debug info: Jan 4 19:51:15 turtle kernel: em5: Adapter hardware address = 0xc51ca420 Jan 4 19:51:15 turtle kernel: em5: CTRL = 0x140248 RCTL = 0x8002 Jan 4 19:51:15 turtle kernel: em5: Packet buffer = Tx=20k Rx=12k Jan 4 19:51:15 turtle kernel: em5: Flow control watermarks high = 10240 low = 8740 Jan 4 19:51:15 turtle kernel: em5: tx_int_delay = 66, tx_abs_int_delay = 66 Jan 4 19:51:15 turtle kernel: em5: rx_int_delay = 32, rx_abs_int_delay = 66 Jan 4 19:51:15 turtle kernel: em5: fifo workaround = 0, fifo_reset_count = 0 Jan 4 19:51:15 turtle kernel: em5: hw tdh = 180, hw tdt = 180 Jan 4 19:51:15 turtle kernel: em5: hw rdh = 708, hw rdt = 707 Jan 4 19:51:15 turtle kernel: em5: Num Tx descriptors avail = 2048 Jan 4 19:51:15 turtle kernel: em5: Tx Descriptors not avail1 = 0 Jan 4 19:51:15 turtle kernel: em5: Tx Descriptors not avail2 = 0 Jan 4 19:51:15 turtle kernel: em5: Std mbuf failed = 0 Jan 4 19:51:15 turtle kernel: em5: Std mbuf cluster failed = 0 Jan 4 19:51:15 turtle kernel: em5: Driver dropped packets = 0 Jan 4 19:51:15 turtle kernel: em5: Driver tx dma failure in encap = 0 # pciconf -lv e...@pci0:5:0:0: class=0x02 card=0x10a48086 chip=0x10a48086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '82571EB Gigabit Ethernet Controller' class = network subclass = ethernet e...@pci0:5:0:1: class=0x02 card=0x10a48086 chip=0x10a48086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '82571EB Gigabit Ethernet Controller' class = network subclass = ethernet e...@pci0:6:0:0: class=0x02 card=0x10a48086 chip=0x10a48086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '82571EB Gigabit Ethernet Controller' class = network subclass = ethernet e...@pci0:6:0:1: class=0x02 card=0x10a48086 chip=0x10a48086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '82571EB Gigabit Ethernet Controller' class = network subclass = ethernet e...@pci0:13:0:0:class=0x02 card=0x108c15d9 chip=0x108c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82573E Intel Corporation 82573E Gigabit Ethernet Controller (Copper)' class = network
