freebsd-hackers-digest V5 #738
owner-freebsd-...@freebsd.org
freebsd-hackers-digest Friday, March 7 2003 Volume 05 : Number 738
In this issue:
Re: Smarter kernel modules?
Re: Smarter kernel modules?
4.8-RC report
Re: 4.8-RC report
Re: Realtek
Re: future of all the jail patches [was: Re: jail statfs patch]
Re: Realtek
send mail using alternate SMTP server
Why natd don't divert packets?
Re: Why natd don't divert packets?
Re: Why natd don't divert packets?
Re: 4.8-RC report
unsubscribe
Re: Why natd don't divert packets?
Re: Why natd don't divert packets?
High CPU usage when forwarding packets
Re: Realtek
Re: Realtek
Re: High CPU usage when forwarding packets
Re: Realtek
----------------------------------------------------------------------
Date: Fri, 7 Mar 2003 06:12:48 +1100
From: Peter Jeremy <peter...@optushome.com.au>
Subject: Re: Smarter kernel modules?
On Thu, Mar 06, 2003 at 09:41:04AM -0700, M. Warner Losh wrote:
>In message: <20030306075...@cirb503493.alcatel.com.au>
> Peter Jeremy <peter...@optushome.com.au> writes:
>: Disadvantages:
>: - Needs grunt-work to write the #defines
>: - Kernel symbols reported by nm(1) look strange (unless we patch
>: binutils to understand our versioning scheme).
>: - May present problems to '##' built symbols.
>
>History has shown that people suck at keeping such a complex scheme up
>to date. Also, it versions functions, but not datta structures. Data
>strucutre changes are the number 1 cause of ABI breakage we've had
>over the last 5 years.
I had thought it was fairly simple to maintain, but hadn't really
thought through the issue of data structures. If a function or
variable definition changes directly, it isn't a great deal of
overhead to increment a number elsewhere in a header file that you
have to edit anyway. (Though the number of 'bump PORTREVISION please'
followups to ports commits suggests that it would be forgotten).
If a struct/union/typedef changes, you would need to look through all
the references to that type and update them. And if any of the
references were another struct/union/typedef, you need to repeat the
process. This would be onerous - especially for common types - and
therefore neglected. I can't think of any way to easily automate
this so I'll withdraw my suggestion.
That said, I feel that a single number (or variable name) is too
coarse and the "do I need to bump the version" decision is too fuzzy.
Unfortunately, I can't think of anything better that wouldn't incur
an unacceptable maintenance overhead.
Peter
------------------------------
Date: Thu, 06 Mar 2003 14:01:29 -0700 (MST)
From: "M. Warner Losh" <i...@bsdimp.com>
Subject: Re: Smarter kernel modules?
In message: <20030306191...@cirb503493.alcatel.com.au>
Peter Jeremy <peter...@optushome.com.au> writes:
: That said, I feel that a single number (or variable name) is too
: coarse and the "do I need to bump the version" decision is too fuzzy.
: Unfortunately, I can't think of anything better that wouldn't incur
: an unacceptable maintenance overhead.
I want the decision to bump it to be "I can't make this change because
it would cause me to have to bump this version."
Warner
------------------------------
Date: Thu, 6 Mar 2003 13:52:07 -0800 (PST)
From: Julian Elischer <jul...@elischer.org>
Subject: 4.8-RC report
After instralling afew machines it seems to mostly work with the
exception of a couple of machiens which just Hang forever while trying
to probe their keyboard.. Has anyone been fiddling in the keyboard
code?
CVS only shows cosmetic changes over the last few months
but something has changed .. I'm going to try another keyboard..
------------------------------
Date: Thu, 6 Mar 2003 14:18:08 -0800 (PST)
From: Julian Elischer <jul...@elischer.org>
Subject: Re: 4.8-RC report
Possibly false alarm:
Preloading the usb keyboard module seems to cause the
normal kbd to hang forever during probing..
I do not yet know if this is documented anywhere
if it isn't then it's still a problem I guess.
On Thu, 6 Mar 2003, Julian Elischer wrote:
>
> After instralling afew machines it seems to mostly work with the
> exception of a couple of machiens which just Hang forever while trying
> to probe their keyboard.. Has anyone been fiddling in the keyboard
> code?
>
> CVS only shows cosmetic changes over the last few months
> but something has changed .. I'm going to try another keyboard..
>
>
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
>
------------------------------
Date: Thu, 6 Mar 2003 15:02:06 -0800 (PST)
From: Paulo Roberto <nir...@yahoo.com>
Subject: Re: Realtek
- --- Bram Van Dam <ganda...@pandora.be> wrote:
> cheap they are they do their job fairly well. If performance isn't
> an issue then go for it.
I couldn't agree more. If you are just staying in 55 mph, you don't
need a Ferrari.
cheers
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
------------------------------
Date: Thu, 6 Mar 2003 15:46:29 -0600 (CST)
From: Mike Silbersack <si...@silby.com>
Subject: Re: future of all the jail patches [was: Re: jail statfs patch]
On Mon, 3 Mar 2003, Bjoern A. Zeeb wrote:
> Christian asks me to file a PR to better get this tracked and perhaps
> included in mainstream.
>
> I had seen lots of jail discussion here the last months but I think
> there had been few PR submission.
>
> What is the overall opinion on this - file PRs ?
>
> What about including (at least some) of the (other) jail patches in HEAD ?
>
> What about jail-ng ?
>
>
> [ Perhaps take this discussion to -current ? ]
>
> --
> Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
Well, the first step to getting anything committed is to find an
interested committer. In order for that committer to look at the patch,
it's naturally best to have a PR filed so that committer can look at it
easily.
So what you should do is:
1. File the PR.
2. Find an interested commmitter.
If 2 fails, ask core for commit privaledges so you can commit it yourself.
Just be quite sure your patch is good before you do that. :)
Mike "Silby" Silbersack
------------------------------
Date: Thu, 6 Mar 2003 21:36:44 -0800
From: Wes Peters <w...@softweyr.com>
Subject: Re: Realtek
On Thursday 06 March 2003 15:02, Paulo Roberto wrote:
> --- Bram Van Dam <ganda...@pandora.be> wrote:
> > cheap they are they do their job fairly well. If performance isn't
> > an issue then go for it.
>
> I couldn't agree more. If you are just staying in 55 mph, you don't
> need a Ferrari.
It's not a ford vs. ferrari problem, it's that the ford only has first
gear, so you're doing 45 mph at redline and in grave danger of blowing
the heads off continuously.
The problem with the RealTek chipset is that the packets have to be
aligned on some completely stupid boundary in memory (32 bytes if memory
serves). The driver code ends up copying the packet data to a tempory
buffer before sending it for almost every outgoing packet, which is just
totally stupid.
There are dozens of other chipsets in the same price range as the
RealTek's that don't require this stupidity, most of them supported by
the dc(4) driver. Track down a couple of different cards, try them out
on your own, and they buy a bunch of them.
Belkin is selling a card based on the Intel (formerly DEC) 21143 for $15;
if you can find them in bulk you can probably get them for $8-9. Those
are a LOT better than the RealTek cards.
JUST SAY NO.
- --
Where am I, and what am I doing in this handbasket?
Wes Peters w...@softweyr.com
------------------------------
Date: Thu, 6 Mar 2003 23:40:22 -0600 (CST)
From: <nb...@unixmexico.com>
Subject: send mail using alternate SMTP server
hi all
is there a command or a way to send email from a shell (no X environment)
specifying the SMTP server, so it don't uses the local SMTP?
may be a hack to the mail command.
thanks
------------------------------
Date: Fri, 7 Mar 2003 11:02:06 +0300 (MSK)
From: denb <de...@front.ru>
Subject: Why natd don't divert packets?
Why natd don't divert packets?
*********screenshot***********************
#ipfw add divert 1111 tcp from any to any 7
#ipfw add divert 1111 tcp from any 7 to any
#natd -v -p 1111 -a 172.16.0.102 -redirect_port tcp 172.16.0.253:7 7
In [TCP] [TCP] 172.16.0.104:49169 -> 172.16.0.102:7 aliased to
[TCP] 172.16.0.104:49169 -> 172.16.0.253:7
In [TCP] [TCP] 172.16.0.104:49169 -> 172.16.0.102:7 aliased to
[TCP] 172.16.0.104:49169 -> 172.16.0.253:7
^C
*********screenshot***********************
Where is Out[TCP]?
Rules after natd running (why second rule has 0 in packets number?):
*********screenshot***********************
#ipfw show
0001 6 180 divert 1111 tcp from any to any dst-port 7
0002 0 0 divert 1111 tcp from any 7 to any
*********screenshot***********************
------------------------------
Date: Fri, 7 Mar 2003 09:14:42 +0100
From: Clement Laforet <sheep...@cultdeadsheep.org>
Subject: Re: Why natd don't divert packets?
On Fri, 7 Mar 2003 11:02:06 +0300 (MSK)
denb <de...@front.ru> wrote:
> Why natd don't divert packets?
>
> *********screenshot***********************
>
> #ipfw add divert 1111 tcp from any to any 7
> #ipfw add divert 1111 tcp from any 7 to any
> #natd -v -p 1111 -a 172.16.0.102 -redirect_port tcp 172.16.0.253:7 7
>
> In [TCP] [TCP] 172.16.0.104:49169 -> 172.16.0.102:7 aliased to
> [TCP] 172.16.0.104:49169 -> 172.16.0.253:7
>
> In [TCP] [TCP] 172.16.0.104:49169 -> 172.16.0.102:7 aliased to
> [TCP] 172.16.0.104:49169 -> 172.16.0.253:7
>
> ^C
> *********screenshot***********************
>
> Where is Out[TCP]?
>
Your boxes seems to be on the same subnet, "out" packets are directly
sent to 172.16.0.104, not 172.16.0.102
nat'ing implies routing, so natd is inefficient in your case
clem
------------------------------
Date: Fri, 7 Mar 2003 11:51:45 +0300 (MSK)
From: denb <de...@front.ru>
Subject: Re: Why natd don't divert packets?
Clement Laforet <sheep...@cultdeadsheep.org>:
> On Fri, 7 Mar 2003 11:02:06 +0300 (MSK)
> denb <de...@front.ru> wrote:
>
> > Why natd don't divert packets?
> >
> > *********screenshot***********************
> >
> > #ipfw add divert 1111 tcp from any to any 7
> > #ipfw add divert 1111 tcp from any 7 to any
> > #natd -v -p 1111 -a 172.16.0.102 -redirect_port tcp
172.16.0.253:7 7
> >
> > In [TCP] [TCP] 172.16.0.104:49169 -> 172.16.0.102:7 aliased to
> > [TCP] 172.16.0.104:49169 -> 172.16.0.253:7
> >
> > In [TCP] [TCP] 172.16.0.104:49169 -> 172.16.0.102:7 aliased to
> > [TCP] 172.16.0.104:49169 -> 172.16.0.253:7
> >
> > ^C
> > *********screenshot***********************
> >
> > Where is Out[TCP]?
> >
> Your boxes seems to be on the same subnet, "out" packets are
directly
> sent to 172.16.0.104, not 172.16.0.102
> nat'ing implies routing, so natd is inefficient in your case
>
> clem
>
>
This working in FreeBSD4.7(ipfw1), but broken in FreeBSD 5.0(ipfw2).
Why?
------------------------------
Date: Fri, 07 Mar 2003 11:50:32 +0200
From: Danny Braniss <da...@cs.huji.ac.il>
Subject: Re: 4.8-RC report
this is what i get when using a USB kb:
1- bios works ok (at least from the kb point of view :-)
2- (pxe)boot works ok - i can hit the space-bar, then type boot -v
3- the boot process hangs somewhere after recognizing the em0.
all is ok with a ps/2 kb.
danny
>
> Possibly false alarm:
>
> Preloading the usb keyboard module seems to cause the
> normal kbd to hang forever during probing..
> I do not yet know if this is documented anywhere
> if it isn't then it's still a problem I guess.
>
>
> On Thu, 6 Mar 2003, Julian Elischer wrote:
>
> >
> > After instralling afew machines it seems to mostly work with the
> > exception of a couple of machiens which just Hang forever while trying
> > to probe their keyboard.. Has anyone been fiddling in the keyboard
> > code?
> >
> > CVS only shows cosmetic changes over the last few months
> > but something has changed .. I'm going to try another keyboard..
> >
> >
> > To Unsubscribe: send mail to majo...@FreeBSD.org
> > with "unsubscribe freebsd-hackers" in the body of the message
> >
>
>
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
>
------------------------------
Date: Fri, 7 Mar 2003 11:28:48 +0100 (CET)
From: Jonas Hedqvist <j...@sdf.se>
Subject: unsubscribe
------------------------------
Date: Fri, 7 Mar 2003 11:40:18 +0100
From: Bernd Walter <ti...@cicely9.cicely.de>
Subject: Re: Why natd don't divert packets?
On Fri, Mar 07, 2003 at 11:51:45AM +0300, denb wrote:
> This working in FreeBSD4.7(ipfw1), but broken in FreeBSD 5.0(ipfw2).
> Why?
This is an issue triggered by compiling libalias with -O2.
Recompile libalias without -O2 and recompile natd so it binds to the
rebuild libalias.a
The problem wasn't there a month ago.
See -current list for firther details.
- --
B.Walter COSMO-Project http://www.cosmo-project.de
ti...@cicely.de Usergroup in...@cosmo-project.de
------------------------------
Date: Fri, 7 Mar 2003 14:22:11 +0300 (MSK)
From: denb <de...@front.ru>
Subject: Re: Why natd don't divert packets?
Bernd Walter <ti...@cicely9.cicely.de>:
> On Fri, Mar 07, 2003 at 11:51:45AM +0300, denb wrote:
> > This working in FreeBSD4.7(ipfw1), but broken in FreeBSD 5.0
(ipfw2).
> > Why?
>
> This is an issue triggered by compiling libalias with -O2.
> Recompile libalias without -O2 and recompile natd so it binds to
the
> rebuild libalias.a
> The problem wasn't there a month ago.
> See -current list for firther details.
>
> --
> B.Walter COSMO-Project http://www.cosmo-
project.de
> ti...@cicely.de Usergroup in...@cosmo-project.de
>
>
I ran this on FreeBSD 5.0-RELEASE, not CURRENT. Any suggestions?
------------------------------
Date: Fri, 7 Mar 2003 13:10:39 +0000
From: Bruce Cran <br...@cran.org.uk>
Subject: High CPU usage when forwarding packets
I've just setup a P75 system as a router, containing fa311 and pcnet network
cards. The fa311 is doing nat to my private network, which is served by the
pcnet card. However, I've found that it often uses 40% cpu just to send
packets from the fa311 (sis) to the pcnet (lnc) cards. natd uses 20%, 10%
are interrupts, and 25% is 'system' as shown in top. Also, I'm getting
several thousand 'lnc0: Missed packet -- no receive buffer' messages.
Could this be the problem, or is the system just not powerful enough do
nat? The sis0 card is 100MBit PCI, while the lcn0 is 10MBit ISA.
Bruce Cran
------------------------------
Date: Fri, 7 Mar 2003 09:16:16 -0800 (PST)
From: Doug Ambrisko <ambr...@ambrisko.com>
Subject: Re: Realtek
Wes Peters writes:
| On Thursday 06 March 2003 15:02, Paulo Roberto wrote:
| > --- Bram Van Dam <ganda...@pandora.be> wrote:
| > > cheap they are they do their job fairly well. If performance isn't
| > > an issue then go for it.
| >
| > I couldn't agree more. If you are just staying in 55 mph, you don't
| > need a Ferrari.
|
| It's not a ford vs. ferrari problem, it's that the ford only has first
| gear, so you're doing 45 mph at redline and in grave danger of blowing
| the heads off continuously.
|
| The problem with the RealTek chipset is that the packets have to be
| aligned on some completely stupid boundary in memory (32 bytes if memory
| serves). The driver code ends up copying the packet data to a tempory
| buffer before sending it for almost every outgoing packet, which is just
| totally stupid.
[snip]
| JUST SAY NO.
Actually, test and the pick the fastest tends to be better.
Since D-Link dropped their good 4-port card for a broken one which they
discontinued we had to scramble for a solution. Our test bed was a
basically a "server" machine tied to a "router/bridge" like thing with
4 clients. We'd run tests all to the server, all to the clients and
everything at once. This illustrated the HW issue with the new D-Link 4
port card since none of their "supported" drivers and OSes could get over
20Mbs. We had 100FDX links to each client and a Gig link to the server.
FreeBSD could peak to 40Mbs if I recall right and we were told FreeBSD
must be broken even though it was faster then their supported OSes
(Windows < 1Mbs)! To be honest I did fix a bunch of bugs in the FreeBSD
driver.
Using this framework we had a bridge riser card that we could plug
4 various PCI ethernet cards. We tested the dc(4), fxp(4), rl(4), sis(4)
cards of various types and with our motherboard and CPU the rl(4) 8139C
chips where the fastest via netperf with a significant margin. I went
into the test biased against Realtek but couldn't justify not using them
after testing. Now we are using the 8100L chip so we have a pretty simple
design.
So I'd say given a sufficiently fast CPU and memory the Realteks work
pretty darn good. The speed win could be do to a slightly better
bus interface. That was the problem with the newer D-Link 4 port card
in that during RX the chip would take over the PCI bus for a loooong time.
A sufficiently fast CPU in our case is 700Mhz Celeron which is a lot
different then pushing 100Mbs with a P5 133Mhz.
Our bigger issue is bus performance on a 32bit/33Mhz bus with 3, 4-port cards.
To date we haven't had any trouble with them and we've shipped a bunch.
Doug A.
------------------------------
Date: Fri, 07 Mar 2003 10:43:37 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: Realtek
Wes Peters wrote:
> The problem with the RealTek chipset is that the packets have to be
> aligned on some completely stupid boundary in memory (32 bytes if memory
> serves). The driver code ends up copying the packet data to a tempory
> buffer before sending it for almost every outgoing packet, which is just
> totally stupid.
And TCP/IP headers are not an even multiple of the alignment boundary
(4 bytes, actually). So every packet the card DMA's in has to be
copied so that access to the TCP packet contents are aligned.
- -- Terry
------------------------------
Date: Fri, 07 Mar 2003 10:58:23 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: High CPU usage when forwarding packets
Bruce Cran wrote:
> Also, I'm getting
> several thousand 'lnc0: Missed packet -- no receive buffer' messages.
> Could this be the problem, or is the system just not powerful enough do
> nat? The sis0 card is 100MBit PCI, while the lcn0 is 10MBit ISA.
The "no receive buffers available" message happens when the
system runs out of mbufs.
There are a lot of reasons this could happen, but the proximal
cause is you didn't tune the number NMBCLUSTERS, et. al. high
enough. You should try rebuilding your kernel with a larger
number.
If the problem still happens, you need to do a "netstat -a > x",
and then look for large numbers in the "Recv-Q" and "Send-Q"
columns, and then figure out what's causing them.
- -- Terry
------------------------------
Date: Fri, 7 Mar 2003 21:34:26 +0100
From: Thierry Herbelot <thi...@herbelot.com>
Subject: Re: Realtek
Le Friday 07 March 2003 18:16, Doug Ambrisko a écrit :
[SNIP]
> everything at once. This illustrated the HW issue with the new D-Link 4
> port card since none of their "supported" drivers and OSes could get over
> 20Mbs. We had 100FDX links to each client and a Gig link to the server.
> FreeBSD could peak to 40Mbs if I recall right and we were told FreeBSD
> must be broken even though it was faster then their supported OSes
> (Windows < 1Mbs)! To be honest I did fix a bunch of bugs in the FreeBSD
> driver.
>
[re-SNIP]
>
> Our bigger issue is bus performance on a 32bit/33Mhz bus with 3, 4-port
> cards.
and the avid reader asks : so, now, what NIC are you really using ? (I too
have used with great pleasure quite a bunch of DLink-DFE-570), and I was
leaning towards using the newer DFE-580 4-port on another project ...)
any suggestions (with benchmark results ?) heartily welcome !
TfH
>
> To date we haven't had any trouble with them and we've shipped a bunch.
then, what are these "them" ?
>
> Doug A.
>
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
------------------------------
End of freebsd-hackers-digest V5 #738
*************************************
To Unsubscribe: send mail to majo...@FreeBSD.org
with unsubscribe freebsd-hackers-digest in the body of the message