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 command n (next
Hi All,
I am trying remote kernel debugging in FreeBSD using serial communication. I
got the following link.
http://www.ibm.com/developerworks/aix/library/au-debugfreebsd.html#list1
My problem is my developing and target system does not have DS25 female port.
Anyone have any idea about Remote
On Sat, 17 Jan 2009 17:57:10 PST Kamlesh Patel shilp.ka...@yahoo.com wrote:
Hi All,
I am trying remote kernel debugging in FreeBSD using serial communication. I
got the following link.
http://www.ibm.com/developerworks/aix/library/au-debugfreebsd.html#list1
My problem is my developing
On Sat, 17 Jan 2009 17:57:10 -0800 (PST)
Kamlesh Patel shilp.ka...@yahoo.com wrote:
Hi All,
I am trying remote kernel debugging in FreeBSD using serial
communication. I got the following link.
http://www.ibm.com/developerworks/aix/library/au-debugfreebsd.html#list1
My problem is my
On Saturday, 17 January 2009 at 17:57:10 -0800, Kamlesh Patel wrote:
Hi All,
I am trying remote kernel debugging in FreeBSD using serial
communication. I got the following link.
http://www.ibm.com/developerworks/aix/library/au-debugfreebsd.html#list1
This article is inaccurate in a number
Eugene Grosbein eu...@kuzbass.ru writes:
First, you need to recompile source you change for sure :-)
But you have not rebuild all other files all the time.
You need to add to your /etc/src.conf (or /etc/make.conf for 6.x and earlier):
MODULES_WITH_WORLD=yes
This will skip rebuilding of all
ddb and kgdb are two useful and often indispensable tools for kernel
debugging on FBSD. ddb won't allow you source level debugging, kgdb will,
but you'll need an extra machine.
If the code you are debugging doesn't depend on specific
hardware, one option is to run FreeBSD (with the kernel
.
Could anyone please inform me kernel Debugging tools for FreeBSD OS?
First, you need to recompile source you change for sure :-)
But you have not rebuild all other files all the time.
You need to add to your /etc/src.conf (or /etc/make.conf for 6.x and earlier):
MODULES_WITH_WORLD=yes
This will skip
Hi Friends, Happy New Year,
I am working on Virtual Memory parts of FreeBSD OS. My Problem is, whenever i
modify little code of vmpage.c file i need to build the whole kernel to check
the modification and i even am not able to debug the kernel code.
Could anyone please inform me kernel
anyone please inform me kernel Debugging tools for FreeBSD OS?
Kamlesh
MS CS, CSUS
___
freebsd-questi...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to
freebsd-questions
not able to debug the kernel code.
Could anyone please inform me kernel Debugging tools for FreeBSD OS?
Hi,
ddb and kgdb are two useful and often indispensable tools for kernel
debugging on FBSD. ddb won't allow you source level debugging, kgdb will,
but you'll need an extra machine. Dtrace
08.03.08, 22:45, Yoshihiro Ota [EMAIL PROTECTED]:
Has anyone tried to remote-debugging of a system running on Qemu?
I thought if I could attach kgdb from Qemu host to a guest FreeBSD
running on Qemu, it would be very helpful for many reasons, i.e.
no hardware requirements, avoid fscking all
Hello, folks,
Has anyone tried to remote-debugging of a system running on Qemu?
I thought if I could attach kgdb from Qemu host to a guest FreeBSD
running on Qemu, it would be very helpful for many reasons, i.e.
no hardware requirements, avoid fscking all disks, and so on.
Has anyone ever
On Sat, Mar 08, 2008 at 02:45:05PM -0500, Yoshihiro Ota wrote:
Hello, folks,
Has anyone tried to remote-debugging of a system running on Qemu?
I thought if I could attach kgdb from Qemu host to a guest FreeBSD
running on Qemu, it would be very helpful for many reasons, i.e.
no hardware
On Sat, 8 Mar 2008, Yoshihiro Ota wrote:
Has anyone tried to remote-debugging of a system running on Qemu?
I thought if I could attach kgdb from Qemu host to a guest FreeBSD running
on Qemu, it would be very helpful for many reasons, i.e. no hardware
requirements, avoid fscking all disks,
On Sat, 8 Mar 2008 22:18:32 +0200
Kostik Belousov [EMAIL PROTECTED] wrote:
On Sat, Mar 08, 2008 at 02:45:05PM -0500, Yoshihiro Ota wrote:
Hello, folks,
Has anyone tried to remote-debugging of a system running on Qemu?
I thought if I could attach kgdb from Qemu host to a guest FreeBSD
[Resending to get wider coverage]
All,
While there are ways to work around some of the problems that Greg
describes, the simple fact is that kernel debugging has gone downhill
quite badly in the past year. Much of this decay appears to be due
to the rush to get GDB 6.x imported in time
Hello all,
I want to do some remote kernel debugging using GDB on FreeBSD 5.3.
I connected host and target with a null-modem cable on COM1 and made a debug
kernel with options GDB, options DDB, options KDB and makeoptions
DEBUG=-g and I set the port flags of sio0 to 0x80.
But if I start
Hi,
kernel option GDB_REMOTE_CHAT allowed to share the same serial line
for console and remote gdb.
Looking at the following commit message for src/sys/conf/NOTES, it says
that GDB_REMOTE_CHAT has been removed, but it is not clear to me
how to obain the equivalent of that option. Could somebody
Replying to myself:
On Thu, 19 Aug 2004 Marco Molteni [EMAIL PROTECTED] wrote:
kernel option GDB_REMOTE_CHAT allowed to share the same serial line
for console and remote gdb.
Looking at the following commit message for src/sys/conf/NOTES, it
says that GDB_REMOTE_CHAT has been removed, but
Hi,
I am studying the kernel source of FreeBSD. I like to know the flow of
packets from NIC to different modules of Kernel and then to the
user-level. I studied the code and identified some of the functions through
which the kernel handles network packets. But I want to check from
where
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 18 Aug 2004 15:41, Dennis George wrote:
I am studying the kernel source of FreeBSD. I like to know the flow of
packets from NIC to different modules of Kernel and then to the
user-level. I studied the code and identified some of the
Daniel O'Connor wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 18 Aug 2004 15:41, Dennis George wrote:
I am studying the kernel source of FreeBSD. I like to know the flow of
packets from NIC to different modules of Kernel and then to the
user-level. I studied the code and identified
Hi,
Thanks for quick response...
My Vmware is running on Windows XP machine In this installed two FreeBSD5.2
vritual machines Now can you tell me how do I enable serial communication between
them ?
And can you tell me any funtion which is called after the call to sysinit (after
+void
+_initialize_bsd_kvm (void)
+{
+ bsd_kvm_ops.to_shortname = kvm;
+ bsd_kvm_ops.to_longname = Kernel memory interface;
+ bsd_kvm_ops.to_doc = XXX;
+ bsd_kvm_ops.to_open = bsd_kvm_open;
+ bsd_kvm_ops.to_close = bsd_kvm_close;
+ bsd_kvm_ops.to_fetch_registers = bsd_kvm_fetch_registers;
+
Date: Mon, 17 May 2004 13:04:17 -0700
From: Marcel Moolenaar [EMAIL PROTECTED]
All that's needed is a bit of new code (bsd-kvm.[ch]) and a support
function in the appropriate *-nat.c file; because it is built on top
of kvm(3) this is native-only. I've added a preliminary patch
FreeBSD, NetBSD and OpenBSD all provide the kvm(3) interface for
debugging kernel virtual memory images: kernel crash dumps and live
kernels. All three include support for this interface in the version
of GDB bundled with the OS, but this code was never contributed back.
I've recently
On Mon, May 17, 2004 at 01:32:00PM +0200, Mark Kettenis wrote:
I've recently implemented support for kvm(3)-based debugging that
works for all three BSD's. The interface is fairly simple, just start
GDB on a kernel binary, i.e.
*snip*
All that's needed is a bit of new code (bsd-kvm.[ch])
On Mon, May 17, 2004 at 10:45:39PM +0200, Mark Kettenis wrote:
I cannot prevent you from committing this, but if it doesn't address
the items mentioned above, it may not be used on FreeBSD. Unless I'm
being relieved of gdb duties of course :-)
Let's see. My kvm stuff would still
On Mon, May 17, 2004 at 03:17:03PM -0700, Marcel Moolenaar wrote:
On Mon, May 17, 2004 at 10:45:39PM +0200, Mark Kettenis wrote:
I cannot prevent you from committing this, but if it doesn't address
the items mentioned above, it may not be used on FreeBSD. Unless I'm
being
Hi,
I have a few FreeBSD machines with an RJ-45 serial connector
on the motherboard. I would like to hook these
machines up to a single FreeBSD PC with a multiport serial
card and set it up to do kernel debugging.
Can anyone recommend any multiport serial cards?
Are there any cards with known
Craig Rodrigues wrote:
Hi,
I have a few FreeBSD machines with an RJ-45 serial connector
on the motherboard. I would like to hook these
machines up to a single FreeBSD PC with a multiport serial
card and set it up to do kernel debugging.
Can anyone recommend any multiport serial cards
On Tuesday, 3 February 2004 at 11:55:42 -0800, Julian Elischer wrote:
On Tue, 3 Feb 2004, Sridhar Chellappa wrote:
How do we debug a freeBSD kernel ? Do we have something similar to
KGDB that linux offers ?
there is a whole chapter in the handbook about this..
Unfortunately, it's a little
M. Warner Losh writes:
In message: [EMAIL PROTECTED]
Sridhar Chellappa [EMAIL PROTECTED] writes:
: How do we debug a freeBSD kernel ? Do we have something similar to
: KGDB that linux offers ?
Ironically, we've had kgdb for a number of years longer than Linux.
Actually,
How do we debug a freeBSD kernel ? Do we have something similar to
KGDB that linux offers ?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
On Tue, Feb 03, 2004 at 11:48:06AM -0500, Sridhar Chellappa wrote:
How do we debug a freeBSD kernel ? Do we have something similar to
KGDB that linux offers ?
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html
-- Brooks
--
Any statement of the form X is
On Tue, 3 Feb 2004, Sridhar Chellappa wrote:
How do we debug a freeBSD kernel ? Do we have something similar to
KGDB that linux offers ?
there is a whole chapter in the handbook about this..
(you can read the handbook from teh freebsd website, and it shuold
already be on your system
In message: [EMAIL PROTECTED]
Sridhar Chellappa [EMAIL PROTECTED] writes:
: How do we debug a freeBSD kernel ? Do we have something similar to
: KGDB that linux offers ?
Ironically, we've had kgdb for a number of years longer than Linux.
Actually, it is ironic that linux has a
Hi,
On a Soekris box, is it possible to debug a FreeBSD kernel online using
remote gdb? I already have the 2ed system to build the image for the
soekris anyway, and thus the directory with the sources and symbols.
To debug when the target is a traditional PC, I've followed the
developers
Hi Everybody,
First, thanks to everybody offering tips and help. The good news is that
the problem is solved.
I couldn't wait, so I finally decided to learn a little FreeBSD kernel
debugging. After reading lots of not very comprehensive man pages and
other guides, I got a 4.4 kernel compiled
On Wed, 11 Jun 2003 18:22, Soren Kristensen wrote:
Lesson learned:
Advanced FreeBSD documentation sucks if you're not a kernel hacker, but
remote kernel debugging works great and are actually kinda fun
Procedural things are more likely to be usefully documented in the handbook or
FAQ
Daniel O'Connor wrote:
Serial GDB is very nice.. You can even do firewire debugging, but I guess you
guys can't really use that :)
(Firewire mini-PCI board? 8-)
Someone should port the network debugging from Darwin using
the tiny IP stack from NetBSD.
-- Terry
On Wed, 2003-06-11 at 06:22, Terry Lambert wrote:
Someone should port the network debugging from Darwin using
the tiny IP stack from NetBSD.
Well, there's this:
http://ipgdb.sourceforge.net/
IPGDB is a collection of extensions to GDB and FreeBSD-4.3
to allow two-machine kernel debugging
and FreeBSD-4.3
to allow two-machine kernel debugging over UDP. It behaves
much like two-machine kernel debugging over serial ports.
These extensions can easily be applied to other releases of
FreeBSD. With a little bit of modification, these extension
can be applied to other BSD variants
Hi Everybody,
I've been working like a madman on bringing up a new Geode SC1100 based
embedded board, but are stalled right now, and need help for debugging
with FreeBSD
The hardware basically seems to be working just fine, and I can boot
both MS-DOS and OpenBSD 2.9 from a CompactFlash.
On Sun, Sep 08, 2002 at 09:54:47PM -0700, Tim Gilman wrote:
Sorry about this, Christian; your patches are buried in my
bottomless inbox. It appears real-life has swept me off my
feet. I fully don't expect to come down for a month or so
(getting married in 2 weeks, honeymoon, etc), so please
On Saturday, 7 September 2002 at 10:28:27 +0200, Christian Zander wrote:
On Sat, Sep 07, 2002 at 12:56:12AM -0700, Julian Elischer wrote:
What I found to work well is remote GDB debugging with the UDP
wrapper (ip-gdb), it responds to CTRL-C as expected.
huh? do we have that?
(rushes of to
On Sun, Sep 08, 2002 at 05:54:56PM +0930, Greg 'groggy' Lehey wrote:
Just by coincidence, I heard of this today from Richard Sharpe of
Panasas. It seems that Tim has moved on, which is possibly why you
haven't heard back from him.
I was aware of that, I had been in touch with Tim over
Christian Zander at 9/8/02 (maybe):
On Sun, Sep 08, 2002 at 05:54:56PM +0930, Greg 'groggy' Lehey wrote:
Just by coincidence, I heard of this today from Richard
Sharpe of Panasas. It seems that Tim has moved on,
which is possibly why you haven't heard back from him.
I was aware of that, I had
Panasas, Inc., (http://www.panasas.com) is releasing modifications to
FreeBSD 4.3's gdb stubs to allow UDP-based two machine debugging.
The source for these changes is available on SourceForge:
http://ipgdb.sourceforge.net
A snippet from the docs:
The remote debugger functions much like
The value of network debugging to me is not that I can
avoid buying a serial cable (big deal), it's that I can
do the debugging remotely.
Agreed.
If I'm going to ssh into a local machine and debug from
there, then I can use a serial cable.
The serial cable solution does not scale too well
On Mon, 25 Feb 2002, Bakul Shah wrote:
The value of network debugging to me is not that I can
avoid buying a serial cable (big deal), it's that I can
do the debugging remotely.
Agreed.
If I'm going to ssh into a local machine and debug from
there, then I can use a serial cable.
stack, no? While this is easier
than tcp, it's still expensive in that you have to cooperate with
applications which use IP.
However, such a mechanism (kernel debugging integrated into the
UDP/IP code) could also support things like SNMP directly to the
kernel. Without involving user process
Without TCP, you have to implement your own version of
retry and ack (equivalent to negotiating a window size
of 1), and so you have to redo what's already there.
Would be nice to have a reliable channel but in our
experience not having this was not a big deal. The gdb
serial protocol is
On Sat, 23 Feb 2002, Bakul Shah wrote:
Without TCP, you have to implement your own version of
retry and ack (equivalent to negotiating a window size
of 1), and so you have to redo what's already there.
Would be nice to have a reliable channel but in our
experience not having this was
Julian Elischer wrote:
The other issue with TCP is that you can set up specific
flows in the company firewall, and also permit SSLeay
based tunnel encapsulation from outside via an intermediate
machine. This isn't really required for off-site debugging,
but it gives another
1) Easy to write a very minimal, outside the stack, IP/UDP layer.
One (very nasty) already exists in libstand. There was a very small
TCP/IP stack mentioned on /. the other day; it looked close to ideal for
this application.
--
To announce that there must be no criticism of the president,
Justin C.Walker writes:
On Wednesday, February 20, 2002, at 04:52 PM, Julian Elischer wrote:
yes but we might as well be protocol compatible if possible :-)
If only to re-use what they did in gdb :-)
The Darwin/Mac OS X scheme only deals with IOKit because that's where
the
This is cool.
As people talk about this it seems that more and more of the needed parts
are already available from one source or another..
On Thu, 21 Feb 2002, Michael Smith wrote:
1) Easy to write a very minimal, outside the stack, IP/UDP layer.
One (very nasty) already exists in
Julian Elischer wrote:
On Thu, 21 Feb 2002, Michael Smith wrote:
There was a very small TCP/IP stack mentioned on /. the other day; it
looked close to ideal for this application.
though I think it is probably better to use a UDP transport rther than
TCP it would be worth checking it out
Terry Lambert [EMAIL PROTECTED] wrote:
Julian Elischer wrote:
On Thu, 21 Feb 2002, Michael Smith wrote:
There was a very small TCP/IP stack mentioned on /. the other day; it
looked close to ideal for this application.
though I think it is probably better to use a UDP transport rther
Ok, so now George has so many choices to choose from
that I'm expecting 3 different implementations from him, with no common
components :-)
On Thu, 21 Feb 2002, Benedikt Schmidt wrote:
Terry Lambert [EMAIL PROTECTED] wrote:
Julian Elischer wrote:
On Thu, 21 Feb 2002, Michael Smith wrote:
Benedikt Schmidt wrote:
Look at http://slashdot.org/article.pl?sid=02/01/29/2115210mode=thread.
The TCP/IP stack mentioned in this article can be found at
http://dunkels.com/adam/uip/ and is licensed under the 4-clause BSD
license.
Thank you.
-- Terry
To Unsubscribe: send mail to [EMAIL
The Apple darwin site is:
http://www.opensource.apple.com
I've not looked through the source for this, so you may have to inquire
on the darwin-development mailing list for pointers into the source
repository.
Regards,
Justin
On Thursday, February 21, 2002, at 07:48 AM, Andrew Gallatin
Ok, so now George has so many choices to choose from
that I'm expecting 3 different implementations from him, with no common
components :-)
That's my exact plan, how did you know?
Actually this has all been pretty helpful, and I'll be considering the
options and playing as soon as I get that
George V. Neville-Neil wrote:
Now that Luigi has put in polling support for some ethernet drivers
I was wondering how much work it would be to make the remote kernel debugging
run over the ethernet. I have worked on systems like this before (it's the
reason
I did polling network
support for some ethernet drivers
I was wondering how much work it would be to make the remote kernel debugging
run over the ethernet. I have worked on systems like this before (it's the
reason
I did polling network device drivers in Wind River's VxWorks) but it depends
on a debugging system
On Tue, 19 Feb 2002, Julian Elischer wrote:
Hi George.
There was someone recently that posted that they had some sort of
remote debuging working over an ethernet (or at least that they ALMOST
had it working.). I remember thinking Cool. I have however had good
success with the
the remote kernel debugging
run over the ethernet. I have worked on systems like this before (it's the
reason
I did polling network device drivers in Wind River's VxWorks) but it depends
on a debugging system that has the ability to have its back end swapped out.
Who would I talk
Folks,
Thanks for all the helpful hints. Depending on what I find when I look
at how DDB/GDB work now I will probably do the following:
A) Use UDP/IP as the transport.
Reasons:
1) Easy to write a very minimal, outside the stack, IP/UDP layer.
2) Allows debugging through routers,
On Wed, 20 Feb 2002, Bakul Shah wrote:
I may have forgotten a few things but this is the gist of how
it worked. Credit for all this work goes to someone else.
We had meant to give this back to the FreeBSD community but
didn't get around to it in time and now it is not possible.
Why
We had meant to give this back to the FreeBSD community but
didn't get around to it in time and now it is not possible.
Why not? (curiosity, not disbelief)
The company got sold before we could sort all this out and a
bunch of the original people no longer work there. Actually
anything is
Forgot to add: this is a pretty straight forward thing to do
and anyone can hack it together in a few days especially when
you have a functional spec of a sort!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
On Tuesday, 19 February 2002 at 21:36:25 -0800, George V. Neville-Neil wrote:
Hi Folks,
Now that Luigi has put in polling support for some ethernet drivers
I was wondering how much work it would be to make the remote kernel debugging
run over the ethernet. I have worked on systems
I was talking to Louis Gerbarg about this topic at the BSDCon last
week. Apparently Darwin already has this functionality, so I suppose
you'd like to take a look at it.
That depends on where they put it. If it depends on I/OKit then we
won't be able to use it easily I figure.
Thanks for
yes but we might as well be protocol compatible if possible :-)
If only to re-use what they did in gdb :-)
On Wed, 20 Feb 2002, George V. Neville-Neil wrote:
I was talking to Louis Gerbarg about this topic at the BSDCon last
week. Apparently Darwin already has this functionality, so I
On Wednesday, 20 February 2002 at 16:52:48 -0800, Julian Elischer wrote:
On Wed, 20 Feb 2002, George V. Neville-Neil wrote:
I was talking to Louis Gerbarg about this topic at the BSDCon last
week. Apparently Darwin already has this functionality, so I suppose
you'd like to take a look at
you mean they use the same protocol?
On Thu, 21 Feb 2002, Greg Lehey wrote:
On Wednesday, 20 February 2002 at 16:52:48 -0800, Julian Elischer wrote:
On Wed, 20 Feb 2002, George V. Neville-Neil wrote:
I was talking to Louis Gerbarg about this topic at the BSDCon last
week. Apparently
On Wednesday, 20 February 2002 at 17:03:38 -0800, Julian Elischer wrote:
On Thu, 21 Feb 2002, Greg Lehey wrote:
On Wednesday, 20 February 2002 at 16:52:48 -0800, Julian Elischer wrote:
On Wed, 20 Feb 2002, George V. Neville-Neil wrote:
I was talking to Louis Gerbarg about this topic at the
On Wednesday, February 20, 2002, at 04:14 PM, George V.
Neville-Neil wrote:
I was talking to Louis Gerbarg about this topic at the BSDCon last
week. Apparently Darwin already has this functionality, so I suppose
you'd like to take a look at it.
That depends on where they put it. If it
On Wednesday, February 20, 2002, at 04:52 PM, Julian Elischer wrote:
yes but we might as well be protocol compatible if possible :-)
If only to re-use what they did in gdb :-)
The Darwin/Mac OS X scheme only deals with IOKit because that's where
the drivers live. The protocol
This all look great. I've got a Darwin 1.4 CD at home, I'll check it
out tonight or some time this week.
Later,
George
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Hi Folks,
Now that Luigi has put in polling support for some ethernet drivers
I was wondering how much work it would be to make the remote kernel debugging
run over the ethernet. I have worked on systems like this before (it's the
reason
I did polling network device drivers in Wind
Folks,
Now that Luigi has put in polling support for some ethernet drivers
I was wondering how much work it would be to make the remote kernel debugging
run over the ethernet. I have worked on systems like this before (it's the
reason
I did polling network device drivers in Wind
Hi George.
There was someone recently that posted that they had some sort of
remote debuging working over an ethernet (or at least that they ALMOST
had it working.). I remember thinking Cool. I have however had good
success with the serial crossover cables needed for the curren serial
On Tue, 19 Feb 2002, Julian Elischer wrote:
Hi George.
There was someone recently that posted that they had some sort of
remote debuging working over an ethernet (or at least that they ALMOST
had it working.). I remember thinking Cool. I have however had good
success with the serial
Hi:
I am trying to debug a kernel using the steps specified in the Handbook.
I follow the
steps to compile the kernel, reboot with -d option, and in the
other machine, I run gdb -k kernel and so...
I have both machines joined with a serial null-modem cable, but
when I try:
(kgdb) target remote
I'm not sure if you're already doing this but, on the machine being
debugged, you must switch to gdb mode by typing 'gdb' at the DDB
prompt. Then, after running gdb -k on your debugging box, go back to
the machine being debugged and type 's'. If you're already doing this,
then it looks like
Hi,
First, apologies if this is not the appropriate place to post this. I'm
trying to hack around the kernel, but I'm running in to roadblocks with
gdb. Also, I'm not on this mailing list, so please Cc: me on any replies.
I was having a problem with a 4.2-RELEASE box's quotas. I compiled up a
I am debugging a kernel. Since a kernel is consisted of many files, how
can I load a specific file into gdb, browse it, and set a break point at
some line within that file? Right now, I can only view the file whose
statements are being executed. Thanks.
-Zhihui
To Unsubscribe: send mail to
* Mohana Krishna Penumetcha [EMAIL PROTECTED] [010111 02:26] wrote:
we are testing our driver for 4.0 freeBSD. kernel is panicing in the
attach routine with the message "double fault". the longest sequence of
function calls from the attach routine use 180 bytes of kernel stack(this
Afaik, on i386 you have ~4k of kernel stack, however you have to
realize that driver entry can come from an interrupt generated when
the stack is already nearly exhausted. I'm not really that much
of a driver programmer, but I've heard of people facing this problem
before, solutions
* Mohana Krishna Penumetcha [EMAIL PROTECTED] [010111 03:08] wrote:
Afaik, on i386 you have ~4k of kernel stack, however you have to
realize that driver entry can come from an interrupt generated when
the stack is already nearly exhausted. I'm not really that much
of a driver
* Mohana Krishna Penumetcha [EMAIL PROTECTED] [010111 03:08] wrote:
Afaik, on i386 you have ~4k of kernel stack, however you have to
realize that driver entry can come from an interrupt generated when
the stack is already nearly exhausted. I'm not really that much
of a driver
Mohana Krishna Penumetcha wrote:
* Mohana Krishna Penumetcha [EMAIL PROTECTED] [010111 03:08] wrote:
Afaik, on i386 you have ~4k of kernel stack, however you have to
realize that driver entry can come from an interrupt generated when
the stack is already nearly exhausted.
On Thu, 11 Jan 2001, Julian Elischer wrote:
Mohana Krishna Penumetcha wrote:
* Mohana Krishna Penumetcha [EMAIL PROTECTED] [010111 03:08] wrote:
Afaik, on i386 you have ~4k of kernel stack, however you have to
realize that driver entry can come from an interrupt
On Tue, 2 Jan 2001, Doug White wrote:
On Tue, 2 Jan 2001, Zhiui Zhang wrote:
I have written a KLD and am debugging it. The program often hangs after
runs for a while (I guess it enters into some dead loop). Is there a way
to attach to the process and somehow find out which code it is
I have written a KLD and am debugging it. The program often hangs after
runs for a while (I guess it enters into some dead loop). Is there a way
to attach to the process and somehow find out which code it is executing
(with remote debugging or ddb)?
Thanks for your help.
-Zhihui
To
On Tue, 2 Jan 2001, Zhiui Zhang wrote:
I have written a KLD and am debugging it. The program often hangs after
runs for a while (I guess it enters into some dead loop). Is there a way
to attach to the process and somehow find out which code it is executing
(with remote debugging or ddb)?
[Sorry for lack of message in this reply but I accidently rm'd the
original emails to reply to :-) ]
One thing I've done in the past is if it's convenient in a section of code
to hijack a function pointer in the kernel, then hijack it so that it will
call your code...
Silly, and not always
1 - 100 of 135 matches
Mail list logo
