pagedaemon.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
run ddb commands when ddb is induced,
but I haven't dug into it yet.
Yep. See ddb(8).
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd
. That is, I now have your older reports from top and zfs-stat and I
have newer vmstat reports. But I do not have all the reports taken at about the
same time, so I don't have a coherent picture of a system state.
--
Andriy Gapon
___
freebsd-stable
on 09/02/2012 10:33 Andriy Gapon said the following:
on 09/02/2012 06:27 Eugene M. Zheganin said the following:
The output I promised (if it's MORE acceptable in the form of a link to a
paste
site, just say it):
I prefer links, but both ways are acceptable to me.
Just one more hint
on 08/02/2012 12:31 Eugene M. Zheganin said the following:
Hi.
On 08.02.2012 02:17, Andriy Gapon wrote:
[output snipped]
Thank you. I don't see anything suspicious/unusual there.
Just case, do you have ZFS dedup enabled by a chance?
I think that examination of vmstat -m and vmstat -z
no problem with users sharing the output and asking for help interpreting
it. I do not know of any easier way to analyze problems like this one.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd
.
suggesions welcome.
Does this really happen when you just sit in the debugger?
Or does it happen when you let the kernel run? Like stepping through the code,
etc
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org
for current needs that
easily.
Yeah, I can tune it down, but I just would like to know what is happening on
an
untuned machine.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
on 07/02/2012 13:34 Eugene M. Zheganin said the following:
Hi.
On 07.02.2012 16:46, Andriy Gapon wrote:
on 07/02/2012 10:36 Eugene M. Zheganin said the following:
If I use the script from http://wiki.freebsd.org/ZFSTuningGuide , it says:
===Cut===
ARC Size
.
BTW, are you reluctant to share the full zfs-stats -a output? You don't have to
place it inline, you can upload it somewhere and provide a link.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd
on 07/02/2012 18:03 Eugene M. Zheganin said the following:
Hi.
On 07.02.2012 21:51, Andriy Gapon wrote:
I am not sure that these conclusions are correct. Wired is wired, it's not
free.
BTW, are you reluctant to share the full zfs-stats -a output? You don't
have to
place it inline
/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail
in situ I would be very grateful.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
, 2012 02:24:46 PM Mark Linimon wrote:
On Fri, Jan 20, 2012 at 07:23:35PM +0200, Andriy Gapon wrote:
I think that it probably could be easier for you and for those reviewing
your kernel config if you 'include'-d GENERIC into your kernel config
and then used device/nodevice, options/nooptions, etc
for my boxes.
I think that it probably could be easier for you and for those reviewing your
kernel config if you 'include'-d GENERIC into your kernel config and then used
device/nodevice, options/nooptions, etc to make your customizations.
Just a thought.
--
Andriy Gapon
IP console). More
strange thing is, when I do a reboot, the server flushes all its disks,
and then does a panic, instead of rebooting.
Please provide output of the following sysctls:
sysctl kern.eventtimer
sysctl kern.timecounter
--
Andriy Gapon
(if you don't have any of them already).
That should add some useful information to the panic messages.
Please try to capture the first panic report before any secondary panics cloud
the
situation.
And I agree with Alexander that the panics and the hangs could be unrelated.
--
Andriy Gapon
on 19/01/2012 21:24 László Károlyi said the following:
On 2012.01.19., at 18:18, Andriy Gapon wrote:
Please provide output of the following sysctls:
sysctl kern.eventtimer
sysctl kern.timecounter
[root@sys ~]# sysctl kern.eventtimer
kern.eventtimer.choice: HPET(450) HPET1(450) HPET2
on 19/01/2012 23:47 László Károlyi said the following:
On 2012.01.19., at 22:36, Andriy Gapon wrote:
on 19/01/2012 23:24 László Károlyi said the following:
On 2012.01.19., at 21:03, Andriy Gapon wrote:
László, can you please try changing kern.timecounter.hardware to TSC-low or
ACPI-fast
the various API/KPI/etc. in the newer branch.
Are you saying that every major branch _has_ to introduce incompatibilities into
a at least one system call?
Otherwise, you are answering a question different from what Volodymyr asked :)
--
Andriy Gapon
there is no COMPAT_FREEBSD8
kernel option in 9? and I think that Volodymyr has tried to answer this part
with another question.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send
release X that are no
longer present in X+1.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http
.
But the overall situation is not as dramatic as you've originally described and
a more gradual approach to updating the ports is possible with enough care. But
this is only for the expert users to attempt :-)
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing
options PRINTF_BUFR_SIZE=256 in your kernel configuration (the
default configs have a value of 128. Do not increase the value too
high, there are concerns about it causing major issues; I can dig up the
post that says that, but I'd rather not).
--
Andriy Gapon
enough load (L = N) there should not be an idle CPU in the system
whatever the topology. Modulo bugs, of course, as always.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe
processes are pinned to their
cpus.
I'd recommended enabling CPU-specific background colors via the menu in
schedgraph for a better illustration of your findings.
NB: I still don't understand the point of purposefully running N+1 CPU-bound
processes.
--
Andriy Gapon
on 22/12/2011 21:47 Steve Kargl said the following:
On Thu, Dec 22, 2011 at 09:01:15PM +0200, Andriy Gapon wrote:
on 22/12/2011 20:45 Steve Kargl said the following:
I've used schedgraph to look at the ktrdump output. A jpg is
available at http://troutmask.apl.washington.edu/~kargl/freebsd
-vm_daddr +
lim_max(td-td_proc, RLIMIT_DATA
addr = round_page((vm_offset_t)vms-vm_daddr +
lim_max(td-td_proc, RLIMIT_DATA));
PROC_UNLOCK(td-td_proc);
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http
33554432 kB
this is HUGE !
Just a guess - this might be some sort of optimization to keep virtual address
range of dynamic allocations untouched by unrelated mmap calls. Not sure if
that's so and how useful could that be.
svn log / svn annotate of the file may reveal more details.
--
Andriy Gapon
on 19/12/2011 19:46 Ivan Klymenko said the following:
В Sat, 17 Dec 2011 23:13:16 +0200
Andriy Gapon a...@freebsd.org пишет:
on 17/12/2011 19:33 George Mitchell said the following:
Summing up for the record, in my original test:
1. It doesn't matter whether X is running or not.
2
always shows up from a syscall, and almost always from syscall 32,
getsockname, but we've also observed it with syscall 5.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
a priority
from the ithread range too - given their role and importance.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr
that the Stefan Esser's post in this thread has likely nailed this one.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr
intended for. I guess I have moral
objections to it. What you're really wanting is Solaris's fmd(1m)
daemon, which I believe is also tied heavily into Solaris's smf(5)
architecture.
http://download.oracle.com/docs/cd/E19963-01/html/821-1462/fmd-1m.html
--
Andriy Gapon
in post-panic environment:
http://people.freebsd.org/~avg/stop_scheduler_on_panic.usb.diff
The patch is the same for both head and stable/8.
It shouldn't hurt if you don't use USB devices or use other USB devices.
--
Andriy Gapon
___
freebsd-stable@freebsd.org
the sched_bind() call at the
start of boot() function in sys/kern/kern_shutdown.c.
For a start you can try adding DDB to your kernel config and capturing a stack
trace of the panic from the ddb prompt.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
processes plus a number of top-level jails. So take this into account when
comparing prison0.pr_uref values - it's better to record the initial value when
no jails are started and it's important to keep the number of non-jailed
processes the same (or to account for its changes).
--
Andriy Gapon
on 20/08/2011 13:02 Andriy Gapon said the following:
on 18/08/2011 02:15 Steven Hartland said the following:
In a nutshell the jail manager we're using will attempt to resurrect the jail
from a dieing state in a few specific scenarios.
Here's an exmaple:-
1. jail restart requested
2. jail
on 20/08/2011 16:35 Hans Petter Selasky said the following:
On Friday 19 August 2011 18:32:13 Andriy Gapon wrote:
on 19/08/2011 00:24 Hans Petter Selasky said the following:
On Thursday 18 August 2011 19:04:10 Andriy Gapon wrote:
If you can help Hans to figure out what you is wrong with USB
on 20/08/2011 18:51 Steven Hartland said the following:
- Original Message - From: Andriy Gapon a...@freebsd.org
BTW, I suspect the following scenario, but I am not able to verify it either
via
testing or in the code:
- last process in a dying jail exits
- pr_uref of the jail
on 20/08/2011 19:54 Hans Petter Selasky said the following:
On Saturday 20 August 2011 18:45:57 Andriy Gapon wrote:
SCHEDULER_STOPPED
The USB code needs to check for the SCHEDULER_STOPPED and cold at the present
moment. If this state can be set during bootup, and cleared at the same time
pr-pr_mtx is re-locked.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
backtrace.
end
define btf
bt $arg0.tf_eip $arg0.tf_ebp
end
document btf
Do a manual backtrace from a specified trapframe.
end
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd
on 19/08/2011 00:24 Hans Petter Selasky said the following:
On Thursday 18 August 2011 19:04:10 Andriy Gapon wrote:
If you can help Hans to figure out what you is wrong with USB subsystem in
this respect that would help us all.
Hi,
usb_busdma.c: /* we use mtx_owned() instead
on 18/08/2011 02:15 Steven Hartland said the following:
- Original Message - From: Andriy Gapon a...@freebsd.org
Thanks to the debug that Steven provided and to the help that I received from
Kostik, I think that now I understand the basic mechanics of this panic, but,
unfortunately
on 18/08/2011 13:35 Steven Hartland said the following:
- Original Message - From: Andriy Gapon a...@freebsd.org
Thats interesting, are you using http as an example or is that something
thats
been gleaned from the debugging of our output? I ask as there's only one
process
running
on 18/08/2011 14:11 Andriy Gapon said the following:
Probably I have mistakenly assumed that the 'prison' in prison_derefer() has
something to do with an actual jail, while it could have been just prison0
where
all non-jailed processes belong.
So, indeed:
(kgdb) p $2-p_ucred-cr_prison
$10
and feedback!
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
on 17/08/2011 23:21 Andriy Gapon said the following:
It seems like everything starts with some kind of a race between terminating
processes in a jail and termination of the jail itself. This is where the
details are very thin so far. What we see is that a process (http) is in
exit(2) syscall
on 16/08/2011 23:43 Steven Hartland said the following:
- Original Message - From: Andriy Gapon a...@freebsd.org
To: Steven Hartland kill...@multiplay.co.uk
Cc: freebsd-stable@FreeBSD.org
Sent: Tuesday, August 16, 2011 9:30 PM
Subject: Re: debugging frequent kernel panics on 8.2
on 17/08/2011 14:12 Andriy Gapon said the following:
A little bit later I will send you another patch that, I hope, will produce
better
diagnostics for this crash (without DDB in kernel).
The patch:
Index: sys/amd64/amd64/trap.c
in your source tree besides those
debugging
patches that I provided to you?
3. do you have any thirdparty/out-of-tree kernel modules?
4. could you please send me your kernel config?
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http
faults on garbage kernel addresses. I
am sure that there could be other clever techniques to catch such garbage
addresses early.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
on 15/08/2011 17:56 Steven Hartland said the following:
(kgdb) x/512a 0xff8d8f357210
[snip]
Can you please also provide the following for this core?
list *vm_map_growstack+93
list *lim_cur+17
list *lim_rlimit+18
Also, it would be interesting to get panic output with DDB option.
--
Andriy
on 14/08/2011 17:43 Steven Hartland said the following:
- Original Message - From: Andriy Gapon a...@freebsd.org
Maybe test it on couple of machines first just in case I overlooked something
essential, although I have a report from another use that the patch didn't
break
anything
on 15/08/2011 13:34 Steven Hartland said the following:
- Original Message - From: Andriy Gapon a...@freebsd.org
I think (not 100% sure) that with DDB in kernel we could get a better
backtrace
here, possibly with pre-dblfault stack frames, because DDB backend is a bit
more
smarter
||
243 (fault_flags VM_FAULT_WIRE_MASK) !=
VM_FAULT_USER_WIRE) {
Interesting... thanks!
Can you please also additionally provide (lengthy) output of x/512a
0xff8d8f356fb0 ?
--
Andriy Gapon
___
freebsd-stable@freebsd.org
on 15/08/2011 15:51 Steven Hartland said the following:
- Original Message - From: Andriy Gapon a...@freebsd.org
on 15/08/2011 13:34 Steven Hartland said the following:
(kgdb) list *0x8053b691
0x8053b691 is in vm_fault (/usr/src/sys/vm/vm_fault.c:239).
234
on 15/08/2011 17:56 Steven Hartland said the following:
- Original Message - From: Andriy Gapon a...@freebsd.org
To: Steven Hartland kill...@multiplay.co.uk
Cc: freebsd-stable@FreeBSD.org
Sent: Monday, August 15, 2011 2:20 PM
Subject: Re: debugging frequent kernel panics on 8.2
merged?
The right way is to get a PR submitted, then chase it up with the
maintainer of that subsystem.
I usually did it in the opposite order.
No need for a PR if a patch is sufficiently trivial and a developer is
sufficiently responsive at the moment.
--
Andriy Gapon
.
)
at /usr/src/sys/kern/sched_ule.c:1852
Previous frame inner to this frame (corrupt stack?)
(kgdb)
Looks like this is just the first thread in the kernel.
Perhaps 'thread apply all bt' could help to find the culprit.
--
Andriy Gapon
___
freebsd-stable
a little more info on console which may indicate
java as the problem.
http://blog.multiplay.co.uk/dropzone/freebsd/panic-java.jpg
I would really appreciate if you could try to reproduce the problem with the
patch
that I sent earlier.
--
Andriy Gapon
on 11/08/2011 19:37 Steven Hartland said the following:
- Original Message - From: Andriy Gapon a...@freebsd.org
I would really appreciate if you could try to reproduce the problem with the
patch
that I sent earlier.
Hi Andriy, what's the risk of this patch causing other issues
on 11/08/2011 20:14 Steven Hartland said the following:
- Original Message - From: Andriy Gapon a...@freebsd.org
I would really appreciate if you could try to reproduce the
problem with the patch that I sent earlier.
Hi Andriy, what's the risk of this patch causing other issues?
I
/stop_scheduler_on_panic.8.x.diff
It might also be a good idea to at least capture a screenshot of whatever
information you get on console when the panic happens.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman
of WITH_CTF=1, so be cautious, plan a way to recover your
system from non-working world.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr
on 03/08/2011 01:46 maestro something said the following:
What do I have to recompile for the patch to be picked up?
make libproc in /usr/src/lib
Correct way is:
$ cd /usr/src/lib/libproc
$ make obj
$ make depend
$ make
$ make install
--
Andriy Gapon
us
here.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
on 03/08/2011 11:42 Andriy Gapon said the following:
on 03/08/2011 03:47 maestro something said the following:
now it seems that the ustack() action on i386 and FreeBSD-9.0BETA1 almost
works.
Almost because dtrace still exits (this time without an error message) The
process for which
with CTF
support. Not sure about yours...
Of course, it's still rather bad that dtrace crashes when it prematurely exits.
But maybe it doesn't crash in the correct environment... I don't know.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http
on 03/08/2011 00:03 Andriy Gapon said the following:
I tried to run dtruss (as you did) and I got this pre-amble before the
assertion:
[some dtrace script body]
: probe description proc:::exit does not match any probes
I guess that in my case I got it because my userland was not compiled
, Andriy Gapon a...@freebsd.org
mailto:a...@freebsd.org wrote:
on 26/07/2011 04:20 maestro something said the following:
Hi,
when using the ustack action on the latest FreeBSD8.2 i386 the kernel
panics.
Here is the information I could gather:
let me
on 30/07/2011 00:27 maestro something said the following:
on 30/07/2011 10:50 Andriy Gapon said the following:
#7 0xc11012d7 in dtrace_panic_trigger () from /boot/kernel/dtrace.ko
Previous frame inner to this frame (corrupt stack?)
(kgdb)
what am I doing wrong and what do I have to do
on 30/07/2011 21:19 maestro something said the following:
On Sat, Jul 30, 2011 at 12:50 AM, Andriy Gapon a...@freebsd.org
mailto:a...@freebsd.org wrote:
on 30/07/2011 00:27 maestro something said the following:
Hi,
trying to do so I don't really find my way around
kernel}/kernel /var/crash/vmcore.0; the debug symbols are
automatically picked up from *.symbols files in the kernel directory.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe
on 30/07/2011 23:03 maestro something said the following:
(kgdb) list *dtrace_probe+0xfd6
No source file for address 0xc10fa6a6.
Are the sources on the same machine?
This is probably the last idea from me.
--
Andriy Gapon
___
freebsd-stable
can not be
dynamically
constructed while _PSS is evaluated and why that would affect any of our code.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail
and
% nc localhost 8080
on another would make the kernel panic
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr
of anyone looking into your request if you
provided a link to the commit or the commit log.
Just saying...
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail
(callout=0xc07388a0 taskqueue_thread_loop,
arg=0xc56ff130, frame=0xc538ed28) at /usr/src/sys/kern/kern_fork.c:861
#26 0xc09a5c24 in fork_trampoline () at
/usr/src/sys/i386/i386/exception.s:275
(kgdb)
--
Andriy Gapon
___
freebsd-stable@freebsd.org
in this crash, based on what Andriy said earlier)
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
on 26/06/2011 08:51 Warner Losh said the following:
On Jun 25, 2011, at 8:49 AM, Andriy Gapon wrote:
Does anybody actually use kern.sync_on_panic tunable/sysctl? If yes, then
in what circumstances do you need it? That is, why any other alternative
doesn't work for you? Like: 1. remounting
3. using su+j, gjournal or a different filesystem altogether
4. using fsck after reboot
It seems to me that syncing filesystems in panic context is an adventure. And
it
may become even more of an adventure if we introduce code that completely stops
scheduler in and after panic.
--
Andriy Gapon
on 04/06/2011 11:22 Andriy Gapon said the following:
commit 458ebd9aca7e91fc6e0825c727c7220ab9f61016
generic_stop_cpus: move timeout detection code from under DIAGNOSTIC
... and also increase it a bit.
IMO it's better to detect and report the (rather serious) condition
on 03/06/2011 18:13 Andriy Gapon said the following:
I wonder if anybody uses kdb_stop_cpus with non-default value.
I would like to go ahead and remove kdb_stop_cpus tunable/sysctl if nobody
objects.
If, yes, I am very interested to learn about your usecase for it.
I think
-- shows TRIM enabled
- reboot
I think that at this step your superblock on disk gets re-written with its copy
in
memory which has never been updated. But not sure.
- Boot into single-user, multi-user, whatever
- tunefs -p /dev/ada0s1a -- shows TRIM disabled
--
Andriy Gapon
on 08/06/2011 19:55 Jeremy Chadwick said the following:
On Wed, Jun 08, 2011 at 07:40:03PM +0300, Andriy Gapon wrote:
on 08/06/2011 19:26 Jeremy Chadwick said the following:
I have the exact same question except not with regards to labels but
toggling TRIM capability on the root filesystem
on 05/06/2011 01:35 Attilio Rao said the following:
2011/6/4 Andriy Gapon a...@freebsd.org:
commit 458ebd9aca7e91fc6e0825c727c7220ab9f61016
generic_stop_cpus: move timeout detection code from under DIAGNOSTIC
... and also increase it a bit.
IMO it's better to detect and report
on 04/06/2011 12:11 Robert N. M. Watson said the following:
On 4 Jun 2011, at 09:22, Andriy Gapon wrote:
commit 458ebd9aca7e91fc6e0825c727c7220ab9f61016
generic_stop_cpus: move timeout detection code from under DIAGNOSTIC
... and also increase it a bit. IMO it's better to detect
on 03/06/2011 20:57 Robert N. M. Watson said the following:
On 3 Jun 2011, at 16:13, Andriy Gapon wrote:
I wonder if anybody uses kdb_stop_cpus with non-default value. If, yes, I
am very interested to learn about your usecase for it.
The issue that prompted the sysctl was non-NMI IPIs
disabled
and is spinning, since the IPI won't be received and the KDB will wait
indefinitely. We probably need to add a timeout, but this is a useful
stopgap in the mean time.
But that was before we started using hard stop in this context (in 2009).
--
Andriy Gapon
on 03/06/2011 18:28 Nathan Whitehorn said the following:
On 06/03/11 10:13, Andriy Gapon wrote:
I wonder if anybody uses kdb_stop_cpus with non-default value.
If, yes, I am very interested to learn about your usecase for it.
I think that the default kdb behavior is the correct one, so
on 27/05/2011 17:16 Arnaud Houdelette said the following:
On Fri, 27 May 2011 14:41:54 +0300, Andriy Gapon wrote:
I am not aware of any plans to implement nextboot for zfs as it would
require at
least some write support for zpool and there is none (for boot code)
at the moment.
Could'nt
a
different (non-bootfs) ZFS dataset:
http://lists.freebsd.org/pipermail/freebsd-fs/2010-July/008976.html
But that still requires access to zfs boot and/or loader command interface.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http
on 25/05/2011 20:13 Patrick Lamaiziere said the following:
Le Tue, 24 May 2011 16:21:08 +0300,
Andriy Gapon a...@freebsd.org a écrit :
Hello,
I am planning on some changes in head and would like to see if people
use the following features:
- machdep.hyperthreading_allowed tunable
of the kernel, so I could analyze it if
someone has got an idea where to look for.)
Backtrace would be a first thing. Information from a frame that called panic
would the next thing.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http
on 24/05/2011 10:26 Joerg Wunsch said the following:
As Andriy Gapon wrote:
panic: wrong offset 4096 for sectorsize 2352
Any ideas why this happens, and how to avoid it?
Backtrace would be a first thing.
OK, here we go (the core has been dumped from within a serial console
BREAK DDB
a private
reply:
- which exactly of the mentioned above features you use
- please make distinction between use of tunables and sysctls
- tell for what you use the feature
- provide overview of your hardware, which scheduler you use and intended
purpose
of the system
Thank you!
--
Andriy Gapon
301 - 400 of 947 matches
Mail list logo
