freebsd-hackers-digest V5 #743
owner-freebsd-...@freebsd.org
freebsd-hackers-digest Wednesday, March 12 2003 Volume 05 : Number 743
In this issue:
Re: Realtek
Re: Realtek
Re: IP addresses of bridge interfaces
Re: IP addresses of bridge interfaces
pthread keys and resource leaks
pointers on how to debug a pppoe quirk
Re: Realtek
FreeBSD-specific CVS: tagexpand question
Re: Realtek
Re: Are there any on-going projects on v4l porting?
Re: Are there any on-going projects on v4l porting?
usb not working on intel motherboard
Re: redirect everything to socks5
magic symbolic links (ideas/patches?)
Re: Realtek
Kernel trace
first parameter to select
Re: Realtek
Re: Realtek
Re: first parameter to select
Re: first parameter to select
----------------------------------------------------------------------
Date: Wed, 12 Mar 2003 17:44:25 +1100
From: Peter Jeremy <peter...@optushome.com.au>
Subject: Re: Realtek
On Tue, Mar 11, 2003 at 11:20:36AM -0800, Doug Ambrisko wrote:
>Wes Peters writes:
>| Flood it with wire speed 64-byte packets and drive it into receive
>| interrupt livelock. Yup, the PCI bus is (most of) the problem here too.
>
>Can't reproduce it. Maybe they fixed it in the 8100L rev.?
>
>I tried a ping -f -s 22 to hit it with 64 byte packets. I also had
>traffic going to the onboard gig and it wasn't impacted (granted the
>source was a 100bit link tied to the gig link).
Are you sure you were generating "wire speed" packets - this is about
200,000 packets/sec at Fast speed. "ping -f" runs at whatever rate
the remote end returns the packets at (or 100pps) - since it (mostly)
waits for a response before sending another packet, you will never see
livelock.
In order to get 200,000 pps, you're going to need 5-10 hosts
generating traffic, each with a good NIC and connected to the test
system via a decent switch. You also need a proper network
benchmarking tool - netperf (ports/netperf) or similar rather than
ping.
Peter
------------------------------
Date: Wed, 12 Mar 2003 00:37:14 -0800
From: Luigi Rizzo <ri...@icir.org>
Subject: Re: Realtek
On Wed, Mar 12, 2003 at 05:44:25PM +1100, Peter Jeremy wrote:
...
> Are you sure you were generating "wire speed" packets - this is about
> 200,000 packets/sec at Fast speed. "ping -f" runs at whatever rate
148,800kpps
> In order to get 200,000 pps, you're going to need 5-10 hosts
> generating traffic, each with a good NIC and connected to the test
one is enough as long as it is sufficiently fast (750MHz and above
in my experiments), you use a C program to call sendto() and
generate UDP packets, and your network card can cope with the
outgoing traffic (e.g. there is no way the 'fxp' can transmit
over ~120kpps no matter how fast the CPU is; 'xl' and several 'dc'
supported chips can do the job. Haven't tried other cards.
Using polling on the sender side helps but it is not
fundamental.
cheers
luigi
------------------------------
Date: Wed, 12 Mar 2003 13:59:32 +0100 (CET)
From: Soeren Straarup <xr...@x12.dk>
Subject: Re: IP addresses of bridge interfaces
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi
I had the same problem.
My solution was to add 'gateway_enable=3D"YES"' to my /etc/rc.conf
I don't know if that is the right way.. but it works.
I also had trouble getting the ip address set at boot time and had
to make a script that did that.
I would like to hear about any other ways to do it.
Best regards S=F8ren
*--------------------------------------------------------------------------=
- -*
| Soeren Straarup Mobile: +45 20 27 62 44 =
|
| FreeBSD wannabe since 2.2.6-R http://xride.x12.dk =
|
| Also running OpenBSD and NetBSD =
|
*--------------------------------------------------------------------------=
- -*
On Tue, 11 Mar 2003, Sean Hamilton wrote:
> Greetings,
>
> I recently upgraded a FreeBSD 4.6.2 bridge to 5.0, and am having troubles
> with how it handles IP addresses.
>
> router
> |
> | t1
> |
> [fxp0]
> FreeBSD bridge
> [fxp1]
> |
> switch
> |
> hosts
>
> The problem is that if the external interface is assigned an address, the=
n
> hosts on the same block can't access it. Likewise if the internal interfa=
ce
> is given an address, *only* hosts on the same block can access it! I have
> verified that in both cases the bridge has its default route correctly se=
t.
>
> I won't be too suprised if this is due to screwey ISP routing, but I don'=
t
> recall this ever being a problem with 4.6.2.
>
> Any tips?
>
> thanks,
>
> sh
>
>
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
>
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQE+by9FXTGeGCdlN14RAs9YAJ9eEkJ7BLGQF+sQkhpuza9jBqpRQgCfQfu9
tgh/cKCXwGFxgSLz9WY9q98=3D
=3D5aVH
- -----END PGP SIGNATURE-----
------------------------------
Date: Wed, 12 Mar 2003 14:37:54 +0000
From: David Malone <dwma...@maths.tcd.ie>
Subject: Re: IP addresses of bridge interfaces
On Tue, Mar 11, 2003 at 01:17:25PM -0800, Sean Hamilton wrote:
> I recently upgraded a FreeBSD 4.6.2 bridge to 5.0, and am having troubles
> with how it handles IP addresses.
This problem is due to a rather contraversial change, where packets
are only accepted to addressed to the interface they are recieved
on if:
net.inet.ip.check_interface=1
This was left off in -stable, but was turned on by default in
- -current 'cos some people felt it was a security hole. There was a
rather long thread about it when it was committed, and it was
discussed on bugtraq at some length. If you need to disable it, you
should be able to do:
net.inet.ip.check_interface=0
in /etc/sysctl.conf.
David.
------------------------------
Date: Wed, 12 Mar 2003 09:43:59 -0600
From: "Jacques A. Vidrine" <nec...@FreeBSD.org>
Subject: pthread keys and resource leaks
Hi All,
Please show me how stupid I am :-) There does not appear to be a way
to avoid resource leaks in a library that must manage thread-local
storage.
The problem appears to be that the destructor given to
pthread_key_create is not called for the `main thread' (uncertain
terminology). Example:
library
private freekey()
free resources, like fds
deallocate thread-local storage
public foo()
pthread_once -> initialize pthread_key
pthread_getspecific -> fetch thread-local storage
if there wasn't any already allocated,
allocate thread-local storage
maybe initialize some stuff, like fds
do your thing
pthread_setspecific -> update thread-local storage
main
1. call foo()
2. create thread that calls foo()
3. pthread_join()
Both invocations of foo() will work correctly: they will each have
their own thread-local storage allocated. When the thread created at
(2) exits, freekey() will be called. But, when the process exits,
freekey() will NOT have been called for the invocation of foo at (1)
(what I am calling the `main thread').
I'm pretty certain I'm using pthread_(set|get)specific in the spirit
intended. Am I misunderstanding something, or is this a flaw in our
implementation? (BTW, this holds for -CURRENT and -STABLE.)
Cheers,
- --
Jacques A. Vidrine <nec...@celabo.org> http://www.celabo.org/
NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos
jvid...@verio.net . nec...@FreeBSD.org . nec...@kth.se
------------------------------
Date: Wed, 12 Mar 2003 11:09:23 -0500
From: The Anarcat <ana...@anarcat.ath.cx>
Subject: pointers on how to debug a pppoe quirk
- --sm4nu43k4a2Rpi4c
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
I recently started having big problems with my ADSL/pppoe
connection. When ppp gets tired of not having any LQR feedback, it
disconnects:
ppp[3839]: tun0: Phase: deflink: ** Too many LQR packets lost **
and the kernel spews out:
/kernel: session in wrong state
=2E..just after ppp prints out:
ppp[58]: tun0: Phase: deflink: dial -> carrier
ppp[58]: tun0: Phase: Received NGM_PPPOE_ACNAME (hook "62031110019965-")
which is usually followed by:
ppp[58]: tun0: Phase: Received NGM_PPPOE_SESSIONID
ppp[58]: tun0: Phase: Received NGM_PPPOE_SUCCESS
ppp[58]: tun0: Phase: deflink: carrier -> login
ppp[58]: tun0: Phase: deflink: login -> lcp
ppp[58]: tun0: Warning: deflink: Reducing configured MRU from 1500 to 1492
ppp[58]: tun0: Phase: bundle: Authenticate
ppp[58]: tun0: Phase: deflink: his =3D PAP, mine =3D none
ppp[58]: tun0: Phase: Pap Output: ******* ********
ppp[58]: tun0: Phase: Pap Input: SUCCESS ()
=2E..instead.
I've heard other people having similar problems last year (see google
for the "wrong state" message) but it's the first time it actually
happens to me. The other person that had this problem had it fixed by
switching NIC, so I might try this here too.
If I need to power cycle the modem in order to get it back into
shape. And I'm pretty sure it's not the modem's fault since I can
reliably trigger the error by generating a "down" event in ppp (pppctl
/var/run/tun down).
I suspect that a recent 4.6->4.8-RC upgrade is responsible for this
problem, since it started happening during an installworld (yes, a
live installworld).
Now I've started hacking the kernel, thinking it might be in
ng_pppoe.c that the problem is. I've replaced the error condition with
a "warning", hoping everything will resolve normally. I don't know
pppoe very much, however, and documentation on the modem (an external
Daewoo dw-8050) is not really available.
Any pointers on where to begin? I've started with a debug printf-style
thing in the guilty section, but I'm not sure it'll do anything:
/*
* Check the session is in the right state.
* It needs to be in PPPOE_SINIT.
*/
sp =3D sendhook->private;
if (sp->state !=3D PPPOE_SINIT) {
printf("session in wrong state: %i\=
n", sp->state);
/* LEAVE(ENETUNREACH);*/
break;
}
I'm about to test those changes here. It is my intuition that the
session is indeed in the good state, and in fact that it is still
connected, and all fine, but the kernel thinks otherwise.
So... any idea?
A.
- --=20
Nothing incites to money-crimes like great poverty or great wealth.
- Mark Twain
- --sm4nu43k4a2Rpi4c
Content-Type: application/pgp-signature
Content-Disposition: inline
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQE+b1uzttcWHAnWiGcRAiOzAJwMBk/a5Gu5mklGfUioxen/nlfPbACfdUoz
YkQyMdjmFz8ub8G+Y31E3Bg=
=TDua
- -----END PGP SIGNATURE-----
- --sm4nu43k4a2Rpi4c--
------------------------------
Date: Wed, 12 Mar 2003 09:48:43 -0800
From: Wes Peters <w...@softweyr.com>
Subject: Re: Realtek
On Wednesday 12 March 2003 00:37, Luigi Rizzo wrote:
> On Wed, Mar 12, 2003 at 05:44:25PM +1100, Peter Jeremy wrote:
> ...
>
> > Are you sure you were generating "wire speed" packets - this is about
> > 200,000 packets/sec at Fast speed. "ping -f" runs at whatever rate
>
> 148,800kpps
>
> > In order to get 200,000 pps, you're going to need 5-10 hosts
> > generating traffic, each with a good NIC and connected to the test
>
> one is enough as long as it is sufficiently fast (750MHz and above
> in my experiments), you use a C program to call sendto() and
> generate UDP packets, and your network card can cope with the
> outgoing traffic (e.g. there is no way the 'fxp' can transmit
> over ~120kpps no matter how fast the CPU is; 'xl' and several 'dc'
> supported chips can do the job. Haven't tried other cards.
>
> Using polling on the sender side helps but it is not
> fundamental.
Or you can cheat and use a SmartBits-2000 like I did. It can send exactly
148,800 packets per second, with very precise timing of the inter-packet
gap, preamble, and actual packet data. You can make a reasonable
facsimile of this on FreeBSD with judicious use of -i and -l. Note that
these are blasted at a Win2K box because I don't have a FreeBSD box to
beat up at the moment:
- -bash-2.05b$ sudo ping -i 0.000001 -c 5000 204.68.178.2
...
64 bytes from 204.68.178.2: icmp_seq=4997 ttl=128 time=0.192 ms
64 bytes from 204.68.178.2: icmp_seq=4998 ttl=128 time=0.185 ms
64 bytes from 204.68.178.2: icmp_seq=4999 ttl=128 time=0.173 ms
- --- 204.68.178.2 ping statistics ---
5000 packets transmitted, 5000 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.104/0.191/0.605/0.033 ms
So it seems to keep up reasonably well, but this is misleading. Use -l to
force the packets out as quickly as the card can generate them:
- -bash-2.05b$ sudo ping -i 0.000001 -c 5000 -l 5000 204.68.178.2
...
64 bytes from 204.68.178.2: icmp_seq=92 ttl=128 time=14.855 ms
64 bytes from 204.68.178.2: icmp_seq=93 ttl=128 time=14.880 ms
64 bytes from 204.68.178.2: icmp_seq=4424 ttl=128 time=17.308 ms
- --- 204.68.178.2 ping statistics ---
5000 packets transmitted, 95 packets received, 98% packet loss
round-trip min/avg/max/stddev = 11.929/14.520/17.308/0.682 ms
Wow. The receiving side handled the first 93 packets and then rolled
over, recovering for only the last packet. (Look at the icmp_seq
numbers.) FreeBSD behaves similarly, but try the test on your own. ;^)
- --
Where am I, and what am I doing in this handbasket?
Wes Peters w...@softweyr.com
------------------------------
Date: Wed, 12 Mar 2003 21:36:02 +0300 (MSK)
From: Dmitry Morozovsky <ma...@rinet.ru>
Subject: FreeBSD-specific CVS: tagexpand question
Colleagues,
I'm not sure this is the most correct place to ask, but it at least seems so.
Is there any way to tune FreeBSD-specific CVS (with CVSROOT/options support) to
provide the following functionality:
- - ident keyword should be standard ($ Id $)
- - it should be expanded as ($ CVSHeader $) to repo-relative path
Looking at cvs sources and peter's changes aroute versions 1.4-1.5 has not
enlightened me enough, unfortunately.
Any help will be greatly appreciated.
Sincerely,
D.Marck [DM5020, DM268-RIPE, DM3-RIPN]
- ------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru ***
- ------------------------------------------------------------------------
------------------------------
Date: Wed, 12 Mar 2003 10:37:43 -0800 (PST)
From: Doug Ambrisko <ambr...@ambrisko.com>
Subject: Re: Realtek
Wes Peters writes:
| Or you can cheat and use a SmartBits-2000 like I did. It can send exactly
| 148,800 packets per second, with very precise timing of the inter-packet
Soon we should be getting an Ixia.
| So it seems to keep up reasonably well, but this is misleading. Use -l to
| force the packets out as quickly as the card can generate them:
|
| -bash-2.05b$ sudo ping -i 0.000001 -c 5000 -l 5000 204.68.178.2
| ...
| 64 bytes from 204.68.178.2: icmp_seq=92 ttl=128 time=14.855 ms
| 64 bytes from 204.68.178.2: icmp_seq=93 ttl=128 time=14.880 ms
| 64 bytes from 204.68.178.2: icmp_seq=4424 ttl=128 time=17.308 ms
|
| --- 204.68.178.2 ping statistics ---
| 5000 packets transmitted, 95 packets received, 98% packet loss
| round-trip min/avg/max/stddev = 11.929/14.520/17.308/0.682 ms
|
| Wow. The receiving side handled the first 93 packets and then rolled
| over, recovering for only the last packet. (Look at the icmp_seq
| numbers.) FreeBSD behaves similarly, but try the test on your own. ;^)
I don't see any difference between the rl and fxp tests using the same
originating machine and dest machine. The dest machine has both rl and fxp
the rl0 results (ping -i 0.000001 -c 5000 -l 5000 <IP>):
PING 192.168.99.2 (192.168.99.2): 56 data bytes
64 bytes from 192.168.99.2: icmp_seq=0 ttl=64 time=0.499 ms
64 bytes from 192.168.99.2: icmp_seq=1 ttl=64 time=0.467 ms
64 bytes from 192.168.99.2: icmp_seq=2 ttl=64 time=0.461 ms
64 bytes from 192.168.99.2: icmp_seq=3 ttl=64 time=0.458 ms
64 bytes from 192.168.99.2: icmp_seq=4 ttl=64 time=0.484 ms
64 bytes from 192.168.99.2: icmp_seq=5 ttl=64 time=0.502 ms
64 bytes from 192.168.99.2: icmp_seq=6 ttl=64 time=0.500 ms
64 bytes from 192.168.99.2: icmp_seq=7 ttl=64 time=0.498 ms
64 bytes from 192.168.99.2: icmp_seq=8 ttl=64 time=0.514 ms
64 bytes from 192.168.99.2: icmp_seq=9 ttl=64 time=0.508 ms
64 bytes from 192.168.99.2: icmp_seq=10 ttl=64 time=0.503 ms
64 bytes from 192.168.99.2: icmp_seq=11 ttl=64 time=0.519 ms
64 bytes from 192.168.99.2: icmp_seq=12 ttl=64 time=0.514 ms
64 bytes from 192.168.99.2: icmp_seq=13 ttl=64 time=0.512 ms
64 bytes from 192.168.99.2: icmp_seq=14 ttl=64 time=0.523 ms
64 bytes from 192.168.99.2: icmp_seq=15 ttl=64 time=0.520 ms
64 bytes from 192.168.99.2: icmp_seq=16 ttl=64 time=0.516 ms
64 bytes from 192.168.99.2: icmp_seq=17 ttl=64 time=0.525 ms
64 bytes from 192.168.99.2: icmp_seq=18 ttl=64 time=0.522 ms
64 bytes from 192.168.99.2: icmp_seq=19 ttl=64 time=0.519 ms
64 bytes from 192.168.99.2: icmp_seq=20 ttl=64 time=0.532 ms
64 bytes from 192.168.99.2: icmp_seq=21 ttl=64 time=0.527 ms
64 bytes from 192.168.99.2: icmp_seq=22 ttl=64 time=0.523 ms
64 bytes from 192.168.99.2: icmp_seq=23 ttl=64 time=0.535 ms
64 bytes from 192.168.99.2: icmp_seq=24 ttl=64 time=0.531 ms
64 bytes from 192.168.99.2: icmp_seq=25 ttl=64 time=0.529 ms
64 bytes from 192.168.99.2: icmp_seq=26 ttl=64 time=0.540 ms
64 bytes from 192.168.99.2: icmp_seq=27 ttl=64 time=0.535 ms
64 bytes from 192.168.99.2: icmp_seq=28 ttl=64 time=0.532 ms
64 bytes from 192.168.99.2: icmp_seq=29 ttl=64 time=0.541 ms
64 bytes from 192.168.99.2: icmp_seq=30 ttl=64 time=0.538 ms
64 bytes from 192.168.99.2: icmp_seq=31 ttl=64 time=0.533 ms
64 bytes from 192.168.99.2: icmp_seq=32 ttl=64 time=0.540 ms
64 bytes from 192.168.99.2: icmp_seq=33 ttl=64 time=0.553 ms
64 bytes from 192.168.99.2: icmp_seq=34 ttl=64 time=0.548 ms
64 bytes from 192.168.99.2: icmp_seq=35 ttl=64 time=0.544 ms
64 bytes from 192.168.99.2: icmp_seq=36 ttl=64 time=0.180 ms
64 bytes from 192.168.99.2: icmp_seq=37 ttl=64 time=0.175 ms
64 bytes from 192.168.99.2: icmp_seq=38 ttl=64 time=0.185 ms
64 bytes from 192.168.99.2: icmp_seq=39 ttl=64 time=0.180 ms
64 bytes from 192.168.99.2: icmp_seq=40 ttl=64 time=0.206 ms
64 bytes from 192.168.99.2: icmp_seq=41 ttl=64 time=0.204 ms
64 bytes from 192.168.99.2: icmp_seq=42 ttl=64 time=0.214 ms
64 bytes from 192.168.99.2: icmp_seq=43 ttl=64 time=0.208 ms
64 bytes from 192.168.99.2: icmp_seq=44 ttl=64 time=0.221 ms
64 bytes from 192.168.99.2: icmp_seq=45 ttl=64 time=0.218 ms
64 bytes from 192.168.99.2: icmp_seq=46 ttl=64 time=0.228 ms
64 bytes from 192.168.99.2: icmp_seq=47 ttl=64 time=0.225 ms
64 bytes from 192.168.99.2: icmp_seq=48 ttl=64 time=0.236 ms
64 bytes from 192.168.99.2: icmp_seq=49 ttl=64 time=0.233 ms
64 bytes from 192.168.99.2: icmp_seq=50 ttl=64 time=0.242 ms
64 bytes from 192.168.99.2: icmp_seq=51 ttl=64 time=0.160 ms
64 bytes from 192.168.99.2: icmp_seq=52 ttl=64 time=0.156 ms
64 bytes from 192.168.99.2: icmp_seq=53 ttl=64 time=0.166 ms
64 bytes from 192.168.99.2: icmp_seq=54 ttl=64 time=0.161 ms
64 bytes from 192.168.99.2: icmp_seq=55 ttl=64 time=0.185 ms
64 bytes from 192.168.99.2: icmp_seq=56 ttl=64 time=0.199 ms
64 bytes from 192.168.99.2: icmp_seq=57 ttl=64 time=0.196 ms
64 bytes from 192.168.99.2: icmp_seq=58 ttl=64 time=0.193 ms
64 bytes from 192.168.99.2: icmp_seq=59 ttl=64 time=0.202 ms
64 bytes from 192.168.99.2: icmp_seq=60 ttl=64 time=0.216 ms
64 bytes from 192.168.99.2: icmp_seq=61 ttl=64 time=0.213 ms
64 bytes from 192.168.99.2: icmp_seq=62 ttl=64 time=0.212 ms
64 bytes from 192.168.99.2: icmp_seq=63 ttl=64 time=0.219 ms
64 bytes from 192.168.99.2: icmp_seq=64 ttl=64 time=0.579 ms
64 bytes from 192.168.99.2: icmp_seq=65 ttl=64 time=0.182 ms
64 bytes from 192.168.99.2: icmp_seq=66 ttl=64 time=0.191 ms
64 bytes from 192.168.99.2: icmp_seq=67 ttl=64 time=0.189 ms
64 bytes from 192.168.99.2: icmp_seq=68 ttl=64 time=0.213 ms
64 bytes from 192.168.99.2: icmp_seq=69 ttl=64 time=0.212 ms
64 bytes from 192.168.99.2: icmp_seq=70 ttl=64 time=0.221 ms
64 bytes from 192.168.99.2: icmp_seq=71 ttl=64 time=0.218 ms
64 bytes from 192.168.99.2: icmp_seq=72 ttl=64 time=0.227 ms
64 bytes from 192.168.99.2: icmp_seq=73 ttl=64 time=0.239 ms
64 bytes from 192.168.99.2: icmp_seq=74 ttl=64 time=0.237 ms
64 bytes from 192.168.99.2: icmp_seq=75 ttl=64 time=0.233 ms
64 bytes from 192.168.99.2: icmp_seq=76 ttl=64 time=0.246 ms
64 bytes from 192.168.99.2: icmp_seq=77 ttl=64 time=0.244 ms
64 bytes from 192.168.99.2: icmp_seq=78 ttl=64 time=0.242 ms
64 bytes from 192.168.99.2: icmp_seq=79 ttl=64 time=0.605 ms
64 bytes from 192.168.99.2: icmp_seq=80 ttl=64 time=0.157 ms
64 bytes from 192.168.99.2: icmp_seq=81 ttl=64 time=0.166 ms
64 bytes from 192.168.99.2: icmp_seq=82 ttl=64 time=0.162 ms
64 bytes from 192.168.99.2: icmp_seq=83 ttl=64 time=0.186 ms
64 bytes from 192.168.99.2: icmp_seq=84 ttl=64 time=0.202 ms
64 bytes from 192.168.99.2: icmp_seq=85 ttl=64 time=0.200 ms
64 bytes from 192.168.99.2: icmp_seq=86 ttl=64 time=0.197 ms
64 bytes from 192.168.99.2: icmp_seq=87 ttl=64 time=0.209 ms
64 bytes from 192.168.99.2: icmp_seq=88 ttl=64 time=0.208 ms
64 bytes from 192.168.99.2: icmp_seq=89 ttl=64 time=0.220 ms
64 bytes from 192.168.99.2: icmp_seq=90 ttl=64 time=0.218 ms
64 bytes from 192.168.99.2: icmp_seq=91 ttl=64 time=0.216 ms
64 bytes from 192.168.99.2: icmp_seq=92 ttl=64 time=0.576 ms
64 bytes from 192.168.99.2: icmp_seq=93 ttl=64 time=0.180 ms
--- 192.168.99.2 ping statistics ---
5000 packets transmitted, 94 packets received, 98% packet loss
round-trip min/avg/max/stddev = 0.156/0.337/0.605/0.159 ms
the fxp results:
PING 192.168.88.2 (192.168.88.2): 56 data bytes
64 bytes from 192.168.88.2: icmp_seq=0 ttl=64 time=0.204 ms
64 bytes from 192.168.88.2: icmp_seq=1 ttl=64 time=0.249 ms
64 bytes from 192.168.88.2: icmp_seq=2 ttl=64 time=0.244 ms
64 bytes from 192.168.88.2: icmp_seq=3 ttl=64 time=0.240 ms
64 bytes from 192.168.88.2: icmp_seq=4 ttl=64 time=0.236 ms
64 bytes from 192.168.88.2: icmp_seq=5 ttl=64 time=0.232 ms
64 bytes from 192.168.88.2: icmp_seq=6 ttl=64 time=0.226 ms
64 bytes from 192.168.88.2: icmp_seq=7 ttl=64 time=0.222 ms
64 bytes from 192.168.88.2: icmp_seq=8 ttl=64 time=0.218 ms
64 bytes from 192.168.88.2: icmp_seq=9 ttl=64 time=0.214 ms
64 bytes from 192.168.88.2: icmp_seq=10 ttl=64 time=0.139 ms
64 bytes from 192.168.88.2: icmp_seq=11 ttl=64 time=0.156 ms
64 bytes from 192.168.88.2: icmp_seq=12 ttl=64 time=0.162 ms
64 bytes from 192.168.88.2: icmp_seq=13 ttl=64 time=0.173 ms
64 bytes from 192.168.88.2: icmp_seq=14 ttl=64 time=0.209 ms
64 bytes from 192.168.88.2: icmp_seq=15 ttl=64 time=0.208 ms
64 bytes from 192.168.88.2: icmp_seq=16 ttl=64 time=0.205 ms
64 bytes from 192.168.88.2: icmp_seq=17 ttl=64 time=0.201 ms
64 bytes from 192.168.88.2: icmp_seq=18 ttl=64 time=0.197 ms
64 bytes from 192.168.88.2: icmp_seq=19 ttl=64 time=0.206 ms
64 bytes from 192.168.88.2: icmp_seq=20 ttl=64 time=0.203 ms
64 bytes from 192.168.88.2: icmp_seq=21 ttl=64 time=0.486 ms
64 bytes from 192.168.88.2: icmp_seq=22 ttl=64 time=0.146 ms
64 bytes from 192.168.88.2: icmp_seq=23 ttl=64 time=0.158 ms
64 bytes from 192.168.88.2: icmp_seq=24 ttl=64 time=0.154 ms
64 bytes from 192.168.88.2: icmp_seq=25 ttl=64 time=0.167 ms
64 bytes from 192.168.88.2: icmp_seq=26 ttl=64 time=0.166 ms
64 bytes from 192.168.88.2: icmp_seq=27 ttl=64 time=0.179 ms
64 bytes from 192.168.88.2: icmp_seq=28 ttl=64 time=0.176 ms
64 bytes from 192.168.88.2: icmp_seq=29 ttl=64 time=0.173 ms
64 bytes from 192.168.88.2: icmp_seq=30 ttl=64 time=0.177 ms
64 bytes from 192.168.88.2: icmp_seq=31 ttl=64 time=0.137 ms
64 bytes from 192.168.88.2: icmp_seq=32 ttl=64 time=0.153 ms
64 bytes from 192.168.88.2: icmp_seq=33 ttl=64 time=0.162 ms
64 bytes from 192.168.88.2: icmp_seq=34 ttl=64 time=0.170 ms
64 bytes from 192.168.88.2: icmp_seq=35 ttl=64 time=0.185 ms
64 bytes from 192.168.88.2: icmp_seq=36 ttl=64 time=0.181 ms
64 bytes from 192.168.88.2: icmp_seq=37 ttl=64 time=0.181 ms
64 bytes from 192.168.88.2: icmp_seq=38 ttl=64 time=0.197 ms
64 bytes from 192.168.88.2: icmp_seq=39 ttl=64 time=0.197 ms
64 bytes from 192.168.88.2: icmp_seq=40 ttl=64 time=0.191 ms
64 bytes from 192.168.88.2: icmp_seq=41 ttl=64 time=0.187 ms
64 bytes from 192.168.88.2: icmp_seq=42 ttl=64 time=0.142 ms
64 bytes from 192.168.88.2: icmp_seq=43 ttl=64 time=0.156 ms
64 bytes from 192.168.88.2: icmp_seq=44 ttl=64 time=0.152 ms
64 bytes from 192.168.88.2: icmp_seq=45 ttl=64 time=0.168 ms
64 bytes from 192.168.88.2: icmp_seq=46 ttl=64 time=0.167 ms
64 bytes from 192.168.88.2: icmp_seq=47 ttl=64 time=0.179 ms
64 bytes from 192.168.88.2: icmp_seq=48 ttl=64 time=0.176 ms
64 bytes from 192.168.88.2: icmp_seq=49 ttl=64 time=0.190 ms
64 bytes from 192.168.88.2: icmp_seq=50 ttl=64 time=0.186 ms
64 bytes from 192.168.88.2: icmp_seq=51 ttl=64 time=0.183 ms
64 bytes from 192.168.88.2: icmp_seq=52 ttl=64 time=0.189 ms
64 bytes from 192.168.88.2: icmp_seq=53 ttl=64 time=0.126 ms
64 bytes from 192.168.88.2: icmp_seq=54 ttl=64 time=0.143 ms
64 bytes from 192.168.88.2: icmp_seq=55 ttl=64 time=0.160 ms
64 bytes from 192.168.88.2: icmp_seq=56 ttl=64 time=0.170 ms
64 bytes from 192.168.88.2: icmp_seq=57 ttl=64 time=0.168 ms
64 bytes from 192.168.88.2: icmp_seq=58 ttl=64 time=0.180 ms
64 bytes from 192.168.88.2: icmp_seq=59 ttl=64 time=0.180 ms
64 bytes from 192.168.88.2: icmp_seq=60 ttl=64 time=0.176 ms
64 bytes from 192.168.88.2: icmp_seq=61 ttl=64 time=0.187 ms
64 bytes from 192.168.88.2: icmp_seq=62 ttl=64 time=0.184 ms
64 bytes from 192.168.88.2: icmp_seq=63 ttl=64 time=0.126 ms
64 bytes from 192.168.88.2: icmp_seq=64 ttl=64 time=0.143 ms
64 bytes from 192.168.88.2: icmp_seq=65 ttl=64 time=0.160 ms
64 bytes from 192.168.88.2: icmp_seq=66 ttl=64 time=0.171 ms
64 bytes from 192.168.88.2: icmp_seq=67 ttl=64 time=0.168 ms
64 bytes from 192.168.88.2: icmp_seq=68 ttl=64 time=0.183 ms
64 bytes from 192.168.88.2: icmp_seq=69 ttl=64 time=0.181 ms
64 bytes from 192.168.88.2: icmp_seq=70 ttl=64 time=0.178 ms
64 bytes from 192.168.88.2: icmp_seq=71 ttl=64 time=0.186 ms
64 bytes from 192.168.88.2: icmp_seq=72 ttl=64 time=0.185 ms
64 bytes from 192.168.88.2: icmp_seq=73 ttl=64 time=0.127 ms
64 bytes from 192.168.88.2: icmp_seq=74 ttl=64 time=0.144 ms
64 bytes from 192.168.88.2: icmp_seq=75 ttl=64 time=0.170 ms
64 bytes from 192.168.88.2: icmp_seq=76 ttl=64 time=0.230 ms
64 bytes from 192.168.88.2: icmp_seq=77 ttl=64 time=0.228 ms
64 bytes from 192.168.88.2: icmp_seq=78 ttl=64 time=0.225 ms
64 bytes from 192.168.88.2: icmp_seq=79 ttl=64 time=0.220 ms
64 bytes from 192.168.88.2: icmp_seq=80 ttl=64 time=0.218 ms
64 bytes from 192.168.88.2: icmp_seq=81 ttl=64 time=0.215 ms
64 bytes from 192.168.88.2: icmp_seq=82 ttl=64 time=0.213 ms
64 bytes from 192.168.88.2: icmp_seq=83 ttl=64 time=0.135 ms
64 bytes from 192.168.88.2: icmp_seq=84 ttl=64 time=0.151 ms
64 bytes from 192.168.88.2: icmp_seq=85 ttl=64 time=0.158 ms
64 bytes from 192.168.88.2: icmp_seq=86 ttl=64 time=0.166 ms
64 bytes from 192.168.88.2: icmp_seq=87 ttl=64 time=0.178 ms
64 bytes from 192.168.88.2: icmp_seq=88 ttl=64 time=0.175 ms
64 bytes from 192.168.88.2: icmp_seq=89 ttl=64 time=0.190 ms
64 bytes from 192.168.88.2: icmp_seq=90 ttl=64 time=0.189 ms
64 bytes from 192.168.88.2: icmp_seq=91 ttl=64 time=0.186 ms
64 bytes from 192.168.88.2: icmp_seq=92 ttl=64 time=0.193 ms
64 bytes from 192.168.88.2: icmp_seq=93 ttl=64 time=0.192 ms
--- 192.168.88.2 ping statistics ---
5000 packets transmitted, 94 packets received, 98% packet loss
round-trip min/avg/max/stddev = 0.126/0.185/0.486/0.042 ms
Now the FreeBSD target whines about the icmp limits. If I turn off
ICMP bandwith limit I see little difference except that end of the
fxp0 case:
64 bytes from 192.168.88.2: icmp_seq=99 ttl=64 time=0.262 ms
64 bytes from 192.168.88.2: icmp_seq=100 ttl=64 time=0.259 ms
64 bytes from 192.168.88.2: icmp_seq=101 ttl=64 time=0.230 ms
64 bytes from 192.168.88.2: icmp_seq=102 ttl=64 time=0.202 ms
64 bytes from 192.168.88.2: icmp_seq=4999 ttl=64 time=0.091 ms
--- 192.168.88.2 ping statistics ---
5000 packets transmitted, 95 packets received, 98% packet loss
round-trip min/avg/max/stddev = 0.091/0.192/0.281/0.043 ms
rl0 case:
64 bytes from 192.168.99.2: icmp_seq=98 ttl=64 time=0.251 ms
64 bytes from 192.168.99.2: icmp_seq=99 ttl=64 time=0.248 ms
64 bytes from 192.168.99.2: icmp_seq=100 ttl=64 time=0.247 ms
64 bytes from 192.168.99.2: icmp_seq=101 ttl=64 time=0.634 ms
64 bytes from 192.168.99.2: icmp_seq=4995 ttl=64 time=0.534 ms
--- 192.168.99.2 ping statistics ---
5000 packets transmitted, 95 packets received, 98% packet loss
round-trip min/avg/max/stddev = 0.129/0.241/0.634/0.107 ms
I'm generating the traffic with a fxp0 device.
So I'm not see much difference.
Doug a
------------------------------
Date: Wed, 12 Mar 2003 19:55:57 +0200
From: Yury Tarasievich <gr...@grsu.by>
Subject: Re: Are there any on-going projects on v4l porting?
At http://freebsddvb.narod.ru, there exists an adequately up-to-date
port of linux DVB drivers, seemingly supporting DVB adapters up to rev.1.5.
Regarding porting of V4L. I may be utterly wrong, but isn't the whole
V4L/V4L2/V4L2-whatever thing rather made ad hoc, not really designed?
Could something reincarnating BeOS (or even OS/2) multimedia subsystem
be better?
Vladimir Kushnir wrote:
>As subj. said - does anybody work on porting v4l & (especially!)
>drivers for non- bt8x based cards? Specifically saa7134 based (got one and
>would rather not have to reboot to Linux to watch TV :-)
>Yes, I know, the simplest answer would be "you're interested - you do" but
>that'd be quite beyond my skills. Still I'd happily help with
>testing/debugging/whatever else.
>
>
>
------------------------------
Date: Wed, 12 Mar 2003 13:47:36 -0600
From: Dan Nelson <dne...@allantgroup.com>
Subject: Re: Are there any on-going projects on v4l porting?
In the last episode (Mar 12), Yury Tarasievich said:
> At http://freebsddvb.narod.ru, there exists an adequately up-to-date
> port of linux DVB drivers, seemingly supporting DVB adapters up to
> rev.1.5.
>
> Regarding porting of V4L. I may be utterly wrong, but isn't the whole
> V4L/V4L2/V4L2-whatever thing rather made ad hoc, not really designed?
> Could something reincarnating BeOS (or even OS/2) multimedia
> subsystem be better?
I like the idea of putting this into the Xfree86 drivers and using the
XVideo extension to drive everything. that doesn't require kernel
mods. It does mean that you need to start X up to capture video,
though.
- --
Dan Nelson
dne...@allantgroup.com
------------------------------
Date: Thu, 13 Mar 2003 09:26:32 +1100
From: JacobRhoden <jrh...@unimelb.edu.au>
Subject: usb not working on intel motherboard
Hi,
It seems that no matter what I do I can not get usb devices to even be
recognised. (Yes usbd is running). Relevant DMESG and usbd error messages
below. Does anyone have any ideas? (I have tried usb mouse, keyboard, and
camera).
Thanks,
Jacob
FreeBSD elkanah.its.unimelb.edu.au 4.8-RC FreeBSD 4.8-RC #1: Wed Mar 12
15:00:01 EST 2003
jrh...@elkanah.its.unimelb.edu.au:/usr/obj/usr/src/sys/JOAB2 i386
uhci0: <Intel 82801DB (ICH4) USB controller USB-A> port 0xe800-0xe81f irq 11
at device 29.0 on pci0
usb0: <Intel 82801DB (ICH4) USB controller USB-A> on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1: <Intel 82801DB (ICH4) USB controller USB-B> port 0xe880-0xe89f irq 5 at
device 29.1 on pci0
usb1: <Intel 82801DB (ICH4) USB controller USB-B> on uhci1
usb1: USB revision 1.0
uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhci2: <Intel 82801DB (ICH4) USB controller USB-C> port 0xec00-0xec1f irq 9 at
device 29.2 on pci0
usb2: <Intel 82801DB (ICH4) USB controller USB-C> on uhci2
usb2: USB revision 1.0
uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
And verbose debug output from usbd:
%/usr/sbin/usbd -d -vv -f /dev/usb0 -f /dev/usb1 -f /dev/usb2
usbd: opened /dev/usb0
usbd: opened /dev/usb1
usbd: opened /dev/usb2
usbd: reading configuration file /etc/usbd.conf
usbd: action 1: ActiveWire board, firmware download
vndr=0x0854 prdct=0x0100 rlse=0x0000
attach='/usr/local/bin/ezdownload -f
/usr/local/share/usb/firmware/0854.0100.0_01.hex ${DEVNAME}'
usbd: action 2: Entrega Serial with UART
vndr=0x1645 prdct=0x8001 rlse=0x0101
attach='/usr/sbin/ezdownload -v -f /usr/share/usb/firmware/1645.8001.0101
/dev/${DEVNAME}'
usbd: action 3: USB ethernet
devname: [ack]ue[0-9]+
attach='dhclient ${DEVNAME}'
detach='killall dhclient'
usbd: action 4: Mouse
devname: ums[0-9]+
attach='/usr/sbin/moused -p /dev/${DEVNAME} -I
/var/run/moused.${DEVNAME}.pid'
usbd: action 5: USB device
usbd: 5 actions
usbd: opened /dev/usb
usbd: doing timeout discovery on /dev/usb0
usbd: doing timeout discovery on /dev/usb1
usbd: doing timeout discovery on /dev/usb2
usbd: processing event queue due to timeout on /dev/usb
usbd: doing timeout discovery on /dev/usb0
usbd: doing timeout discovery on /dev/usb1
usbd: doing timeout discovery on /dev/usb2
usbd: processing event queue due to timeout on /dev/usb
Jacob Rhoden Phone: +61 3 8344 6102
ITS Division Email: jrh...@unimelb.edu.au
Melbourne University Mobile: +61 403 788 386
------------------------------
Date: Wed, 12 Mar 2003 15:28:18 -0800 (PST)
From: Doug Ambrisko <ambr...@ambrisko.com>
Subject: Re: redirect everything to socks5
Keith Pitcher writes:
| Living in rural slow connection land, I've been playing around with
| satellite Internet. The problem is the company only has Win
| drivers. (Linux driver is in the works, but no plans to open source it, will be
| released as a binary - the bastards)
|
| Anyhow, to get the download speed of the satellite it uses a http proxy and
| a socks5 proxy. This works fine for things that allow proxies or socks. But
| there are a lot of things that don't support it.
|
| Is there a way to "socksify" everything my freebsd box does, so no
| matter what I do, I can just point it to the socks machine and it works?
"runsocks" works for most apps as long as they use a shared libc and
don't link to libc_r. If they use libc_r you need to make a libc_r shim
for that. Also a libc shim for Linux would be needed for Linux apps
that use a shared libc.
Now I did find that Netscape and runsocks/socks gateway had trouble with
https type transfers. Doing a packet capture it would do an unencrupted
request, fail and then reture with an encrypted request. This confused
the state of the proxied connection.
| Would also be handy to have a way to "socksify" the box when it acts as a
| network gateway, so I'd only have one really strangely configured machine and
| the rest would be normal.
You might be able to do a nat like thing to a socks proxy via divert.
Another work-around is to run a "gateway/router" thing on a Windows box
and then point your machine to that gateway and it would socksify the
transfer to the other network. This actually works well except for
depending on a Windows box.
Not knowing enough about these things but slightly interested in DirectWay
for our trailer I've read about interfaces that go to Ethernet or 802.11b.
I wonder if these can automatically do that since I don't use Windows I
would need that type of solution.
Doug A.
------------------------------
Date: Wed, 12 Mar 2003 19:39:52 -0500
From: John <j...@bsdwins.com>
Subject: magic symbolic links (ideas/patches?)
Hi Folks,
I have a need to implement a highly specific variant usage of
what are commonly referred to as magic symlinks, ie:
/src -> /.src/$ARCH/src
where $ARCH needs to come from the user environment.
A related patchset from NetBSD (1995) can be seen here:
http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=1781
In my specific implementation, the value of $ARCH will ALWAYS
be 3 characters (Not having implemented anything yet, and to
avoid possibly playing the userland game, I was thinking of
adding a field to the proc structure and having the setenv/putenv
functions place the value there via a sysctl, thus allowing a
very simple interface... short sighted?).
If anyone has any comments, or patches hanging around for
this type of implementation, I would appreciate a pointer to them.
Many, Many Thanks,
John
------------------------------
Date: Wed, 12 Mar 2003 19:01:26 -0700
From: <sor...@cydem.org.ua>
Subject: Re: Realtek
> 5000 packets transmitted, 94 packets received, 98% packet loss
> round-trip min/avg/max/stddev = 0.156/0.337/0.605/0.159 ms
> So I'm not see much difference.
are you sure it's not because of this:
'ping: sendto: No buffer space available'?
12.03.2003; 18:56:02
[SorAlx] http://cydem.org.ua/
------------------------------
Date: Wed, 12 Mar 2003 22:27:42 -0500
From: Yaoping Ruan <yr...@cs.princeton.edu>
Subject: Kernel trace
Does any one know the implementation of "ktrace" in FreeBSD? I would like to hack the
source code and have a relatively easy way to copy the kernel stack image when a
certain of thing happens, such as page fault. It should work like the breakpoints in
gdb. But kernel panic is too much trouble for just a single stack image, and kgdb is
not simple enough. Which source file(s) I should look at?
- - Yaoping Ruan
------------------------------
Date: Wed, 12 Mar 2003 19:35:27 -0800
From: "Sean Hamilton" <s...@bel.bc.ca>
Subject: first parameter to select
Greetings,
What is the first parameter to select(2) for? Microsoft's select ignores it,
and it does not appear to have any valid use since it only allows
constraints on values which are assigned by the system.
Purely historic?
sh
------------------------------
Date: Wed, 12 Mar 2003 19:37:20 -0800 (PST)
From: Doug Ambrisko <ambr...@ambrisko.com>
Subject: Re: Realtek
sor...@cydem.org.ua writes:
[ Charset ISO-8859-1 unsupported, converting... ]
| > 5000 packets transmitted, 94 packets received, 98% packet loss
| > round-trip min/avg/max/stddev = 0.156/0.337/0.605/0.159 ms
| > So I'm not see much difference.
|
| are you sure it's not because of this:
| 'ping: sendto: No buffer space available'?
No such messages appeared.
Doug A.
------------------------------
Date: Wed, 12 Mar 2003 20:53:20 -0700
From: <sor...@cydem.org.ua>
Subject: Re: Realtek
>| are you sure it's not because of this:
>| 'ping: sendto: No buffer space available'?
>No such messages appeared.
I forgot that I hooked it up to 10Mbit hub for
now, so nevermind 8)
are you piping it through 'less'? you won't see
this message in 'less' output
what's the value of your 'kern.ipc.nmbclusters'?
`sysctl kern.ipc.nmbclusters`: kern.ipc.nmbclusters: 4560
(FreeBSD 4.6.2-RELEASE)
I'll test 'rl' vs 'xl' later on 100Mbit/s.
12.03.2003; 20:16:35
[SorAlx] http://cydem.org.ua/
------------------------------
Date: Wed, 12 Mar 2003 22:58:42 -0600
From: Dan Nelson <dne...@allantgroup.com>
Subject: Re: first parameter to select
In the last episode (Mar 12), Sean Hamilton said:
> What is the first parameter to select(2) for? Microsoft's select
> ignores it, and it does not appear to have any valid use since it
> only allows constraints on values which are assigned by the system.
I'd hate to have the kernel scan a 6000-element (or whatever maxfiles
is on your system) array every time I called select with nfds=10.
If MS ignores the nfds parameter, it risks accessing uninitialized
memory or selecting on fds that the user no longer wants to look at.
I'd call it a bug.
> Purely historic?
Performance.
- --
Dan Nelson
dne...@allantgroup.com
------------------------------
Date: Thu, 13 Mar 2003 01:57:16 -0500
From: David Cuthbert <da...@kanga.org>
Subject: Re: first parameter to select
Sean Hamilton wrote:
> What is the first parameter to select(2) for? Microsoft's select
ignores it,
> and it does not appear to have any valid use since it only allows
> constraints on values which are assigned by the system.
>
> Purely historic?
Ah, you've been reading the Winsock documentation.
fd_set is usually a fixed-size bitmask of filedescriptors (this
implementation isn't guaranteed, but I haven't seen another). The
number of bits corresponds to the maximum number of files a process can
have open (according to your header files; tweaks to your kernel and
process limits can dictate otherwise).
select() needs to know how many of those bits (descriptors) to scan.
Passing in FD_SETSIZE will tell it to scan all of the bits. But most
processes only have a few handles open, so the majority of the scanning
goes to waste. Instead (except on Microsoft's Winsock, which always
assumes FD_SETSIZE regardless of what you pass in), you can tell it to
stop at bit/descriptor N, where N is the highest numbered descriptor in
all of the fd_set bitmasks passed to select().
To be honest, I've never passed anything but FD_SETSIZE for this
parameter. When I'm writing a performance critical server, I use poll()
instead. It's faster and I don't have to reinitialize the fd_set
bitmasks on each iteration. It's technically less portable, but I've
never had an issue across Solaris, HP-UX, Linux, or FreeBSD.
------------------------------
End of freebsd-hackers-digest V5 #743
*************************************
To Unsubscribe: send mail to majo...@FreeBSD.org
with unsubscribe freebsd-hackers-digest in the body of the message