Implement 'poll_put_char' and 'poll_get_char' callbacks in struct
'owl_uart_ops' that enables OWL UART to be used for kernel debugging
over serial line.
Signed-off-by: Cristian Ciocaltea
---
Changes in v3:
- Used 'readl_poll_timeout_atomic()' in 'owl_uart_poll_put_char()'
to get rid of 'cpu_r
On Fri, Jan 08, 2021 at 08:58:38AM +0100, Jiri Slaby wrote:
> On 07. 01. 21, 19:16, Cristian Ciocaltea wrote:
> > Hi Greg,
> >
> > Thank you for the review!
> >
> > On Thu, Jan 07, 2021 at 04:20:55PM +0100, Greg Kroah-Hartman wrote:
> > > On Tue, Jan 05, 2021 at 07:02:02PM +0200, Cristian Ciocalt
On 07. 01. 21, 19:16, Cristian Ciocaltea wrote:
Hi Greg,
Thank you for the review!
On Thu, Jan 07, 2021 at 04:20:55PM +0100, Greg Kroah-Hartman wrote:
On Tue, Jan 05, 2021 at 07:02:02PM +0200, Cristian Ciocaltea wrote:
Implement 'poll_put_char' and 'poll_get_char' callbacks in struct
'owl_uar
Hi Greg,
Thank you for the review!
On Thu, Jan 07, 2021 at 04:20:55PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 05, 2021 at 07:02:02PM +0200, Cristian Ciocaltea wrote:
> > Implement 'poll_put_char' and 'poll_get_char' callbacks in struct
> > 'owl_uart_ops' that enables OWL UART to be used fo
On Tue, Jan 05, 2021 at 07:02:02PM +0200, Cristian Ciocaltea wrote:
> Implement 'poll_put_char' and 'poll_get_char' callbacks in struct
> 'owl_uart_ops' that enables OWL UART to be used for kernel debugging
> over serial line.
>
> Signed-off-by: Cristian Ciocaltea
> ---
> Changes in v2:
> - Reve
Implement 'poll_put_char' and 'poll_get_char' callbacks in struct
'owl_uart_ops' that enables OWL UART to be used for kernel debugging
over serial line.
Signed-off-by: Cristian Ciocaltea
---
Changes in v2:
- Reverted unnecessary changes per Andreas feedback
- Optimized implementation for 'owl_u
On Fri, May 29, 2020 at 05:56:47PM +0200, Andreas Färber wrote:
> Hi,
>
> Am 29.05.20 um 17:50 schrieb Cristian Ciocaltea:
> > Implement poll_put_char and poll_get_char callbacks in struct uart_ops
> > that enables OWL UART to be used for KGDB debugging over serial line.
> >
> > Signed-off-by: Cr
Hi,
Am 29.05.20 um 17:50 schrieb Cristian Ciocaltea:
Implement poll_put_char and poll_get_char callbacks in struct uart_ops
that enables OWL UART to be used for KGDB debugging over serial line.
Signed-off-by: Cristian Ciocaltea
---
drivers/tty/serial/owl-uart.c | 45 +
Implement poll_put_char and poll_get_char callbacks in struct uart_ops
that enables OWL UART to be used for KGDB debugging over serial line.
Signed-off-by: Cristian Ciocaltea
---
drivers/tty/serial/owl-uart.c | 45 ++-
1 file changed, 39 insertions(+), 6 deletions
Julien Masson writes:
> The kgdb invokes the poll_put_char and poll_get_char when communicating
> with the host. This patch implement the serial polling hooks for the
> meson_uart to be used for KGDB debugging over serial line.
>
> Signed-off-by: Julien Masson
Looks good, and very useful thanks
The kgdb invokes the poll_put_char and poll_get_char when communicating
with the host. This patch implement the serial polling hooks for the
meson_uart to be used for KGDB debugging over serial line.
Signed-off-by: Julien Masson
---
Changes since v1 [0]:
* Use readl_poll_timeout_atomic instead o
On Fri 01 Feb 2019 at 11:10, Corentin Labbe wrote:
> On Fri, Feb 01, 2019 at 10:59:22AM +0100, Julien Masson wrote:
>> The kgdb invokes the poll_put_char and poll_get_char when communicating
>> with the host. This patch implement the serial polling hooks for the
>> meson_uart to be used for KGD
The kgdb invokes the poll_put_char and poll_get_char when communicating
with the host. This patch implement the serial polling hooks for the
meson_uart to be used for KGDB debugging over serial line.
Signed-off-by: Julien Masson
---
drivers/tty/serial/meson_uart.c | 46 ++
The kgdb invokes the poll_put_char and poll_get_char when communicating
with the host. This patch implement the serial polling hooks for the
meson_uart to be used for KGDB debugging over serial line.
Signed-off-by: Julien Masson
---
drivers/tty/serial/meson_uart.c | 46 ++
On Fri, Feb 01, 2019 at 10:59:22AM +0100, Julien Masson wrote:
> The kgdb invokes the poll_put_char and poll_get_char when communicating
> with the host. This patch implement the serial polling hooks for the
> meson_uart to be used for KGDB debugging over serial line.
>
> Signed-off-by: Julien Mas
The kgdb invokes the poll_put_char and poll_get_char when communicating
with the host. This patch implement the serial polling hooks for the
meson_uart to be used for KGDB debugging over serial line.
Signed-off-by: Julien Masson
---
It has been tested on "Le Potato" board:
https://libre.computer/
On 10/3/16, Jeffrey Merkey wrote:
> On 10/3/16, Joe Perches wrote:
>>
>> On Tue, 2016-10-04 at 13:29 +1100, Stephen Rothwell wrote:
>>> Hi Joe,
>>
>> Hi Stephen.
>>
>>> On Mon, 03 Oct 2016 18:47:04 -0700 Joe Perches wrote:
>>> >
>>> > On Mon, 2016-10-03 at 18:17 -0600, Jeffrey Merkey wrote:
>>>
On 10/3/16, Joe Perches wrote:
>
> On Tue, 2016-10-04 at 13:29 +1100, Stephen Rothwell wrote:
>> Hi Joe,
>
> Hi Stephen.
>
>> On Mon, 03 Oct 2016 18:47:04 -0700 Joe Perches wrote:
>> >
>> > On Mon, 2016-10-03 at 18:17 -0600, Jeffrey Merkey wrote:
>> > > The following changes since commit
>> > > c
On Tue, 2016-10-04 at 13:29 +1100, Stephen Rothwell wrote:
> Hi Joe,
Hi Stephen.
> On Mon, 03 Oct 2016 18:47:04 -0700 Joe Perches wrote:
> >
> > On Mon, 2016-10-03 at 18:17 -0600, Jeffrey Merkey wrote:
> > > The following changes since commit
> > > c8d2bc9bc39ebea8437fd974fdbc21847bb897a3:
>
Hi Joe,
On Mon, 03 Oct 2016 18:47:04 -0700 Joe Perches wrote:
>
> On Mon, 2016-10-03 at 18:17 -0600, Jeffrey Merkey wrote:
> > The following changes since commit c8d2bc9bc39ebea8437fd974fdbc21847bb897a3:
> >
> > Linux 4.8 (2016-10-02 16:24:33 -0700)
> >
> > are available in the git repository
On Mon, 2016-10-03 at 18:17 -0600, Jeffrey Merkey wrote:
> The following changes since commit c8d2bc9bc39ebea8437fd974fdbc21847bb897a3:
>
> Linux 4.8 (2016-10-02 16:24:33 -0700)
>
> are available in the git repository at:
>
> https://github.com/jeffmerkey/linux.git mdb-v4.8
>
> for you to f
The following changes since commit c8d2bc9bc39ebea8437fd974fdbc21847bb897a3:
Linux 4.8 (2016-10-02 16:24:33 -0700)
are available in the git repository at:
https://github.com/jeffmerkey/linux.git mdb-v4.8
for you to fetch changes up to 8e3486647ebcef24e67fc2eebe49f3641a4ffc95:
Add MDB Deb
The following changes since commit c8d2bc9bc39ebea8437fd974fdbc21847bb897a3:
Linux 4.8 (2016-10-02 16:24:33 -0700)
are available in the git repository at:
https://github.com/jeffmerkey/linux.git mdb-v4.8
for you to fetch changes up to 8e3486647ebcef24e67fc2eebe49f3641a4ffc95:
Add MDB Deb
:
Add MDB Linux Kernel Debugger to Linux v4.6 (2016-05-15 18:16:50 -0600)
Signed-Off-By: Jeff Merkey
The MDB Linux Kernel Debugger for Linux Kernel v4.6 is now available via git.
Checkpatch Compliance Results:
./scripts
On 3/25/16, Stephen Rothwell wrote:
> Hi Jeff,
>
> On Fri, 25 Mar 2016 17:01:27 -0600 Jeffrey Merkey
> wrote:
>>
>> I went back and checked the code and as it turns out, none of the
>> patches you nak'd are in the current branch, there are different
>> patches there now. There are two patches y
gt; it in its current form. If we merge bits of it then we want to merge it via
> the
> x86 tree, not a separate tree.
>
> In fact I also have more fundamental objections as well, such as the question
> of
> unnecessary code duplication: this new MDB debugger overlaps in functi
Hi Jeff,
On Fri, 25 Mar 2016 17:01:27 -0600 Jeffrey Merkey wrote:
>
> I went back and checked the code and as it turns out, none of the
> patches you nak'd are in the current branch, there are different
> patches there now. There are two patches you ignored that are in it,
> but no record of a
x27;s one of the objections by me:
>>>>
>>>>https://lkml.org/lkml/2016/1/29/64
>>>>
>>>> ... which technical objections were replied to by Jeff Merkey by
>>>> accusing
>>>> me
>>>> of
>>>> trolling:
&g
> of
>>> trolling:
>>>
>>> "You were not included on the post since you are not a maintainer of
>>> watchdog.c
>>>so I am confused as to why you are nacking and trolling me on
>>> something
>>> not in
>>>your area.&q
> not in
>> your area."
>>
>>https://lkml.org/lkml/2016/1/29/397
>>
>> So this tree is very far from being ready and I'm not convinced we want
>> to
>> merge
>> it in its current form. If we merge bits of it then we want t
cking and trolling me on something
> not in
>your area."
>
>https://lkml.org/lkml/2016/1/29/397
>
> So this tree is very far from being ready and I'm not convinced we want to
> merge
> it in its current form. If we merge bits of it then we want to merge it via
e merge bits of it then we want to merge it via the
x86 tree, not a separate tree.
In fact I also have more fundamental objections as well, such as the question
of
unnecessary code duplication: this new MDB debugger overlaps in functionality
with
the already in-tree kgdb+KDB live kernel debugger approa
On 3/17/16, Joe Perches wrote:
> On Thu, 2016-03-17 at 23:31 -0600, Jeffrey Merkey wrote:
>> On 3/16/16, Jeffrey Merkey wrote:
>> > On 3/15/16, Theodore Ts'o wrote:
>> > > On Tue, Mar 15, 2016 at 01:03:39PM +1100, Stephen Rothwell wrote:
>> > > >
>> > > > We don't generally PGP (GPG) sign commit
On Thu, 2016-03-17 at 23:31 -0600, Jeffrey Merkey wrote:
> On 3/16/16, Jeffrey Merkey wrote:
> > On 3/15/16, Theodore Ts'o wrote:
> > > On Tue, Mar 15, 2016 at 01:03:39PM +1100, Stephen Rothwell wrote:
> > > >
> > > > We don't generally PGP (GPG) sign commits in the kernel tree (so "-S"
> > > >
On 3/15/16, Theodore Ts'o wrote:
> On Tue, Mar 15, 2016 at 01:03:39PM +1100, Stephen Rothwell wrote:
>> We don't generally PGP (GPG) sign commits in the kernel tree (so "-S"
>> is not required), just tags. However we always require that anyone who
>> handles a patch adds a Signed-off-by line to t
On 3/16/16, Jeffrey Merkey wrote:
> On 3/15/16, Theodore Ts'o wrote:
>> On Tue, Mar 15, 2016 at 01:03:39PM +1100, Stephen Rothwell wrote:
>>> We don't generally PGP (GPG) sign commits in the kernel tree (so "-S"
>>> is not required), just tags. However we always require that anyone who
>>> handl
On Tue, Mar 15, 2016 at 01:03:39PM +1100, Stephen Rothwell wrote:
> We don't generally PGP (GPG) sign commits in the kernel tree (so "-S"
> is not required), just tags. However we always require that anyone who
> handles a patch adds a Signed-off-by line to the final commit. See
> Documentation/S
Hi Jeff,
On Mon, 14 Mar 2016 18:40:37 -0600 Jeffrey Merkey wrote:
>
> I was sure I told git to put a sign-off line. Well, I'll go fix that
> and amend the commit as signed. Don't know what happened there. Are
> you supposed to say
>
> git commit -s -a -v -S
>
> I just used
>
> git commit -S
On 3/14/16, Stephen Rothwell wrote:
> Hi Joe,
>
> On Mon, 14 Mar 2016 16:57:03 -0700 Joe Perches wrote:
>>
>> On Mon, 2016-03-14 at 17:50 -0600, Jeffrey Merkey wrote:
>> > The following changes since commit
>> > b562e44f507e863c6792946e4e1b1449fbbac85d:
>> >
>> > Linux 4.5 (2016-03-13 21:28:54
Hi Joe,
On Mon, 14 Mar 2016 16:57:03 -0700 Joe Perches wrote:
>
> On Mon, 2016-03-14 at 17:50 -0600, Jeffrey Merkey wrote:
> > The following changes since commit b562e44f507e863c6792946e4e1b1449fbbac85d:
> >
> > Linux 4.5 (2016-03-13 21:28:54 -0700)
> >
> > are available in the git repository
On Mon, 2016-03-14 at 17:50 -0600, Jeffrey Merkey wrote:
> The following changes since commit b562e44f507e863c6792946e4e1b1449fbbac85d:
>
> Linux 4.5 (2016-03-13 21:28:54 -0700)
>
> are available in the git repository at:
>
> https://github.com/jeffmerkey/linux.git tags/mdb-v4.5-signed
>
>
:
Add MDB Debugger to linux v4.5 (2016-03-14 15:17:44 -0600)
Signed GPG Tag for mdb-v4.5
Hi Linus,
Please consider one in-kernel debugger for 4.6 with full disassembler
for x86/x86_64 architectures systems. This code is fully
b-v4.5-rc6
for you to fetch changes up to 690db267b161b4cdb67950e5600d9190d2e7a2f3:
Add kbuild-test-robot fixes for CONFIG_VT (2016-02-29 14:09:38 -0700)
Hi Linus,
Please consider one in-kernel debugger for 4.6 with full disasse
b-v4.5-rc6
for you to fetch changes up to 690db267b161b4cdb67950e5600d9190d2e7a2f3:
Add kbuild-test-robot fixes for CONFIG_VT (2016-02-29 14:09:38 -0700)
Hi Linus,
Please consider one in-kernel debugger for 4.6 with full disasse
MDB Kernel Debugger Patches Released for v4.1.15, v4.3.2, v4.3.3, v4.2.8 on the
linux-stable tree.
Linux 4.x Patches
* Linux v4.3.3 :
https://github.com/jeffmerkey/linux-stable/compare/v4.3.3...jeffmerkey:mdb-v4.3.3.diff
* Linux v4.3.2 :
https://github.com/jeffmerkey/linux-stable/compare/v4.3.2
MDB Linux Kernel Debugger Patches Released for 4.3.1 and 4.2.7 on the
linux-stable tree.
Linux 4.X Patches
* Linux v4.3.1 :
https://github.com/jeffmerkey/linux-stable/compare/v4.3.1...jeffmerkey:mdb-v4.3.1.diff
* Linux v4.2.7 :
https://github.com/jeffmerkey/linux-stable/compare/v4.2.7
Links to patches are released for the following kernels. See change
logs on github.
MDB Linux Kernel Debugger Patches, Installation and Configuration info
located at:
http://jeffmerkey.github.io/linux
http://www.jeffmerkey.com
http://www.awahili.com
MDB Linux Kernel Debugger Git Repositories
git repo on github.com at https://github.com/jeffmerkey/linux.
> See the logs in the git repo for info on changes.
>
> Patches are available from github. To download patches and diffs, go to:
>
> http://jeffmerkey.github.io
>
> MDB (The Minimal Kernel Debugger) was writte
download patches and diffs, go to:
http://jeffmerkey.github.io
MDB (The Minimal Kernel Debugger) was written in 1998 and was one of
the earliest debuggers on Linux. It was originally developed for Linux
kernel file system development on the 2.2 series Linux kernels. MDB is
a tool I wrote for my
Correction to previous email, wrong linux version in title line from
previous release
CURRENT
http://merkeydebugger.googlecode.com/files/mdb-2.6.32-279.22.1.el6-03-16-2013.patch
REPOSITORY
http://code.google.com/p/merkeydebugger/
http://sourceforge.net/projects/merkeydebugger/
FIXES:
- port to 2
CURRENT
http://merkeydebugger.googlecode.com/files/mdb-2.6.32-279.22.1.el6-03-16-2013.patch
REPOSITORY
http://code.google.com/p/merkeydebugger/
http://sourceforge.net/projects/merkeydebugger/
FIXES:
- port to 2.6.32-279 and test
- fix patch delta changes and Fuzz warnings.
NOTE: Not tested on x
KGTP is a realtime and lightweight Linux debugger and tracer.
To use it, you don't need patch or rebuild the Linux kernel. Just
build KGTP module and insmod it is OK.
It makes Linux Kernel supply a GDB remote debug interface. Then GDB in
current machine or remote machine can debug and trace Linux
Hi,
I'm working on a linux file system checker right now. Can anyone
recommend a good kernel debugger for 2.6? I googled a bit before I post
to this mailing. It looks like kgdb and kdg are two choices. Which one
is better? Appears to me kgdb requires two machines.
Thanks,
-Junfeng
** Reply to message from "SATHISH.J" <[EMAIL PROTECTED]> on Tue, 26
Jun 2001 10:24:02 +0530 (IST)
> I couls see http://kgdb.sourceforge.net/ the kgdb for 2.4.5 kernel
> version. Can I use the same for 2.2.14 kernel which I am using?
Definitely not. Kernel patches are version-specific, especial
Hi,
I couls see http://kgdb.sourceforge.net/ the kgdb for 2.4.5 kernel
version. Can I use the same for 2.2.14 kernel which I am using? If so how
can I use gdb.bz2 downloaded file. I have this downloaded to my windows
machine and have ftp ed to my linux machine to my home directory. Please
tell me
On Mon, 25 Jun 2001 12:41:53 +0530 (IST),
"SATHISH.J" <[EMAIL PROTECTED]> wrote:
>I would like to use a kernel debugger to set some breakpoints in some
>of the kernel functions. In SVR4 and unixware we use kdb. What is its
>equivalent in linux? Please tell me where t
Hi,
You can download kernel debugger(kgdb) form the
following location:
http://kgdb.sourceforge.net/toc.html
Bye,
siva.s
--- "SATHISH.J" <[EMAIL PROTECTED]> wrote:
> Hi,
> I would like to use a kernel debugger to set some
> breakpoints in some
> of the kernel functi
Hi,
I would like to use a kernel debugger to set some breakpoints in some
of the kernel functions. In SVR4 and unixware we use kdb. What is its
equivalent in linux? Please tell me where the kernel debugger can be
downloaded for linux.
Thanks in advance,
With regards,
sathish.j
-
To
Hi,
kgdb (patch for using gdb to do source level debugging for linux kernel)
is available for 2.4.0-test9 and now supports console output in gdb.
Thanks to Duane Voth, it's now available for 2.2.17 kernel also
(all features except for console output).
Please see http://kgdb.sourceforge.net/ for
>Hence, yes I can provide an interface from the kernel to log a trace event
>with a variable length buffer, but I don't think that taking away the
statically
>defined trace points is the right thing to do. (I might have gotten this
>completely wrong, though ... My presumption about your suggest
ically
> insert a probe anywhere into memory (user and kernel) without the need for
> re-compilation of the source. From the RPN program that's driven by the
> probe event handler we can initiate other facilities such as entering SGI's
> kernel debugger or invoking Crash Dump or fo
Thought I'd let you know that I will reply to your suggestions (which
are quite interesting by the way) ... but I need to catch up some sleep
as it's close to 7AM here in Montreal and my brains are failing ... ;)
===
Karim Yaghmour
From the RPN program that's driven by the
probe event handler we can initiate other facilities such as entering SGI's
kernel debugger or invoking Crash Dump or forcing a core dump. Now, DProbes
came from OS/2 and was called dynamic trace. Its original purpose was to
implement tracepoints on
Hello Richard,
Part of your analysis is correct. The hooks were designed to take care of
static tracepoints only. That said, dynamic allocation of event IDs was
next on my list and the hooking mechanism would have been modified consequently.
As for "multiple exits registered per hook", if you m
Yes, we looked at that and it didn't seem to provide the generality we
needed - multipe exits registered per hook, ability to arm a set of hooks
atomically, ability to prioritise dispatching order of a hook exit, MP
complient. I may be wrong but the Linux Trace Toolkit hooks like like they
were
[EMAIL PROTECTED] wrote:
> One big argument against RAS of any sort is that it bloats the kernel and
> not every one wants it (until they have a problem). A further argument with
> Linux is that you may have to do quite a bit of hard work to get the subset
> of RAS you need to co-exist, if it exis
On Tue, 3 Oct 2000 12:32:37 -0300 (BRST),
Rik van Riel <[EMAIL PROTECTED]> wrote:
>On Wed, 4 Oct 2000, Keith Owens wrote:
>> Rik van Riel <[EMAIL PROTECTED]> wrote:
>> >Sysrq-T is broken on x86 ;
>>
>> show_task() calls thread_saved_pc() which is giving bad results.
>> Getting the correc
On Wed, 4 Oct 2000, Keith Owens wrote:
> Rik van Riel <[EMAIL PROTECTED]> wrote:
> >Sysrq-T is broken on x86 ;
>
> show_task() calls thread_saved_pc() which is giving bad results.
> Getting the correct PC for blocked threads is easy,
>
> Index: 0-test9-pre9.3/include/asm-i386/processor.
On Sun, 1 Oct 2000 23:50:17 -0300 (BRST),
Rik van Riel <[EMAIL PROTECTED]> wrote:
>On Sun, 1 Oct 2000, David Ford wrote:
>> During normal operation of the machine, -T shows processes
>> having PCs of 0x and 0x7f00 which strikes me as a
>> bit odd.
>>
>> For e.g. the following:
>>
>>
Rik van Riel wrote:
> Schedule() is the last function in the kernel they
> went into before they got scheduled away ;)
>
> The second last function is the one you're interested
> in ...
Hmm, 'k.
> > PC: schedule()
> > -1: down()
> > -2: down_fail()
> Then I guess something was trying to tak
On Sun, 1 Oct 2000, David Ford wrote:
> Rik van Riel wrote:
>
> > > How broken is it? I have a test9-pre7 system that's exhibits an
> > > elusive bug, reiserfs hangs at boot time, and all I need is a
> > > backtrace on the D state processes.
> >
> > Could be a VM bug. ;)
>
> It could, but I str
Rik van Riel wrote:
> > How broken is it? I have a test9-pre7 system that's exhibits an
> > elusive bug, reiserfs hangs at boot time, and all I need is a
> > backtrace on the D state processes.
>
> Could be a VM bug. ;)
It could, but I strongly doubt it. We've seen this bug [very] infrequently
On Sun, 01 Oct 2000 14:36:22 -0700,
David Ford <[EMAIL PROTECTED]> wrote:
>Keith Owens wrote:
>
>> http://oss.sgi.com/projects/kdb/download/ix86
>>
>> Stay away from 1.5-beta for the moment unless you like debugging the
>> debugger. No patch against 2.4.0-test9-pre7 yet, hopefully later
>> today
On Sun, 1 Oct 2000, David Ford wrote:
> Keith Owens wrote:
>
> > http://oss.sgi.com/projects/kdb/download/ix86
> >
> > Stay away from 1.5-beta for the moment unless you like debugging the
> > debugger. No patch against 2.4.0-test9-pre7 yet, hopefully later
> > today.
>
> How broken is it? I ha
Keith Owens wrote:
> http://oss.sgi.com/projects/kdb/download/ix86
>
> Stay away from 1.5-beta for the moment unless you like debugging the
> debugger. No patch against 2.4.0-test9-pre7 yet, hopefully later
> today.
How broken is it? I have a test9-pre7 system that's exhibits an elusive bug,
r
On Sun, 01 Oct 2000 14:11:01 -0700,
David Ford <[EMAIL PROTECTED]> wrote:
>my apologies, but could someone point me to the most current release of
>the debugger?
http://oss.sgi.com/projects/kdb/download/ix86
Stay away from 1.5-beta for the moment unless you like debugging the
debugger. No patc
David Ford wrote:
> my apologies, but could someone point me to the most current release of
> the debugger?
>
> -d
>
> --
> "There is a natural aristocracy among men. The grounds of this are
> virtue and talents", Thomas Jefferson [1742-1826], 3rd US President
[EMAIL PROTECTED] Ask
my apologies, but could someone point me to the most current release of
the debugger?
-d
--
"There is a natural aristocracy among men. The grounds of this are
virtue and talents", Thomas Jefferson [1742-1826], 3rd US President
begin:vcard
n:Ford;David
x-mozilla-html:TRUE
org:htt
Very good post. Our concerns for how we are using Linux are in line with
what Rich describes below.
On a previous project that I worked with we had a kernel debugger that could
be included in the kernel by option, and typically wasn't activated on live
systems unless we had someone on
I think the case for the kernel debugger is better stated as the case for
RAS (Reliability, Serviceability and Availability) in the kernel, in other
words, there is a case for having the right diagnostic, reporting and
recovery tools in the right place at the right time. A kdb does not fulfil
Linux. I
can do some of it, but I think having a "kernel debugger source" for the
industry like SGI who wants to fund and promote kernel debugging tools
would make more sense and as Keith pointed out, centralize changes and
features.
:-)
Jeff Merkey
CEO, TRG
"Jeff V. Merkey&quo
I think he did already Keith -- he said he would reject any kernel
debugger submissions.
:-)
Jeff
Keith Owens wrote:
>
> Various people have replied to my note on "The case for a standard
> kernel debugger" discussing whether or not it is a good idea. However
> o
I am porting the MANOS debugger to Linux. No changes here. Linus will
reject it for the tree, but the offer for SGI and Keith Owens to take it
over and merge it with his kdb effort is also genuine.
:-)
Jeff
Daniel Phillips wrote:
>
> Marco Colombo wrote:
> > BTW, a kernel
Amen here too. From a kernel supportability perspective, a kernel debugger
has
saved me many hours. The open the doors to things that often can't be seen
or
seen easily by just knowing the source.
For a real world 24X7 type support situation where a problem needs fixing
_now_
or ther
Andi Kleen wrote:
>
> On Thu, Sep 14, 2000 at 02:21:44PM +0200, Daniel Phillips wrote:
> > The hardest problem: how do you do the block read? Possibilities:
> >
> > - Ignore the problem, use normal block device I/O
> > - Use the real mode bios, needs V86 support
>
> And it requires a sync b
On Thu, Sep 14, 2000 at 02:21:44PM +0200, Daniel Phillips wrote:
> The hardest problem: how do you do the block read? Possibilities:
>
> - Ignore the problem, use normal block device I/O
> - Use the real mode bios, needs V86 support
And it requires a sync before every possible crash to ensu
Marco Colombo wrote:
> BTW, a kernel debugger *is* available. And maybe even a more powerful
> one will be if Jeff decides to port and publicly release it.
One that subject, I would *love* to take the time to see how small a
subset of Ext2 I could write to have a (mostly) non-invasive
On Thu, 14 Sep 2000, Frederic Magniette wrote:
[...]
> In that way, I think that a kernel debugger could be a powerful coding
> tool and not only a patching tool as you say.
I don't have enough background to judge on the merits of a kernel
debugger. I simply trust Linus' feelin
Various people have replied to my note on "The case for a standard
kernel debugger" discussing whether or not it is a good idea. However
only one person's reply matters here - Linus. I ask other people to
refrain from replying to this thread until Linus has had a chance to
read
Frederic Magniette wrote:
>
> This can be really awful if your code is called very often and then saturate the
> logs.
One trick you can pull is:
if (current->uid == )
printk(stuff);
and then exercise the offending code path as user . It
works for some things.
n code
especially when the kernel start to segfault. Then you have to begin a very slow
process of printing
lots of parameters and wondering about what you could have done which is so bad.
This can be really awful if your code is called very often and then saturate the
logs.
In that way, I think
On Wed, 13 Sep 2000, Timur Tabi wrote:
> ** Reply to message from Keith Owens <[EMAIL PROTECTED]> on Thu, 14 Sep 2000
> 08:49:50 +1100
>
>
> > (5) Easier for kernel beginners to learn the kernel internals. Having
> > worked on 10+ operating systems over the years, I can testify that
> >
** Reply to message from Keith Owens <[EMAIL PROTECTED]> on Thu, 14 Sep 2000
08:49:50 +1100
> (5) Easier for kernel beginners to learn the kernel internals. Having
> worked on 10+ operating systems over the years, I can testify that
> some form of kernel/OS tracing facility is extremely
Amen Brother
Jeff
Keith Owens wrote:
>
> Resend, this time with cc: torvalds.
>
> This note puts the case for including a kernel debugger in the master
> tarballs. These points do not only apply to kdb, they apply to any
> kernel debugger. Comments about the perceiv
Resend, this time with cc: torvalds.
This note puts the case for including a kernel debugger in the master
tarballs. These points do not only apply to kdb, they apply to any
kernel debugger. Comments about the perceived deficiencies of kdb,
kgdb, xmon or any other debugger are not relevant
This note puts the case for including a kernel debugger in the master
tarballs. These points do not only apply to kdb, they apply to any
kernel debugger. Comments about the perceived deficiencies of kdb,
kgdb, xmon or any other debugger are not relevant here, nor are
questions about how or when
Rik van Riel wrote:
>
>
> > NDS provides no value to Linux unless it's integrated into the
> > OS, which will happen when MANOS goes out next year around
> > March. NDS is more of a Microsoft play than a Linux play and
> > Linux already has better internet directory technology than NDS
> > --
On Fri, 8 Sep 2000, Jeff V. Merkey wrote:
> This thread is dead. I am porting the MANOS debugger to Linux,
Ohhh cool. While I don't use debuggers myself, I know people
who really like having a good debugger around and are more
productive finding and fixing problems when they have one.
A debugg
OTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for
> Linux
>
> >"The lack of a Kernel Debugger and other basic kernel level facilities on
> >Linux make TRG's job about 20 times harder on Linu
>From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for
Linux
>"The lack of a Kernel Debugger and other basic kernel level facilities on
>Linux make TRG's job about
1 - 100 of 110 matches
Mail list logo
