+1.
On 28 September 2013 06:56, Ian Lepore wrote:
> On Sat, 2013-09-28 at 20:37 +1000, Peter Jeremy wrote:
> > I have a system with 4GB RAM and hence need to use an amd64 kernel to use
> > all the RAM (I can only access 3GB RAM with an i386 kernel). OTOH, amd64
> > proces
On Sat, 28 Sep 2013, Peter Jeremy wrote:
I have a system with 4GB RAM and hence need to use an amd64 kernel to use
all the RAM (I can only access 3GB RAM with an i386 kernel). OTOH, amd64
processes are significantly (50-100%) larger than equivalent i386 processes
and none none of the
On Sat, Sep 28, 2013 at 01:25:39PM +0200, Dimitry Andric wrote:
> On Sep 28, 2013, at 12:37, Peter Jeremy wrote:
> > I have a system with 4GB RAM and hence need to use an amd64 kernel to use
> > all the RAM (I can only access 3GB RAM with an i386 kernel). OTOH, amd64
&g
On Sat, 2013-09-28 at 20:37 +1000, Peter Jeremy wrote:
> I have a system with 4GB RAM and hence need to use an amd64 kernel to use
> all the RAM (I can only access 3GB RAM with an i386 kernel). OTOH, amd64
> processes are significantly (50-100%) larger than equivalent i386 processes
&
On Sep 28, 2013, at 12:37, Peter Jeremy wrote:
> I have a system with 4GB RAM and hence need to use an amd64 kernel to use
> all the RAM (I can only access 3GB RAM with an i386 kernel). OTOH, amd64
> processes are significantly (50-100%) larger than equivalent i386 processes
> and
I have a system with 4GB RAM and hence need to use an amd64 kernel to use
all the RAM (I can only access 3GB RAM with an i386 kernel). OTOH, amd64
processes are significantly (50-100%) larger than equivalent i386 processes
and none none of the applications I'll be running on the system need
I am trying to debug kernel in one VBox VM from another VBox VM using
this howto:
http://census-labs.com/news/2009/01/19/freebsd-kernel-debugging with the
exception that on the target VM hint.uart.0.flags="0x90" is set instead.
It works, stops at breakpoints, etc. However, kgdb
I have kernel configured with options KDB and DDB.
But when kernel panic occurs while running as VBox VM, VBox takes over
and says: "A critical error occurred while running the virtual machine",
etc. It doesn't drop into DDB. Pressing Ok closes VM, pressing "Ignore"
At 2500 Hz, the tick rate increases by 1 Hz per cycle. There was mention of
a patch that would allow the rate to be as high as 40k without this effect.
--I'll post the link as soon as I find the mailing list thread--
Will this patch work with the current available releases?
On Friday, July 19, 2013 10:16:15 pm Yuri wrote:
> On 07/19/2013 14:04, John Baldwin wrote:
> > Hmm, that definitely looks like garbage. How are you with gdb scripting?
> > You could write a script that walks the PQ_ACTIVE queue and see if this
> > pointers ends up in there. It would then be inte
On 07/19/2013 14:04, John Baldwin wrote:
Hmm, that definitely looks like garbage. How are you with gdb scripting?
You could write a script that walks the PQ_ACTIVE queue and see if this
pointers ends up in there. It would then be interesting to see if the
previous page's next pointer is corrupt
On Friday, July 19, 2013 3:32:43 pm Yuri wrote:
> On 07/19/2013 08:00, John Baldwin wrote:
> > Well, you can probably find the value of 'm' in a register if you look at
the
> > dissassembly around the fault. You can then cast that pointer to the
right
> > type and print its contents.
>
> Here i
On 07/19/2013 08:00, John Baldwin wrote:
Well, you can probably find the value of 'm' in a register if you look at the
dissassembly around the fault. You can then cast that pointer to the right
type and print its contents.
Here is the value of *m in frame 8:
(kgdb) p *(struct vm_page*)0xfe
On Thursday, July 18, 2013 8:56:58 pm Yuri wrote:
> On 07/18/2013 13:52, John Baldwin wrote:
> > Are you in frame 8?
>
> For some reason the debug info is missing in frame 8, but is present in
> surrounding frames 7 and 9.
> The might be a bug in makefiles that debug flag isn't passed into
> sys
On 07/18/2013 13:52, John Baldwin wrote:
Are you in frame 8?
For some reason the debug info is missing in frame 8, but is present in
surrounding frames 7 and 9.
The might be a bug in makefiles that debug flag isn't passed into
sys/vm/ directory.
Yuri
On 07/18/2013 13:52, John Baldwin wrote:
Are you in frame 8?
Yes.
Yuri
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
page is allocated during suspend but isn't freed appropriately?
>
> Unfortunately, I get this:
> (kgdb) p *m
> No symbol "m" in current context.
>
> even though kernel was built with "makeoptions DEBUG=-g", same for
> other symbols there.
>
&
y, I get this:
(kgdb) p *m
No symbol "m" in current context.
even though kernel was built with "makeoptions DEBUG=-g", same for
other symbols there.
Is there a way to identify when and by whom the page has been allocated?
Yuri
___
On Thursday, July 18, 2013 2:15:48 pm Yuri wrote:
> On 07/16/2013 08:07, John Baldwin wrote:
> > Can you go to frame 8 and do 'l' in kgdb?
>
> (kgdb) up 8
> #8 0x80baea78 in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:829
> 829 if (!VM_OBJECT_TRYLOCK(object) &&
> (kg
On 07/16/2013 08:07, John Baldwin wrote:
Can you go to frame 8 and do 'l' in kgdb?
(kgdb) up 8
#8 0x80baea78 in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:829
829 if (!VM_OBJECT_TRYLOCK(object) &&
(kgdb) l
824 if (!vm_pageout_page_lock(m, &nex
!= MTX_DESTROYED,
> 299 ("mtx_trylock() of destroyed mutex @ %s:%d", file,
> line));
>
> Current thread was:
> * 67 Thread 100064 (PID=5: pagedaemon) doadump (textdump= optimized out>) at pcpu.h:234
>
> How to find the cause of the crash?
>
&
On 07/15/2013 00:22, Yuri wrote:
How to find the cause of the crash?
I added WITNESS and related options and next crash produced such messages:
Jul 15 03:25:53 satellite kernel: panic: Bad link elm 0xfe00b780d000
next->prev != elm
Jul 15 03:25:53 satellite kernel: cpuid = 1
Jul 15 03
(PID=5: pagedaemon) doadump (textdump=optimized out>) at pcpu.h:234
How to find the cause of the crash?
Yuri
--- kgdb log ---
# kgdb /boot/kernel/kernel vmcore.0
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, a
at it allocates mbufs in the packet sending
path, and so relies on a number of kernel subsystems to be in a
consistent state. It doesn't use the stack, routing table, or driver
interrupt interfaces though. It could likely be made committable with
a relatively small effort to switch to preallocati
he packet sending
path, and so relies on a number of kernel subsystems to be in a
consistent state. It doesn't use the stack, routing table, or driver
interrupt interfaces though. It could likely be made committable with
a relatively small effort to switch to preallocating an mbuf+cluster
or two
On Jul 11, 2013, at 2:05 PM, Artem Belevich wrote:
> It would probably work for most of the crashes, but will not work in few
> interesting classes of failure. Using in-kernel stack implicitly assumes
> that your memory allocator still works as both the stack and the interface
>
On Jul 11, 2013, at 4:05 PM, Artem Belevich wrote:
>
> It would probably work for most of the crashes, but will not work in few
> interesting classes of failure. Using in-kernel stack implicitly assumes that
> your memory allocator still works as both the stack and the inte
ts on my part to change that).
>
>
It would probably work for most of the crashes, but will not work in few
interesting classes of failure. Using in-kernel stack implicitly assumes
that your memory allocator still works as both the stack and the interface
driver will need to get their mbufs
On Jul 11, 2013, at 7:27 AM, Julian Elischer wrote:
> I could imagine that we could stash away a vimage stack just for this purpose.
> yould set it up on boot and leave it detached until you need it.
>
> you just need to switch the interfaces over to the new stack on panic and put
> them into
> Speaking of Apple solutions, I've recently used Apple's kgdb with the
> kernel debug kit & kdp remote debugging, to debug a panic'd OS X host.
> It's really quite nice, because the debug kit comes with a ton of
> macros, similar to kdb, and you also get t
On 7/11/13 6:09 AM, Kevin Day wrote:
Those sound useful. Just out of curiosity, however, since we're on the topic
of kernel dumps: Has anyone even looked into the notion of an emergency
fall-back network stack to enable remote kernel panic (or system hang)
debugging, the way OS X let
eful. Just out of curiosity, however, since we're on
> > the topic of kernel dumps: Has anyone even looked into the notion
> > of an emergency fall-back network stack to enable remote kernel
> > panic (or system hang) debugging, the way OS X lets you do? I can't
> >
On 10/07/2013 23:09, Kevin Day wrote:
>>
>> Those sound useful. Just out of curiosity, however, since we're on the
>> topic of kernel dumps: Has anyone even looked into the notion of an
>> emergency fall-back network stack to enable remote kernel panic (or system
remote console for the usual
console IO & ddb, or to run remote gdb. Quite insecure but
that didn't matter as this was used in a test network. There
was no emegerency network stack; just a polling function added
to an ethernet driver since this had to work even when the
kernel was on
definitely the target to go for.
>
> Looking at http://www.opensource.apple.com/tarballs/xnu/xnu-2050.22.13.tar.gz
> there's even reasonable "documentation" on the kernel debugging protocol in
> xnu/osfmk/kdp. Folks could do worse than try to clone it. The gdb debugger
&
>
>
> Those sound useful. Just out of curiosity, however, since we're on the
> topic of kernel dumps: Has anyone even looked into the notion of an
> emergency fall-back network stack to enable remote kernel panic (or system
> hang) debugging, the way OS X lets yo
On Wed, Jul 10, 2013 at 12:57 PM, Jordan Hubbard
wrote:
>
> On Jul 10, 2013, at 11:16 AM, Julian Elischer wrote:
>
>> My first candidates are:
>
> Those sound useful. Just out of curiosity, however, since we're on the
> topic of kernel dumps: Has anyone even
ess that if anyone is
thinking of putting any time and attention into this area at all, that's
definitely the target to go for.
Looking at http://www.opensource.apple.com/tarballs/xnu/xnu-2050.22.13.tar.gz
there's even reasonable "documentation" on the kernel debugging protocol
On Jul 10, 2013, at 11:16 AM, Julian Elischer wrote:
> My first candidates are:
Those sound useful. Just out of curiosity, however, since we're on the topic
of kernel dumps: Has anyone even looked into the notion of an emergency
fall-back network stack to enable remote kernel p
really nobody use geli.
tried today - still geli crash system within a minute.
On Fri, 21 Jun 2013, Wojciech Puchar wrote:
after getting yesterday new kernel, upgrading everything (including userland,
all in sync) my geli encrypted partition starts to randomly produce
read/write errors
after getting yesterday new kernel, upgrading everything (including
userland, all in sync) my geli encrypted partition starts to randomly
produce read/write errors (error number 11) or just random reboots.
going back to kernel compiled from 6 day older sources fixes everything.
evidently a
for certain
advanced features will be tackled. Both the RX and the TX side are
part of this project.
--
Andre
-Original Message-
From: Andriy Gapon [mailto:a...@freebsd.org]
Sent: Monday, May 27, 2013 03:18 PM
To: Orit Moskovich
Cc: Konstantin Belousov; freebsd-hackers@freebsd.org
Subject: R
[trimmed cc]
on 27/05/2013 15:29 Orit Moskovich said the following:
>>From what I've read in subr_taskqueue.c taskqueue_swi, taskqueue_swi_giant
>>and taskqueue_fast are all implemented using swi_add which calls
>>ithread_create().
> Is there any performance difference between them. Is one of t
n the other?
-Original Message-
From: Andriy Gapon [mailto:a...@freebsd.org]
Sent: Monday, May 27, 2013 03:18 PM
To: Orit Moskovich
Cc: Konstantin Belousov; freebsd-hackers@freebsd.org
Subject: Re: preemptive kernel
on 27/05/2013 10:21 Orit Moskovich said the following:
> What is actually
described earlier.
> -Original Message-
> From: Andriy Gapon [mailto:a...@freebsd.org]
> Sent: Monday, May 27, 2013 10:11 AM
> To: Konstantin Belousov
> Cc: Orit Moskovich; freebsd-hackers@freebsd.org
> Subject: Re: preemptive kernel
>
> on 27/05/2013 09:34 Konstant
From: Andriy Gapon [mailto:a...@freebsd.org]
Sent: Monday, May 27, 2013 10:11 AM
To: Konstantin Belousov
Cc: Orit Moskovich; freebsd-hackers@freebsd.org
Subject: Re: preemptive kernel
on 27/05/2013 09:34 Konstantin Belousov said the following:
> Having both filter and ithread for the same inte
on 27/05/2013 09:34 Konstantin Belousov said the following:
> Having both filter and ithread for the same interrupt is apparently
> possible but weird. I do not see anything which would prevent interrupt
> filter from being executed while the ithread is running. But again, this
> is very unusual
;
> -Original Message-
> From: Konstantin Belousov [mailto:kostik...@gmail.com]
> Sent: Sunday, May 26, 2013 06:48 PM
> To: Orit Moskovich
> Cc: freebsd-hackers@freebsd.org
> Subject: Re: preemptive kernel
>
> On Sun, May 26, 2013 at 11:09:03AM +, Orit Moskovich wrot
d.org
Subject: Re: preemptive kernel
On Sun, May 26, 2013 at 11:09:03AM +, Orit Moskovich wrote:
> Can a filter routine preempt another filter routine? And can an interrupt
> thread (or a filter routine) preempt another ithread?
Filter handler borrows the context from the thread executed
On Sun, May 26, 2013 at 11:09:03AM +, Orit Moskovich wrote:
> Can a filter routine preempt another filter routine? And can an interrupt
> thread (or a filter routine) preempt another ithread?
Filter handler borrows the context from the thread executed at the
time of the interrupt. At least o
Can a filter routine preempt another filter routine? And can an interrupt
thread (or a filter routine) preempt another ithread?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send an
Am 10.04.2013 15:27, schrieb Matthew Jacob:
On 4/9/2013 11:53 PM, Daniel Braniss wrote:
this host can run x11 apps! so 'Huge' is a relative matter, my first
PDP11/45 has 64K :-) danny
Bah. Real old farts ran munix on a 32k PDP 11/03- shell and apps in
the low 16k and the kernel in
On 2013-Apr-09 11:05:56 -0700, Freddie Cash wrote:
>You have to look at the in-memory sizes, not the on-disk sizes.
Or, even better, look at the difference between installed physical RAM
and how much RAM is available to userland processes.
--
Peter Jeremy
pgpOHqKqYTU0M.pgp
Description: PGP si
On 10 April 2013 13:06, Joshua Isom wrote:
>
> I upgraded my system with 32Gb for a reason.
Yes, yes you did.
TO force me to fix ath(4) and busdma. ;-)
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/fre
On 4/10/2013 9:43 AM, Jonathan Anderson wrote:
The last I heard, LTO on the kernel required something like 16 GB of RAM and
produced a not-quite-working image.
Jon
I upgraded my system with 32Gb for a reason.
___
freebsd-hackers@freebsd.org
g/~brooks/patches/xcc3.diff
BD> If you set XCC=/path/to/clang XCXX=/path/to/clang++ XCPP=clang-cpp then
BD> when building world and kernel you will use those compilers and not
BD> build a cross compiler. In that mode you will still build and use a
BD> cross binutils
BTW, building binuti
ooks/patches/xcc3.diff
BD> If you set XCC=/path/to/clang XCXX=/path/to/clang++ XCPP=clang-cpp then
BD> when building world and kernel you will use those compilers and not
BD> build a cross compiler. In that mode you will still build and use a
BD> cross binutils
I've checked thi
On Tuesday, 9 April 2013 at 22:18, Joshua Isom wrote:
> Would clang's LTO help for size? I know work's starting on the bsd
> elftools ld, but I doubt it has any LTO support yet. Running -Os on the
> kernel as a whole instead of object files could probably help a lot
> also.
key is to pass the --sysroot option to the compiler. I've got a not
quite finished (mostly due to a complete lack of documentation) set of
patches to Makefile.inc1 to do this:
http://people.freebsd.org/~brooks/patches/xcc3.diff
If you set XCC=/path/to/clang XCXX=/path/to/clang++ XCPP=clang
Hello, deeptech71.
You wrote 10 апреля 2013 г., 1:00:10:
d> Lev Serebryakov wrote:
>> Is "system" version (system is snapshot from Mar 30) is "external" and
>> "modern"?
d> Lev Serebryakov wrote:
>>It is very sad, that external compiler cannot be used with "fresh"
>> sources (when headers are
On 4/9/2013 11:53 PM, Daniel Braniss wrote:
this host can run x11 apps! so 'Huge' is a relative matter, my first
PDP11/45 has 64K :-) danny
Bah. Real old farts ran munix on a 32k PDP 11/03- shell and apps in the
low 16k and the kernel in the upper. Or was it the other way around? At
> > happy that FreeBSD is among the selected organization.
> >
> > I am a third year student interested to work in the field of embedded
> > system. I applied last year and the title of my project was " Kernel Size
> why only in embedded system. smaller programs
uld clang's LTO help for size? I know work's starting on the bsd
elftools ld, but I doubt it has any LTO support yet. Running -Os on the
kernel as a whole instead of object files could probably help a lot
also. I might try to set it up and see a size comparision.
Also, what about
Lev Serebryakov wrote:
Is "system" version (system is snapshot from Mar 30) is "external" and "modern"?
No. The base version of Clang has been patched to work well with the base
system, at least regarding the discussed issue of standard header files.
Lev Serebryakov wrote:
It is very sad
27;s included in the build.
You can build a bare-bones kernel and modules, and use that to see how
big things are.
You can group those by subsystem to get an idea of how big each
subsystem is. Whether or not it's loaded is (mostly) irrelevant - if
we compile out USB but then include it as a m
In order to optimize - in this case for size - we need a way to measure
what should we focus on, and it looks like we don't have it yet.
Would it be possible to write a tool - e.g. by instrumenting LLVM - that
would make it possible to calculate, for every function in the call graph,
the amount of
Hello, Kimmo.
You wrote 9 апреля 2013 г., 21:59:37:
KP> Your comparison is far from accurate, include the memory taken by
KP> loaded kernel modules on both systems and then you might get some
KP> proper numbers.
Linux is known to _work_ on SOHO MIPS boxes, with 4MiB of flash and
16M
You have to look at the in-memory sizes, not the on-disk sizes.
Linux kernels are very barebones when it comes to what is compiled directly
into the kernel image on disk. Everything else is loaded from modules at
boot time. Especially if using distro-provided kernels. They even use ram
disks
On Tue, Apr 9, 2013 at 8:53 PM, Wojciech Puchar
wrote:
>>> And yes FreeBSD kernel is huge. doesn't really matter with 1GB or more
>>> RAM but yes - it is huge even relative to linux.
>>
>>
>> Ah, any insight as to why?
>
> my custom compiled kernel
And yes FreeBSD kernel is huge. doesn't really matter with 1GB or more RAM
but yes - it is huge even relative to linux.
Ah, any insight as to why?
my custom compiled kernel:
-r-xr-xr-x 1 root wheel 8791402 6 kwi 22:08 /boot//kernel/kernel
only with features i need. linux is AFAIK l
On 4/9/13 10:36 AM, Wojciech Puchar wrote:
happy that FreeBSD is among the selected organization.
I am a third year student interested to work in the field of embedded
system. I applied last year and the title of my project was " Kernel
Size
why only in embedded system. smaller program
happy that FreeBSD is among the selected organization.
I am a third year student interested to work in the field of embedded
system. I applied last year and the title of my project was " Kernel Size
why only in embedded system. smaller programs are always good :)
And yes FreeBSD kernel is
Hello, deeptech71.
You wrote 9 апреля 2013 г., 3:06:42:
d> There are some issues when building "updated" sources [1]. There
d> was a thread about adding support for an "external" compiler [2],
d> but that yielded a non-working solution [3].
Ok, World build time was reduced from 1:27 to just
On 4/8/13 6:42 PM, Adrian Chadd wrote:
Well, it's relatively easy to experience what it's like.
No it's not. We all have jobs that demand different things from us.
Taking the time to guess at the problem, only to be told "you're doing
it wrong" by someone actually in the position to build t
Hello, deeptech71.
You wrote 9 апреля 2013 г., 3:06:42:
d> 1. Add the following or similar to /etc/make.conf:
d> CC=/full/path/to/clang
d> CPP=/full/path/to/clang-cpp
d> CXX=/full/path/to/clang++
d> Note: make sure clang-cpp or similar exists.
d> 2. Add the following to /etc/src.conf:
d> WITHOUT
tally
> application dependent, so that really can't be done for you.
>
> As for the rest, there isn't any large low hanging fruit that can get culled
> from the kernel easily. The base kernel isn't modular enough to trim out
> individual syscalls or anything, and doing
arge low hanging fruit that can get culled
from the kernel easily. The base kernel isn't modular enough to trim out
individual syscalls or anything, and doing so wouldn't have made a huge dent.
There are a lot of ways FreeBSD could be more embedded friendly (being able
turn on/o
Well, it's relatively easy to experience what it's like.
Reboot your machine with 32mb. Try to do things like bring up network
interfaces. Snark when stupid stuff occurs, like you can't allocate
enough mbufs for the driver RX path _and_ run the ifconfig command to
completion to bring said interfac
On 4/8/13 4:10 PM, Adrian Chadd wrote:
Hi,
Your idea is interesting, but it doesn't fix the underlying problem -
there's just too much code. :(
If you were to API'ify some of the more basic things such as fget,
fdrop, filedesc stuff you could potentially swap out the systems for
simpler (albe
plied last year and the title of my project was " Kernel
> Size Reduction for Embedded System". The link to my last year
> proposal is "
> https://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/amitrawat10/1#c8001";
> But due to some flaws it doesn't
Hi,
Your idea is interesting, but it doesn't fix the underlying problem -
there's just too much code. :(
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "fr
ed last year and the title of my project was " Kernel
> Size Reduction for Embedded System". The link to my last year proposal
> is
> https://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/amitrawat10/1#c8001
> But due to some flaws it doesn't get selected. I
Lev Serebryakov wrote:
Is it possible to build NanoBSD faster? Use system compiler, and don't build
bootstrap compiler at all?
There are some issues when building "updated" sources [1]. There was a thread about
adding support for an "external" compiler [2], but that yielded a non-working solu
GSOC posted the list of selected organization for GSOC 2013 and I am highly
happy that FreeBSD is among the selected organization.
I am a third year student interested to work in the field of embedded
system. I applied last year and the title of my project was " Kernel Size
Reduction for Emb
Hello, Freebsd-hackers.
I need to rebuild world and kernel often for experiments with
NanoBSD, and I want to use clang.
But clang bootstrap is drastically slow. And second clang build is
not any faster.
Whole "buildworld" with lots of parts, like gcc toolchain, games,
exa
Thanks John,
That is helpful.
On Mon, Apr 1, 2013 at 2:33 PM, John Baldwin wrote:
> On Friday, March 22, 2013 4:10:16 pm vasanth rao naik sabavat wrote:
> > Hi Adrian,
> >
> > Just to clarify, is the kernel pre-emption involuntary?
> >
> > Let say I have a ker
On Friday, March 22, 2013 4:10:16 pm vasanth rao naik sabavat wrote:
> Hi Adrian,
>
> Just to clarify, is the kernel pre-emption involuntary?
>
> Let say I have a kernel thread processing a huge list of entries, would
> this thread get involuntarily context switched out
It's because there are kernel structures which kgdb needs to get its
grubby fingers into when decoding things.
I wish things weren't so tightly coupled though..
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.o
On 3/25/2013 2:41 AM, Andriy Gapon wrote:
on 25/03/2013 02:19 Joshua Isom said the following:
I thought the debugger would have worked regardless.
No, kgdb and libkvm have to be in sync with kernel.
Unfortunately.
Is it a bug or necessity
on 25/03/2013 02:19 Joshua Isom said the following:
> I thought the debugger would have worked regardless.
No, kgdb and libkvm have to be in sync with kernel.
Unfortunately.
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
h
So far they've been out of sync. I'd done it once before with a 6 base
and 7 kernel to get some hardware to work. I installed world in a
chroot and kgdb seems to be working fine in the chroot. I thought the
debugger would have worked regardless.
On 3/24/2013 4:49 PM, Adrian C
Hi,
Do you rebuild the world _and_ kernel together, or do you have them out of sync?
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-ha
Backtrace gives me an error. The only backtrace I'm given is from the
kernel message while it's crashing. After it's crashed I'm getting nothing.
[jri:~] root# kgdb -q /boot/kernel/kernel /var/crash/vmcore.30
Reading symbols from /boot/kernel/zfs.ko...Reading symbol
All are the same problem.
> The debugging problem is when I fire up kgdb, I have to backtrace even
> though the kernel message buffer contains a back trace. If I try to set the
> frame with "frame 0xff8020bddb30" I get an error "Cannot access memory
> at address 0x0".
I have several core dumps that need debugged. All are the same problem.
The debugging problem is when I fire up kgdb, I have to backtrace even
though the kernel message buffer contains a back trace. If I try to set
the frame with "frame 0xff8020bddb30" I get an error &quo
Hi Adrian,
Just to clarify, is the kernel pre-emption involuntary?
Let say I have a kernel thread processing a huge list of entries, would
this thread get involuntarily context switched out because of kernel
preemption?
What is the time slice after which a kernel thread can involuntarily
Yes.
Adrian
On 22 March 2013 12:09, vasanth rao naik sabavat
wrote:
> Hi,
>
> Is the FreeBSD-10 kernel preemptive?
>
> --
> Thanks,
> Vasanth
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebs
Hi,
Is the FreeBSD-10 kernel preemptive?
--
Thanks,
Vasanth
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
On Fri, 2013-03-15 at 18:21 +0100, Loïc BLOT wrote:
> Hi all,
> I don't know if it's the good list, but hackers for RPI, i think it's a
> good thing :D
>
> I have a little problem with custom kernel with RPI. I have modified
> RPI-B config file to include run/runf
Hi all,
I don't know if it's the good list, but hackers for RPI, i think it's a
good thing :D
I have a little problem with custom kernel with RPI. I have modified
RPI-B config file to include run/runfw driver, compiled the kernel and
install it (make buildkernel KERNCON
1 - 100 of 4806 matches
Mail list logo
