date:20120306

Re: flowtable usable or not

2012-03-06 Thread Adrian Chadd

You haven't been bitten by the storage layer or filesystem hackery
bits which has caused filesystem corruption. :)

That said, FFS+SUJ has made recover-from-kernel-panic so much less
painful. Thankyou Jeffr and others!

What I tend to do is either run current on a VM or organise some
dedicated -current laptops. And run the bits of -current I'm testing
on -8 and -9.




Adrian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: flowtable usable or not

2012-03-06 Thread Doug Barton

On 3/6/2012 2:12 AM, Adrian Chadd wrote:
> You haven't been bitten by the storage layer or filesystem hackery
> bits which has caused filesystem corruption. :)

Ummm, I have, actually. I was one of the early adopters of SU+J and
complained loudly when it ate my /var/ for lunch. I also use a lot of
separate slices/partitions, so my system partition isn't getting written
to very often, isn't using SU+J, and almost always comes up clean after
a crash. My layout looks like this:

FreeBSD 1 & 2 are the same:
/ + /usr
/var
/tmp (memory disk)
/usr/local/ (this is the big partition, things like ports WRKDIRPREFIX
and /usr/obj go here)

Then I have separate ext2fs filesystems for /home, /data (cvs, svn,
other big trees). These are accessible from my Linux partition, which is
also where the shared swap partition is.

Using ext2fs for things I really care about (like /home) or things that
would take a long time to reproduce (like cvs and svn trees) has helped
avoid some of the more exciting corruption/data loss events, and
everything on the /usr/local's is either backed up, or trivially
reproducable.

> That said, FFS+SUJ has made recover-from-kernel-panic so much less
> painful. Thankyou Jeffr and others!

It's also made a mess out of snapshots ... The only thing I use SU+J for
is /var and /usr/local (see above).

> What I tend to do is either run current on a VM or organise some
> dedicated -current laptops. And run the bits of -current I'm testing
> on -8 and -9.

Well you get a gold start for actually running it at all, so there you
go. :)

Doug
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[releng_8 tinderbox] failure on i386/i386

2012-03-06 Thread FreeBSD Tinderbox

TB --- 2012-03-06 07:08:02 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca
TB --- 2012-03-06 07:08:02 - starting RELENG_8 tinderbox run for i386/i386
TB --- 2012-03-06 07:08:02 - cleaning the object tree
TB --- 2012-03-06 07:08:57 - cvsupping the source tree
TB --- 2012-03-06 07:08:57 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/RELENG_8/i386/i386/supfile
TB --- 2012-03-06 07:14:30 - building world
TB --- 2012-03-06 07:14:30 - CROSS_BUILD_TESTING=YES
TB --- 2012-03-06 07:14:30 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-03-06 07:14:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-03-06 07:14:30 - SRCCONF=/dev/null
TB --- 2012-03-06 07:14:30 - TARGET=i386
TB --- 2012-03-06 07:14:30 - TARGET_ARCH=i386
TB --- 2012-03-06 07:14:30 - TZ=UTC
TB --- 2012-03-06 07:14:30 - __MAKE_CONF=/dev/null
TB --- 2012-03-06 07:14:30 - cd /src
TB --- 2012-03-06 07:14:30 - /usr/bin/make -B buildworld
>>> World build started on Tue Mar  6 07:14:31 UTC 2012
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Tue Mar  6 08:00:57 UTC 2012
TB --- 2012-03-06 08:00:57 - generating LINT kernel config
TB --- 2012-03-06 08:00:57 - cd /src/sys/i386/conf
TB --- 2012-03-06 08:00:57 - /usr/bin/make -B LINT
TB --- 2012-03-06 08:00:57 - cd /src/sys/i386/conf
TB --- 2012-03-06 08:00:57 - /usr/sbin/config -m LINT
TB --- 2012-03-06 08:00:57 - building LINT kernel
TB --- 2012-03-06 08:00:57 - CROSS_BUILD_TESTING=YES
TB --- 2012-03-06 08:00:57 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-03-06 08:00:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-03-06 08:00:57 - SRCCONF=/dev/null
TB --- 2012-03-06 08:00:57 - TARGET=i386
TB --- 2012-03-06 08:00:57 - TARGET_ARCH=i386
TB --- 2012-03-06 08:00:57 - TZ=UTC
TB --- 2012-03-06 08:00:57 - __MAKE_CONF=/dev/null
TB --- 2012-03-06 08:00:57 - cd /src
TB --- 2012-03-06 08:00:57 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Tue Mar  6 08:00:57 UTC 2012
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT completed on Tue Mar  6 08:21:56 UTC 2012
TB --- 2012-03-06 08:21:56 - cd /src/sys/i386/conf
TB --- 2012-03-06 08:21:56 - /usr/sbin/config -m LINT-VIMAGE
TB --- 2012-03-06 08:21:56 - building LINT-VIMAGE kernel
TB --- 2012-03-06 08:21:56 - CROSS_BUILD_TESTING=YES
TB --- 2012-03-06 08:21:56 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-03-06 08:21:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-03-06 08:21:56 - SRCCONF=/dev/null
TB --- 2012-03-06 08:21:56 - TARGET=i386
TB --- 2012-03-06 08:21:56 - TARGET_ARCH=i386
TB --- 2012-03-06 08:21:56 - TZ=UTC
TB --- 2012-03-06 08:21:56 - __MAKE_CONF=/dev/null
TB --- 2012-03-06 08:21:56 - cd /src
TB --- 2012-03-06 08:21:56 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE
>>> Kernel build for LINT-VIMAGE started on Tue Mar  6 08:21:56 UTC 2012
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT-VIMAGE completed on Tue Mar  6 08:42:26 UTC 2012
TB --- 2012-03-06 08:42:26 - cd /src/sys/i386/conf
TB --- 2012-03-06 08:42:26 - /usr/sbin/config -m GENERIC
TB --- 2012-03-06 08:42:26 - building GENERIC kernel
TB --- 2012-03-06 08:42:26 - CROSS_BUILD_TESTING=YES
TB --- 2012-03-06 08:42:26 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-03-06 08:42:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-03-06 08:42:26 - SRCCONF=/dev/null
TB --- 2012-03-06 08:42:26 - TARGET=i386
TB --- 2012-03-06 08:42:26 - TARGET_ARCH=i386
TB --- 2012-03-06 08:42:26 - TZ=UTC
TB --- 2012-03-06 08:42:26 - __MAKE_CONF=/dev/null
TB --- 2012-03-06 08:42:26 - cd /src
TB --- 2012-03-06 08:42:26 - /usr/bin/make -B buildkernel KERNCONF=GENERIC
>>> Kernel build for GENERIC started on Tue Mar  6 08:42:26 UTC 2012
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for GENERIC completed on Tue Mar  6 08:57:04 UTC 2012
TB --- 2012-03-06 08:57:04 - cd /src/sys/i386/conf
TB --- 2012-03-06 08:57:04 - /usr/sbin/config -m PAE
TB --- 2012-03-06 08:57:04 - building PAE kernel
TB --- 2012-03-06 08:57:04 - CROSS_BUILD_TESTING=YES
TB --- 2012-03-06 08:57:04 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-03-06 08:57:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-03-06 08:57:04 - SRCCONF=

Re: Heavy fs corruption with 9.0-RELEASE

2012-03-06 Thread Julian H. Stacey

Xin Li wrote:
> On 03/05/12 14:12, Arnaud Lacombe wrote:
> > Hi,
> > 
> > I've been running a couple of system with 9.0-RELEASE since it is
> > out. All the system were installed through the standard
> > installation procedure. After unclean reboot, either crash or
> > power-failure, I get a huge amount of really bad filesystem
> > corruption (read: "silent", fs-wide, corruptions). This happens
> > with either i386 or amd64 build. Systems involved use compact flash
> > as their system permanent storage medium.
> [...]
> > I do not see this behavior when running 9.0-RELEASE on top of a 
> > 7.4-RELEASE userland (including FS). I've seen this behavior on 
> > various CF, so a single bad card is unlikely to be the culprit.

Various sizes & manufacturers of CF ?
Or merely CF from same source ?
If the latter, could be a batch fault.
Try CF cards from different manufacturers. 
Remember though manufacturers may detect batch faults & not sell them,
they may still be sold anyway !

  Criminals exist & mislabelling happens.  eg 2 tales:

My family once had a number of USB sticks, 1 each, (2 Gig each
costing 50 GBP (a lot of money, but not exorbitant then) at a
Sunday computer market in UK), most were faulty with BSD & MS,
I wondered if they might have been rejects from manufacturer,
scheduled for destruction, & some criminal might have `rescued'
them from the crusher, & sold them on.)

A German magazine (CT) reported on placebo cache chips some
years back, chips with pins but no silicon inside.


Cheers,
Julian
-- 
Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com
 Reply below not above, cumulative like a play script, & indent with "> ".
 Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable.
Mail from @yahoo dumped @berklix.  http://berklix.org/yahoo/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: lock violation in unionfs (9.0-STABLE r230270)

2012-03-06 Thread Pavel Polyakov


mount -t unionfs -o noatime /usr /mnt

insmntque: mp-safe fs and non-locked vp: 0xfe01d96704f0 is not
exclusive locked but should be
KDB: enter: lock violation


Pavel,
can you give a spin to this patch?:
http://www.freebsd.org/~attilio/unionfs_missing_insmntque_lock.patch

I think that the unlocking is due at that point as the vnode lock can
be switch later on.

Let me know what you think about it and what the test does.


Thanks!
This patch fixes the problem with lock violation. Sorry I've tested it so
late.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Intel(R) PRO/1000 PT Dual Port Server Adapter not working properly

2012-03-06 Thread Irjohn Junus

Thanks Herbert. I bought another Intel CT to test and it work flawlessly,
so it was a bad PT adapter.

On Mon, Mar 5, 2012 at 8:04 AM, Herbert J. Skuhra wrote:

> On Sun, 4 Mar 2012 14:39:01 +0800
> Irjohn Junus  wrote:
>
> > Hello,
> >
> > This was originally posted here:
> > http://forums.freebsd.org/showthread.php?p=168854&posted=1#post168854
> >
> > I'm building a new PF firewall box based on FreeBSD 9 Release.
> Motherboard
> > is Foxconn H61S Mini-ITX with Intel PRO/1000 PT dual port server adapter.
> >
> > The adapter is recognized as em0 and em1 but em0 just won't work (i.e no
> > light on the port when connected to the switch) and em1 works only in
> > 100baseTX full-duplex mode (no carrier if I force it to 1000baseT). I
> tried
> > to change switch port, UTP cable from Cat5e to Cat6 but still no luck.
> The
> > onboard Realtek works fine. Switch is Netgear GS608. Could it be a bad
> > Intel card?
> >
> > I also tried to compile the latest driver from Intel but it gives error
> > during compilation:
> > http://downloadcenter.intel.com/conf...&Dwnldid=17509<
> http://downloadcenter.intel.com/confirm.aspx?httpDown=http://downloadmirror.intel.com/17509/eng/em-7.2.4.tar.gz&lang=eng&Dwnldid=17509
> >
> >
> > Any help will be greatly appreciated. Thanks!
> >
> > ps: command captures are provided at the url above.
>
> Maybe you should test with 8.3-BETA1. The recent em1000 drivers (7.3.0?)
> were mfc'ed to stable/8 January 31st but not to stable/9.
>
> See:
>
> 
> 
>
> --
> Herbert
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

HEADS UP: FreeBSD 7.3 EoL coming soon

2012-03-06 Thread Colin Percival

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Everyone,

On March 31st, FreeBSD 7.3 will reach its End of Life and will no longer
be supported by the FreeBSD Security Team.  Users of FreeBSD 7.3 are
strongly encouraged to upgrade to FreeBSD 7.4, FreeBSD 8.1, FreeBSD 8.2,
or FreeBSD 9.0 before the that date.

Please note that due to the unexpectedly long interval between FreeBSD 8.2
and the upcoming FreeBSD 8.3, the EoL date for FreeBSD 8.2 (originaly set
at February 29, 2012) has been postponed until July 31, 2012 in keeping
with the policy of having a three-month "upgrade window".  In the unlikely
event that FreeBSD 8.3-RELEASE arrives later than the end of April, the
EoL dates for FreeBSD 8.1 and 8.2 will be further postponed.

The current supported branches and expected EoL dates are:

   +-+
   |  Branch   |  Release   |  Type  |   Release date  |  Estimated EoL  |
   |---+++-+-|
   |RELENG_7   |n/a |n/a |n/a  |February 28, 2013|
   |---+++-+-|
   |RELENG_7_3 |7.3-RELEASE |Extended|March 23, 2010   |March 31, 2012   |
   |---+++-+-|
   |RELENG_7_4 |7.4-RELEASE |Extended|February 24, 2011|February 28, 2013|
   |---+++-+-|
   |RELENG_8   |n/a |n/a |n/a  |last release + 2y|
   |---+++-+-|
   |RELENG_8_1 |8.1-RELEASE |Extended|July 23, 2010|July 31, 2012|
   |---+++-+-|
   |RELENG_8_2 |8.2-RELEASE |Normal  |February 24, 2011|July 31, 2012|
   |---+++-+-|
   |RELENG_9   |n/a |n/a |n/a  |last release + 2y|
   |---+++-+-|
   |RELENG_9_0 |9.0-RELEASE |Normal  |January 10, 2012 |January 31, 2013 |
   +-+

- -- 
Colin Percival
Security Officer, FreeBSD | freebsd.org | The power to serve
Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (FreeBSD)

iEYEARECAAYFAk9WFRoACgkQOM7KaQxqam6d1wCeL3/mYODX7++F6Z5oioJNhOfP
wkYAn3/OtMkPuv5Vv4DD8RPCarhNpeS/
=mCaz
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[releng_8 tinderbox] failure on i386/i386

2012-03-06 Thread FreeBSD Tinderbox

TB --- 2012-03-06 13:32:24 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca
TB --- 2012-03-06 13:32:24 - starting RELENG_8 tinderbox run for i386/i386
TB --- 2012-03-06 13:32:24 - cleaning the object tree
TB --- 2012-03-06 13:33:23 - cvsupping the source tree
TB --- 2012-03-06 13:33:23 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/RELENG_8/i386/i386/supfile
TB --- 2012-03-06 13:33:35 - building world
TB --- 2012-03-06 13:33:35 - CROSS_BUILD_TESTING=YES
TB --- 2012-03-06 13:33:35 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-03-06 13:33:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-03-06 13:33:35 - SRCCONF=/dev/null
TB --- 2012-03-06 13:33:35 - TARGET=i386
TB --- 2012-03-06 13:33:35 - TARGET_ARCH=i386
TB --- 2012-03-06 13:33:35 - TZ=UTC
TB --- 2012-03-06 13:33:35 - __MAKE_CONF=/dev/null
TB --- 2012-03-06 13:33:35 - cd /src
TB --- 2012-03-06 13:33:35 - /usr/bin/make -B buildworld
>>> World build started on Tue Mar  6 13:33:35 UTC 2012
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Tue Mar  6 14:20:16 UTC 2012
TB --- 2012-03-06 14:20:16 - generating LINT kernel config
TB --- 2012-03-06 14:20:16 - cd /src/sys/i386/conf
TB --- 2012-03-06 14:20:16 - /usr/bin/make -B LINT
TB --- 2012-03-06 14:20:16 - cd /src/sys/i386/conf
TB --- 2012-03-06 14:20:16 - /usr/sbin/config -m LINT
TB --- 2012-03-06 14:20:16 - building LINT kernel
TB --- 2012-03-06 14:20:16 - CROSS_BUILD_TESTING=YES
TB --- 2012-03-06 14:20:16 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-03-06 14:20:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-03-06 14:20:16 - SRCCONF=/dev/null
TB --- 2012-03-06 14:20:16 - TARGET=i386
TB --- 2012-03-06 14:20:16 - TARGET_ARCH=i386
TB --- 2012-03-06 14:20:16 - TZ=UTC
TB --- 2012-03-06 14:20:16 - __MAKE_CONF=/dev/null
TB --- 2012-03-06 14:20:16 - cd /src
TB --- 2012-03-06 14:20:16 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Tue Mar  6 14:20:16 UTC 2012
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT completed on Tue Mar  6 14:41:17 UTC 2012
TB --- 2012-03-06 14:41:17 - cd /src/sys/i386/conf
TB --- 2012-03-06 14:41:17 - /usr/sbin/config -m LINT-VIMAGE
TB --- 2012-03-06 14:41:17 - building LINT-VIMAGE kernel
TB --- 2012-03-06 14:41:17 - CROSS_BUILD_TESTING=YES
TB --- 2012-03-06 14:41:17 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-03-06 14:41:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-03-06 14:41:17 - SRCCONF=/dev/null
TB --- 2012-03-06 14:41:17 - TARGET=i386
TB --- 2012-03-06 14:41:17 - TARGET_ARCH=i386
TB --- 2012-03-06 14:41:17 - TZ=UTC
TB --- 2012-03-06 14:41:17 - __MAKE_CONF=/dev/null
TB --- 2012-03-06 14:41:17 - cd /src
TB --- 2012-03-06 14:41:17 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE
>>> Kernel build for LINT-VIMAGE started on Tue Mar  6 14:41:17 UTC 2012
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT-VIMAGE completed on Tue Mar  6 15:01:55 UTC 2012
TB --- 2012-03-06 15:01:55 - cd /src/sys/i386/conf
TB --- 2012-03-06 15:01:55 - /usr/sbin/config -m GENERIC
TB --- 2012-03-06 15:01:55 - building GENERIC kernel
TB --- 2012-03-06 15:01:55 - CROSS_BUILD_TESTING=YES
TB --- 2012-03-06 15:01:55 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-03-06 15:01:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-03-06 15:01:55 - SRCCONF=/dev/null
TB --- 2012-03-06 15:01:55 - TARGET=i386
TB --- 2012-03-06 15:01:55 - TARGET_ARCH=i386
TB --- 2012-03-06 15:01:55 - TZ=UTC
TB --- 2012-03-06 15:01:55 - __MAKE_CONF=/dev/null
TB --- 2012-03-06 15:01:55 - cd /src
TB --- 2012-03-06 15:01:55 - /usr/bin/make -B buildkernel KERNCONF=GENERIC
>>> Kernel build for GENERIC started on Tue Mar  6 15:01:55 UTC 2012
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for GENERIC completed on Tue Mar  6 15:16:22 UTC 2012
TB --- 2012-03-06 15:16:22 - cd /src/sys/i386/conf
TB --- 2012-03-06 15:16:22 - /usr/sbin/config -m PAE
TB --- 2012-03-06 15:16:22 - building PAE kernel
TB --- 2012-03-06 15:16:22 - CROSS_BUILD_TESTING=YES
TB --- 2012-03-06 15:16:22 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-03-06 15:16:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-03-06 15:16:22 - SRCCONF=

Re: msk0: interrupt storm

2012-03-06 Thread John Baldwin

On Thursday, March 01, 2012 8:29:55 pm YongHyeon PYUN wrote:
> On Wed, Feb 29, 2012 at 01:03:29AM +0400, Pavel Gorshkov wrote:
> > My laptop running 9.0-RELEASE/amd64/GENERIC freezes and
> > (sometimes) unfreezes intermittently, logging the following:
> > 
> > Feb 28 23:07:36 lifebook kernel: interrupt storm detected on "irq259:"; 
throttling interrupt source
> > 
> > $ vmstat -i
> > ...
> > irq259: mskc0   11669511   3456
> > 
> > 
> > Looks very similar to this:
> > http://www.freebsd.org/cgi/query-pr.cgi?pr=164569
> > 
> > Any suggestions?
> 
> Try disabling MSI and see whether that makes any difference.

I also get interrupt storms with msk.  They do fix themselves when they 
happen, and I've seen it happen with the machine is idle.  This is on my 
little netbook where msk had several problems initially that have since been 
fixed.

mskc0:  port 0x2000-0x20ff mem 
0xe000-0xe0003fff irq 19 at device 0.0 on pci32
msk0:  on mskc0
msk0: Ethernet address: 00:24:81:40:e3:ef
miibus0:  on msk0
e1000phy0:  PHY 0 on miibus0
e1000phy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow

mskc0@pci0:32:0:0:  class=0x02 card=0x3056103c chip=0x436c11ab 
rev=0x10 hdr=0x00
vendor = 'Marvell Technology Group Ltd.'
device = '88E8072 PCI-E Gigabit Ethernet Controller'
class  = network
subclass   = ethernet

-- 
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

9-stable: what happened to geom_labels?

2012-03-06 Thread Warren Block

A new install of 9-release, updated to 9-stable today with the GENERIC 
kernel.

gpart show -l shows GPT labels, yet there isn't even a /dev/gpt directory.

Has something changed with labels?
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Heavy fs corruption with 9.0-RELEASE

2012-03-06 Thread Thierry Thomas

Le mar  6 mar 12 à 10:41:16 +0100, Julian H. Stacey 
 écrivait :

> A German magazine (CT) reported on placebo cache chips some
> years back, chips with pins but no silicon inside.

This one is original, at least:


(Sorry, it might require a FB account)

Regards,
-- 
Th. Thomas.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

geli keyfiles won't load automatically at boot time

2012-03-06 Thread xenophon\+freebsd

Whether I boot from an unencrypted UFS partition or from a CD, I cannot
get the boot loader to load my geli keyfiles automatically.  I always
have to interrupt the boot process and issue "load_geli" commands for
each provider and its corresponding keyfile.  Other settings in
/boot/loader.conf get read and applied correctly - kernel modules, root
file system specification, boot hints, etc.  Here are the relevant lines
from /boot/loader.conf:

geom_eli_load="YES"
geli_ada0p2_keyfile0_load="YES"
geli_ada0p2_keyfile0_type="ada0p2:geli_keyfile0"
geli_ada0p2_keyfile0_file="/boot/keys/ada0p2.key"
geli_ada1p2_keyfile0_load="YES"
geli_ada1p2_keyfile0_type="ada1p2:geli_keyfile0"
geli_ada1p2_keyfile0_file="/boot/keys/ada1p2.key"
geli_ada2p2_keyfile0_load="YES"
geli_ada2p2_keyfile0_type="ada2p2:geli_keyfile0"
geli_ada2p2_keyfile0_file="/boot/keys/ada2p2.key"
geli_ada3p2_keyfile0_load="YES"
geli_ada3p2_keyfile0_type="ada3p2:geli_keyfile0"
geli_ada3p2_keyfile0_file="/boot/keys/ada3p2.key"

If I boot with this configuration, I get the following error:

GEOM_ELI: Found no keyfiles in loader.conf for ada0p2
GEOM_ELI: Found no keyfiles in loader.conf for ada1p2
GEOM_ELI: Found no keyfiles in loader.conf for ada2p2
GEOM_ELI: Found no keyfiles in loader.conf for ada3p2

Instead, I have to issue the following loader commands manually:

load_geli ada0p2 /boot/keys/ada0p2.key 
load_geli ada1p2 /boot/keys/ada1p2.key
load_geli ada2p2 /boot/keys/ada2p2.key
load_geli ada3p2 /boot/keys/ada3p2.key

Then, the system will boot normally.  Can anyone tell me what's wrong
with my configuration?  It matches what's on the geli(8) manual page.
I've glanced through the relevant kernel sources, but I won't pretend
that I understood everything that I read.

Best wishes,
Matthew

-- 
I FIGHT FOR THE USERS

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

FreeBSD 8.2 - active plus inactive memory leak!?

2012-03-06 Thread Luke Marsden

Hi all,

I'm having some trouble with some production 8.2-RELEASE servers where
the 'Active' and 'Inact' memory values reported by top don't seem to
correspond with the processes which are running on the machine.  I have
two near-identical machines (with slightly different workloads); on one,
let's call it A, active + free is small (6.5G) and on the other (B)
active + free is large (13.6G), even though they have almost identical
sums-of-resident memory (8.3G on A and 9.3G on B).

The only difference is that A has a smaller number of quite long-running
processes (it's hosting a small number of busy sites) and B has a larger
number of more frequently killed/recycled processes (it's hosting a
larger number of quiet sites, so the FastCGI processes get killed and
restarted frequently).  Notably B has many more ZFS filesystems mounted
than A (around 4,000 versus 100).  The machines are otherwise under
similar amounts of load.  I hoped that the community could please help
me understand what's going on with respect to the worryingly large
amount of active + free memory on B.

Both machines are ZFS-on-root with FreeBSD 8.2-RELEASE with uptimes
around 5-6 days.  I have recently reduced the ARC cache on both machines
since my previous thread [1] and Wired memory usage is now stable at 6G
on A and 7G on B with an arc_max of 4G on both machines.

Neither of the machines have any swap in use:

Swap: 10G Total, 10G Free

My current (probably quite simplistic) understanding of the FreeBSD
virtual memory system is that, for each process as reported by top:

  * Size corresponds to the total size of all the text pages for the
process (those belonging to code in the binary itself and linked
libraries) plus data pages (including stack and malloc()'d but
not-yet-written-to memory segments).
  * Resident corresponds to a subset of the pages above: those pages
which actually occupy physical/core memory.  Notably pages may
appear in size but not appear in resident for read-only text
pages from libraries which have not been used yet or which have
been malloc()'d but not yet written-to.

My understanding for the values for the system as a whole (at the top in
'top') is as follows:

  * Active / inactive memory is the same thing: resident memory from
processes in use.  Being in the inactive as opposed to active
list simply indicates that the pages in question are less
recently used and therefore more likely to get swapped out if
the machine comes under memory pressure.
  * Wired is mostly kernel memory.
  * Cache is freed memory which the kernel has decided to keep in
case it correspond to a useful page in future; it can be cheaply
evicted into the free list.
  * Free memory is actually not being used for anything.

It seems that pages which occur in the active + inactive lists must
occur in the resident memory of one or more processes ("or more" since
processes can share pages in e.g. read-only shared libs or COW forked
address space).  Conversely, if a page *does not* occur in the resident
memory of any process, it must not occupy any space in the active +
inactive lists.

Therefore the active + inactive memory should always be less than or
equal to the sum of the resident memory of all the processes on the
system, right?

But it's not.  So, I wrote a very simple Python script to add up the
resident memory values in the output from 'top' and, on machine A:

Mem: 3388M Active, 3209M Inact, 6066M Wired, 196K Cache, 11G
Free
There were 246 processes totalling 8271 MB resident memory

Whereas on machine B:

Mem: 11G Active, 2598M Inact, 7177M Wired, 733M Cache, 1619M
Free
There were 441 processes totalling 9297 MB resident memory

Now, on machine A:

3388M active + 3209M inactive - 8271M sum-of-resident = -1674M

I can attribute this negative value to shared libraries between the
running processes (which the sum-of-res is double-counting but active +
inactive is not).  But on machine B:

11264M active + 2598M inactive - 9297M sum-of-resident = 4565M

I'm struggling to explain how, when there are only 9.2G (worst case,
discounting shared pages) of resident processes, the system is using 11G
+ 2598M = 13.8G of memory!

This "missing memory" is scary, because it seems to be increasing over
time, and eventually when the system runs out of free memory, I'm
certain it will crash in the same way described in my previous thread
[1].

Is my understanding of the virtual memory system badly broken - in which
case please educate me ;-) or is there a real problem here?  If so how
can I dig deeper to help uncover/fix it?

Best Regards,
Luke Marsden

[1] lists.freebsd.org/pipermail/freebsd-fs/2012-February/013775.html
[2] https://gist.github.com/1988153

-- 
CTO, Hybrid Logic
+447791750420  |  +1-415-449-1165  | www.hybri

[releng_8 tinderbox] failure on i386/i386

2012-03-06 Thread FreeBSD Tinderbox

TB --- 2012-03-06 19:44:36 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca
TB --- 2012-03-06 19:44:36 - starting RELENG_8 tinderbox run for i386/i386
TB --- 2012-03-06 19:44:36 - cleaning the object tree
TB --- 2012-03-06 19:45:53 - cvsupping the source tree
TB --- 2012-03-06 19:45:53 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/RELENG_8/i386/i386/supfile
TB --- 2012-03-06 19:46:14 - building world
TB --- 2012-03-06 19:46:14 - CROSS_BUILD_TESTING=YES
TB --- 2012-03-06 19:46:14 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-03-06 19:46:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-03-06 19:46:14 - SRCCONF=/dev/null
TB --- 2012-03-06 19:46:14 - TARGET=i386
TB --- 2012-03-06 19:46:14 - TARGET_ARCH=i386
TB --- 2012-03-06 19:46:14 - TZ=UTC
TB --- 2012-03-06 19:46:14 - __MAKE_CONF=/dev/null
TB --- 2012-03-06 19:46:14 - cd /src
TB --- 2012-03-06 19:46:14 - /usr/bin/make -B buildworld
>>> World build started on Tue Mar  6 19:46:15 UTC 2012
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Tue Mar  6 20:32:16 UTC 2012
TB --- 2012-03-06 20:32:16 - generating LINT kernel config
TB --- 2012-03-06 20:32:16 - cd /src/sys/i386/conf
TB --- 2012-03-06 20:32:16 - /usr/bin/make -B LINT
TB --- 2012-03-06 20:32:16 - cd /src/sys/i386/conf
TB --- 2012-03-06 20:32:16 - /usr/sbin/config -m LINT
TB --- 2012-03-06 20:32:16 - building LINT kernel
TB --- 2012-03-06 20:32:16 - CROSS_BUILD_TESTING=YES
TB --- 2012-03-06 20:32:16 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-03-06 20:32:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-03-06 20:32:16 - SRCCONF=/dev/null
TB --- 2012-03-06 20:32:16 - TARGET=i386
TB --- 2012-03-06 20:32:16 - TARGET_ARCH=i386
TB --- 2012-03-06 20:32:16 - TZ=UTC
TB --- 2012-03-06 20:32:16 - __MAKE_CONF=/dev/null
TB --- 2012-03-06 20:32:16 - cd /src
TB --- 2012-03-06 20:32:16 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Tue Mar  6 20:32:16 UTC 2012
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT completed on Tue Mar  6 20:52:52 UTC 2012
TB --- 2012-03-06 20:52:52 - cd /src/sys/i386/conf
TB --- 2012-03-06 20:52:52 - /usr/sbin/config -m LINT-VIMAGE
TB --- 2012-03-06 20:52:52 - building LINT-VIMAGE kernel
TB --- 2012-03-06 20:52:52 - CROSS_BUILD_TESTING=YES
TB --- 2012-03-06 20:52:52 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-03-06 20:52:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-03-06 20:52:52 - SRCCONF=/dev/null
TB --- 2012-03-06 20:52:52 - TARGET=i386
TB --- 2012-03-06 20:52:52 - TARGET_ARCH=i386
TB --- 2012-03-06 20:52:52 - TZ=UTC
TB --- 2012-03-06 20:52:52 - __MAKE_CONF=/dev/null
TB --- 2012-03-06 20:52:52 - cd /src
TB --- 2012-03-06 20:52:52 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE
>>> Kernel build for LINT-VIMAGE started on Tue Mar  6 20:52:52 UTC 2012
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT-VIMAGE completed on Tue Mar  6 21:13:10 UTC 2012
TB --- 2012-03-06 21:13:10 - cd /src/sys/i386/conf
TB --- 2012-03-06 21:13:10 - /usr/sbin/config -m GENERIC
TB --- 2012-03-06 21:13:10 - building GENERIC kernel
TB --- 2012-03-06 21:13:10 - CROSS_BUILD_TESTING=YES
TB --- 2012-03-06 21:13:10 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-03-06 21:13:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-03-06 21:13:10 - SRCCONF=/dev/null
TB --- 2012-03-06 21:13:10 - TARGET=i386
TB --- 2012-03-06 21:13:10 - TARGET_ARCH=i386
TB --- 2012-03-06 21:13:10 - TZ=UTC
TB --- 2012-03-06 21:13:10 - __MAKE_CONF=/dev/null
TB --- 2012-03-06 21:13:10 - cd /src
TB --- 2012-03-06 21:13:10 - /usr/bin/make -B buildkernel KERNCONF=GENERIC
>>> Kernel build for GENERIC started on Tue Mar  6 21:13:10 UTC 2012
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for GENERIC completed on Tue Mar  6 21:27:31 UTC 2012
TB --- 2012-03-06 21:27:31 - cd /src/sys/i386/conf
TB --- 2012-03-06 21:27:31 - /usr/sbin/config -m PAE
TB --- 2012-03-06 21:27:31 - building PAE kernel
TB --- 2012-03-06 21:27:31 - CROSS_BUILD_TESTING=YES
TB --- 2012-03-06 21:27:31 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-03-06 21:27:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-03-06 21:27:31 - SRCCONF=

Re: Heavy fs corruption with 9.0-RELEASE

2012-03-06 Thread Julian H. Stacey

Thierry Thomas wrote:
> Le mar  6 mar 12 à 10:41:16 +0100, Julian H. Stacey 
>  écrivait :
> 
> > A German magazine (CT) reported on placebo cache chips some
> > years back, chips with pins but no silicon inside.
> 
> This one is original, at least:
> 
> 
> (Sorry, it might require a FB account)

It does not require a facebook account.
I burst out laughing when I saw the pictures,
I reccomend others look,
Thanks Thierry for posting the URL :-)

Cheers,
Julian
-- 
Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com
 Reply below not above, cumulative like a play script, & indent with "> ".
 Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable.
Mail from @yahoo dumped @berklix.  http://berklix.org/yahoo/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

RE: geli keyfiles won't load automatically at boot time

2012-03-06 Thread Dewayne Geraghty

> -Original Message-
> From: owner-freebsd-sta...@freebsd.org 
> [mailto:owner-freebsd-sta...@freebsd.org] On Behalf Of 
> xenophon\+freebsd
> Sent: Wednesday, 7 March 2012 5:03 AM
> To: freebsd-stable@freebsd.org
> Subject: geli keyfiles won't load automatically at boot time
> 
> Whether I boot from an unencrypted UFS partition or from a 
> CD, I cannot get the boot loader to load my geli keyfiles 
> automatically.  I always have to interrupt the boot process 
> and issue "load_geli" commands for each provider and its 
> corresponding keyfile.  Other settings in /boot/loader.conf 
> get read and applied correctly - kernel modules, root file 
> system specification, boot hints, etc.  Here are the relevant 
> lines from /boot/loader.conf:
> 
> geom_eli_load="YES"
> geli_ada0p2_keyfile0_load="YES"
> geli_ada0p2_keyfile0_type="ada0p2:geli_keyfile0"
> geli_ada0p2_keyfile0_file="/boot/keys/ada0p2.key"

Suggest that you try 
geli_ada0p2_keyfile0_name="/boot/keys/ada0p2.key"

Etc.
Regards, Dewayne.

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

ixgbe v2.3.11 won't negotiate LACP, v2.4.4 does

2012-03-06 Thread Chris Forgeron

I have a few systems with Intel X520-DA2 PCIe network cards (10 Gig).

The problem I've been running into is with a fresh 9.0-STABLE or 9.0-RELEASE 
install. I can't get a LACP connection established over the ix0 and ix1 ports. 
It's showing COLLECTING and DISTRIBUTING, but not ACTIVE. 

I've noticed that older 9.0-BETA copies with the 2.3.10 ixgbe driver are 
working with the same switch without problems.

The 9.0-STABLE that I was doing the most work with had an ixgbe of 2.3.11

 After some digging around, I downloaded the ixgbe 2.4.4 from the Intel site, 
compiled the .ko (a little editing due to the bool typdef), and now my 
9.0-STABLE systems can properly setup a LACP link over ixgbe devices.

 I'm sure others will run into this in time - Can we get the 2.4.4 into 
9-STABLE? 

 Thanks.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD 8.2 - active plus inactive memory leak!?

2012-03-06 Thread Luke Marsden

Thanks for your email, Chuck.

> > Conversely, if a page *does not* occur in the resident
> > memory of any process, it must not occupy any space in the active +
> > inactive lists.
> 
> Hmm...if a process gets swapped out entirely, the pages for it will be moved 
> to the cache list, flushed, and then reused as soon as the disk I/O 
> completes. 
>   But there is a window where the process can be marked as swapped out (and 
> considered no longer resident), but still has some of it's pages in physical 
> memory.

There's no swapping happening on these machines (intentionally so,
because as soon as we hit swap everything goes tits up), so this window
doesn't concern me.

I'm trying to confirm that, on a system with no pages swapped out, that
the following is a true statement:

a page is accounted for in active + inactive if and only if it
corresponds to one or more of the pages accounted for in the
resident memory lists of all the processes on the system (as per
the output of 'top' and 'ps')

> > Therefore the active + inactive memory should always be less than or
> > equal to the sum of the resident memory of all the processes on the
> > system, right?
> 
> No.  If you've got a lot of process pages shared (ie, a webserver with lots 
> of 
> httpd children, or a database pulling in a large common shmem area), then 
> your 
> process resident sizes can be very large compared to the system-wide 
> active+inactive count.

But that's what I'm saying...

sum(process resident sizes) >= active + inactive

Or as I said it above, equivalently:

active + inactive <= sum(process resident sizes)

The data I've got from this system, and what's killing us, shows the
opposite: active + inactive > sum(process resident sizes) - by over 5GB
now and growing, which is what keeps causing these machines to crash.

In particular:
Mem: 13G Active, 1129M Inact, 7543M Wired, 120M Cache, 1553M Free

But the total sum of resident memories is 9457M (according to summing
the output from ps or top).

13G + 1129M = 14441M (active + inact) > 9457M (sum of res)

That's 4984M out, and that's almost enough to push us over the edge.

If my understanding of VM is correct, I don't see how this can happen.
But it's happening, and it's causing real trouble here because our free
memory keeps hitting zero and then we swap-spiral.

What can I do to investigate this discrepancy?  Are there some tools
that I can use to debug the memory allocated in "active" to find out
where it's going, if not to resident process memory?

Thanks,
Luke

-- 
CTO, Hybrid Logic
+447791750420  |  +1-415-449-1165  | www.hybrid-cluster.com 


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

Re: FreeBSD 8.2 - active plus inactive memory leak!?

2012-03-06 Thread Ian Lepore

On Tue, 2012-03-06 at 19:13 +, Luke Marsden wrote:
> Hi all,
> 
> I'm having some trouble with some production 8.2-RELEASE servers where
> the 'Active' and 'Inact' memory values reported by top don't seem to
> correspond with the processes which are running on the machine.  I have
> two near-identical machines (with slightly different workloads); on one,
> let's call it A, active + free is small (6.5G) and on the other (B)
> active + free is large (13.6G), even though they have almost identical
> sums-of-resident memory (8.3G on A and 9.3G on B).
> 
> The only difference is that A has a smaller number of quite long-running
> processes (it's hosting a small number of busy sites) and B has a larger
> number of more frequently killed/recycled processes (it's hosting a
> larger number of quiet sites, so the FastCGI processes get killed and
> restarted frequently).  Notably B has many more ZFS filesystems mounted
> than A (around 4,000 versus 100).  The machines are otherwise under
> similar amounts of load.  I hoped that the community could please help
> me understand what's going on with respect to the worryingly large
> amount of active + free memory on B.
> 
> Both machines are ZFS-on-root with FreeBSD 8.2-RELEASE with uptimes
> around 5-6 days.  I have recently reduced the ARC cache on both machines
> since my previous thread [1] and Wired memory usage is now stable at 6G
> on A and 7G on B with an arc_max of 4G on both machines.
> 
> Neither of the machines have any swap in use:
> 
> Swap: 10G Total, 10G Free
> 
> My current (probably quite simplistic) understanding of the FreeBSD
> virtual memory system is that, for each process as reported by top:
> 
>   * Size corresponds to the total size of all the text pages for the
> process (those belonging to code in the binary itself and linked
> libraries) plus data pages (including stack and malloc()'d but
> not-yet-written-to memory segments).
>   * Resident corresponds to a subset of the pages above: those pages
> which actually occupy physical/core memory.  Notably pages may
> appear in size but not appear in resident for read-only text
> pages from libraries which have not been used yet or which have
> been malloc()'d but not yet written-to.
> 
> My understanding for the values for the system as a whole (at the top in
> 'top') is as follows:
> 
>   * Active / inactive memory is the same thing: resident memory from
> processes in use.  Being in the inactive as opposed to active
> list simply indicates that the pages in question are less
> recently used and therefore more likely to get swapped out if
> the machine comes under memory pressure.
>   * Wired is mostly kernel memory.
>   * Cache is freed memory which the kernel has decided to keep in
> case it correspond to a useful page in future; it can be cheaply
> evicted into the free list.
>   * Free memory is actually not being used for anything.
> 
> It seems that pages which occur in the active + inactive lists must
> occur in the resident memory of one or more processes ("or more" since
> processes can share pages in e.g. read-only shared libs or COW forked
> address space).  Conversely, if a page *does not* occur in the resident
> memory of any process, it must not occupy any space in the active +
> inactive lists.
> 
> Therefore the active + inactive memory should always be less than or
> equal to the sum of the resident memory of all the processes on the
> system, right?
> 
> But it's not.  So, I wrote a very simple Python script to add up the
> resident memory values in the output from 'top' and, on machine A:
> 
> Mem: 3388M Active, 3209M Inact, 6066M Wired, 196K Cache, 11G
> Free
> There were 246 processes totalling 8271 MB resident memory
> 
> Whereas on machine B:
> 
> Mem: 11G Active, 2598M Inact, 7177M Wired, 733M Cache, 1619M
> Free
> There were 441 processes totalling 9297 MB resident memory
> 
> Now, on machine A:
> 
> 3388M active + 3209M inactive - 8271M sum-of-resident = -1674M
> 
> I can attribute this negative value to shared libraries between the
> running processes (which the sum-of-res is double-counting but active +
> inactive is not).  But on machine B:
> 
> 11264M active + 2598M inactive - 9297M sum-of-resident = 4565M
> 
> I'm struggling to explain how, when there are only 9.2G (worst case,
> discounting shared pages) of resident processes, the system is using 11G
> + 2598M = 13.8G of memory!
> 
> This "missing memory" is scary, because it seems to be increasing over
> time, and eventually when the system runs out of free memory, I'm
> certain it will crash in the same way described in my previous thread
> [1].
> 
> Is my understanding of the virtual memory system badly broken - in which
> case please educate me ;-) or is there a real problem here

FreeBSD 8.3-RC1 Available...

2012-03-06 Thread Ken Smith


The first Release Candidate build of the 8.3-RELEASE release cycle is
now available on the FTP servers for the amd64, i386, and pc98
architectures.  The MD5/SHA256 sums are at the bottom of this message.
The ISO images and, for architectures that support it, the memory stick
images are available here:

  ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/8.3/

(or any of the FreeBSD mirror sites).

We hope to have one more Release Candidate build, followed by the
release itself.  The schedule is available here:

  http://www.freebsd.org/releases/8.3R/schedule.html

and so far we're not too far off.

If you notice any problems you can report them through the normal Gnats
PR system or here on the -stable mailing list.

If you would like to use csup/cvsup mechanisms to do a source-based
update of an existing system the branch tag to use is now "RELENG_8_3".
If you would like to use SVN instead use "releng/8.3".  As part of
preparing for RC1 "releng/8.3" was branched.

The freebsd-update(8) utility supports binary upgrades of i386 and amd64 
systems running earlier FreeBSD releases.  Systems running 8.1-RELEASE,
8.2-RELEASE, or 8.3-BETA1 can upgrade as follows:

# freebsd-update upgrade -r 8.3-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 earlier FreeBSD releases (FreeBSD 7.x) can also use freebsd-update
to upgrade to FreeBSD 8.3-RC1, 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 7.x and FreeBSD 8.x.

Checksums:

MD5 (FreeBSD-8.3-RC1-amd64-bootonly.iso) = d3fee39afba719d0f47c0eea881a84ad
MD5 (FreeBSD-8.3-RC1-amd64-disc1.iso) = cb38356833f43998510c5b496eac7917
MD5 (FreeBSD-8.3-RC1-amd64-dvd1.iso) = 043901211a0730242df482d83794c6fc
MD5 (FreeBSD-8.3-RC1-amd64-livefs.iso) = 76a1c13fe4af6a9845e8ea13069a97d6
MD5 (FreeBSD-8.3-RC1-amd64-memstick.img) = a6b74511a2edccd98407c464b8781681

MD5 (FreeBSD-8.3-RC1-i386-bootonly.iso) = b3e9d11a41f54487f0ef077cb8f517ec
MD5 (FreeBSD-8.3-RC1-i386-disc1.iso) = 2d3ddbe3c7256bc9df67b06a33e8be48
MD5 (FreeBSD-8.3-RC1-i386-dvd1.iso) = 2df8cf3af608afa983aa667e54a8de43
MD5 (FreeBSD-8.3-RC1-i386-livefs.iso) = e03f18a0a2c05b32692501e7012ed52f
MD5 (FreeBSD-8.3-RC1-i386-memstick.img) = c46fe4e008edece737e7a31a076bff2a

MD5 (FreeBSD-8.3-RC1-pc98-bootonly.iso) = 9de8c5e4dc516740af4dd2aa6cde759f
MD5 (FreeBSD-8.3-RC1-pc98-disc1.iso) = c24d2270a8a9e8685ac82e096a131246
MD5 (FreeBSD-8.3-RC1-pc98-livefs.iso) = 80905bdfe7bd89a04068e0344d791ec4

SHA256 (FreeBSD-8.3-RC1-amd64-bootonly.iso) = 
d47d63b59465ac0254e770e6e3fa5a3959895dedce130250f26848306439d55d
SHA256 (FreeBSD-8.3-RC1-amd64-disc1.iso) = 
38b08f12f0b3e83045e46b7f09404a2f36e26f7e3c668bc4a01b8383ab72c48a
SHA256 (FreeBSD-8.3-RC1-amd64-dvd1.iso) = 
535547adcab0ff8cceb778674151323da015aefc6d8b36337d85f62a4fad87bc
SHA256 (FreeBSD-8.3-RC1-amd64-livefs.iso) = 
600b26d6c15946c88ffc516d3cce57eb2ee48149f8af96e9124ca478901e8a5c
SHA256 (FreeBSD-8.3-RC1-amd64-memstick.img) = 
53218723e35deba522bfbd87d8d5e1451705f6f386f2b004468190ae89fd0bc1

SHA256 (FreeBSD-8.3-RC1-i386-bootonly.iso) = 
5c37eb5124fb057384d5828e8cc1e116f0b9c0a7efe6f3365f59ba87a50be83c
SHA256 (FreeBSD-8.3-RC1-i386-disc1.iso) = 
1fec8dc68433c12a9b24da1b7e35a6d4e6bb96cb1258fb809111572d1b16ebb9
SHA256 (FreeBSD-8.3-RC1-i386-dvd1.iso) = 
ec2f7f7c38d22726fcd9c95d4d7699068eeddbaa2b60eb235373a2eadd792931
SHA256 (FreeBSD-8.3-RC1-i386-livefs.iso) = 
7a75e051ef26571621d2782f42e30d9f0f6552cbd8f0dfdb5dd9d6d2da853500
SHA256 (FreeBSD-8.3-RC1-i386-memstick.img) = 
966ff5e1e9e561395083ebce110a6e9c07778a6e05f689bb94451efecaa15bf4

SHA256 (FreeBSD-8.3-RC1-pc98-bootonly.iso) = 
0866dc444b92e5a03ad90da8e87f49e184aead6e2148af1f3cc35d4c74e14b35
SHA256 (FreeBSD-8.3-RC1-pc98-disc1.iso) = 
5f6521693b1d0cf6b89af6783035afb58c75fb2be9e4b6c064b13c5e584bdcd0
SHA256 (FreeBSD-8.3-RC1-pc98-livefs.iso) = 
f1f6237364819a34f522f4d740e5c37db4bcd03cc254cf531584e3c5f7d59ac5


-- 
Ken Smith
- From there to here, from here to  |   kensm...@buffalo.edu
  there, funny things are everywhere.   |
  - Theodor Geisel  |


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

add k3772z 3g modem support for FreeBSD-9

2012-03-06 Thread Oliver Pinter

Hi all!

I wrote a patch, to add support for Vodafone K3772-Z 3g modem.

-- 
Oliver Pinter
(Tresorium)
commit 092aa1246e1dde0ffe11a7bc06b540f4fa5851c9
Author: Oliver Pinter 
Date:   Wed Mar 7 01:47:51 2012 +0100

added support for Vodafone 3772-Z to u3g driver

ugen1.2:  at usbus1
ugen1.2:  at usbus1 (disconnected)
ugen1.2:  at usbus1
umodem0:  on usbus1
umodem0: data interface 2, has CM over data, has break
umodem1:  on usbus1
umodem1: data interface 4, has CM over data, has break
cdce0:  on usbus1
ue0:  on cdce0
ue0: Ethernet address: 02:77:c1:XX:XX:XX
umass0:  on usbus1
(probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0
(probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(probe0:umass-sim0:0:0:0): SCSI status: Check Condition
(probe0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:28,0 (Not ready to rea
dy change, medium may have changed)

Signed-off-by: Oliver Pinter 

diff --git a/share/man/man4/u3g.4 b/share/man/man4/u3g.4
index 4df0b26..a2122cb 100644
--- a/share/man/man4/u3g.4
+++ b/share/man/man4/u3g.4
@@ -61,6 +61,8 @@ Option GT 3G, GT 3G Quad, etc.
 .It
 Vodafone Mobile Connect Card 3G
 .It
+Vodafone Mobile Broadband K3772-Z
+.It
 Qualcomm Inc. CDMA MSM
 .It
 Huawei B190, E180v, E220 ('')
diff --git a/sys/dev/usb/serial/u3g.c b/sys/dev/usb/serial/u3g.c
index e0b38bd..23b0f6c 100644
--- a/sys/dev/usb/serial/u3g.c
+++ b/sys/dev/usb/serial/u3g.c
@@ -422,6 +422,7 @@ static const STRUCT_USB_HOST_ID u3g_devs[] = {
 	U3G_DEV(QUALCOMMINC, SURFSTICK, 0),
 	U3G_DEV(QUALCOMMINC, E2002, 0),
 	U3G_DEV(QUALCOMMINC, E2003, 0),
+	U3G_DEV(QUALCOMMINC, K3772_Z, U3GINIT_SCSIEJECT),
 	U3G_DEV(QUALCOMMINC, MF626, 0),
 	U3G_DEV(QUALCOMMINC, MF628, 0),
 	U3G_DEV(QUALCOMMINC, MF633R, 0),
diff --git a/sys/dev/usb/usbdevs b/sys/dev/usb/usbdevs
index c770043..bc990c8 100644
--- a/sys/dev/usb/usbdevs
+++ b/sys/dev/usb/usbdevs
@@ -2744,6 +2744,7 @@ product QUALCOMMINC E0078	0x0078	3G modem
 product QUALCOMMINC E0082	0x0082	3G modem
 product QUALCOMMINC E0086	0x0086	3G modem
 product QUALCOMMINC SURFSTICK	0x0117	1&1 Surf Stick
+product QUALCOMMINC K3772_Z	0x1179	3G modem
 product QUALCOMMINC ZTE_STOR	0x2000	USB ZTE Storage
 product QUALCOMMINC E2002	0x2002	3G modem
 product QUALCOMMINC E2003	0x2003	3G modem
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[releng_8 tinderbox] failure on i386/i386

2012-03-06 Thread FreeBSD Tinderbox

TB --- 2012-03-07 01:46:26 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca
TB --- 2012-03-07 01:46:26 - starting RELENG_8 tinderbox run for i386/i386
TB --- 2012-03-07 01:46:26 - cleaning the object tree
TB --- 2012-03-07 01:47:21 - cvsupping the source tree
TB --- 2012-03-07 01:47:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/RELENG_8/i386/i386/supfile
TB --- 2012-03-07 01:47:32 - building world
TB --- 2012-03-07 01:47:32 - CROSS_BUILD_TESTING=YES
TB --- 2012-03-07 01:47:32 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-03-07 01:47:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-03-07 01:47:32 - SRCCONF=/dev/null
TB --- 2012-03-07 01:47:32 - TARGET=i386
TB --- 2012-03-07 01:47:32 - TARGET_ARCH=i386
TB --- 2012-03-07 01:47:32 - TZ=UTC
TB --- 2012-03-07 01:47:32 - __MAKE_CONF=/dev/null
TB --- 2012-03-07 01:47:32 - cd /src
TB --- 2012-03-07 01:47:32 - /usr/bin/make -B buildworld
>>> World build started on Wed Mar  7 01:47:33 UTC 2012
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Wed Mar  7 02:33:49 UTC 2012
TB --- 2012-03-07 02:33:49 - generating LINT kernel config
TB --- 2012-03-07 02:33:49 - cd /src/sys/i386/conf
TB --- 2012-03-07 02:33:49 - /usr/bin/make -B LINT
TB --- 2012-03-07 02:33:49 - cd /src/sys/i386/conf
TB --- 2012-03-07 02:33:49 - /usr/sbin/config -m LINT
TB --- 2012-03-07 02:33:49 - building LINT kernel
TB --- 2012-03-07 02:33:49 - CROSS_BUILD_TESTING=YES
TB --- 2012-03-07 02:33:49 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-03-07 02:33:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-03-07 02:33:49 - SRCCONF=/dev/null
TB --- 2012-03-07 02:33:49 - TARGET=i386
TB --- 2012-03-07 02:33:49 - TARGET_ARCH=i386
TB --- 2012-03-07 02:33:49 - TZ=UTC
TB --- 2012-03-07 02:33:49 - __MAKE_CONF=/dev/null
TB --- 2012-03-07 02:33:49 - cd /src
TB --- 2012-03-07 02:33:49 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Wed Mar  7 02:33:49 UTC 2012
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT completed on Wed Mar  7 02:54:46 UTC 2012
TB --- 2012-03-07 02:54:46 - cd /src/sys/i386/conf
TB --- 2012-03-07 02:54:46 - /usr/sbin/config -m LINT-VIMAGE
TB --- 2012-03-07 02:54:46 - building LINT-VIMAGE kernel
TB --- 2012-03-07 02:54:46 - CROSS_BUILD_TESTING=YES
TB --- 2012-03-07 02:54:46 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-03-07 02:54:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-03-07 02:54:46 - SRCCONF=/dev/null
TB --- 2012-03-07 02:54:46 - TARGET=i386
TB --- 2012-03-07 02:54:46 - TARGET_ARCH=i386
TB --- 2012-03-07 02:54:46 - TZ=UTC
TB --- 2012-03-07 02:54:46 - __MAKE_CONF=/dev/null
TB --- 2012-03-07 02:54:46 - cd /src
TB --- 2012-03-07 02:54:46 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE
>>> Kernel build for LINT-VIMAGE started on Wed Mar  7 02:54:46 UTC 2012
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT-VIMAGE completed on Wed Mar  7 03:16:21 UTC 2012
TB --- 2012-03-07 03:16:21 - cd /src/sys/i386/conf
TB --- 2012-03-07 03:16:21 - /usr/sbin/config -m GENERIC
TB --- 2012-03-07 03:16:21 - building GENERIC kernel
TB --- 2012-03-07 03:16:21 - CROSS_BUILD_TESTING=YES
TB --- 2012-03-07 03:16:21 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-03-07 03:16:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-03-07 03:16:21 - SRCCONF=/dev/null
TB --- 2012-03-07 03:16:21 - TARGET=i386
TB --- 2012-03-07 03:16:21 - TARGET_ARCH=i386
TB --- 2012-03-07 03:16:21 - TZ=UTC
TB --- 2012-03-07 03:16:21 - __MAKE_CONF=/dev/null
TB --- 2012-03-07 03:16:21 - cd /src
TB --- 2012-03-07 03:16:21 - /usr/bin/make -B buildkernel KERNCONF=GENERIC
>>> Kernel build for GENERIC started on Wed Mar  7 03:16:21 UTC 2012
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for GENERIC completed on Wed Mar  7 03:31:17 UTC 2012
TB --- 2012-03-07 03:31:17 - cd /src/sys/i386/conf
TB --- 2012-03-07 03:31:17 - /usr/sbin/config -m PAE
TB --- 2012-03-07 03:31:17 - building PAE kernel
TB --- 2012-03-07 03:31:17 - CROSS_BUILD_TESTING=YES
TB --- 2012-03-07 03:31:17 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-03-07 03:31:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-03-07 03:31:17 - SRCCONF=

Re: msk0: interrupt storm

2012-03-06 Thread YongHyeon PYUN

On Tue, Mar 06, 2012 at 10:36:05AM -0500, John Baldwin wrote:
> On Thursday, March 01, 2012 8:29:55 pm YongHyeon PYUN wrote:
> > On Wed, Feb 29, 2012 at 01:03:29AM +0400, Pavel Gorshkov wrote:
> > > My laptop running 9.0-RELEASE/amd64/GENERIC freezes and
> > > (sometimes) unfreezes intermittently, logging the following:
> > > 
> > > Feb 28 23:07:36 lifebook kernel: interrupt storm detected on "irq259:"; 
> throttling interrupt source
> > > 
> > > $ vmstat -i
> > > ...
> > > irq259: mskc0   11669511   3456
> > > 
> > > 
> > > Looks very similar to this:
> > > http://www.freebsd.org/cgi/query-pr.cgi?pr=164569
> > > 
> > > Any suggestions?
> > 
> > Try disabling MSI and see whether that makes any difference.
> 
> I also get interrupt storms with msk.  They do fix themselves when they 
> happen, and I've seen it happen with the machine is idle.  This is on my 
> little netbook where msk had several problems initially that have since been 
> fixed.
> 
> mskc0:  port 0x2000-0x20ff mem 
> 0xe000-0xe0003fff irq 19 at device 0.0 on pci32
> msk0:  on mskc0
> msk0: Ethernet address: 00:24:81:40:e3:ef
> miibus0:  on msk0
> e1000phy0:  PHY 0 on miibus0
> e1000phy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
> 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow
> 
> mskc0@pci0:32:0:0:  class=0x02 card=0x3056103c chip=0x436c11ab 
> rev=0x10 hdr=0x00
> vendor = 'Marvell Technology Group Ltd.'
> device = '88E8072 PCI-E Gigabit Ethernet Controller'
> class  = network
> subclass   = ethernet
> 

John, can you let me know the value of B0_Y2_SP_ISRC2 register in
interrupt handler when you see the interrupt storm?
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: ixgbe v2.3.11 won't negotiate LACP, v2.4.4 does

2012-03-06 Thread Jack Vogel

Never rains but it pours, this is the second request today :)

Yes, I will do an MFC as soon as quickly as I am able.

Jack


On Tue, Mar 6, 2012 at 3:00 PM, Chris Forgeron  wrote:

> I have a few systems with Intel X520-DA2 PCIe network cards (10 Gig).
>
> The problem I've been running into is with a fresh 9.0-STABLE or
> 9.0-RELEASE install. I can't get a LACP connection established over the ix0
> and ix1 ports. It's showing COLLECTING and DISTRIBUTING, but not ACTIVE.
>
> I've noticed that older 9.0-BETA copies with the 2.3.10 ixgbe driver are
> working with the same switch without problems.
>
> The 9.0-STABLE that I was doing the most work with had an ixgbe of 2.3.11
>
>  After some digging around, I downloaded the ixgbe 2.4.4 from the Intel
> site, compiled the .ko (a little editing due to the bool typdef), and now
> my 9.0-STABLE systems can properly setup a LACP link over ixgbe devices.
>
>  I'm sure others will run into this in time - Can we get the 2.4.4 into
> 9-STABLE?
>
>  Thanks.
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: flowtable usable or not

Re: flowtable usable or not

[releng_8 tinderbox] failure on i386/i386

Re: Heavy fs corruption with 9.0-RELEASE

Re: lock violation in unionfs (9.0-STABLE r230270)

Re: Intel(R) PRO/1000 PT Dual Port Server Adapter not working properly

HEADS UP: FreeBSD 7.3 EoL coming soon

[releng_8 tinderbox] failure on i386/i386

Re: msk0: interrupt storm

9-stable: what happened to geom_labels?

Re: Heavy fs corruption with 9.0-RELEASE

geli keyfiles won't load automatically at boot time

FreeBSD 8.2 - active plus inactive memory leak!?

[releng_8 tinderbox] failure on i386/i386

Re: Heavy fs corruption with 9.0-RELEASE

RE: geli keyfiles won't load automatically at boot time

ixgbe v2.3.11 won't negotiate LACP, v2.4.4 does

Re: FreeBSD 8.2 - active plus inactive memory leak!?

Re: FreeBSD 8.2 - active plus inactive memory leak!?

FreeBSD 8.3-RC1 Available...

add k3772z 3g modem support for FreeBSD-9

[releng_8 tinderbox] failure on i386/i386

Re: msk0: interrupt storm

Re: ixgbe v2.3.11 won't negotiate LACP, v2.4.4 does

24 matches

Site Navigation

Mail list logo

Footer information