Re: kern/138999: [libc] lighttpd/php-cgi with freebsd sendfile(2) enabled causing kernel to not reenter userland

The following reply was made to PR kern/138999; it has been noted by GNATS. From: Jacob Myers To: bug-follo...@freebsd.org, ja...@whotookspaz.org Cc: Subject: Re: kern/138999: [libc] lighttpd/php-cgi with freebsd sendfile(2) enabled causing kernel to not reenter userland Date: Thu, 24 Sep 2009

Re: kern/138999: [libc] lighttpd/php-cgi with freebsd sendfile(2) enabled causing kernel to not reenter userland

The following reply was made to PR kern/138999; it has been noted by GNATS. From: Jacob Myers To: bug-follo...@freebsd.org, ja...@whotookspaz.org Cc: Subject: Re: kern/138999: [libc] lighttpd/php-cgi with freebsd sendfile(2) enabled causing kernel to not reenter userland Date: Thu, 24 Sep 2009

Re: TCP UTO (RFC 5482) patch calls for review

On 1 Sep 2009, at 18:34, Fang Wang wrote: Hi, The attached patch implements TCP User Timeout Option(RFC 5482 [0]) in freebsd tcp stack. And this patch comes from my GSoC 2009 project -- Implement TCP UTO(mentor, Rui Paulo). I will be very grateful to any tips, suggestions and questions. Brie

Confused tcpdump

15:50:42.622040 IP 10.0.0.10.871009576 > 10.0.0.4.2049: 192 lookup [|nfs] 15:50:42.622386 IP 10.0.0.4.2049 > 10.0.0.10.871009576: reply ok 236 lookup [|nfs] I'm pretty sure 871009576 is not a valid port number... DES -- Dag-Erling Smørgrav - d...@des.no _

Re: Confused tcpdump

2009/9/24 Poul-Henning Kamp : > In message <86d45g4ffl@ds4.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= > wr > ites: >>15:50:42.622040 IP 10.0.0.10.871009576 > 10.0.0.4.2049: 192 lookup [|nfs] >>15:50:42.622386 IP 10.0.0.4.2049 > 10.0.0.10.871009576: reply ok 236 lookup= >> [|nfs] >> >>I'm pr

Re: Confused tcpdump

In message <86d45g4ffl@ds4.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= wr ites: >15:50:42.622040 IP 10.0.0.10.871009576 > 10.0.0.4.2049: 192 lookup [|nfs] >15:50:42.622386 IP 10.0.0.4.2049 > 10.0.0.10.871009576: reply ok 236 lookup= > [|nfs] > >I'm pretty sure 871009576 is not a valid port nu

Point-to-Point interfaces regressions

I have found few cases, that were working fine before, but not so good now on CURRENT. There is two interfaces: bge0: flags=8843 metric 0 mtu 1500 options=9b ether 00:1b:24:c5:5b:09 inet 192.168.3.131 netmask 0xff00 broadcast 192.168.3.255 inet 10.0.0.1 netmask

Re: zyd & TEW-424UB

On Wed, Sep 23, 2009 at 12:17:50PM +0200, Albert Shih wrote: > Hi all > > I'm using FreeBSD 7-stable on my laptop. The wifi card is not working with > FreeBSD. > > So I just buy a > > Trendnet TEW-424UB > > wifi usb adapter. I find this model in the > > man zyd >

Re: Confused tcpdump

2009/9/24 Dag-Erling Smørgrav : > 15:50:42.622040 IP 10.0.0.10.871009576 > 10.0.0.4.2049: 192 lookup [|nfs] > 15:50:42.622386 IP 10.0.0.4.2049 > 10.0.0.10.871009576: reply ok 236 lookup > [|nfs] > > I'm pretty sure 871009576 is not a valid port number... > > DES > -- > Dag-Erling Smørgrav - d...@d

wpa_supplicant signal quality vs level

I have noticed that 'wpa_cli scan_results' always reported a signal level of 0 for every bssid found during a scan. I found this a bit odd (especially since ifconfig wlan0 list scan reported good signal level data) FreeBSD 8.0-RC1 r197417 amd64 Looking at the /usr/src/usr.sbin/wpa/wpa_supplicant

Re: Point-to-Point interfaces regressions

Alexander Motin wrote: I have found few cases, that were working fine before, but not so good now on CURRENT. There is two interfaces: bge0: flags=8843 metric 0 mtu 1500 options=9b ether 00:1b:24:c5:5b:09 inet 192.168.3.131 netmask 0xff00 broadcast 192.168.3.255

Re: kern/139113: [arp] removing IP alias doesn't delete permanent arp entry

Old Synopsis: removing IP alias doesn't delete permanent arp entry New Synopsis: [arp] removing IP alias doesn't delete permanent arp entry Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Sep 24 20:29:44 UTC 2009 Responsible-Chan

Re: kern/139117: [lagg] + wlan boot timing (EBUSY)

Synopsis: [lagg] + wlan boot timing (EBUSY) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Sep 24 20:30:23 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=139117

RE: Point-to-Point interfaces regressions

> > 1) I am going to reuse Ethernet address as local for PtP link: > %ifconfig ng0 10.0.0.1 10.0.0.2 > ifconfig: ioctl (SIOCAIFADDR): File exists > %ifconfig ng0 > ng0: flags=88d1 metric > 0 > mtu 1500 > inet 10.0.0.1 --> 10.0.0.2 netmask 0xff00 > So as you can see, address was assigne

Re: Point-to-Point interfaces regressions

Li, Qing wrote: >> 1) I am going to reuse Ethernet address as local for PtP link: >> %ifconfig ng0 10.0.0.1 10.0.0.2 >> ifconfig: ioctl (SIOCAIFADDR): File exists >> %ifconfig ng0 >> ng0: flags=88d1 metric >> 0 >> mtu 1500 >> inet 10.0.0.1 --> 10.0.0.2 netmask 0xff00 >> So as you can se

RE: Point-to-Point interfaces regressions

> > Me and many other people running net/mpd handling thousands of PtP > interfaces sharing local addresses with each other and with some > Ethernet interface. This change makes such setup inoperable, as mpd > will constantly receive errors while trying to set addresses and > drop connections. >

Re: low ath speed on 8.0-RC1

Denis Shaposhnikov wrote: > Hello, > > On Tue, 22 Sep 2009 11:43:31 -0500 > Stef Walter wrote: > >>> I see also it periodically changes "media:" between OFDM/54Mbps and >>> OFDM/48Mbps. >> That's normal behavior. ath_rate_sample is finding the OFDM speed at >> which traffic flows best. > > May

Re: wpa_supplicant signal quality vs level

David Horn wrote: > I have noticed that 'wpa_cli scan_results' always reported a signal > level of 0 for every bssid found during a scan. I found this a bit > odd (especially since ifconfig wlan0 list scan reported good signal > level data) > > FreeBSD 8.0-RC1 r197417 amd64 > > Looking at the /u