Re: kern/123172: [bce] Watchdog timeout problems with if_bce

[Josh Endries]

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

From: Josh Endries <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc:  
Subject: Re: kern/123172: [bce] Watchdog timeout problems with if_bce
Date: Wed, 30 Apr 2008 08:58:23 -0400

 It's been working well for a while, so I might have fixed whatever was 
 causing the problem to manifest. I converted my lo0 jails to use real 
 IPs, and removed my pf config that was routing things around, so I 
 suspect that had something to do with it. I can't change it back right 
 now, later this week/weekend I should be able to.
 
 I had jails on 127.0.0.x (a couple still are), namely the BIND jail, but 
 my switch was load balancing it so the machine was BINATing the 10.0.0 
 address the switch was talking to  with the local 127.0.0.3 address 
 (iirc). The switch was NATing the 10 address to a real IP.
 
 The problem was that I also have some real IPs on this box, so the 
 machine wanted to route packets out that interface, so I had to use 
 route-to/reply-to for the BIND jail to get things to go back out the way 
 they came in, instead of using the x.x.164/24 route or default route. It 
 did work in the configuration, but had the watchdog errors. I think this 
 might have something to do with the issue; I'll put things back and test 
 it some more when I have some time.
 
 I did see that other PR, but since this is a newer version of FreeBSD, 
 and I have no ACPI problems or problems booting (that I've noticed, at 
 least), I decided to submit. They certainly could be related (we're both 
 using amd64; unfortunately I can't change that to test i386). Here is 
 some more info...
 
 jls:
 
 JID  IP Address  Hostname  Path
   5  x.x.164.7   smtp  /jails/smtp/root
   4  127.0.0.5   mx/jails/mx/root
   3  x.x.164.4   ns/jails/ns/root
   2  127.0.0.4   pkg   /jails/pkg/root
   1  127.0.0.2   mysql /jails/mysql/root
 
 /etc/pf.conf:
 
 nat on vlan2 from  to any -> x.x.164.123
 binat on vlan8 from $jail_mysql_ip to any -> $jail_mysql_exip
 
 block log (user) all
 pass in log (user) quick on vlan2 inet proto { tcp, udp } from any to 
 $jail_ns_ip port domain keep state
 pass out log (user) quick on vlan2 inet proto { tcp, udp } from 
 $jail_ns_ip to any port domain keep state
 pass quick log (user) on lo0 inet proto udp from  to 
  port domain keep state
 pass quick log (user) on lo0 inet proto tcp from  to 
 $jail_mysql_ip port 3306 keep state
 pass out log (user) quick on vlan8 inet proto tcp from $jail_mysql_exip 
 to 10.0.1.2 port 3306 keep state
 pass in log (user) quick on vlan11 inet proto tcp from  to 
 vlan11 port 55185 keep state
 pass log (user) quick inet proto icmp all icmp-type $icmp_types keep state
 pass out log (user) quick on vlan2 inet proto tcp from x.x.164.123 to 
 any keep state
 
 uname -a:
 
 FreeBSD hathor 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Tue Mar 24 13:36:33 
 EDT 2009 [EMAIL PROTECTED]:/jails/src/usr/obj/jails/src/usr/src/sys/ULEMAC 
   amd64
 
 kernel config:
 
 include GENERIC
 ident   ULEMAC
 nooptions   SCHED_4BSD
 options SCHED_ULE
 options MAC
 
 ifconfig:
 
 bce0: flags=8843 metric 0 mtu 1500
  
 options=1bb
  ether 00:1f:29:06:d9:e2
  media: Ethernet autoselect (100baseTX )
  status: active
  lagg: laggdev lagg0
 bce1: flags=8843 metric 0 mtu 1500
  
 options=1bb
  ether 00:1f:29:06:d9:e2
  media: Ethernet autoselect (100baseTX )
  status: active
  lagg: laggdev lagg0
 lo0: flags=8049 metric 0 mtu 16384
  inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
  inet6 ::1 prefixlen 128
  inet 127.0.0.1 netmask 0xff00
  inet 127.0.0.2 netmask 0x
  inet 127.0.0.4 netmask 0x
  inet 127.0.0.5 netmask 0x
 lagg0: flags=8843 metric 0 mtu 1500
  
 options=1bb
  ether 00:1f:29:06:d9:e2
  media: Ethernet autoselect
  status: active
  laggproto lacp
  laggport: bce1 flags=1c
  laggport: bce0 flags=1c
 vlan2: flags=8843 metric 0 mtu 1500
  options=3
  ether 00:1f:29:06:d9:e2
  inet x.x.164.123 netmask 0xff00 broadcast x.x.164.255
  inet x.x.164.4 netmask 0x broadcast x.x.164.4
  inet x.x.164.7 netmask 0x broadcast x.x.164.7
  media: Ethernet autoselect
  status: active
  vlan: 2 parent interface: lagg0
 vlan8: flags=8843 metric 0 mtu 1500
  options=3
  ether 00:1f:29:06:d9:e2
  inet 10.0.1.6 netmask 0xfff8 broadcast 10.0.1.7
  media: Ethernet autoselect
  status: active
  vlan: 8 parent interface: lagg0
 vlan11: flags=8843 metric 0 mtu 1500
  options=3
  ether 00:1f:29:06:d9:e2
   

Re: multiple routing tables review patch ready for simple testing.

[Bruce M Simpson]

Julian Elischer wrote:

An interface may however be present in entries from multiple FIBs
in which case the INCOMING packets on that interface need to
be disambiguated with respect to which FIB they belong to.


Yes, there is no way the forwarding code alone can do this.

It should not be expected to, and it's important to maintain a clean 
functional separation there, otherwise one ends up in the same quagmire 
which has been plaguing a lot of QoS research projects over the years 
(Where do I put this bit of the system?)




This is a job for an outside entity (from the fibs).
In this case a packet classifier such as pf or ipfw is ideal
for the job. providing an outside mechanism for implementing
whatever policy the admin wants to set up.


Absolutely. This has been the intent from the beginning.

There is no "one size fits all" approach here. We could put a packet 
classifier into the kernel which works just fine for DOCSIS consumer 
distribution networks, but has absolutely no relevance to an ATM 
backbone (these are the two main flavours of access for folk in the UK).




I find it is convenient to envision each routing FIB as a routing
plane, in a stack of such planes. Each plane may know about the same
interfaces or different interfaces. When a packet enters a routing
plane it is routed according to the internal rules of that plane.
Irrespective of how other planes may act.  Each plane can only route
a packet to interfaces that are know about on that plane.
Incoming packets on an interface don't know what plane to go to
and must be told which to use by the external mechanism. It
IS possible that an interface in the future might have a default
plane, but I haven't implemented this.


This limitation seems fine for now.

Users can't be expected to configure the defaults "by default" if they 
aren't supported, so, if overall the VRF-like feature defaults to off, 
and there are big flashing bold letters saying "You must fully configure 
the forwarding plane mappings if you wish to use multiple FIBs", then 
that's fine by me.




if you have several alias addresses on an interface it is possible
that some FIBS know about some of them and others know about other
addresses. New addresses when added are added to each FIB and
whatever is adding them shoudl remove them from the ones that don't
need it.  This may change but it fits in with how the current code
works and keeps the diff to a manageable size.


   In any event, for plain old IP forwarding, a node's endpoint 
addresses are used only as convenient ways of referring to physical links.


To back up and give this some detailed background:

   For example, 192.0.2.1/24 might be configured on fxp0, and we 
receive a packet on another interface for 192.0.2.2. When resolving a 
route, the forwarding code needs to do a lookup to see from where 
192.0.2.2 is reachable before the next-hop is resolved in the table. 
That happens on a per-FIB basis, when the patches are applied -- however 
the job of tagging input for which FIB is the job of the classifier.


   The problems with the above approach begin when an input interface 
resides in multiple virtual FIBs (no 1:1 mapping), or when you can't 
refer to it by an address (it has no address -- unnumbered 
point-to-point link, or addresses do not apply), or when you attempt to 
implement encapsulation (e.g. GRE, IPIP) in the forwarding layer.


   Then, you're reliant on each individual FIB having resolved 
next-hops correctly. The existing forwarding code already does some of 
this by forcing the ifp to be set for any route added to the table. This 
is done implicitly for routes which transit point-to-point interfaces.
   BSD has had some weaknesses in this area. It makes implementing 
things like VRRP particularly difficult, which is why the ifnet approach 
to CARP was used (the forwarding table gets to see a single ifp); it 
eliminates a level of possible recursion from that layer of the routing 
stack.


   With multicast, for example, next-hops can't be identified by IPv4 
addresses alone. Every forwarding decision has potentially more than one 
result, and links are referred to by physical link (this could be an 
ifp, an interface index, a name, whatever), and where messages are 
forwarded is determined using a link-scope protocol such as IGMP.


   There, it's reasonable to expect that the user partitioned off the 
multicast forwarding planes into separate virtual FIBs, and that the 
appropriate rules in the classifier are configured.


   For SSM, the key (S,G) match has to happen in the input classifier, 
if one is going to route flows OK using the multiple FIB feature -- the 
multicast routing daemons have to be aware of it, 'cuz you can't run a 
separate instance of PIM for every set of flows -- PIM is greedy 
per-link, a !1:1 mapping problem exists, PIM has no way of telling 
separate instances apart (no hierarchy in the form of e.g. OSPF areas, 
and even OSPF won't let you put a link in more than 

Re: multiple routing tables review patch ready for simple testing.

[Kevin Oberman]

> Date: Tue, 29 Apr 2008 00:44:18 -0700
> From: Julian Elischer <[EMAIL PROTECTED]>
> Sender: [EMAIL PROTECTED]
> 
> The patch can be found at
>   http://www.freebsd.org/~julian/mrt.diff
>  (or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6)
>  
> or source can be taken from perforce at:
>  //depot/user/julian/routing/src
> 
> a kernel needs to be created with the option ROUTETABLES=N
> 
> e.g.
>  +optionsROUTETABLES=2   # max 16. 1 is back 
> compatible.
> 
> leaving this out will result in just a single routing table as per normal.
> 
> the max is 16 but I have an artificial (even lower) at 8 but that may
> be gone by the time people try it :-)
> 
> I ws informed early in this project that kernel routing tables should
> now be refered to as FIBs (forwarding Information base?).
> 
> the new command "setfib" sets teh default fib for a process and all its
> decendents

I have been working with big routers in my day job for years and it's
really frustrating to not have this sort of capability when I work with
FreeBSD, but I don't expect a general purpose OS to ever have the
routing capabilities of a dedicated router.

I think this will really, really be nice for my needs, though.

As terminology goes, I think you have it slightly off.

Modern routers have two "classes" of tables to move packets between
interfaces: the RIB Routing information base) and the FIB (Forwarding
Information Base). A router has multiple RIBs, usually one for each
network layer protocol (IPv4 and IPv6, both unicast and multicast) and
added RIBs for policy based routes. They may be further broken up by the
protocol used to populate the table (BGP, OSPF, ISIS, MPLS, static,
connected, ...)

The RIBs exports data, as needed to a single FIB which is used by the
ASICs (hardware forwarding engines) to do the actual forwarding of the
packets. In a real router, the forwarding of almost all packets is done
in hardware with no real involvement by the processor that determines the
routes. (N.B. This is a gross simplification of what modern routers
do or can do, but I don't want to send a book to the list.)

A general purpose OS is a different beast as it has no physical
equivalent of the FIB. It may have multiple routing tables, though, to
I think setrib would be a term less likely to cause confusion then
setfib even though, in the case of your FreeBSD patches, it's really
both.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]   Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751


pgpNlC61DpI7I.pgp
Description: PGP signature

Re: multiple routing tables review patch ready for simple testing.

[Kevin Oberman]

> Date: Tue, 29 Apr 2008 12:17:15 -0700
> From: Julian Elischer <[EMAIL PROTECTED]>
> Sender: [EMAIL PROTECTED]
> 
> Kevin Oberman wrote:
> >> Date: Tue, 29 Apr 2008 00:44:18 -0700
> >> From: Julian Elischer <[EMAIL PROTECTED]>
> >> Sender: [EMAIL PROTECTED]
> >>
> >> The patch can be found at
> >>   http://www.freebsd.org/~julian/mrt.diff
> >>  (or http://www.freebsd.org/~julian/mrt6.diff for RELENG_6)
> >>  
> >> or source can be taken from perforce at:
> >>  //depot/user/julian/routing/src
> >>
> >> a kernel needs to be created with the option ROUTETABLES=N
> >>
> >> e.g.
> >>  +optionsROUTETABLES=2   # max 16. 1 is back 
> >> compatible.
> >>
> >> leaving this out will result in just a single routing table as per normal.
> >>
> >> the max is 16 but I have an artificial (even lower) at 8 but that may
> >> be gone by the time people try it :-)
> >>
> >> I ws informed early in this project that kernel routing tables should
> >> now be refered to as FIBs (forwarding Information base?).
> >>
> >> the new command "setfib" sets teh default fib for a process and all its
> >> decendents
> > 
> > I have been working with big routers in my day job for years and it's
> > really frustrating to not have this sort of capability when I work with
> > FreeBSD, but I don't expect a general purpose OS to ever have the
> > routing capabilities of a dedicated router.
> > 
> > I think this will really, really be nice for my needs, though.
> > 
> > As terminology goes, I think you have it slightly off.
> > 
> > Modern routers have two "classes" of tables to move packets between
> > interfaces: the RIB Routing information base) and the FIB (Forwarding
> > Information Base). A router has multiple RIBs, usually one for each
> > network layer protocol (IPv4 and IPv6, both unicast and multicast) and
> > added RIBs for policy based routes. They may be further broken up by the
> > protocol used to populate the table (BGP, OSPF, ISIS, MPLS, static,
> > connected, ...)
> > 
> > The RIBs exports data, as needed to a single FIB which is used by the
> > ASICs (hardware forwarding engines) to do the actual forwarding of the
> > packets. In a real router, the forwarding of almost all packets is done
> > in hardware with no real involvement by the processor that determines the
> > routes. (N.B. This is a gross simplification of what modern routers
> > do or can do, but I don't want to send a book to the list.)
> > 
> > A general purpose OS is a different beast as it has no physical
> > equivalent of the FIB. It may have multiple routing tables, though, to
> > I think setrib would be a term less likely to cause confusion then
> > setfib even though, in the case of your FreeBSD patches, it's really
> > both.
> 
> The way I see it the routing daemons (e.g. quagga) have the RIBS
> and the kernel has FIBS because it doesn't really know the big picture.
> 
> If we need to change the terminology now is the time..
> I asked for comments on terminology before and this is what we
> came up with.. but once it gets committed it gets set in stone.

On further review, I agree with you. The table in the kernel really is a
FIB (or a logical equivalent), and not really a RIB, so I withdraw any
objection to setfib.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]   Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751


pgpy7E8KvRlXJ.pgp
Description: PGP signature

Re: multiple routing tables review patch ready for simple testing.

[Julian Elischer]

Bruce M Simpson wrote:

Julian Elischer wrote:

An interface may however be present in entries from multiple FIBs
in which case the INCOMING packets on that interface need to
be disambiguated with respect to which FIB they belong to.


Yes, there is no way the forwarding code alone can do this.

It should not be expected to, and it's important to maintain a clean 
functional separation there, otherwise one ends up in the same quagmire 
which has been plaguing a lot of QoS research projects over the years 
(Where do I put this bit of the system?)




This is a job for an outside entity (from the fibs).
In this case a packet classifier such as pf or ipfw is ideal
for the job. providing an outside mechanism for implementing
whatever policy the admin wants to set up.


Absolutely. This has been the intent from the beginning.

There is no "one size fits all" approach here. We could put a packet 
classifier into the kernel which works just fine for DOCSIS consumer 
distribution networks, but has absolutely no relevance to an ATM 
backbone (these are the two main flavours of access for folk in the UK).


[...]



It
IS possible that an interface in the future might have a default
plane, but I haven't implemented this.





This limitation seems fine for now.

[...]




   For SSM, the key (S,G)


what's SSM?
[...]



To summarize:
   For now, the limitations of the system should be documented so that 
users don't inadvertently configure local forwarding loops, even for 
unicast traffic; with multicast, the amplification effect of 
misconfiguration is inherently more damaging to a network.


I'm not sure where I should add documentation.
I haven't found the exact right place yet..
I have some notes but I haven't found a good place to put them



cheers
BMS

P.S. I see you tweaked verify_path() to do the lookup in the numbered 
FIB. Cool.


I should point out that for ad-hoc networks, the ability to turn off 
RPF/uRPF for multicast is needed as the routing domain is often NOT 
fully converged -- so the RPF checks normally present may discard 
legitimate traffic which hasn't been forwarded yet. An encapsulation is 
typically used to maintain forwarding state which is relevant to the 
particular topology in use.


I haven't changed any of that.. Basically I've kept clear of
M/Cast. The way I see it, if you don't define ROUTETABLES=2 (or more)
or don;t define it at all in your config then you get what you had
before and I shouldn't have broken anything.

I take it from this that you don't have any major complaints
as far as what I've done.

I'd like to get a few people to apply the diff and try it
(more than just me for sure), and then I'd like to get it committed 
soon so that I can move on with it.  I would like to get what is

there now commited becasue it is a logical break before moving to
more work.  What is there is fully functional and consistent.
and should be tested before more extensive changes occur
so that we know where to look if there are problems.


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

Re: multiple routing tables review patch ready for simple testing.

[Bakul Shah]

On Tue, 29 Apr 2008 13:42:03 PDT Julian Elischer <[EMAIL PROTECTED]>  wrote:
> 
> Interfaces are not however assigned to  FIB instance. each FIB may
> contain entries for each interface, and by default they do, but you
> can delete teh entries associated with a particular interface from
> a particular FIB so that fib will never use that interface.
> 
> An interface may however be present in entries from multiple FIBs
> in which case the INCOMING packets on that interface need to
> be disambiguated with respect to which FIB they belong to.

This confuses me

The whole point of a FIB is to decide the *next* hop for a
given input packet. So questions.
1) A packet arrives on an interface.  If this interface is
   associated with more than one FIB, which FIB does it get
   given to?

2) If that decision is taken by a a packet 'classifier',
   isn't it in effect doing the job of a FIB (deciding the
   next hop, which happens to be a local FIB)?  Recall that
   basically a packet passes from a FIB to another FIB until
   it gets to its eventual destination.

3) When a local packets needs to be sent, which FIB gets it?
   Does setfib decides that?  If there a default FIB?

> This is a job for an outside entity (from the fibs).
> In this case a packet classifier such as pf or ipfw is ideal
> for the job. providing an outside mechanism for implementing
> whatever policy the admin wants to set up.

I believe having to use pf/ipfw will slow things down a bit
so the question is what does associating an interface with
multiple FIBs buy you?

> if you have several alias addresses on an interface it is possible
> that some FIBS know about some of them and others know about other
> addresses. New addresses when added are added to each FIB and
> whatever is adding them shoudl remove them from the ones that don't
> need it.  This may change but it fits in with how the current code
> works and keeps the diff to a manageable size.
> (and it suits what I need for work where a route manager daemon
> knows to do this.)

Wouldn't it make sense to treat each alias as on a separate
logical interface?  Then each logical interface belongs to
exactly one FIB.  On input you decide which logical inteface
a packet arrived on by looking at its destination MAC
address.  That reduces confusion quite a bit, at least in my
mind!  What does doing more than this buy you?
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: multiple routing tables review patch ready for simple testing.

[Bruce M. Simpson]

Bakul Shah wrote:

1) A packet arrives on an interface.  If this interface is
   associated with more than one FIB, which FIB does it get
   given to?
  


If you only have a single FIB, there is no issue here.
If you have multiple FIBs, the decision gets made by the classifier.


2) If that decision is taken by a a packet 'classifier',
   isn't it in effect doing the job of a FIB (deciding the
   next hop, which happens to be a local FIB)?  Recall that
   basically a packet passes from a FIB to another FIB until
   it gets to its eventual destination.
  


Up until now, the BSD forwarding code always forwarded packets on the 
basis of the destination address.


In an IP environment this is totally reasonable. Most implementations 
work on this basis -- ultimately, there is a fan-out to a collection of 
tries which hold the prefix information, and there has to be a decision 
about which trie(s) to use for resolving the next-hop. Linux iproute2 
works on this basis more or less.


So the classifier is NOT doing the job of the FIB.


3) When a local packets needs to be sent, which FIB gets it?
   Does setfib decides that?  If there a default FIB?
  


If you look at Julian's patch, he's added an option to the socket layer 
to control this.

There is a default FIB which is used when no FIB tag exists.



I believe having to use pf/ipfw will slow things down a bit
so the question is what does associating an interface with
multiple FIBs buy you?
  


You only need to pass through pf/ipfw if you wish to source-route 
packets, or need to apply a forwarding policy decision more complex than 
the destination field, which is all rtalloc() has historically supported.


If there is any additional latency or slowdown, it's down to how good 
your matching algorithms are as you enter the classifier.




Wouldn't it make sense to treat each alias as on a separate
logical interface?  Then each logical interface belongs to
exactly one FIB.  On input you decide which logical inteface
a packet arrived on by looking at its destination MAC
address.  That reduces confusion quite a bit, at least in my
mind!  What does doing more than this buy you?
  


It doesn't buy anything because there is still no 1:1 mapping -- the 
link-layer destination address maps to an ifp, and multiple aliases 
exist on the ifp.


You still need a classifier to look at other fields in the message and 
decide, based on policy, which FIB is used for next-hop resolution.


Tag switching systems avoid the issue by prepending a tag, but of 
course, what does a packet go through upon entry to an MPLS domain?


You guessed it: A classifier.

cheers
BMS


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

Re: multiple routing tables review patch ready for simple testing.

[Bruce M. Simpson]

Bruce M. Simpson wrote:


Wouldn't it make sense to treat each alias as on a separate
logical interface?  Then each logical interface belongs to
exactly one FIB.  On input you decide which logical inteface
a packet arrived on by looking at its destination MAC
address.  That reduces confusion quite a bit, at least in my
mind!  What does doing more than this buy you?
  


It doesn't buy anything because there is still no 1:1 mapping -- the 
link-layer destination address maps to an ifp, and multiple aliases 
exist on the ifp.


Let me qualify that further: You are talking about splitting network 
layer addresses onto their own logical interfaces, with the goal of 
having a 1:1 mapping for FIB resolution.


This doesn't buy anything, because in IP, the previous hop never encodes 
the next-hop address it sends to -- it merely performs a lookup and 
forwards to you; your MAC address is the same for every IP address you 
have on the link, therefore it is not a unique identifier.


UNLESS you use a separate MAC address for every IP alias which you add, 
in which case, you are merely pushing the mapping elsewhere in the 
stack; it actually adds more complexity in this case.

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

Re: multiple routing tables review patch ready for simple testing.

[Bruce M Simpson]

Julian Elischer wrote:


what's SSM?


Source-specific multicast, where multicast flows (channels) are 
identified by both their original source address, and group address. 
Multicast addresses have no meaning on their own beyond the scope of a 
single link.



I haven't changed any of that.. Basically I've kept clear of
M/Cast. The way I see it, if you don't define ROUTETABLES=2 (or more)
or don;t define it at all in your config then you get what you had
before and I shouldn't have broken anything.


Cool! Doing multicast "right" is Hard. Doing it "right" in ad-hoc 
topologies is Harder.


It makes sense to steer clear of it for now. It can no doubt benefit 
from the hierarchy offered by multiple FIBs, but again, the policy 
routing mechanisms don't really exist just now, and things like PIM need 
changes to encompass it.


They will need to come into existence for the model to work on a macro 
scale, for the same reason SSM was put on the table.




I take it from this that you don't have any major complaints
as far as what I've done.


No problems here... I haven't tried testing.

I would say though if we are going to be renaming rtalloc() and friends, 
that names should really change to be descriptive of what it does.
It doesn't "allocate a route", it tries to look up a forwarding table 
entry, and returns a reference to it.


cheers
BMS
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

[PATCH] autoload if_vlan.ko on vlan creation

[Niki Denev]

Hi,

I've noticed that autoloading of if_vlan.ko on vlan creation does not work
in the case when the vlans are specified with the interface name. i.e. :
fxp0.5
And the problem is that ifmaybeload() in ifconfig.c expects that all
interfaces
are in the format : if_${driver}${number}, which is not the case for vlans
created
in the above mentioned way (which is much more easier and intuitive IMHO)
This patch fixes this for me, and probably others may find it useful.

P.S.: Because of the assumption for the interface name that ifmaybeload()
does,
this patch looks more like a hack and probably a better way could be found
for handling this case.
P.S2: If "ifconfig fxp0." is typed this will autoload if_vlan.ko because we
have a dot after the first number
in the interface name (there is no check if there are other digits after the
dot). I'm not sure
if a more strict check is needed though because I can't imagine this can
cause any real problems.

--- ifconfig.c.orig2008-04-30 12:29:25.0 -0400
+++ ifconfig.c2008-04-30 12:44:50.0 -0400
@@ -935,18 +935,21 @@
 if (noload)
 return;

-/* trim the interface number off the end */
+/* locate interface number beginning */
 strlcpy(ifname, name, sizeof(ifname));
 for (dp = ifname; *dp != 0; dp++)
-if (isdigit(*dp)) {
-*dp = 0;
+if (isdigit(*dp))
 break;
-}

-/* turn interface and unit into module name */
-strcpy(ifkind, "if_");
-strlcpy(ifkind + MOD_PREFIX_LEN, ifname,
-sizeof(ifkind) - MOD_PREFIX_LEN);
+/* check the special case for vlan interfaces */
+if (strchr(dp, '.')) {
+strcpy(ifkind, "if_vlan");
+} else {
+/* turn interface and unit into module name */
+strcpy(ifkind, "if_");
+strlcpy(ifkind + MOD_PREFIX_LEN, ifname,
+sizeof(ifkind) - MOD_PREFIX_LEN);
+}

 /* scan files in kernel */
 mstat.version = sizeof(struct module_stat);
--- ifconfig.c.orig	2008-04-30 12:29:25.0 -0400
+++ ifconfig.c	2008-04-30 12:44:50.0 -0400
@@ -935,18 +935,21 @@
 	if (noload)
 		return;
 
-	/* trim the interface number off the end */
+	/* locate interface number beginning */
 	strlcpy(ifname, name, sizeof(ifname));
 	for (dp = ifname; *dp != 0; dp++)
-		if (isdigit(*dp)) {
-			*dp = 0;
+		if (isdigit(*dp))
 			break;
-		}
 
-	/* turn interface and unit into module name */
-	strcpy(ifkind, "if_");
-	strlcpy(ifkind + MOD_PREFIX_LEN, ifname,
-	sizeof(ifkind) - MOD_PREFIX_LEN);
+	/* check the special case for vlan interfaces */
+	if (strchr(dp, '.')) {
+		strcpy(ifkind, "if_vlan");
+	} else {
+		/* turn interface and unit into module name */
+		strcpy(ifkind, "if_");
+		strlcpy(ifkind + MOD_PREFIX_LEN, ifname,
+		sizeof(ifkind) - MOD_PREFIX_LEN);
+	}
 
 	/* scan files in kernel */
 	mstat.version = sizeof(struct module_stat);
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: multiple routing tables review patch ready for simple testing.

[Julian Elischer]

Bakul Shah wrote:

On Tue, 29 Apr 2008 13:42:03 PDT Julian Elischer <[EMAIL PROTECTED]>  wrote:

Interfaces are not however assigned to  FIB instance. each FIB may
contain entries for each interface, and by default they do, but you
can delete teh entries associated with a particular interface from
a particular FIB so that fib will never use that interface.

An interface may however be present in entries from multiple FIBs
in which case the INCOMING packets on that interface need to
be disambiguated with respect to which FIB they belong to.


This confuses me

The whole point of a FIB is to decide the *next* hop for a
given input packet. So questions.
1) A packet arrives on an interface.  If this interface is
   associated with more than one FIB, which FIB does it get
   given to?



which ever one you select, using the policy of your choice.

that's what policy routing is about.
if you don't WANT policy based routing, dont turn it on.




2) If that decision is taken by a a packet 'classifier',
   isn't it in effect doing the job of a FIB (deciding the
   next hop, which happens to be a local FIB)?  Recall that
   basically a packet passes from a FIB to another FIB until
   it gets to its eventual destination.


the packet classifier selects a FIB which in turn implements a 
particular routing decision tree.

In the degenerate case where a FIB has only one route
then you are correct, but there are technical reasons why this is
superior to just using a fwd rule in the firewall.




3) When a local packets needs to be sent, which FIB gets it?
   Does setfib decides that?  If there a default FIB?


the socket has a fib assocuated with it.
it is inherrited from the process which has a fib associated with it,
which it inherrited from its parent
which probbaly used the setfib syscall.

A process can also use the setfib socket option to make a socket with
a different FIB to its own default fib.




This is a job for an outside entity (from the fibs).
In this case a packet classifier such as pf or ipfw is ideal
for the job. providing an outside mechanism for implementing
whatever policy the admin wants to set up.


I believe having to use pf/ipfw will slow things down a bit
so the question is what does associating an interface with
multiple FIBs buy you?


interfaces are not associated with FIBS on input. Just output..
i.e. a FIB knows about an interface or it doesn't. If it doesn't
know about it it can't send an packets out that way can it?




if you have several alias addresses on an interface it is possible
that some FIBS know about some of them and others know about other
addresses. New addresses when added are added to each FIB and
whatever is adding them shoudl remove them from the ones that don't
need it.  This may change but it fits in with how the current code
works and keeps the diff to a manageable size.
(and it suits what I need for work where a route manager daemon
knows to do this.)




Wouldn't it make sense to treat each alias as on a separate
logical interface?  Then each logical interface belongs to
exactly one FIB.  On input you decide which logical inteface
a packet arrived on by looking at its destination MAC
address.  That reduces confusion quite a bit, at least in my
mind!  What does doing more than this buy you?


you are talking about vimage (for FreeBSD) or what cisco calls VRF.

Stop thinking about receive interfaces... routing is only intersted in
OUTGOING interfaces.



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

Re: multiple routing tables review patch ready for simple testing.

[Julian Elischer]

Bruce M. Simpson wrote:

Bakul Shah wrote:

1) A packet arrives on an interface.  If this interface is
   associated with more than one FIB, which FIB does it get
   given to?
  


If you only have a single FIB, there is no issue here.
If you have multiple FIBs, the decision gets made by the classifier.


2) If that decision is taken by a a packet 'classifier',
   isn't it in effect doing the job of a FIB (deciding the
   next hop, which happens to be a local FIB)?  Recall that
   basically a packet passes from a FIB to another FIB until
   it gets to its eventual destination.
  


Up until now, the BSD forwarding code always forwarded packets on the 
basis of the destination address.


In an IP environment this is totally reasonable. Most implementations 
work on this basis -- ultimately, there is a fan-out to a collection of 
tries which hold the prefix information, and there has to be a decision 
about which trie(s) to use for resolving the next-hop. Linux iproute2 
works on this basis more or less.


So the classifier is NOT doing the job of the FIB.


3) When a local packets needs to be sent, which FIB gets it?
   Does setfib decides that?  If there a default FIB?
  


If you look at Julian's patch, he's added an option to the socket layer 
to control this.

There is a default FIB which is used when no FIB tag exists.


actually this ha changed in the latest code..
now all packets have a fib. as do all sockets and processes.
If you do nothing those values are all 0 meaning FIB 0.





I believe having to use pf/ipfw will slow things down a bit
so the question is what does associating an interface with
multiple FIBs buy you?
  


You only need to pass through pf/ipfw if you wish to source-route 
packets, or need to apply a forwarding policy decision more complex than 
the destination field, which is all rtalloc() has historically supported.


If there is any additional latency or slowdown, it's down to how good 
your matching algorithms are as you enter the classifier.




Wouldn't it make sense to treat each alias as on a separate
logical interface?  Then each logical interface belongs to
exactly one FIB.  On input you decide which logical inteface
a packet arrived on by looking at its destination MAC
address.  That reduces confusion quite a bit, at least in my
mind!  What does doing more than this buy you?
  


It doesn't buy anything because there is still no 1:1 mapping -- the 
link-layer destination address maps to an ifp, and multiple aliases 
exist on the ifp.


You still need a classifier to look at other fields in the message and 
decide, based on policy, which FIB is used for next-hop resolution.


Tag switching systems avoid the issue by prepending a tag, but of 
course, what does a packet go through upon entry to an MPLS domain?


You guessed it: A classifier.

cheers
BMS



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

Re: multiple routing tables review patch ready for simple testing.

[Julian Elischer]

Bruce M Simpson wrote:

Julian Elischer wrote:


what's SSM?


Source-specific multicast, where multicast flows (channels) are 
identified by both their original source address, and group address. 
Multicast addresses have no meaning on their own beyond the scope of a 
single link.



I haven't changed any of that.. Basically I've kept clear of
M/Cast. The way I see it, if you don't define ROUTETABLES=2 (or more)
or don;t define it at all in your config then you get what you had
before and I shouldn't have broken anything.


Cool! Doing multicast "right" is Hard. Doing it "right" in ad-hoc 
topologies is Harder.


It makes sense to steer clear of it for now. It can no doubt benefit 
from the hierarchy offered by multiple FIBs, but again, the policy 
routing mechanisms don't really exist just now, and things like PIM need 
changes to encompass it.


They will need to come into existence for the model to work on a macro 
scale, for the same reason SSM was put on the table.




I take it from this that you don't have any major complaints
as far as what I've done.


No problems here... I haven't tried testing.


please  please do..

just apply the patch to a regular source tree and compile.. :-)



I would say though if we are going to be renaming rtalloc() and friends, 
that names should really change to be descriptive of what it does.
It doesn't "allocate a route", it tries to look up a forwarding table 
entry, and returns a reference to it.


It's important to not break source compatibility for 3rd party 
suppliers and users. (e.g. ironport, juniper, nokia, issilon, etc. etc.)


they know about rtalloc...

having said that I do plan on a pass over the code to rationalise some 
of the names that may have "evolved" during developement of the patch.





cheers
BMS


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

Re: kern/122875: "rstatd: Can't get namelist. 1" - fbsd 7.0-stable (works ok in 7.0-release)

[hotlips Internet admin]

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

From: hotlips Internet admin <[EMAIL PROTECTED]>
To: Kris Kennaway <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: kern/122875: "rstatd: Can't get namelist. 1" - fbsd 7.0-stable
 (works ok in 7.0-release)
Date: Wed, 30 Apr 2008 14:32:56 -0400 (EDT)

 On Mon, 28 Apr 2008, Kris Kennaway wrote:
 |hotlips Internet admin wrote:
 |> The following reply was made to PR kern/122875; it has been noted by GNATS.
 |> 
 |> From: hotlips Internet admin <[EMAIL PROTECTED]>
 |> To: [EMAIL PROTECTED], [EMAIL PROTECTED]
 |> Cc: [EMAIL PROTECTED]
 |> Subject: Re: kern/122875: "rstatd: Can't get namelist. 1" - fbsd 7.0-stable
 |>  (works ok in 7.0-release)
 |> Date: Fri, 25 Apr 2008 20:50:51 -0400 (EDT)
 |> 
 |>  On Fri, 18 Apr 2008 [EMAIL PROTECTED] wrote:
 |>   |Thank you very much for your problem report.
 |>  |It has the internal identification `kern/122875'.
 |>  |The individual assigned to look at your
 |>  |report is: freebsd-bugs.  |
 |>  |You can access the state of your problem report at any time
 |>  |via this link:
 |>  |
 |>  |http://www.freebsd.org/cgi/query-pr.cgi?pr=122875
 |>  |
 |>  |>Category:   kern
 |>  |>Responsible:freebsd-bugs
 |>  |>Synopsis:   "rstatd: Can't get namelist. 1" - fbsd 7.0-stable (works
 |> ok in 7.0-release)
 |>  |>Arrival-Date:   Fri Apr 18 02:20:00 UTC 2008
 |> this also happens in FreeBSD 6.3-STABLE
 |> I depend heavily on rpc.rstatd as a part of monitoring
 |> servers and firewalls etc., so this is a serious issue
 |> for me until I can get a fix or work-around
 |
 |Revert the recent commits by Peter until a fix is applied.
 
 
I'm not sure if this is something i should do locally,
or whether those commites are being reverted in the
FBSD source tree
 
 
if it's someting to do locally, I would need to know
what to do in detail ...
 
 
this also seems related to PR ports/123146 btw ...
 
 
 Thanks,
 Bruce Becker   +1 416 410 0879
 GTS Network Administration Toronto, Ont.
 Email: [EMAIL PROTECTED]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [PATCH] autoload if_vlan.ko on vlan creation

[Brooks Davis]

On Wed, Apr 30, 2008 at 02:01:21PM -0400, Niki Denev wrote:
> Hi,
> 
> I've noticed that autoloading of if_vlan.ko on vlan creation does not
> work in the case when the vlans are specified with the interface name.
> i.e. : fxp0.5 And the problem is that ifmaybeload() in ifconfig.c
> expects that all interfaces are in the format : if_${driver}${number},
> which is not the case for vlans created in the above mentioned way
> (which is much more easier and intuitive IMHO) This patch fixes this
> for me, and probably others may find it useful.

What is the practical use of this feature?  If you don't have the
module loaded, the rc scripts won't even see the interface unless
you manually set network_interfaces which has been documented as a
deprecated configuration since 6.2 and will soon generate warnings in
7-stable.  If you want to use an interface, why not add an appropriate
entry to /boot/loader.conf and be done with it?

-- Brooks

> P.S.: Because of the assumption for the interface name that
> ifmaybeload() does, this patch looks more like a hack and probably a
> better way could be found for handling this case.  P.S2: If "ifconfig
> fxp0." is typed this will autoload if_vlan.ko because we have a dot
> after the first number in the interface name (there is no check if
> there are other digits after the dot). I'm not sure if a more strict
> check is needed though because I can't imagine this can cause any real
> problems.
>
> 
> --- ifconfig.c.orig2008-04-30 12:29:25.0 -0400
> +++ ifconfig.c2008-04-30 12:44:50.0 -0400
> @@ -935,18 +935,21 @@
>  if (noload)
>  return;
> 
> -/* trim the interface number off the end */
> +/* locate interface number beginning */
>  strlcpy(ifname, name, sizeof(ifname));
>  for (dp = ifname; *dp != 0; dp++)
> -if (isdigit(*dp)) {
> -*dp = 0;
> +if (isdigit(*dp))
>  break;
> -}
> 
> -/* turn interface and unit into module name */
> -strcpy(ifkind, "if_");
> -strlcpy(ifkind + MOD_PREFIX_LEN, ifname,
> -sizeof(ifkind) - MOD_PREFIX_LEN);
> +/* check the special case for vlan interfaces */
> +if (strchr(dp, '.')) {
> +strcpy(ifkind, "if_vlan");
> +} else {
> +/* turn interface and unit into module name */
> +strcpy(ifkind, "if_");
> +strlcpy(ifkind + MOD_PREFIX_LEN, ifname,
> +sizeof(ifkind) - MOD_PREFIX_LEN);
> +}
> 
>  /* scan files in kernel */
>  mstat.version = sizeof(struct module_stat);

> --- ifconfig.c.orig   2008-04-30 12:29:25.0 -0400
> +++ ifconfig.c2008-04-30 12:44:50.0 -0400
> @@ -935,18 +935,21 @@
>   if (noload)
>   return;
>  
> - /* trim the interface number off the end */
> + /* locate interface number beginning */
>   strlcpy(ifname, name, sizeof(ifname));
>   for (dp = ifname; *dp != 0; dp++)
> - if (isdigit(*dp)) {
> - *dp = 0;
> + if (isdigit(*dp))
>   break;
> - }
>  
> - /* turn interface and unit into module name */
> - strcpy(ifkind, "if_");
> - strlcpy(ifkind + MOD_PREFIX_LEN, ifname,
> - sizeof(ifkind) - MOD_PREFIX_LEN);
> + /* check the special case for vlan interfaces */
> + if (strchr(dp, '.')) {
> + strcpy(ifkind, "if_vlan");
> + } else {
> + /* turn interface and unit into module name */
> + strcpy(ifkind, "if_");
> + strlcpy(ifkind + MOD_PREFIX_LEN, ifname,
> + sizeof(ifkind) - MOD_PREFIX_LEN);
> + }
>  
>   /* scan files in kernel */
>   mstat.version = sizeof(struct module_stat);

> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"



pgpJHMtSNOPAs.pgp
Description: PGP signature

Re: multiple routing tables review patch ready for simple testing.

[Bakul Shah]

On Wed, 30 Apr 2008 18:56:07 BST "Bruce M. Simpson" <[EMAIL PROTECTED]>  wrote:
> > 2) If that decision is taken by a a packet 'classifier',
> >isn't it in effect doing the job of a FIB (deciding the
> >next hop, which happens to be a local FIB)?  Recall that
> >basically a packet passes from a FIB to another FIB until
> >it gets to its eventual destination.
> >   
> 
> Up until now, the BSD forwarding code always forwarded packets on the 
> basis of the destination address.
>
> In an IP environment this is totally reasonable. Most implementations 
> work on this basis -- ultimately, there is a fan-out to a collection of 
> tries which hold the prefix information, and there has to be a decision 
> about which trie(s) to use for resolving the next-hop. Linux iproute2 
> works on this basis more or less.
> 
> So the classifier is NOT doing the job of the FIB.

Thanks for the explanation!

I guess we look at it somewhat differently.  You seem to
imply that using anything other than destination address is
not a FIB's job.  While to me a FIB can use anything it wants
for its forwarding decision.

> > Wouldn't it make sense to treat each alias as on a separate
> > logical interface?  Then each logical interface belongs to
> > exactly one FIB.  On input you decide which logical inteface
> > a packet arrived on by looking at its destination MAC
> > address.  That reduces confusion quite a bit, at least in my
> > mind!  What does doing more than this buy you?
> >   
> 
> It doesn't buy anything because there is still no 1:1 mapping -- the 
> link-layer destination address maps to an ifp, and multiple aliases 
> exist on the ifp.
> 
> You still need a classifier to look at other fields in the message and 
> decide, based on policy, which FIB is used for next-hop resolution.

Hmm... a few years ago when we looked at this stuff in the
context of hardware assisted forwarding that used more than
just the destination ip address (probably you'd call it
"policy based routing"), it was not clear to me at the time
whether it made sense to separate such classification.  We
were looking at a function something like

 nexthop = lookup(protocol, src addr, dst addr, src port, dst port, ...)

I suppose it makes sense to feed everything except the dst
addr to a classifier when doing this in software (and may be
even hardware but there you have different constraints).  For
us the entire "forwarding table/classifier" was really just a
funky microprogram.  That is, each microinstruction ate some
bits of a packet and decided which next instruction to fetch
and execute.  It wasn't clear to me at the time which was
better -- should it eat the dst addr first or last.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [PATCH] autoload if_vlan.ko on vlan creation

[Niki Denev]

On Wed, Apr 30, 2008 at 2:50 PM, Brooks Davis <[EMAIL PROTECTED]> wrote:
>  What is the practical use of this feature?  If you don't have the
>  module loaded, the rc scripts won't even see the interface unless
>  you manually set network_interfaces which has been documented as a
>  deprecated configuration since 6.2 and will soon generate warnings in
>  7-stable.  If you want to use an interface, why not add an appropriate
>  entry to /boot/loader.conf and be done with it?
>
>  -- Brooks
>

Well, it just bugged me that :

  ifconfig bridge|vlan|lagg create

all autoload the required modules, while

   ifconfig fxp0.5 create

does not.

Anyways, the patch seems to be broken and probably
fixing this just for one special case is not worth it...
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: multiple routing tables review patch ready for simple testing.

[Kevin Oberman]

> Date: Wed, 30 Apr 2008 10:25:51 -0700
> From: Julian Elischer <[EMAIL PROTECTED]>
> 
> Bruce M Simpson wrote:
> > Julian Elischer wrote:
> >> An interface may however be present in entries from multiple FIBs
> >> in which case the INCOMING packets on that interface need to
> >> be disambiguated with respect to which FIB they belong to.
> > 
> > Yes, there is no way the forwarding code alone can do this.
> > 
> > It should not be expected to, and it's important to maintain a clean 
> > functional separation there, otherwise one ends up in the same quagmire 
> > which has been plaguing a lot of QoS research projects over the years 
> > (Where do I put this bit of the system?)
> > 
> >>
> >> This is a job for an outside entity (from the fibs).
> >> In this case a packet classifier such as pf or ipfw is ideal
> >> for the job. providing an outside mechanism for implementing
> >> whatever policy the admin wants to set up.
> > 
> > Absolutely. This has been the intent from the beginning.
> > 
> > There is no "one size fits all" approach here. We could put a packet 
> > classifier into the kernel which works just fine for DOCSIS consumer 
> > distribution networks, but has absolutely no relevance to an ATM 
> > backbone (these are the two main flavours of access for folk in the UK).
> > 
> >[...]
> 
> >> It
> >> IS possible that an interface in the future might have a default
> >> plane, but I haven't implemented this.
> > 
> 
> > This limitation seems fine for now.
> [...]
> 
> 
> > 
> >For SSM, the key (S,G)
> 
> what's SSM?

Source Specific Multicast. It is a scheme for finding the source of a
multicast stream without the need for MSDP. It is intended for
broadcasting (in the radio/TV sense) streams from a single source. It is
not suitable for conferencing as it can't work with multiple sources.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]   Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751


pgpMdTx2slS7m.pgp
Description: PGP signature

em1: Unable to allocate bus resource: memory

[jonathan]

(Please CC as I'm not subscribed to net@)

I bought a new PCIe NIC a few months ago and was working with Jack Vogel
on getting it to work but he was busy, then I got busy and things stalled.
Does anyone else have any idea what might be wrong here?  The card is
recognized but the em driver fails to initialize it for some reason.  I'm
running 7-STABLE and the standard information is below.

uname -a (system csuped within a couple hours of build time):
FreeBSD storage.kc8onw.net 7.0-STABLE FreeBSD 7.0-STABLE #8: Wed Apr 30
14:20:32 ADT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/STORAGE
 i386

dmesg lines for em1 (full dmesg available if needed):
em1:  port
0xdc00-0xdc1f mem 0xfe8e-0xfe8f,0xfe8c-0xfe8d irq 16 at
device 0.0 on pci3
em1: Unable to allocate bus resource: memory
em1: Allocation of PCI resources failed

pciconf -lv for em 1:
[EMAIL PROTECTED]:3:0:0: class=0x02 card=0x10838086 chip=0x10b98086 rev=0x06
hdr=0x00
vendor = 'Intel Corporation'
device = '82572EI PRO/1000 PT Desktop Adapter (Copper)'
class  = network
subclass   = ethernet

Thank you,
Jonathan



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

Re: em1: Unable to allocate bus resource: memory

[Andrew Snow]

> I bought a new PCIe NIC a few months ago and was working with Jack Vogel
> on getting it to work but he was busy, then I got busy and things 
stalled.

> Does anyone else have any idea what might be wrong here?  The card is
> recognized but the em driver fails to initialize it for some reason.  I'm
> running 7-STABLE and the standard information is below.


I experience the same problem with an Intel PCIe gigabit NIC.  I don't 
know of any workaround, my cards are sitting on the shelf until someone 
works it out...


- Andrew
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: misc/123066: kernel trap with ipsec

[Bruce Evans]

On Fri, 25 Apr 2008, Kris Kennaway wrote:


Unfortunately we need the rest of the stack.  Can you either try to
reproduce with DDB in the kernel and obtain a stack trace from there,
or if this is not possible then try recompiling the kernel with -O
instead of -O2 which tends to produce better stack traces.


I wonder why there haven't been more reports of gcc-4.2 -O[2] breaking
things (I probably read the wrong lists).  -O2 almost completely breaks
kernel profiling and debugging using ddb, mainly by inlining functions
that are only used once.

Even -O is documented as enabling -funit-at-a-time, which is documented
as enabling -finline-functions-called-once.  -funit-at-a-time gives
the possibility of inlining functions that are instantiated before
they are used, and then -finline-functions-called-once tends to inline
them.  However, this doesn't seem to happen very often with only -O.
Maybe -O only inlines small functions, but -O2 inlines all functions
that are only called once.  Losing the symbols and frames for large
inlined functions is especially annoying.

I started using -O2 for kernels about a year ago because although it
it has little effect (usually negative) in normal use, it gave an
optimization of a whole 1 to 5% in network microbenchmarks that I was
working on.

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

Re: em1: Unable to allocate bus resource: memory

[Jack Vogel]

On Wed, Apr 30, 2008 at 7:39 PM, Andrew Snow <[EMAIL PROTECTED]> wrote:
>
>  > I bought a new PCIe NIC a few months ago and was working with Jack Vogel
>  > on getting it to work but he was busy, then I got busy and things
> stalled.
>  > Does anyone else have any idea what might be wrong here?  The card is
>  > recognized but the em driver fails to initialize it for some reason.  I'm
>  > running 7-STABLE and the standard information is below.
>
>
>  I experience the same problem with an Intel PCIe gigabit NIC.  I don't know
> of any workaround, my cards are sitting on the shelf until someone works it
> out...
>

You won't know if its still a problem if you don't take them off the
shelf and try it :)

I can't fix problems that I cannot reproduce... well, unless I get REAL
lucky and fix something along the way, but that means that if you
don't help me it likely won't get fixed :)

Sometimes its frustrating, you can try hard... I can try hard, and we still
can't solve something,  but its the only way to proceed.

I am hoping to MFC the em/igb drivers in HEAD soon, it would be helpful
to me, and to everyone, if as many get out and test that driver as possible.

Cheers,

Jack
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: em1: Unable to allocate bus resource: memory

[Jack Vogel]

Try the driver in HEAD, it might even just build and work on 7, if
not let me know.

Jack

On Wed, Apr 30, 2008 at 7:11 PM,  <[EMAIL PROTECTED]> wrote:
> (Please CC as I'm not subscribed to net@)
>
>  I bought a new PCIe NIC a few months ago and was working with Jack Vogel
>  on getting it to work but he was busy, then I got busy and things stalled.
>  Does anyone else have any idea what might be wrong here?  The card is
>  recognized but the em driver fails to initialize it for some reason.  I'm
>  running 7-STABLE and the standard information is below.
>
>  uname -a (system csuped within a couple hours of build time):
>  FreeBSD storage.kc8onw.net 7.0-STABLE FreeBSD 7.0-STABLE #8: Wed Apr 30
>  14:20:32 ADT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/STORAGE
>   i386
>
>  dmesg lines for em1 (full dmesg available if needed):
>  em1:  port
>  0xdc00-0xdc1f mem 0xfe8e-0xfe8f,0xfe8c-0xfe8d irq 16 at
>  device 0.0 on pci3
>  em1: Unable to allocate bus resource: memory
>  em1: Allocation of PCI resources failed
>
>  pciconf -lv for em 1:
>  [EMAIL PROTECTED]:3:0:0: class=0x02 card=0x10838086 chip=0x10b98086 
> rev=0x06
>  hdr=0x00
> vendor = 'Intel Corporation'
> device = '82572EI PRO/1000 PT Desktop Adapter (Copper)'
> class  = network
> subclass   = ethernet
>
>  Thank you,
>  Jonathan
>
>
>
>  ___
>  freebsd-net@freebsd.org mailing list
>  http://lists.freebsd.org/mailman/listinfo/freebsd-net
>  To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: em1: Unable to allocate bus resource: memory

[jonathan]

On Thu, May 1, 2008 00:09, Jack Vogel wrote:
> I am hoping to MFC the em/igb drivers in HEAD soon, it would be helpful
> to me, and to everyone, if as many get out and test that driver as
> possible.

Can we just "csup -i src/sys/dev/em/ supfile" on a 7-stable system or are
there other changes that need to happen as well?

Jonathan


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

Re: em1: Unable to allocate bus resource: memory

[Jack Vogel]

On Wed, Apr 30, 2008 at 9:49 PM,  <[EMAIL PROTECTED]> wrote:
> On Thu, May 1, 2008 00:09, Jack Vogel wrote:
>  > I am hoping to MFC the em/igb drivers in HEAD soon, it would be helpful
>  > to me, and to everyone, if as many get out and test that driver as
>  > possible.
>
>  Can we just "csup -i src/sys/dev/em/ supfile" on a 7-stable system or are
>  there other changes that need to happen as well?
>
>  Jonathan

hmmm, I'm not sure, I don't usually do that on a small directory, there are
changes to files and Makefile. It depends if you are going to build as a
module or static in the kernel?

Jack
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: em1: Unable to allocate bus resource: memory

[Andrew Snow]

Jack Vogel wrote:

You won't know if its still a problem if you don't take them off the
shelf and try it :)



Good point.  I wasn't trying to point the finger at you, I think you are 
doing a fantastic job overall :)


The card in question is a Pro/1000PT desktop adapter on PCIe 1x bus. I 
had used some other cards in the meantime and forgot all about my PCIe 
card.  Just got it out to try it again.


While it didnt work in 6.2 (all packets would get silently dropped), it 
now works fine for me in 7.0!



Thanks for all your good work.

- Andrew
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Some odd behaviour of vmstat and vmtotal...

[Andrew Snow]

In deploying 7.0 at work we were finding a persistent problem when
running "vmstat 1" on systems.  The problem shows up as a 10ms "pause"
in processing, usually packet stamping and forwarding by a user level
process. 


Thats interesting.  I once did some quick and dirty profiling of vmtotal 
and found it runs extremely quickly.  Are you running on slow machines 
(embedded perhaps)?  Or do you have a situation where you perhaps have 
alot more VM objects created than normal?  I can't think of a good 
example where this would be the case..


- Andrew
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: kern/122989: [swi] [panic] 6.3 kernel panic in swi1: net

[linimon]

Synopsis: [swi] [panic] 6.3 kernel panic in swi1: net

Responsible-Changed-From-To: freebsd-i386->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Thu May 1 05:52:44 UTC 2008
Responsible-Changed-Why: 
reclassify.

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