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?
--
Colin
.
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
===
--- etc/rc (revision 256432)
+++ etc/rc (working
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
___
freebsd-current@freebsd.org mailing
On 10/14/13 05:07, Hiroki Sato wrote:
Colin Percival cperc...@freebsd.org 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
cp +fi
At this stage, it is possible
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 marker. And not all embedded systems
booted, and it
would be much simpler to provide just the firstboot functionality.
--
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
___
freebsd-current
the upgrade process.
--
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
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
Index: etc/defaults/rc.conf
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 | www.tarsnap.com
On 10/27/13 14:52, Erik Cederstrand wrote:
Den 27/10/2013 kl. 22.03 skrev Colin Percival cperc...@freebsd.org:
Doing freebsd-update builds, I've now had two instances where
/usr/bin/svnlite
has built inexplicably differently -- changes scattered all over the binary.
Which kind of changes
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 without your help.
--
Colin Percival
Security
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 supported branches?
Yes... the code
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 a big review (S00N(TM
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 about this once I have some data.
--
Colin Percival
Security Officer Emeritus, FreeBSD | The power
. 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 truly paranoid
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org
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
Security Officer Emeritus, FreeBSD | The power to serve
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.tarsnap.com
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 be back to normal now.
--
Colin Percival
Security Officer, FreeBSD | freebsd.org
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 Percival
Security Officer, FreeBSD
that anyone who wants to use more than ~ 3.5 GB of swap space ought
to set kern.maxswzone in /boot/loader.conf.
Is it time to increase this default on amd64? (I understand that keeping the
value low on i386 is important due to KVA limitations, but amd64 has far more
address space available...)
--
Colin
On 08/13/12 14:23, Peter Jeremy wrote:
On 2012-Aug-12 15:44:07 -0700, Colin Percival cperc...@freebsd.org
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 be approximately 9 MiB per GiB
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.tarsnap.com | Online backups for the truly paranoid
___
freebsd-current@freebsd.org mailing
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 | The power
, the performance problems with proxies are limited to HTTP proxies
which don't speak HTTP/1.1.
--
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
On 01/29/14 14:26, Adrian Chadd wrote:
On 29 January 2014 13:51, Colin Percival cperc...@freebsd.org 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 performance sucks when
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@freebsd.org mailing list
http
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, I've had pointed out to me
.
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.
Colin Percival
.
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
___
[EMAIL PROTECTED] mailing list
http
the
performance of a static /bin/sh is only an issue in non-interactive cases.
/Newbie developer question
Colin Percival
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL
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.
Colin Percival
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 times.
Colin Percival
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 sys for building 4.9. I expected
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
___
[EMAIL
, 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
___
freebsd-current
nyone 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-current@fre
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
Found
On 10/25/17 15:56, O'Connor, Daniel wrote:
>> On 26 Oct 2017, at 08:13, Colin Percival <cperc...@tarsnap.com> wrote:
>> [Proposal for removing hpt* drivers since hpt27xx and hptnr take a long
>> time to in DEVICE_PROBE.]
>
> Seems sensible to me, but also wor
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/listinfo/freebsd
er 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.
Thanks,
--
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the
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
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
>&g
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 it goes into the tree.
--
Colin Perciva
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, Tarsnap |
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
:
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_TEMT
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:55, Ma
48 matches
Mail list logo
