Re: geli(8) breaks after a couple hours of uptime

on 10/02/2013 01:35 Pawel Jakub Dawidek said the following: > geli(8) almost exclusively deals with sensitive data. Even mlocking > MAXPHYS would fail with current limits, but this is bad idea. > > With mlockall() I am sure I didn't miss anything - be it forgetting > about mlocking some buffer or

Re: 7+ days of dogfood

On Sun, Feb 10, 2013 at 08:33:25AM +0200, Ian FREISLICH wrote: > Steve Kargl wrote: > > Firefox segfaults after ~10 seconds. Chrome gets stuck in a uwait > > state and never becomes responsive. Libreoffice displays its splash > > screen and immediately segfaults. Xorg does not start because it >

Re: 7+ days of dogfood

On Feb 9, 2013, at 10:33 PM, Ian FREISLICH wrote: > 2. MALLOC_PRODUCTION=yes > Maybe it's the placebo effect. Binaries are smaller in memory > and "things seem faster" There have been significant improvements in this area very recently. Please give it another try without this setting and

Re: 7+ days of dogfood

Steve Kargl wrote: > Firefox segfaults after ~10 seconds. Chrome gets stuck in a uwait > state and never becomes responsive. Libreoffice displays its splash > screen and immediately segfaults. Xorg does not start because it > cannot load the xf86-video-driver (unless it is explicitly recompiled

Re: building custom kernel on -current: unknown option "COMPAT_LINUX"

On 9 February 2013 20:26, Anton Shterenlikht wrote: > > I removed COMPAT_LINUX, and only left > > options COMPAT_43 > options COMPAT_LINUX32 > >From /usr/src/sys/amd64/conf/NOTES (9.1-RELEASE): # Enable Linux ABI emulation #XXX#optionsCOMPAT_LINUX # Enable 32-bit Linux ABI emulation (requi

Re: building custom kernel on -current: unknown option "COMPAT_LINUX"

On Sun, 10 Feb 2013 00:31:44 GMT, Anton Shterenlikht wrote: > From free...@edvax.de Sun Feb 10 00:29:36 2013 > > On Sun, 10 Feb 2013 00:18:06 GMT, Anton Shterenlikht wrote: > > This is on amd64 r246552 > > > > I added > > > > options COMPAT_43 > >

Re: building custom kernel on -current: unknown option "COMPAT_LINUX"

On Sun, 10 Feb 2013 00:18:06 GMT, Anton Shterenlikht wrote: > This is on amd64 r246552 > > I added > > options COMPAT_43 > options COMPAT_LINUX > options COMPAT_LINUX32 > > to the kernel config, > following sys/amd64/conf/NOTES > > On buildkernel I get: > > unknown option "COMPAT_LINUX" > > W

Re: 7+ days of dogfood

Hi, On Sat, 9 Feb 2013 16:07:23 -0800 Steve Kargl wrote: > actual real-world conditions. In his words, FreeBSD should "eat its > own dogfood." The new installation on FreeBSD.org, of course, would I am on dog food since last May/June. How should I phrase it? Every can tastes different. Most c

Re: building custom kernel on -current: unknown option "COMPAT_LINUX"

From free...@edvax.de Sun Feb 10 00:42:11 2013 On Sun, 10 Feb 2013 00:31:44 GMT, Anton Shterenlikht wrote: > From free...@edvax.de Sun Feb 10 00:29:36 2013 > > On Sun, 10 Feb 2013 00:18:06 GMT, Anton Shterenlikht wrote: > > This is

Re: building custom kernel on -current: unknown option "COMPAT_LINUX"

From free...@edvax.de Sun Feb 10 00:29:36 2013 On Sun, 10 Feb 2013 00:18:06 GMT, Anton Shterenlikht wrote: > This is on amd64 r246552 > > I added > > options COMPAT_43 > options COMPAT_LINUX > options COMPAT_LINUX32

Re: 7+ days of dogfood

On Sat, Feb 09, 2013 at 04:07:23PM -0800, Steve Kargl wrote: > > Libreoffice currently does not build, but that's not totally > unexpected as compiling libreoffice seems to be a hit-or-miss > proposition. > laptop:root[201] cd /usr/ports/editors/libreoffice/work/libreoffice-core-3.6.5.2/l10ntoo

Re: 7+ days of dogfood

Date: Sat, 9 Feb 2013 16:07:23 -0800 From: Steve Kargl To: freebsd-current@freebsd.org Subject: 7+ days of dogfood In a long thread started by Peter Wemm on developers@, he described the move/upgrade of the FreeBSD.org cluster to using FreeBSD-10.

building custom kernel on -current: unknown option "COMPAT_LINUX"

This is on amd64 r246552 I added options COMPAT_43 options COMPAT_LINUX options COMPAT_LINUX32 to the kernel config, following sys/amd64/conf/NOTES On buildkernel I get: unknown option "COMPAT_LINUX" What am I missing? Thanks Anton ___ freebsd-cur

7+ days of dogfood

In a long thread started by Peter Wemm on developers@, he described the move/upgrade of the FreeBSD.org cluster to using FreeBSD-10. A part of his description included the need to test top-of-tree under actual real-world conditions. In his words, FreeBSD should "eat its own dogfood." The new ins

Re: geli(8) breaks after a couple hours of uptime

On Sat, Feb 09, 2013 at 06:00:53PM +0200, Andriy Gapon wrote: > on 09/02/2013 17:04 Andrey Zonov said the following: > > On 2/9/13 5:07 PM, Fabian Keil wrote: > >> > >> This would at least prevent the segfault. > >> > > > > I see two possibilities to get segfault: > > - no checking for result fr

Re: HEAD memsticks broken? [USB/CAM Problems?]

On 09-02-2013 20:28, Alexander Motin wrote: > How long ago that HEAD was built? Could you get full dmesg? I don't > think that "PREVENT ALLOW MEDIUM REMOVAL" should cause device drop. "No > sense data present" also doesn't look right. As I mentioned earlier, I've tried several HEAD snapshots. This

Re: [patch] Userland DTrace

On 2/10/13 1:47 AM, Mark Johnston wrote: > On Fri, Feb 08, 2013 at 04:04:38PM +, Matt Burke wrote: >> I've been spending some time trying to get the fasttrap provider to work >> on FreeBSD without panicing. I believe I have succeeded, at least to the >> point where it's no longer panicing. >> >

Re: [patch] Userland DTrace

On 2/8/13 8:04 PM, Matt Burke wrote: > I've been spending some time trying to get the fasttrap provider to work > on FreeBSD without panicing. I believe I have succeeded, at least to the > point where it's no longer panicing. > > There were two panic causes. The first was > http://www.freebsd.org/

[dcha...@freebsd.org: some usb troubles]

Hi all, trying to run HEAD on macbookpro10,1: 1) usb3.0 does not work at 9.1 and HEAD (r246587) 2) between stable/9 and HEAD (r246587) we are lost uhid devices (external keyboard and mouse) and umass. dmesg on the same hw can be find here: http://people.freebsd.org/~dchagin/macbookpro/dmesg.gene

Re: Intel 82574 issue reported on Slashdot

On Sat, Feb 9, 2013 at 4:25 PM, CeDeROM wrote: > On Sat, Feb 9, 2013 at 3:44 PM, Christoph Moench-Tegeder > wrote: >> ## O. Hartmann (ohart...@zedat.fu-berlin.de): >>> We don't even have the tool tcpreplay in the ports mentioned in that BLOG. >> It's in net-mgmt/tcpreplay. > > And I managed to bu

Re: [patch] Userland DTrace

On Fri, Feb 08, 2013 at 04:04:38PM +, Matt Burke wrote: > I've been spending some time trying to get the fasttrap provider to work > on FreeBSD without panicing. I believe I have succeeded, at least to the > point where it's no longer panicing. > > There were two panic causes. The first was >

some usb troubles

Hi all, trying to run macbookpro10,1 on HEAD: 1) usb3.0 does not work at 9.1 and HEAD (r246587) 2) Between stable/9 and HEAD (r246587) we are lost uhid devices (external keyboard and mouse) and umass. dmesg on the same hw can find here: http://people.freebsd.org/~dchagin/macbookpro/dmesg.generic

Re: Intel 82574 issue reported on Slashdot

On 02/09/13 09:15, Johnny Eriksson wrote: >> In all honesty.. The blog post (and your email) are basically >> information free, they don't name names and provide no script >> or downloadable code that will allow end users to check if they >> are affected. > A link with a little bit more information

Re: HEAD memsticks broken? [USB/CAM Problems?]

On 09.02.2013 12:15, Hans Petter Selasky wrote: > On Saturday 09 February 2013 10:26:59 Joel Dahl wrote: >> On 09-02-2013 8:32, Joel Dahl wrote: >>> Hi, >>> >>> I suspect something is broken with memsticks built from HEAD. I noticed >>> that I couldn't boot the latest HEAD (amd64) memstick snapsho

Re: [patch] Userland DTrace

On 08/02/2013 20:04, Matt Burke wrote: I've been spending some time trying to get the fasttrap provider to work on FreeBSD without panicing. I believe I have succeeded, at least to the point where it's no longer panicing. There were two panic causes. The first was http://www.freebsd.org/cgi/quer

Re: geli(8) breaks after a couple hours of uptime

on 09/02/2013 17:04 Andrey Zonov said the following: > On 2/9/13 5:07 PM, Fabian Keil wrote: >> >> This would at least prevent the segfault. >> > > I see two possibilities to get segfault: > - no checking for result from memory allocation functions > - too big stack > > I have no found any br

Re: geli(8) breaks after a couple hours of uptime

on 09/02/2013 15:07 Fabian Keil said the following: > It also wouldn't hurt to document why a 64K per-process limit with an > unlimited number of processes per user is considered a good default in > the first place. I don't think that maxproc=unlimited is a good default regardless of memorylocked.

Re: Intel 82574 issue reported on Slashdot

On Sat, Feb 9, 2013 at 3:44 PM, Christoph Moench-Tegeder wrote: > ## O. Hartmann (ohart...@zedat.fu-berlin.de): >> We don't even have the tool tcpreplay in the ports mentioned in that BLOG. > It's in net-mgmt/tcpreplay. And I managed to build mentioned Ostinato packet crafting utility with no pro

Re: geli(8) breaks after a couple hours of uptime

On 2/9/13 5:07 PM, Fabian Keil wrote: > > This would at least prevent the segfault. > I see two possibilities to get segfault: - no checking for result from memory allocation functions - too big stack I have no found any broken memory allocation checking, but I found two big objects on the

Destroying ZFS snapshots "too quickly": xpt_scan_lun: can't allocate CCB, can't continue

Before the introduction of async_destroy I wrote a script to destroy ZFS snapshots in parallel to speed up the process. It's available at: http://www.fabiankeil.de/sourcecode/zfs-snapshot-destroyer/zsd.pl A couple of years ago the only downside seemed to be that it requires more memory and file de

Re: Intel 82574 issue reported on Slashdot

## O. Hartmann (ohart...@zedat.fu-berlin.de): > We don't even have the tool tcpreplay in the ports mentioned in that BLOG. It's in net-mgmt/tcpreplay. Regards, Christoph -- Spare Space ___ freebsd-current@freebsd.org mailing list http://lists.freebsd

Re: Physbio changes final call for tests and reviews

Konstantin Belousov wrote: > I finished the last (insignificant) missed bits in the Jeff' physbio > work. Now I am asking for the last round of testing and review, esp. for > the !x86 architectures. Another testing focus are the SCSI HBAs and RAID > controllers which drivers are changed by the pa

Re: Intel 82574 issue reported on Slashdot

in message , wrote Daniel O'Connor thusly... > > > On 09/02/2013, at 4:46, Jack Vogel wrote: > > > recommends contacting your motherboard manufacturer if you have > > continued concerns or questions whether your products are > > impacted. Here is the link: > > > > http://communities.intel.com/com

Re: geli(8) breaks after a couple hours of uptime

Eitan Adler wrote: > On 8 February 2013 07:46, Andriy Gapon wrote: > > on 08/02/2013 13:48 Ulrich Spörlein said the following: > >> It looks like 128k as a limit is still too low for geli(8) to work, and > >> I've set it to 256k now, so that I can use "sudo geli". Can you maybe > >> revise the

Re: Intel 82574 issue reported on Slashdot

Am 02/09/13 09:15, schrieb Johnny Eriksson: >> In all honesty.. The blog post (and your email) are basically >> information free, they don't name names and provide no script >> or downloadable code that will allow end users to check if they >> are affected. > > A link with a little bit more inform

Summary of junk emails blocked - 1 Junk Emails Blocked

Junk Box Summary for: curr...@freebsd.org The 1 emails listed below have been placed in your personal Junk Box since your last Junk Box Summary and will be deleted after 30 days. To retrieve any of these messages, visit your Junk Box at: Login using your standard u

Re: Intel 82574 issue reported on Slashdot

On 09/02/2013, at 20:42, Parv wrote: >> "Contact your motherboard manufacturer" is much more time >> consuming than "Run sysctl... | grep foo | awk ..." to see if your >> system is affected. > > Gift^WStraight from horse's mouth ... > > http://blog.krisk.org/2013/02/packets-of-death.html I've

Re: HEAD memsticks broken? [USB/CAM Problems?]

On Saturday 09 February 2013 10:26:59 Joel Dahl wrote: > On 09-02-2013 8:32, Joel Dahl wrote: > > Hi, > > > > I suspect something is broken with memsticks built from HEAD. I noticed > > that I couldn't boot the latest HEAD (amd64) memstick snapshot on two > > machines (Lenovo X220 and HP ProLiant

Re: HEAD memsticks broken? [USB/CAM Problems?]

On 09-02-2013 8:32, Joel Dahl wrote: > Hi, > > I suspect something is broken with memsticks built from HEAD. I noticed that I > couldn't boot the latest HEAD (amd64) memstick snapshot on two machines > (Lenovo X220 and HP ProLiant ML350 G5). Trying snapshots from the FreeBSD.org > FTP or allbsd.o

Re: uath panic on insert.

On Saturday 09 February 2013 09:47:46 Ian FREISLICH wrote: > Hans Petter Selasky wrote: > > On Friday 08 February 2013 22:43:17 Ian FREISLICH wrote: > > > Hans Petter Selasky wrote: > > > > Hi, > > > > > > > > Your problem should be fixed by: > > > > http://svnweb.freebsd.org/changeset/base/246565

Re: uath panic on insert.

Hans Petter Selasky wrote: > On Friday 08 February 2013 22:43:17 Ian FREISLICH wrote: > > Hans Petter Selasky wrote: > > > Hi, > > > > > > Your problem should be fixed by: > > > http://svnweb.freebsd.org/changeset/base/246565 > > > > > > Please test and report back if it doesn't. > > > > It does

Re: Intel 82574 issue reported on Slashdot

> In all honesty.. The blog post (and your email) are basically > information free, they don't name names and provide no script > or downloadable code that will allow end users to check if they > are affected. A link with a little bit more information: http://blog.krisk.org/2013/02/packets-of-d