rt numbers, and discuss the performance
differences before BSD grep is (re-)made the default.
--
Colin Percival
Security Officer, FreeBSD | freebsd.org | The power to serve
Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid
___
I'm leaning towards debug.quietdump, but it's not a strong preference.
--
Colin Percival
Security Officer, FreeBSD | freebsd.org | The power to serve
Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid
___
freebsd-current
Hi all,
On 12/28/10 07:37, Colin Percival wrote:
> The '(CTRL-C to abort)' which gets printed while dumping is irritating me
> because EC2's console has a very limited buffer and having this spammed
> makes it impossible to see any printfs immediately prior.
Never mind,
ther.
On the issue of performance, however: I know people have benchmarked
fork-bombs, but has anyone done benchmarks with moderate numbers of
long-lived, library-intensive, processes? It seems to me that dynamic
linking could have caching advantages.
actually closer to 10 kb.
The bandwidth usage associated with updating a system is only a concern
for people who roll their own binary update mechanism -- and those people
aren't likely to be doing everything over a modem.
Colin Percival
_
tatic /bin/sh is only an issue in non-interactive cases.
Colin Percival
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ing
out of memory; it's not surprising that dynamic linking has an increased
cost in such circumstances, since reading the diverse files into memory
will take longer than reading a single static binary.
I doubt many systems will experience this sort of performance delta.
Can anyone suggest why the kernel seems to be behaving so sluggishly?
The system hardware is P4 2.8Ghz, 865G, 2GB DDR, IDE drives; there is
very little disk activity, so I'm sure that isn't the issue; and disabling
HTT results in about a 2% improvement in both user and sys
At 15:30 30/11/2003 +0100, Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, Colin
Percival
writes:
> When running `make buildworld`, I see large amounts of sys time; eg, 27
>minutes user & 14 minutes sys for building 5.2, or 14 minutes user & 10
>minutes s
nce I'm not
passing the -j option to make; but a 5% performance delta between UP and
SMP kernels is rather surprising (to me, at least), and the fact that the
system time varies so much on the SMP kernel also seems peculiar.
Is this normal?
Colin Percival
_
clang/llvm 3.9.0.
So... is anyone else seeing unexpected panics or other odd behaviour starting
after clang/llvm 3.9.0 was imported?
--
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
; so
whatever Rick is tripping over, it doesn't seem to be affecting these tests.
--
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
___
freebsd-curren
ptimized spinning rust)
disks are optimized for 1 MB I/Os, and Amazon's NFS service (EFS) recommends
using a maximum I/O size of 1 MB (and despite NFS not being *physical* I/O it
seems to still be limited by MAXPHYS).
--
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
m this function?" Please feel
free to commit this fix.
For the benefit of the list: It looks like there was a short period this
morning when several portsnap mirrors were out of sync due to the mirroring
cron jobs running into a network outage somewhere around portsnap-master.
Everything should
ed
> in freebsd-update thinking everything is ok but left the kernel unbootable.
Yes, this is a known issue in freebsd-update -- it needs to be much smarter
about detecting and handling errors. Unfortunately I haven't had time to
deal with this (and it's a lot of work).
--
Colin
Hi all,
I just discovered after upgrading the portsnap buildbox from 8.2 to 9.0-rc3 that
# mount -u /path/containing/a/symlink
now fails with 'not currently mounted'. Can anyone tell me if this change was
deliberate?
--
Colin Percival
Security Officer, FreeBSD | freebsd.org | Th
should give us a theoretical 16 GiB or a "safe" 8 GiB limit
on swap usage (2^17 structures which are 276 bytes each on i386).
But I agree that the real issue was with amd64, not i386.
--
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.t
space available...)
--
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/fre
On 08/13/12 14:23, Peter Jeremy wrote:
> On 2012-Aug-12 15:44:07 -0700, Colin Percival
> wrote:
>> If I'm understanding things correctly, the "maxswzone" value -- set by
>> the kern.maxswzone loader tunable or to VM_SWZONE_SIZE_MAX by default --
>> should
e re@ that this is a simple enough (and safe enough) change to merge
before 10.0-RELEASE.
Comments?
--
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
Index: etc/rc
g a diskless system would know to not create a
"run firstboot scripts" marker. And not all embedded systems are
diskless...
--
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
__
On 10/14/13 05:07, Hiroki Sato wrote:
> Colin Percival wrote
> in <525b258f.3030...@freebsd.org>:
>
> cp> I've attached a very simple patch which makes /etc/rc:
>
> cp> +if ! [ -e /var/db/firstboot ]; then
> cp> + skip="$skip -s firstboot"
On 10/14/13 10:00, Ian Lepore wrote:
> On Mon, 2013-10-14 at 09:51 -0700, Colin Percival wrote:
>> Yes, it's hard to store state on diskless systems... but I figured
>> that anyone building a diskless system would know to not create a
>> "run firstboot scripts
ordering and skipping scripts because of that.
I considered this, but decided that the most common requirement use of
"run once" would be for "run when the system is first booted", and it
would be much simpler to provide just the firstboot functio
cidentally get run simply because you
failed to create a /firstboot file during the upgrade process.
--
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
_
erever people decide to put the firstboot sentinel will also be
available at that point.
Does anyone see any problems with this?
--
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
Inde
nning into this, I haven't
been able to reproduce it myself and so I can't track down what is causing this.
If anyone can provide assistance with this, it would be very gratefully
received.
--
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap |
On 10/27/13 14:52, Erik Cederstrand wrote:
> Den 27/10/2013 kl. 22.03 skrev Colin Percival :
>> Doing freebsd-update builds, I've now had two instances where
>> /usr/bin/svnlite
>> has built inexplicably differently -- changes scattered all over the binary.
>
>
ular panic occurs if
an errata notice is being considered
as well as other yet-to-be-imagined reports of a similarly aggregate and
anonymized nature.
So please install the sysutils/panicmail port and enable it in rc.conf! This
all depends on getting useful data, and I can't do that wit
On 11/04/13 02:47, Bob Bishop wrote:
> On 4 Nov 2013, at 10:41, Colin Percival wrote:
>> After considerable review on freebsd-hackers (thanks dt71 and jilles!) I have
>> now added sysutils/panicmail to the FreeBSD ports tree. [etc]
>
> Nice. Is this applicable to all sup
On 11/04/13 10:49, d...@gmx.com wrote:
> Colin Percival wrote, On 11/04/2013 11:41:
>> After considerable review on freebsd-hackers (thanks dt71 and jilles!) I have
>> now added sysutils/panicmail to the FreeBSD ports tree.
>
> The pkesh script is probably still in need of
what I get from kgdb 'bt'. If I find
that I'm missing something important, I can always add it to a new version of
the panicmail port. ;-)
> I can share with you offline the crash server code, it's django and relatively
> straight forward.
I'll come back to you abo
reeBSD on my
> hardware.
Go right ahead. It's a small shell script -- might even work fine without
any changes. It's BSD licensed, of course.
--
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the tr
d what with patched
> trees and random kernel configs.
Right, I'm sure there will be panics I can't match up against anything else --
but this is fine. If I get enough panic reports, I can still get useful data
out even if some of them aren't immediately usable.
--
Colin Percival
mages reboot faster after a panic (not that it happens
very often, of course) -- there's no point waiting for a key press at the
console because the EC2 console is output-only.
Any objections?
--
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.t
patches available is
typically at least 10x the number being fetched this doesn't seem like it
would be very efficient.
FWIW, the performance problems with proxies are limited to HTTP proxies
which don't speak HTTP/1.1.
--
Colin Percival
Security Officer Emeritus,
On 01/29/14 14:26, Adrian Chadd wrote:
> On 29 January 2014 13:51, Colin Percival wrote:
>> FWIW, the performance problems with proxies are limited to HTTP proxies
>> which don't speak HTTP/1.1.
>
> Did you / others ever actually benchmark this?
The fact that perf
Hi all,
A HEAD@254238 kernel fails to boot in EC2 with
> panic: UMA: Increase vm.boot_pages
on 32-CPU instances. Instances with up to 16 CPUs boot fine.
I know there has been some mucking about with VM recently -- anyone want
to claim this, or should I start doing a binary search?
--
Co
in = %d\n", drain); would be sufficient.
And yes, only emitting this warning once per device (or once per boot?)
would probably be good.
--
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
d now:
commit 5ad8c32c722b58da4c153f241201af51b11f3152
Author: Colin Percival
AuthorDate: 2022-10-28 04:42:44 +
Commit: Colin Percival
CommitDate: 2022-10-28 19:20:28 +
ns8250: Fix sense of LSR_TEMT FCR check
When flushing the UART, we need to drain manually if LSR_TE
I think the current situation should be sorted out aside from potential issues
for people who upgraded to a "broken" version before updating to the latest
code -- CCing bapt and tijl just in case since they're more familiar with this
than I am.
Colin Percival
On 3/16/23 15:5
cease to be published on 15.x (but
remain on older branches).
In short: If you have code which fetches any of those images, you'll want to
use the new URLs which specify the filesystem type explicitly.
--
Colin Percival
FreeBSD Release Engineering Lead & EC2 platform maintainer
Founder
is change.
Any objections?
--
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/l
On 10/25/17 15:56, O'Connor, Daniel wrote:
>> On 26 Oct 2017, at 08:13, Colin Percival wrote:
>> [Proposal for removing hpt* drivers since hpt27xx and hptnr take a long
>> time to in DEVICE_PROBE.]
>
> Seems sensible to me, but also worth contacting the blob authors
ek, since I'm planning on writing
a paper to submit to AsiaBSDCon (which has a deadline of December 31st); so
if anyone has interest/time to look at this in the near future (I mean, it's
not like anyone is going to be busy this weekend, right?) I'd love to have
some feedback before i
On 12/22/17 09:08, Mark Johnston wrote:
> On Fri, Dec 22, 2017 at 09:44:46AM +0000, Colin Percival wrote:
>> For the past few months I've been working on code for profiling the FreeBSD
>> "kernel boot", i.e., everything between when kernel code starts running and
>
ry about userland programs
defining _KERNEL and then including kernel headers... I think I know how to
fix this, just testing now.
Thanks,
--
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
__
On 12/31/17 12:17, Colin Percival wrote:
> Oops! It never occurred to me that I had to worry about userland programs
> defining _KERNEL and then including kernel headers... I think I know how to
> fix this, just testing now.
Should be fixed now.
--
Colin Percival
Security Officer
he new location. Where is it?
I think the freebsd-update build code might be homeless right now. I know I
have seen emails mentioning that it needs to land somewhere but I don't recall
any decision being reached.
--
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder
along to the
Foundation people who are managing this project).
--
Colin Percival
FreeBSD Release Engineering Lead & EC2 platform maintainer
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
50 matches
Mail list logo
