Re: Regression in vr - not receiveing multicast

2008-12-09 Thread Goran Lowkrantz 
--On December 10, 2008 16:19:33 +0900 Pyun YongHyeon <[EMAIL PROTECTED]> 
wrote:



On Wed, Dec 10, 2008 at 08:06:16AM +0100, Goran Lowkrantz wrote:
 > --On December 9, 2008 12:53:05 +0100 Goran Lowkrantz
 > <[EMAIL PROTECTED]> wrote:
 >
 > >--On December 9, 2008 20:47:23 +0900 Pyun YongHyeon <[EMAIL PROTECTED]>
 > >wrote:
 > >
 > >>On Tue, Dec 09, 2008 at 10:40:17AM +0100, Goran Lowkrantz wrote:
 > >> > Hi,
 > >> >
 > >> > in July, vr had this problem and was fixed:
 > >> > 
 > >> > 
 > >> >
 > >> > but now it's back again!
 > >> >
 > >>
 > >>There was just one bug fix since then and I guess the fix is not
 > >>related with your issue.
 > >>
 > >> > On a system with the following:
 > >> > 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #3: Thu Oct 16 12:31:04 UTC
2008  > >> >
 > >> > I have to set all vr interfaces in promisc to get routing info.
 > >> >
 > >> > Using Quagga
 > >> > # pkg_info -Ix uagga
 > >> > quagga-0.99.10_3Free RIPv1, RIPv2, OSPFv2, BGP4, IS-IS route
 > >>software  >
 > >> > on an inner network using RIPv2
 > >> > # ifmcstat -i vr0
 > >> > vr0:
 > >> > inet xxx.xxx.xxx.xxx
 > >> > group 224.0.0.9
 > >> > igmpv2
 > >> > mcast-macaddr 01:00:5e:00:00:09 refcnt 1
 > >> > group 224.0.0.1
 > >> > mcast-macaddr 01:00:5e:00:00:01 refcnt 1
 > >> >
 > >> >
 > >> > On the same box, we have some em devices also and they work
without  > >>any   > problems.
 > >> >
 > >>
 > >>There is fundamental differences between em(4) and vr(4). The
 > >>vr(4) for VT6105M takes advantage of perfect multicast filtering
 > >>feature which is not present on all em(4) interface. Perfect
 > >>multicast filtering can reduce unwanted multicast traffics such
 > >>that it could save a lot of CPU cycles. The downside is that vr(4)
 > >>cannot accept multicast frames for a multicast group without
 > >>joining the multicast group first.
 > >>For multicast routing purpose I guess 'options MROUTING' kernel
 > >>option should be enabled to accept all multicast frames.
 > >>Does your kernel have that option?
 > >
 > >No it has not. I will create such a beast and return with stories.
 > >
 >
 >
 > I have tried with 'options MROUTING' and it didn't work.
 >
 > Did I miss something? Do I have to install and run mrouted also?
 >
 > It seems like maybe the first two packages are accepted after
registration   > as I don't lose the routes until after about 6 min
uptime. But to get   > further updates, I need the interfaces in promisc.
 >
 > So, next step?
 >

Can you see ALLMULTI flag from the output of "ifconfig vr0"?


No ->
# ifconfig vr0
vr0: flags=8943 metric 0 
mtu 1500

options=284b
ether 00:00:24:c8:e0:9c
inet xxx.xxx.xxx.xxx netmask 0xfff8 broadcast xxx.xxx.xxx.yyy
media: Ethernet autoselect (100baseTX )
status: active


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

Re: Regression in vr - not receiveing multicast

2008-12-09 Thread Pyun YongHyeon 
On Wed, Dec 10, 2008 at 08:06:16AM +0100, Goran Lowkrantz wrote:
 > --On December 9, 2008 12:53:05 +0100 Goran Lowkrantz 
 > <[EMAIL PROTECTED]> wrote:
 > 
 > >--On December 9, 2008 20:47:23 +0900 Pyun YongHyeon <[EMAIL PROTECTED]>
 > >wrote:
 > >
 > >>On Tue, Dec 09, 2008 at 10:40:17AM +0100, Goran Lowkrantz wrote:
 > >> > Hi,
 > >> >
 > >> > in July, vr had this problem and was fixed:
 > >> > 
 > >> > 
 > >> >
 > >> > but now it's back again!
 > >> >
 > >>
 > >>There was just one bug fix since then and I guess the fix is not
 > >>related with your issue.
 > >>
 > >> > On a system with the following:
 > >> > 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #3: Thu Oct 16 12:31:04 UTC 2008
 > >> >
 > >> > I have to set all vr interfaces in promisc to get routing info.
 > >> >
 > >> > Using Quagga
 > >> > # pkg_info -Ix uagga
 > >> > quagga-0.99.10_3Free RIPv1, RIPv2, OSPFv2, BGP4, IS-IS route
 > >>software  >
 > >> > on an inner network using RIPv2
 > >> > # ifmcstat -i vr0
 > >> > vr0:
 > >> > inet xxx.xxx.xxx.xxx
 > >> > group 224.0.0.9
 > >> > igmpv2
 > >> > mcast-macaddr 01:00:5e:00:00:09 refcnt 1
 > >> > group 224.0.0.1
 > >> > mcast-macaddr 01:00:5e:00:00:01 refcnt 1
 > >> >
 > >> >
 > >> > On the same box, we have some em devices also and they work without
 > >>any   > problems.
 > >> >
 > >>
 > >>There is fundamental differences between em(4) and vr(4). The
 > >>vr(4) for VT6105M takes advantage of perfect multicast filtering
 > >>feature which is not present on all em(4) interface. Perfect
 > >>multicast filtering can reduce unwanted multicast traffics such
 > >>that it could save a lot of CPU cycles. The downside is that vr(4)
 > >>cannot accept multicast frames for a multicast group without
 > >>joining the multicast group first.
 > >>For multicast routing purpose I guess 'options MROUTING' kernel
 > >>option should be enabled to accept all multicast frames.
 > >>Does your kernel have that option?
 > >
 > >No it has not. I will create such a beast and return with stories.
 > >
 > 
 > 
 > I have tried with 'options MROUTING' and it didn't work.
 > 
 > Did I miss something? Do I have to install and run mrouted also?
 > 
 > It seems like maybe the first two packages are accepted after registration 
 > as I don't lose the routes until after about 6 min uptime. But to get 
 > further updates, I need the interfaces in promisc.
 > 
 > So, next step?
 > 

Can you see ALLMULTI flag from the output of "ifconfig vr0"?

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

Re: Regression in vr - not receiveing multicast

2008-12-09 Thread Goran Lowkrantz 
--On December 9, 2008 12:53:05 +0100 Goran Lowkrantz 
<[EMAIL PROTECTED]> wrote:



--On December 9, 2008 20:47:23 +0900 Pyun YongHyeon <[EMAIL PROTECTED]>
wrote:


On Tue, Dec 09, 2008 at 10:40:17AM +0100, Goran Lowkrantz wrote:
 > Hi,
 >
 > in July, vr had this problem and was fixed:
 > 
 > 
 >
 > but now it's back again!
 >

There was just one bug fix since then and I guess the fix is not
related with your issue.

 > On a system with the following:
 > 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #3: Thu Oct 16 12:31:04 UTC 2008
 >
 > I have to set all vr interfaces in promisc to get routing info.
 >
 > Using Quagga
 > # pkg_info -Ix uagga
 > quagga-0.99.10_3Free RIPv1, RIPv2, OSPFv2, BGP4, IS-IS route
software  >
 > on an inner network using RIPv2
 > # ifmcstat -i vr0
 > vr0:
 >   inet xxx.xxx.xxx.xxx
 >   group 224.0.0.9
 >   igmpv2
 >   mcast-macaddr 01:00:5e:00:00:09 refcnt 1
 >   group 224.0.0.1
 >   mcast-macaddr 01:00:5e:00:00:01 refcnt 1
 >
 >
 > On the same box, we have some em devices also and they work without
any   > problems.
 >

There is fundamental differences between em(4) and vr(4). The
vr(4) for VT6105M takes advantage of perfect multicast filtering
feature which is not present on all em(4) interface. Perfect
multicast filtering can reduce unwanted multicast traffics such
that it could save a lot of CPU cycles. The downside is that vr(4)
cannot accept multicast frames for a multicast group without
joining the multicast group first.
For multicast routing purpose I guess 'options MROUTING' kernel
option should be enabled to accept all multicast frames.
Does your kernel have that option?


No it has not. I will create such a beast and return with stories.




I have tried with 'options MROUTING' and it didn't work.

Did I miss something? Do I have to install and run mrouted also?

It seems like maybe the first two packages are accepted after registration 
as I don't lose the routes until after about 6 min uptime. But to get 
further updates, I need the interfaces in promisc.


So, next step?

/glz


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

Re: [ATA] and re(4) stability issues

2008-12-09 Thread Pyun YongHyeon 
On Tue, Dec 09, 2008 at 07:52:37PM +0100, Victor Balada Diaz wrote:
 > Hello,
 > 
 > I got various machines[1] at hetzner.de and I've been having problems
 > with interrupts on FreeBSD 7.0 and now FreeBSD 7.1 -BETA2 in amd64. I've
 > been trying to narrow the problem so someone more knowledgeable than me
 > is able to fix it. This mail is an other attempt to ask a question
 > with regards ATA code to see if this time i got something.
 > 
 > For the ones that don't actually know what happened:
 > 
 > With FreeBSD 7.0 -RELEASE for amd64 and default kernel
 > the system shared re0 interrupt with OHCI and this caused
 > re(4) to corrupt packets and create interrupt storms. Tried

re(4) in 7.0-RELEASE had bus_dma(9) bug which could be easily
triggered on systems with > 4GB memory. But I dont' know whether
this is related with interrupt storms.

 > updating to 7.1 -BETA2 and still had some problems with it.
 > 
 > I've opened the PR kern/128287[2] and Remko quickly answered
 > with a workaround: that workaround was removing USB support from
 > my kernel. I did it and re(4) wasn't sharing interrupts anylonger,
 > and the interrupt storms were gone. Now sometime later the interface
 > goes up and down from time to time, but less often. Also sometimes
 > the machine losts the network interface but continues to work.
 > 

It seems that your controller supports MSI so you can set a tunable
hw.re.msi_disable to 0 to enable MSI. With MSI you can remove
interrupt sharing(e.g. add hw.re.msi_disable="0" to
/boot/loader.conf file.) However there were several issues on re(4)
w.r.t MSI so it was off by default.

 > I know it continues to work because some days later i can see that
 > it tried to deliver the status reports but was unable to resolve the
 > aliases hostnames. I can't ping the machine and i know the network
 > is OK. If i reboot the machine everything is working again.
 > 

Recently I've made small changes to re(4) which may help to detect
link state change event. Would you try re(4) in HEAD?

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

Re: FreeBSD 7.1-RC1 Available...

2008-12-09 Thread Ken Smith 

Sigh.  Sorry, did it again...  Note the checksum for the dvd1 images is
for them in their ungzip-ed form so uncompress them before trying to
verify the checksums.

Checksums:

MD5 (7.1-RC1-amd64-bootonly.iso) = de6338599df1be6915dd01001c1ef4e5
MD5 (7.1-RC1-amd64-disc1.iso) = 116d0dbff53871778fb0e1e90ce4f2a6
MD5 (7.1-RC1-amd64-disc2.iso) = 2fb908291c90330b665098bb785d0746
MD5 (7.1-RC1-amd64-disc3.iso) = 1aecb94dbdc8cce4e1d793d308d32364
MD5 (7.1-RC1-amd64-docs.iso) = 440b5eb826a710d5e07f579d31142551
MD5 (7.1-RC1-amd64-dvd1.iso) = 205147c332524d49521f3b98c8b1b73b
MD5 (7.1-RC1-amd64-livefs.iso) = 1972008c2b34eb3e51074ebd61a4a454

MD5 (7.1-RC1-i386-bootonly.iso) = e12d84609a00bdc6f996e77eff77226a
MD5 (7.1-RC1-i386-disc1.iso) = 8743fff3a445d99b36772ff9984f7cae
MD5 (7.1-RC1-i386-disc2.iso) = 4dabd0b245e42c2eb88a89ac4e132bad
MD5 (7.1-RC1-i386-disc3.iso) = 63860e393c8001015c38cceb263b9ac7
MD5 (7.1-RC1-i386-docs.iso) = 57bfd48213da28789af84ea10301895a
MD5 (7.1-RC1-i386-dvd1.iso) = e5acb528569ca5cc7fbc5d41fc2ae636
MD5 (7.1-RC1-i386-livefs.iso) = b261a6d73a491d188ac2dd1f913a86ef

MD5 (7.1-RC1-ia64-bootonly.iso) = 07dfef578edb3aab31c2389c7f2d2bbe
MD5 (7.1-RC1-ia64-disc1.iso) = 332009d292433d9232c0e4c906ee69c7
MD5 (7.1-RC1-ia64-disc2.iso) = f217c565ee264d883de71ccc3c94f91a
MD5 (7.1-RC1-ia64-disc3.iso) = 15b8393ea09706ee7715bfdd62f11071
MD5 (7.1-RC1-ia64-docs.iso) = 16d95be27399605a487b1c1b61b02be5
MD5 (7.1-RC1-ia64-livefs.iso) = 15069a0e7142791a35fc25b64bf1d16c

MD5 (7.1-RC1-pc98-bootonly.iso) = be89ea6f9010c86839815ebb6d5d29df
MD5 (7.1-RC1-pc98-disc1.iso) = ff94a112a96cc5c7f1f9ca8039106a7d
MD5 (7.1-RC1-pc98-livefs.iso) = 2cc908c7f9449256eb807782229f7288

MD5 (7.1-RC1-powerpc-bootonly.iso) = e87dcd0649e66743ee54a461669f3401
MD5 (7.1-RC1-powerpc-disc1.iso) = 5109252f3fa6b42458c1a01692b37833
MD5 (7.1-RC1-powerpc-disc2.iso) = 9870248b2ebce575e675541ade94f4eb
MD5 (7.1-RC1-powerpc-disc3.iso) = 42b5a3c0228860d161679fd8c54c2266
MD5 (7.1-RC1-powerpc-docs.iso) = 81272f56de121e9491f3aeb48f7eb2cc

MD5 (7.1-RC1-sparc64-bootonly.iso) = d65c6d0120e17661b50593cf1cea35a0
MD5 (7.1-RC1-sparc64-disc1.iso) = 47990a92b36bfcbb8fc10e8fa33ea16a
MD5 (7.1-RC1-sparc64-disc2.iso) = a5debb7feab8e21870f46ea0dc689e1a
MD5 (7.1-RC1-sparc64-disc3.iso) = b3c1e1b3aa26c71b91c68e89c57661d8
MD5 (7.1-RC1-sparc64-docs.iso) = 01d2184ae88c1a94403ee63de7333f18

SHA256 (7.1-RC1-amd64-bootonly.iso) = 
be7d99f1f29c56ea107eb41feb78683359379a82d6ce80dbcd0fc3126f5b7ec4
SHA256 (7.1-RC1-amd64-disc1.iso) = 
3be67ca088868059df0790251e0484ec67f617fdd04a382e91ca0bae239c9d87
SHA256 (7.1-RC1-amd64-disc2.iso) = 
91ba01dade4d37245ff5a5ff23d4a9b62d99e41decd1958389d078e3b400309e
SHA256 (7.1-RC1-amd64-disc3.iso) = 
301e34f1ff84acdf568abd7a298eb16d9d41e7362d6814137ad888c046930b7e
SHA256 (7.1-RC1-amd64-docs.iso) = 
f783cefa13144062d14db44ddb44969a571f1b298930a8a544c7ac5e50e12cc3
SHA256 (7.1-RC1-amd64-dvd1.iso) = 
971b8a21b53eaf583a4bb02c63a5eaba73dc29eaa638d5712805ffc933eb643e
SHA256 (7.1-RC1-amd64-livefs.iso) = 
b81e4b42fa8e908eb9d75708daae4cb8b92e373e1e58fea306502920b7b52b33

SHA256 (7.1-RC1-i386-bootonly.iso) = 
b40e292d89c3e7167524bc9a9db54375188160e7e5855530471e8b2454727c11
SHA256 (7.1-RC1-i386-disc1.iso) = 
13b88f219569748b5f760e190948e87a0febc3824278909d96db4173d6858820
SHA256 (7.1-RC1-i386-disc2.iso) = 
be7d09d59f921f121b3bb31e6d642f7b9a17a79bd15e2c4ae0f2c25ba041cbba
SHA256 (7.1-RC1-i386-disc3.iso) = 
70c2fe469b0d99e73e711d11542bf303a3d8193eae22c35e7187c79aa22d1a41
SHA256 (7.1-RC1-i386-docs.iso) = 
64b96484e324d8cfec79c894f259dc3f1dfeb55f87ecd59c1c6049b59e8cfbc9
SHA256 (7.1-RC1-i386-dvd1.iso) = 
5a265d19a6d8ed410e0e91d53cbf358bfa7b7e7e168cd6332a21dcdfddd0d37d
SHA256 (7.1-RC1-i386-livefs.iso) = 
ba8be5619e0de22a5c69d5f8e245e7547cf5e3b1a5a6047ecdc71a5d3444ee4b

SHA256 (7.1-RC1-ia64-bootonly.iso) = 
413a31029e32c64cc137cb3e2c6dfddac10779bef17e2de0f7ed3a02cc2dff9a
SHA256 (7.1-RC1-ia64-disc1.iso) = 
2f5fe288fcb5312347c89e147a78a634d906b575104692a28b016b7514f5b541
SHA256 (7.1-RC1-ia64-disc2.iso) = 
282fc15c7c2b594eff5041d5bd75337218f64ef41f1d97e991a2bc8c125a8e7c
SHA256 (7.1-RC1-ia64-disc3.iso) = 
d4eada87243a20c7d2645096442e85e11717977bfff6f30d98766a09f31c66c1
SHA256 (7.1-RC1-ia64-docs.iso) = 
b5ec27943a48588c12678c8653553e5eff1d0a382ccc26ce1aa0b642310eee2d
SHA256 (7.1-RC1-ia64-livefs.iso) = 
33dfe5eada1d01bf8ed7c3093561eb5d92d4bed6a2dd2c5c69c50abe4db1523c

SHA256 (7.1-RC1-pc98-bootonly.iso) = 
f5aa07453a9ab84e26949d70bb5b2982778724afbd74553678e2142e2950
SHA256 (7.1-RC1-pc98-disc1.iso) = 
24cf624b2edc719452da4ddfcf961dfb40bbc8964321ee10c7d3af1715ec6f74
SHA256 (7.1-RC1-pc98-livefs.iso) = 
ffd6d1065f3d991b0676a18e8ff4b2c69647e69eda9c980510a25415bf65fcab

SHA256 (7.1-RC1-powerpc-bootonly.iso) = 
779110e8d426f5847fc2a89e273641933cdb2c1b535a8f8cb5b7d94bbe62b6d0
SHA256 (7.1-RC1-powerpc-disc1.iso) = 
5cab6aa5bb22e25fc30ebd4909de2df005cc070f5338175446d721ef0fac662f
SHA256 (7.1-RC1-powerpc-disc2.iso) = 
487722bef61d3bfd1bf9d507b1cd98f5e7a22a0629ce3f6548e5394f3831189b
SHA256 (7.1-RC1-po

FreeBSD 7.1-RC1 Available...

2008-12-09 Thread Ken Smith 

So...  Two show-stoppers, one Security Advisory, and one "Gee.  Did we
really implement that new interface that way?  That needs a bit more
work." later...

FreeBSD 7.1-RC1 is now available, the first of the Release Candidates.
There will be at least one more Release Candidate before the release so
the release itself is likely around 3 weeks from now IF no new
show-stoppers are uncovered during testing.

In addition to general testing we're looking for information about
potential problems with the boot loader.  There has been traffic here
about problems but the reports haven't helped narrow down the causes
yet.  So far it seems to be related to USB keyboards and at least so far
systems with more than one processor in them.  More data points like
cases where a USB keyboard was not involved as well as if possible
things like which motherboard it is might help us narrow down the cause.
Testing on a variety of motherboards, of varying ages and manufacturers
would help.

And a late arrival that's not possible to test without the packages,
sysinstall's issues with excessive disc swapping when installing large
sets of packages off the CDROMs should be fixed.  Given the package
layout it should ask for a disc no more than once.  Testing to make sure
that's working would be appreciated.

NOTE: If updating from a 7.0 or earlier system due to a change in the
Vendor's drivers certain Intel NICs will now come up as igb(4) instead
of em(4).  We normally try to avoid changes like that in stable branches
but the vendor felt it necessary in order to support the new adapters.
See the UPDATING entry dated 20080811 for details.  There are only 3 PCI
ID's that should have their name changed from em(4) to igb(4): 0x10A7,
0x10A9, and 0x10D6.  You should be able to determine if your card will
change names by running the command "pciconf -l", and for the line
representing your NIC (should be named em on older systems, e.g. em0 or
em1, etc) check the fourth column.  If it says "chip=0x10a7" (or one of
the other two IDs given above) you will have the adapter's name change.

The ISO images and FTP install trees are available on the FreeBSD Mirror
sites.  Using the primary site as an example:

  ftp://ftp.freebsd.org/pub/FreeBSD/releases/${arch}/ISO-IMAGES/7.1/

where ${arch} is one of amd64, i386, ia64, pc98, powerpc, or sparc64.
The ISOs for amd64, i386, and sparc64 include what is expected to be the
final package set.  For all architectures the ISOs with "disc" in their
names are CDROM-sized, if you intend to install a variety of packages
during installation you will need all three.  For amd64 and i386 there
is a gzip-ed iso with "dvd" in its name which is DVD-sized.  It contains
everything (install bits, livefs, docs, and packages) and can be used if
your machine has a DVD drive in it.

If you would like to do a source-based update to 7.1-RC1 from an already
installed machine you can update your tree to RELENG_7_1 using normal
cvsup/csup methods.  Note that due to an unfortunate side-effect of the
"real" source code repository now being in SVN it will look like all
files have a new version so mergemaster may be a bit tedious.

The freebsd-update(8) utility supports binary upgrades of i386 and amd64
systems running earlier FreeBSD releases.  Systems running 7.0-RELEASE,
7.1-BETA, or 7.1-BETA2 can upgrade as follows:
  
# freebsd-update upgrade -r 7.1-RC1

During this process, FreeBSD Update may ask the user to help by merging
some configuration files or by confirming that the automatically performed
merging was done correctly.
  
# freebsd-update install

The system must be rebooted with the newly installed kernel before continuing.
# shutdown -r now
   
After rebooting, freebsd-update needs to be run again to install the new
userland components, and the system needs to be rebooted again:

# freebsd-update install
# shutdown -r now
   
Users of Intel network interfaces which are changing their name from "em" to
"igb" should make necessary changes to configuration files BEFORE running
freebsd-update, since otherwise the network interface will not be configured
appropriately after rebooting for the first time.
   
Users of earlier FreeBSD releases (FreeBSD 6.x) can also use freebsd-update to
upgrade to FreeBSD 7.1, but will be prompted to rebuild all third-party
applications (e.g., anything installed from the ports tree) after the second
invocation of "freebsd-update install", in order to handle differences in the
system libraries between FreeBSD 6.x and FreeBSD 7.x.

-- 
Ken Smith
- From there to here, from here to  |   [EMAIL PROTECTED]
  there, funny things are everywhere.   |
  - Theodore Geisel |



signature.asc
Description: This is a digitally signed message part

Please confirm your request to join SKATINGEXTREME

2008-12-09 Thread Yahoo! Groups 

Hello [EMAIL PROTECTED],

We have received your request to join the SKATINGEXTREME 
group hosted by Yahoo! Groups, a free, easy-to-use community service.

This request will expire in 7 days.

TO BECOME A MEMBER OF THE GROUP: 

1) Go to the Yahoo! Groups site by clicking on this link:
   
http://groups.yahoo.com/i?i=yvl4asaeasr2mkc2uta5qvz53fy2pwjx&e=stable%40FreeBSD%2Eorg
 

  (If clicking doesn't work, "Cut" and "Paste" the line above into your 
   Web browser's address bar.)

-OR-

2) REPLY to this email by clicking "Reply" and then "Send"
   in your email program

If you did not request, or do not want, a membership in the
SKATINGEXTREME group, please accept our apologies
and ignore this message.

Regards,

Yahoo! Groups Customer Care

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 

 



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

Re: visibility of release process

2008-12-09 Thread Kevin Day 


On Dec 8, 2008, at 10:25 AM, Ken Smith wrote:


Bottom line is my communication skills suck and of the bazillion other
things I could do with my time these sorts of housekeeping chores wind
up at a low enough priority they don't get done.  But as you and  
others
have made clear the priority needs to get raised and I need to deal  
with

it.  That's the part being worked on.



Personally, as a end user, developer and cluster manager there are a  
few things that I would find extremely useful. I mean no disrespect to  
you or any of the work anyone on the team is putting forth for this -  
it's way more than I'm contributing so I'm grateful of what's being  
done now. This is just a wishlist. :)


* Make the release notes a working document throughout the development  
cycle. Major caveats that anything in it before it's actually released  
is subject to change, but until the release notes are published I have  
a really tough time knowing what the next release even has in it. Is  
it worth holding off upgrading 50 servers for something we'd actually  
use, or are the changes of no concern? Is it something I didn't even  
know was in the tree that I might backport myself? If the release  
notes actually are available somewhere before the final stages of a  
release, I haven't been able to find them.


* More notice to hubs@ before the release notes are generated. The  
releases always come with a "At the time of this writing, these  
mirrors have the full distribution" list. If it was announced to us  
mirror operators before that list is made, we could make sure we were  
synced in time to be included. Maybe even a semi-shaming of "These  
mirrors do not appear to have the required bits:". The difference in  
bandwidth we see on our public mirror (ftp3.us) is pretty extreme if  
we're listed there or not, which seems to be a 50/50 coin-toss on the  
last few releases. I'm honestly not sure why, since we can easily pull  
>50mbps from ftp-master.


* The published release schedules are usually pretty far out of date.  
Beta/RCs get put up but the schedule says they haven't been, schedules  
sometimes have obviously slipped but it's unclear if it's affecting  
the final release date or not, etc. I know there aren't always answers  
to the unknowns, but more information would help.


* Where are the BETA/RCs announced? Taking a page from apple, a mini- 
release notes saying "These items have changed since the last release/ 
beta/rc:" "These areas could use additional testing:" "These bugs are  
believed to be fixed, if you're still experiencing them let us know:"  
would probably get more people testing them. and give more insight  
into what's new. On anything other than a -RELEASE, make mention of  
this document in /etc/motd. I understand this would require effort  
from people working on those features, but if the beta readme file was  
in CVS and it was easier for developers to add to it themselves... If  
I'm not on the right mailing list, I won't see the "Call for testers"  
email that some send out.


* Non FreeBSD users have a tough time with understanding that FreeBSD  
6.4 was released after 7.0. I don't think the version numbering system  
should change, but new/novice users need a clearer guide as to which  
version to install on a fresh system. For example, the /releases/ page  
says:


Release 7.0 (February 2008)
Release 6.4 (November 2008)

Which one of those is considered stable? If I know nothing about  
FreeBSD which one is "better" for me? Maybe a page that lists new  
features in rows, and a column/notes about its status in each version.  
FreeBSD has support for the Q1235 RAID controller from FooWare, but  
what version did it gain that?


I'd love to help, but I'm not sure how/were an outsider can really  
make much impact here. But, I'm semi-volunteering. :)


-- Kevin

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

Re: visibility of release process

2008-12-09 Thread Patrick Lamaizière 
Le Tue, 9 Dec 2008 11:16:57 +0100,
Ruben van Staveren <[EMAIL PROTECTED]> a écrit :

> > Sure, but show me how to go to http://svn.freebsd.org/viewvc/base/  
> > and see commit log per branch or any other way to see what is
> > going on in a branch. Fisheye gives you that in a really clear way
> > and it costs nothing to add another option for users.
> 
> Though experimental, I'm greatly enjoying
> http://www.secnetix.de/olli/FreeBSD/svnews/?p=/stable/7

Nice. There is also http://freshbsd.org/ (really cool IMHO). 

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

[ATA] and re(4) stability issues

2008-12-09 Thread Victor Balada Diaz 
Hello,

I got various machines[1] at hetzner.de and I've been having problems
with interrupts on FreeBSD 7.0 and now FreeBSD 7.1 -BETA2 in amd64. I've
been trying to narrow the problem so someone more knowledgeable than me
is able to fix it. This mail is an other attempt to ask a question
with regards ATA code to see if this time i got something.

For the ones that don't actually know what happened:

With FreeBSD 7.0 -RELEASE for amd64 and default kernel
the system shared re0 interrupt with OHCI and this caused
re(4) to corrupt packets and create interrupt storms. Tried
updating to 7.1 -BETA2 and still had some problems with it.

I've opened the PR kern/128287[2] and Remko quickly answered
with a workaround: that workaround was removing USB support from
my kernel. I did it and re(4) wasn't sharing interrupts anylonger,
and the interrupt storms were gone. Now sometime later the interface
goes up and down from time to time, but less often. Also sometimes
the machine losts the network interface but continues to work.

I know it continues to work because some days later i can see that
it tried to deliver the status reports but was unable to resolve the
aliases hostnames. I can't ping the machine and i know the network
is OK. If i reboot the machine everything is working again.

When switched from 7.0 to 7.1 BETA2 i also found that under load
after some hours the machine created interrupt storms on ATA disks.

Digging at linux source code i've found that they do some special things
for this chipset that i've been unable to find on our code. This is
linux code for my chipset:

371 AHCI_HFLAGS (AHCI_HFLAG_IGN_SERR_INTERNAL |
372  AHCI_HFLAG_32BIT_ONLY | AHCI_HFLAG_NO_MSI |
373  AHCI_HFLAG_SECT255),

File and the rest of the code in here[3].

As i saw AHCI_HFLAG_NO_MSI i tried doing the easiest thing i could
think of, switching MSI and MSI-x off for the whole system, so
i added to /boot/loader.conf this tunables:

hw.pci.enable_msix="0"
hw.pci.enable_msi="0"

And then rebooted the machine. After various hours of doing almost nothing
i've found that the machine answered ping but was unable to answer any
request (eg, ssh, nagios nrpe, etc). The machine recovered itself after
some minutes and when i was able to ssh into i saw the following in dmesg:

ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing 
request directly
ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing 
request directly
ad4: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request 
directly
ad4: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request 
directly
ad4: WARNING - SET_MULTI taskqueue timeout - completing request directly
ad4: TIMEOUT - WRITE_DMA48 retrying (1 retry left) LBA=1463123158

and a lot more errors like that. I didn't get this errors with MSI enabled.
I see WRITE_DMA48 and in linux code i saw AHCI_HFLAG_32BIT_ONLY which is later
used for DMA related things. Could someone who is more knowledgeable check
if we're doing the right thing?

I've attached verbose dmesg of a machine that's like this one with
7.1 -BETA2, MSI enabled and GENERIC kernel minus USB and firewrire.

Also, please, could someone give me a hand on how could i continue debugging
this interrupt issues? I'm a bit lost and digging code and posting each
time i think i've found something is not going to go anywhere.

I would also like to say that i've seen reports of this kind of problems
on amd64 machines in the lists since various years ago, so i don't think
this is just a problem with this BIOS/motherboard (MSI K9AG Neo2 Digital)
on the lists


Thanks in advance for any help.
Regards.


[1]: http://www.hetzner.de/hosting/produkte_rootserver/ds7000/
[2]: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/128287
[3]: http://fxr.watson.org/fxr/source/drivers/ata/ahci.c?v=linux-2.6#L369
-- 
La prueba más fehaciente de que existe vida inteligente en otros
planetas, es que no han intentado contactar con nosotros. 
Copyright (c) 1992-2008 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.1-BETA2 #1: Wed Oct 22 13:19:14 CEST 2008
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/NOUSB
Preloaded elf kernel "/boot/kernel/kernel" at 0x80c12000.
Preloaded elf obj module "/boot/kernel/geom_mirror.ko" at 0x80c121a8.
Preloaded elf obj module "/boot/kernel/accf_data.ko" at 0x80c12818.
Preloaded elf obj module "/boot/kernel/accf_http.ko" at 0x80c12cc8.
Preloaded elf obj module "/boot/kernel/k8temp.ko" at 0x80c13238.
Preloaded elf obj module "/boot/kernel/geom_journal.ko" at 0x80c13720.
Calibrating clock(s) ... i8254 clock: 1193242 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequ

Re: confirming bugs is bad behavior, etc.

2008-12-09 Thread Alfred Perlstein 
Jo, I'm trying to get FreeBSD to consider not supporting
another "6.4" or "5.5" as both seems to have some of the problems
you're describing due to a the next gen -stable being out
for so long sucking away developer time.

As a user, what do you think about this?

I hate to force users to upgrade, but I also hate to potentially
be falsly advertising "stability" when there might not be enough
maintainers to keep that true.

Thoughts?

-Alfred

* Jo Rhett <[EMAIL PROTECTED]> [081201 12:28] wrote:
> On Dec 1, 2008, at 11:59 AM, George V. Neville-Neil wrote:
> >I have mostly stayed away from these threads because they've often
> >devolved into unproductive finger pointing.
> >
> >Please leave the hyperbole out of your posts, or at least attempt to
> >cut it back.  People on these lists are working quite hard to solve
> >problems for the whole of the FreeBSD community and your posts, such
> >as this one, are not helping us to move forward.
> 
> 
> My posts have always been directed at solving very real, operational  
> problems with using FreeBSD on server platforms, which is exactly the  
> stated goal for freebsd.  I have always offered not only problems, but  
> resources to help test or evaluate the issues, and serious  
> considerations for ways to improve the process.
> 
> Yes, you're right.  Threads I start about real problems always devolve  
> into unproductive finger pointing.  That would be the freebsd  
> developers attacking the reporter for identifying a real, operational  
> problem.  Take a look at the posts of the FreeBSD developers, and view  
> for yourself the unprofessional attacks and personal insults hurled by  
> them at people who are simply trying to get real problems resolved.
> 
> And yet, instead of asking your developers to stop violating the  
> posted rules of the mailing list, you are asking a bug reporter who  
> simply informed another bug reporter that their problem was both  
> widespread and not limited to USB devices to stop posting to the  
> list.  Because god knows that "yes we saw it too and it's widely  
> reported" is bad behavior.  Much worse that personal attacks which are  
> strictly against the list rules.
> 
> Yes, I'm sure that the personal attacks really do help drive freebsd  
> development forward.  Much more so than me bringing resources and  
> actually testing things does.
> 
> Now that Core has clearly spoken their mind on this issue, by refusing  
> to ask freebsd developers to avoid violating the list charter and then  
> publicly calling out someone for just saying "yeah, it's a widely  
> reported problem" ... leaves any doubt that positive change is going  
> to happen here.
> 
> Your request is accepted.  I'm unsubscribing now.
> 
> -- 
> Jo Rhett
> Net Consonance : consonant endings by net philanthropy, open source  
> and other randomness
> 
> 
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"

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

update release schedule information?

2008-12-09 Thread Fernan Aguero 
Hi,

the release schedule information available in
http://www.freebsd.org/releases/7.1R/schedule.html
is outdated.

You probably already know about this ... and
I also know 7.1-RELEASE is delayed, but the schedule page does not
provide any useful information on what's going to happen next. BETA2
has already passed but it has not been mentioned in this document.

The front page for the project (www.freebsd.org) links to
ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/ISO-IMAGES/7.1/
with the text 'Upcoming Release 7.1 - BETA2'
(but BETA2 is not mentioned in schedule.html)

If you navigate to the FTP site using that link now, you'll find that
the images for the RC1 are already available (Dec 7th). But the
'actual' dates for the RC1 builds are missing from schedule.html.

I'm not familiar with the docproj procedures, but have tried to help
by editing the release.ent and schedule.sgml files (patches attached),
which looked as the obvious candidates to me. If someone can check
them, complete the missing dates in schedule.sgml, and commit the
changes, that would be great!

Cheers,

-- 
fernan
34c34
< 
---
> 
--- www/en/releases/7.1R/schedule.sgml.orig	2008-12-09 13:34:22.0 -0300
+++ www/en/releases/7.1R/schedule.sgml	2008-12-09 13:38:45.0 -0300
@@ -110,6 +110,13 @@
   Begin BETA1 builds.
 
 
+
+  BETA2 builds
+  --
+  --
+  Begin BETA2 builds.
+
+
 
 
   RELENG_7_1 branch
@@ -122,7 +129,7 @@
 
   RC1 builds
   15 September 2008
-  --
+  7 December 2008
   Begin RC1 builds.
 
 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: sio vs uart vs ucomm problems / differences

2008-12-09 Thread Mike Tancsa 

At 09:19 PM 11/25/2008, Mike Tancsa wrote:
We are in the process of migrating one of our embedded apps to use 
uart by default instead of sio in RELENG_7 in prep for the day when 
sio eventually disappears.  Unfortunately, the application doesnt 
want to work with uart

with puc backed devices, but still works with sio. Stranger still, the app



For the archives,
We were sort of able to figure it out in
http://lists.freebsd.org/pipermail/freebsd-current/2008-December/001052.html
and
http://lists.freebsd.org/pipermail/freebsd-usb/2008-December/005817.html


---Mike 


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

Re: lagg(4) and failover

2008-12-09 Thread Brian A. Seklecki 
On Mon, 2008-12-08 at 23:58 -0800, Tom Samplonius wrote:
>   I don't know if that is such a great idea, as that would only test
> the switch that you are connected to.

Heatbeats (STP,CARP) and active sanity checking (Nagios, ifwatchd(8))
are the two main options.

Results may vary in every system/network device permutation.

At least we're talking about it -- even if just for the sake of the
archives -- that wasn't happening before.


-- 
Brian A. Seklecki <[EMAIL PROTECTED]>
Collaborative Fusion, Inc.


signature.asc
Description: This is a digitally signed message part

Re: ext2fuse: user-space ext2 implementation

2008-12-09 Thread Paul B. Mahol 
On 12/8/08, Bruce M. Simpson <[EMAIL PROTECTED]> wrote:
> I have rolled a port for ext2fuse:
> http://people.freebsd.org/~bms/dump/fusefs-ext2fs.tar

Ignoring fact that is buggy, slooow and port doesnt have any cache implemented
and port leaves files behind in share/doc/ext2fuse when package
deleted it looks fine.

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

Re: Regression in vr - not receiveing multicast

2008-12-09 Thread Pyun YongHyeon 
On Tue, Dec 09, 2008 at 10:40:17AM +0100, Goran Lowkrantz wrote:
 > Hi,
 > 
 > in July, vr had this problem and was fixed:
 > 
 > 
 > 
 > but now it's back again!
 > 

There was just one bug fix since then and I guess the fix is not
related with your issue.

 > On a system with the following:
 > 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #3: Thu Oct 16 12:31:04 UTC 2008
 > 
 > I have to set all vr interfaces in promisc to get routing info.
 > 
 > Using Quagga
 > # pkg_info -Ix uagga
 > quagga-0.99.10_3Free RIPv1, RIPv2, OSPFv2, BGP4, IS-IS route software
 > 
 > on an inner network using RIPv2
 > # ifmcstat -i vr0
 > vr0:
 >  inet xxx.xxx.xxx.xxx
 >  group 224.0.0.9
 >  igmpv2
 >  mcast-macaddr 01:00:5e:00:00:09 refcnt 1
 >  group 224.0.0.1
 >  mcast-macaddr 01:00:5e:00:00:01 refcnt 1
 > 
 > 
 > On the same box, we have some em devices also and they work without any 
 > problems.
 > 

There is fundamental differences between em(4) and vr(4). The
vr(4) for VT6105M takes advantage of perfect multicast filtering
feature which is not present on all em(4) interface. Perfect
multicast filtering can reduce unwanted multicast traffics such
that it could save a lot of CPU cycles. The downside is that vr(4)
cannot accept multicast frames for a multicast group without
joining the multicast group first.
For multicast routing purpose I guess 'options MROUTING' kernel
option should be enabled to accept all multicast frames.
Does your kernel have that option?

 > Let me know what I can do to help fix this.
 > 
 > /glz
 > 

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

Re: Regression in vr - not receiveing multicast

2008-12-09 Thread Goran Lowkrantz 
--On December 9, 2008 20:47:23 +0900 Pyun YongHyeon <[EMAIL PROTECTED]> 
wrote:



On Tue, Dec 09, 2008 at 10:40:17AM +0100, Goran Lowkrantz wrote:
 > Hi,
 >
 > in July, vr had this problem and was fixed:
 > 
 > 
 >
 > but now it's back again!
 >

There was just one bug fix since then and I guess the fix is not
related with your issue.

 > On a system with the following:
 > 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #3: Thu Oct 16 12:31:04 UTC 2008
 >
 > I have to set all vr interfaces in promisc to get routing info.
 >
 > Using Quagga
 > # pkg_info -Ix uagga
 > quagga-0.99.10_3Free RIPv1, RIPv2, OSPFv2, BGP4, IS-IS route
software  >
 > on an inner network using RIPv2
 > # ifmcstat -i vr0
 > vr0:
 >   inet xxx.xxx.xxx.xxx
 >   group 224.0.0.9
 >   igmpv2
 >   mcast-macaddr 01:00:5e:00:00:09 refcnt 1
 >   group 224.0.0.1
 >   mcast-macaddr 01:00:5e:00:00:01 refcnt 1
 >
 >
 > On the same box, we have some em devices also and they work without
any   > problems.
 >

There is fundamental differences between em(4) and vr(4). The
vr(4) for VT6105M takes advantage of perfect multicast filtering
feature which is not present on all em(4) interface. Perfect
multicast filtering can reduce unwanted multicast traffics such
that it could save a lot of CPU cycles. The downside is that vr(4)
cannot accept multicast frames for a multicast group without
joining the multicast group first.
For multicast routing purpose I guess 'options MROUTING' kernel
option should be enabled to accept all multicast frames.
Does your kernel have that option?


No it has not. I will create such a beast and return with stories.


/glz


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

Re: visibility of release process

2008-12-09 Thread Ruben van Staveren 


On 9 Dec 2008, at 10:56, Aristedes Maniatis wrote:

Sure, but show me how to go to http://svn.freebsd.org/viewvc/base/  
and see commit log per branch or any other way to see what is going  
on in a branch. Fisheye gives you that in a really clear way and it  
costs nothing to add another option for users.


Though experimental, I'm greatly enjoying 
http://www.secnetix.de/olli/FreeBSD/svnews/?p=/stable/7

Maybe it is worth considering to team up and bring this under the  
freebsd.org umbrella ?


Regards,
Ruben


PGP.sig
Description: This is a digitally signed message part

Regression in vr - not receiveing multicast

2008-12-09 Thread Goran Lowkrantz 

Hi,

in July, vr had this problem and was fixed:



but now it's back again!

On a system with the following:
7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #3: Thu Oct 16 12:31:04 UTC 2008

I have to set all vr interfaces in promisc to get routing info.

Using Quagga
# pkg_info -Ix uagga
quagga-0.99.10_3Free RIPv1, RIPv2, OSPFv2, BGP4, IS-IS route software

on an inner network using RIPv2
# ifmcstat -i vr0
vr0:
inet xxx.xxx.xxx.xxx
group 224.0.0.9
igmpv2
mcast-macaddr 01:00:5e:00:00:09 refcnt 1
group 224.0.0.1
mcast-macaddr 01:00:5e:00:00:01 refcnt 1


On the same box, we have some em devices also and they work without any 
problems.


Let me know what I can do to help fix this.

/glz


... the future isMobile

 Goran Lowkrantz <[EMAIL PROTECTED]>
 System Architect, isMobile AB
 Sandviksgatan 81, PO Box 58, S-971 03 Luleå, Sweden
 Mobile: +46(0)70-587 87 82
http://www.ismobile.com ...

---
"There is hopeful symbolism in the fact that flags do not wave in a vacuum."
   -- Arthur C. Clarke
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: visibility of release process

2008-12-09 Thread Aristedes Maniatis 


On 09/12/2008, at 5:21 AM, Peter Jeremy wrote:


What do you mean as "news source"?  Commits are inherently low level
and it's difficult to see how a commit could be massaged into some
sort of press release without a fair amount of meta information in
the commit log.


Well, I use this as a way of tracking activity sometimes:

http://news.gmane.org/gmane.os.freebsd.devel.cvs

And indeed, I notice now it has been improved recently. The commit  
messages now include full paths and diffs. Very helpful.



* the bug tracker. Let's just say that FreeBSD's bug tracker is  
fairly

primitive and 'target release' is not an option.


Agreed.  This is an issue that comes up regularly but I don't believe
a solution has been identified.  I suspect one of the requirements
would be that it be FOSS


I don't understand why it should be necessarily FOSS. I believe the  
best solution should be chosen by those people who would use it most:  
the core developers. I know for a fact that many non-free providers  
would give FreeBSD a free perpetual license for the goodwill it would  
create, as for instance Atlassian do for Jira at Apache and other open  
source projects. Is it also a requirement that FreeBSD only be hosted  
on servers with FOSS bios? What about P4?


My personal wish list would be:

* rich search interface
* workflow (eg. if a critical task remains open for more than x days  
without attention, it is automatically escalated)
* svn integration (so that commit messages reference the task and vice  
versa)

* release notes and roadmap
* ease of integration with multiple front end tools, so developers can  
comment on issues from the command line or their iphone




I've had a look at several of the fisheye sites and am not sure what

it would buy the Project, other than some pretty graphs.  I don't see
how this is any more "friendly" than svn.freebsd.org.



Sure, but show me how to go to http://svn.freebsd.org/viewvc/base/ and  
see commit log per branch or any other way to see what is going on in  
a branch. Fisheye gives you that in a really clear way and it costs  
nothing to add another option for users.



Cheers

Ari Maniatis


-->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001   fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A


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

Re: lagg(4) and failover

2008-12-09 Thread Andrew Snow 

  lagg is ultimately a problem as a high-availability solution since most 
switches do not support multi-switch 802.3ad yet, and most probably never well. 
 So you are limited to a single switch.  So 802.3ad is good only for 
aggregation, and not for high availability.


What about using STP or RSTP instead of lagg? Which L2 managed switches 
like 3com and HP support.  Then you could connect each of two NICs to a 
different switch, as well as connect the switches to each other.


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

Regression in vr - not receiveing multicast

2008-12-09 Thread Goran Lowkrantz 

Hi,

in July, vr had this problem and was fixed:



but now it's back again!

On a system with the following:
7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #3: Thu Oct 16 12:31:04 UTC 2008

I have to set all vr interfaces in promisc to get routing info.

Using Quagga
# pkg_info -Ix uagga
quagga-0.99.10_3Free RIPv1, RIPv2, OSPFv2, BGP4, IS-IS route software

on an inner network using RIPv2
# ifmcstat -i vr0
vr0:
inet xxx.xxx.xxx.xxx
group 224.0.0.9
igmpv2
mcast-macaddr 01:00:5e:00:00:09 refcnt 1
group 224.0.0.1
mcast-macaddr 01:00:5e:00:00:01 refcnt 1


On the same box, we have some em devices also and they work without any 
problems.


Let me know what I can do to help fix this.

/glz


... the future isMobile

 Goran Lowkrantz <[EMAIL PROTECTED]>
 System Architect, isMobile AB
 Sandviksgatan 81, PO Box 58, S-971 03 Luleå, Sweden
 Mobile: +46(0)70-587 87 82
http://www.ismobile.com ...
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: lagg(4) and failover

2008-12-09 Thread Peter Jeremy 
Please wrap your mail before 80 columns.
On 2008-Dec-08 23:58:00 -0800, Tom Samplonius <[EMAIL PROTECTED]> wrote:
>  The Linux bonding driver supports probing the default gateway.

This is the same brokenness as Solaris IPMP.  I agree that probing
an external IP address (probably, but not necessarily a gateway) is
the way to go but you need to be able to configure this.  Otherwise
you need to jump through hoops where the interfaces you are protecting
is not the default route (or there are multiple independent groups
of interfaces being protected).

>  Now, it uses ARP for this (probably because the ARP who-has code is
>also in the kernel and easily accessible), which also not so great,

I don't see that it's necessary to have the interface failover code
in the kernel.  The kernel needs hooks to allow a daemon to bind to
the physical interfaces and control which one is active, but the
actual code that decides how to determine which interface is active
should be in userland.  (Note that routing works this way).

>switches do not support multi-switch 802.3ad yet, and most probably
>never well.  So you are limited to a single switch.  So 802.3ad is
>good only for aggregation, and not for high availability.

Keep in mind that higher-end switches as well as stacked lower-end
switches have a reasonable amount of internal redundancy so 802.3ad
within one distinct components of one physical switch may be adequate
for many purposes.  Keep in mind that you'll still need multiple
FreeBSD boxes to prevent them being a single point of failure.

-- 
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.


pgpRg83tFxR9k.pgp
Description: PGP signature

Re: lagg(4) and failover

2008-12-09 Thread Tom Samplonius 

- "Brian A. Seklecki" <[EMAIL PROTECTED]> wrote:
> On Sun, 2008-12-07 at 08:03 +1100, Peter Jeremy wrote:
> > On 2008-Dec-05 07:34:21 -0500, "Brian A. Seklecki"
> > <[EMAIL PROTECTED]> wrote:
> > >Well ... name a price for the development; HA L1/L2 is a feature
> the
> > >community would gladly sponsor the development of.
> > 
> > net/ifstated covers at least some of this.
> 
> I was thinking something like a heartbeat protocol could work well
> w/o
> LACP hacking on mid-range switches.
> 
> I think that's how Dell does it with the RHEL crap for Broadcom.
> 
> Send multicast packets on both an active/standby link.  If either
> node
> discontinues to see the others packets, some admin-configurable logic
> promotes (Metric/Bias/Weighting).

  I don't know if that is such a great idea, as that would only test the switch 
that you are connected to.

  The Linux bonding driver supports probing the default gateway.  Now, it uses 
ARP for this (probably because the ARP who-has code is also in the kernel and 
easily accessible), which also not so great, as a ARP who-has is a broadcast.  
So if you have lots of servers on the LAN using the bonding driver, you get a 
lot of broadcast traffic.  ICMP echo-request would be a better approach, but my 
take on this, is that the echo-request/reply handling code would have to be 
written, so this hasn't been done yet.  But ultimately, gateway probing is the 
best, as not only does it verify the directly connected switch, but also that 
you can get from that switch to the outside world.

  lagg is ultimately a problem as a high-availability solution since most 
switches do not support multi-switch 802.3ad yet, and most probably never well. 
 So you are limited to a single switch.  So 802.3ad is good only for 
aggregation, and not for high availability.

  So an active-standby system with probing is the way to go for 
high-availability.  It seems that FreeBSD has most of the components of this 
already.  ng_one2many was a possible base for this.  

> ~BAS
> 
> -- 
> Brian A. Seklecki <[EMAIL PROTECTED]>
> Collaborative Fusion, Inc.

Tom

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