On 8 Oct 2013, at 10:41, Julian H. Stacey wrote:
> I too am seeing
> urtwn0: timeout waiting for checksum report
Sorry, this is a know problem that I haven't been able to figure out... It
probably exists in the OpenBSD driver as well. Usually retrying works.
--
Rui Paulo
_
On Sun, Oct 13, 2013 at 5:47 PM, Julian Elischer wrote:
> On 10/12/13 10:28 AM, David Wolfskill wrote:
>
>> On Sat, Oct 12, 2013 at 02:14:28AM +, Thomas Mueller wrote:
>>
>>> ...
>>> Thanks for info!
>>>
>> Glad to help.
>>
>> I saw that bind was removed from the current branch because of se
Hi,
At $JOB, we have machines with 400GB RAM that even the smallest
15GB amd64 minidump takes well over an hour. The major cause of
the slowness is that in minidumpsys(), blk_write() is called
PAGE_SIZE at a time. This causes blk_write() to poll the console
for the Ctrl-C abort once per page.
The
Hi, Reference:
> From: "Julian H. Stacey"
> Date: Mon, 14 Oct 2013 08:33:35 +0200
"Julian H. Stacey" wrote:
> Anyone else seeing vi dropping out after a while with "Bus error" & no core ?
>
> Seen on 10.0-ALPHA4 & now on 10.0-ALPHA5
> (after buildkernel installkernel buildworl
On 2013-10-15 19:07, Glen Barber wrote:
> On Tue, Oct 15, 2013 at 05:49:06PM -0500, James R. Van Artsdalen wrote:
>> BLACKIE:/root# uname -a
>> FreeBSD BLACKIE.housenet.jrv 10.0-BETA1 FreeBSD 10.0-BETA1 #0 r256428M:
>> Sun Oct 13 23:46:54 CDT 2013
>> r...@clank.housenet.jrv:/usr/obj/usr/src/sys
On Tue, Oct 15, 2013 at 07:07:47PM -0400, Glen Barber wrote:
> > Based on the hardware config that's either ada0p3 or ada1p3. Whichever
> > it is I want to mirror it onto the other but I don't the names to use
> > for src and dst.
>
> You can set kern.geom.label.gptid.enable=0 in loader.conf(5),
On Tue, Oct 15, 2013 at 05:49:06PM -0500, James R. Van Artsdalen wrote:
> BLACKIE:/root# uname -a
> FreeBSD BLACKIE.housenet.jrv 10.0-BETA1 FreeBSD 10.0-BETA1 #0 r256428M:
> Sun Oct 13 23:46:54 CDT 2013
> r...@clank.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64
>
> This pool is on da{0,1,2,
BLACKIE:/root# uname -a
FreeBSD BLACKIE.housenet.jrv 10.0-BETA1 FreeBSD 10.0-BETA1 #0 r256428M:
Sun Oct 13 23:46:54 CDT 2013
r...@clank.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64
This pool is on da{0,1,2,3,4,5,6,7} - I think, only da4 is sure
NAME
On Monday, October 14, 2013 4:44:28 am Anton Shterenlikht wrote:
>
> BTW, I see in dmesg:
>
> Starting ddb.
> ddb: sysctl: debug.ddb.scripting.scripts: Invalid argument
> /etc/rc: WARNING: failed to start ddb
>
> What is that about?
>
>
> panic: uma_zfree: Freeing to non free bucket index.
> c
On 10/15/13 13:09, Matthew Fleming wrote:
> We use something like this at work. However, our version creates a file after
> the firstboot scripts have run, and doesn't run if the file exists.
>
> Is there a reason to prefer one choice over the other? Naively I'd expect it
> to
> be better to ru
On 10/15/13 01:58, Nick Hibma wrote:
>> Indeed... the way my patch currently does things, it looks for the
>> firstboot sentinel at the start of /etc/rc, which means it *has* to
>> be on /. Making the path an rcvar is a good idea (updated patch
>> attached) but we still need some way to re-probe f
On Sun, Oct 13, 2013 at 3:58 PM, Colin Percival wrote:
> Hi all,
>
> I've attached a very simple patch which makes /etc/rc:
>
> 1. Skip any rc.d scripts with the "firstboot" keyword if /var/db/firstboot
> does not exist,
>
> 2. If /var/db/firstboot and /var/db/firstboot-reboot exist after running
On 2013-10-15 15:33, Tim Kientzle wrote:
> Wonderful! This capability is long overdue.
>
> On Oct 13, 2013, at 3:58 PM, Colin Percival wrote:
>> As examples of what such scripts could do:
> More examples:
>
> I've been experimenting with putting "gpart resize" and "growfs"
> into rc.d scripts to
Wonderful! This capability is long overdue.
On Oct 13, 2013, at 3:58 PM, Colin Percival wrote:
> As examples of what such scripts could do:
More examples:
I've been experimenting with putting "gpart resize" and "growfs"
into rc.d scripts to construct images that can be dd'ed onto some medium
a
On Fri, Oct 11, 2013 at 5:14 PM, John-Mark Gurney wrote:
> Maksim Yevmenkin wrote this message on Fri, Oct 11, 2013 at 15:39 -0700:
>> > On Oct 11, 2013, at 2:52 PM, John-Mark Gurney wrote:
>> >
>> > Maksim Yevmenkin wrote this message on Fri, Oct 11, 2013 at 11:17 -0700:
>> >> i would like to su
On Tue, Oct 15, 2013 at 04:10:04PM +0100, Anton Shterenlikht wrote:
> This panic is always reproducible by
> starting nginx, and directing the browser
> to poudriere logs/bulk/ia64-default/latest/.
From ddb, do 'show pginfo '.
pgpKqixxtbb2b.pgp
Description: PGP signature
On Tue, Oct 15, 2013 at 09:52:44AM +0400, Sevan / Venture37 wrote:
> Hi,
> I noticed that back in April changes had been commited to allow ccache
> to build -HEAD world so give it a try again on r256380.
> The build process now fails at building libc.so.7 with error
> /usr/bin/ld: this linker was n
On Tue, Oct 15, 2013 at 4:17 PM, Anton Shterenlikht wrote:
> I'm trying to set up textdump(4).
>
> On boot I see:
>
> WITNESS: unable to allocate a new witness object
>
> also
It means that you run out of WITNESS object on the free list.
>
> Expensive timeout(9) function: 0x9ffc00e222e0(0xa0
I'm trying to set up textdump(4).
On boot I see:
WITNESS: unable to allocate a new witness object
also
Expensive timeout(9) function: 0x9ffc00e222e0(0xa09ed320)
0.002434387 s
kickstart.
Does the first indicate I haven't set up
WITNESS correctly?
What does the second tell me?
Th
[:~]# zfs-stats -a
ZFS Subsystem ReportTue Oct 15 16:48:43 2013
System Information:
Kernel Version:
On 2013-10-15 07:53, Dmitriy Makarov wrote:
> Please, any idea, thougth, help!
> Maybe what information can be useful for diggin - anything...
>
> System what I'm talkin about has a huge problem: performance degradation in
> short time period (day-two). Don't know can we somehow relate this vmsta
Fabian Keil wrote:
> After the iconv import claws-mail started to deadlock in iconv every now
> and then on my system, which prevented claws-mail from rendering windows
> or reacting to input.
[...]
> Did anyone else run into this or can comment on the patch or
> the backtraces?
Thanks for the
>From davide.itali...@gmail.com Tue Oct 15 11:30:07 2013
>
>On Tue, Oct 15, 2013 at 10:43 AM, Anton Shterenlikht wrote:
>
>> Anyway, savecore eventually deadlocks:
>>
>> panic: deadlkres: possible deadlock detected for 0xe000127b7b00, blocked
>> for 901401 ticks
>>
>
>[trim]
>
>>
>> Tracing c
Please, any idea, thougth, help!
Maybe what information can be useful for diggin - anything...
System what I'm talkin about has a huge problem: performance degradation in
short time period (day-two). Don't know can we somehow relate this vmstat fails
with degradation.
> Hi all
>
> On CURRE
On Tue, Oct 15, 2013 at 10:43 AM, Anton Shterenlikht wrote:
> Anyway, savecore eventually deadlocks:
>
> panic: deadlkres: possible deadlock detected for 0xe000127b7b00, blocked
> for 901401 ticks
>
[trim]
>
> Tracing command savecore pid 805 tid 100079 td 0xe000127b7b00
> cpu_switch(0
>>> 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 are
>>> diskless...
>>
>> The embedded systems we create at $work have readonly root and mf
>From davide.itali...@gmail.com Mon Oct 14 12:50:44 2013
>
>This is fair enough -- If you're still at the ddb prompt, please print
>the whole panic message (or at least the address of the lock reported
>as deadlocked by DEADLKRES), so that we can at least have a candidate.
>
Here's another one, fo
>From davide.itali...@gmail.com Fri Oct 11 15:39:49 2013
>
>If you're not able to get a full dump, a textdump would be enough.
>In your DDB scripts just remove the 'call doadump' step and you should
>be done, unless I'm missing something.
>Please adjust the script as well to include all the informa
28 matches
Mail list logo
