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:
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 doesn't panic anymore.
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
Please test
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.org
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 ML350
On 09/02/2013, at 20:42, Parv p...@pair.com 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
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:
http://10.10.10.17:10080
Login using your standard
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 information:
Eitan Adler li...@eitanadler.com wrote:
On 8 February 2013 07:46, Andriy Gapon a...@freebsd.org 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
in message a18965a6-8d17-4919-9947-fe43d2503...@gsoft.com.au,
wrote Daniel O'Connor thusly...
On 09/02/2013, at 4:46, Jack Vogel jfvo...@gmail.com wrote:
recommends contacting your motherboard manufacturer if you have
continued concerns or questions whether your products are
impacted.
Konstantin Belousov kostik...@gmail.com 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
## 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
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
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
On Sat, Feb 9, 2013 at 3:44 PM, Christoph Moench-Tegeder
c...@burggraben.net 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
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.
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 broken memory
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
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 snapshot on two
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:
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:
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
On Sat, Feb 9, 2013 at 4:25 PM, CeDeROM cede...@tlen.pl wrote:
On Sat, Feb 9, 2013 at 3:44 PM, Christoph Moench-Tegeder
c...@burggraben.net 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
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:
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
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.
There
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 is
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 from memory
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
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
___
Date: Sat, 9 Feb 2013 16:07:23 -0800
From: Steve Kargl s...@troutmask.apl.washington.edu
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
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/l10ntools/
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
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 on
Hi,
On Sat, 9 Feb 2013 16:07:23 -0800
Steve Kargl s...@troutmask.apl.washington.edu 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?
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
What am I missing?
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
options
On 9 February 2013 20:26, Anton Shterenlikht me...@bristol.ac.uk 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
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
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 let
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
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
42 matches
Mail list logo
