Kernel debugger

Kernel debugger

[Madhavi]

Hi

I am currently testing a device driver on linux-2.4.19. This is
implemented as a loadable kernel module.

# Could anyone suggest a good debugger that can be used to debug kernel
  modules?

# When I tried using gdb with vmlinux and /proc/kcore, I am getting a
  message saying that no debug symbols are found. How do I enable debug
  symbols for linux kernel image? Kernel Debug is already enabled. Is
  there some other configuration that needs to be there?

Thanks in advance.

regards
Madhavi.

Re: Kernel debugger

[Linux Geek]

Madhavi wrote:

># Could anyone suggest a good debugger that can be used to debug kernel
>  modules?
>  
>
LKCD, KDB are good choices.

>  
>

Re: Kernel debugger

[Richard J Moore]

On Tuesday 21 Jan 2003 6:17 am, Madhavi wrote:
If you need to debug a complex problem where stepping through or even 
pin-pointing roughtly the right code location then you might consider 
dprobes/kprobes.

Richard




> Hi
>
> I am currently testing a device driver on linux-2.4.19. This is
> implemented as a loadable kernel module.
>
> # Could anyone suggest a good debugger that can be used to debug kernel
>   modules?
>
> # When I tried using gdb with vmlinux and /proc/kcore, I am getting a
>   message saying that no debug symbols are found. How do I enable debug
>   symbols for linux kernel image? Kernel Debug is already enabled. Is
>   there some other configuration that needs to be there?
>
> Thanks in advance.
>
> regards
> Madhavi.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Richard J Moore
IBM Linux Technology Centre

n_tty.c - possible enhancement

[Henrique Gobbi]

Dear all !!!

I was having data loss problems using my serial ports at 115200 with 
software flow control (I can't use hw flow control) and I ended up 
figuring out that the problem was happening because of the small value 
of the tty buffer high water mark (TTY_THRESHOLD_THROTTLE). Changing 
that define value and recompiling the kernel was the only solution i 
found to my problem.

The way this code is implemented today is bad. The water marks are hard 
coded and the only way to change them is recompiling the kernel again, 
and this is not a good solution for that. I want to change that.

My idea is:
-------------------------------------------------------------------------
1 - Create two new variables in the tty struct: high_watermark and 
low_watermark;

2 - Initialize this variables with the values they have today: 128 and 128;

3 - Create 4 ioctl's to set and get the values of this 2 variables;

4 - Change the file n_tty.c. The line that has
	if (n_tty_receive_room(tty) < TTY_THRESHOLD_THROTTLE) {
     will have:
	if (n_tty_receive_room(tty) < tty->high_watermark) {

     and the same thing will be done for the low watermark
-------------------------------------------------------------------------

I would appreciate any comment on this matter. If you guys don't see any 
problem on this I will commit a patch as soon as possible

later
Henrique

Preemptive kernel

[Henrique Gobbi]

Hi again !!!

Where's the official repository for preemptive kernel patches. I'm 
looking the patch for the kernel 2.4.17 for the ppc arch.

thanks in advance
Henrique

Re: Preemptive kernel

[Robert Love]

On Tue, 2003-02-25 at 12:14, Henrique Gobbi wrote:

> Where's the official repository for preemptive kernel patches. I'm 
> looking the patch for the kernel 2.4.17 for the ppc arch.

http://www.kernel.org/pub/linux/kernel/people/rml/preempt-kernel/

Not sure how well supported PPC was back in 2.4.17.  A newer patch, or
2.5, is recommended.

	Robert Love

Re: n_tty.c - possible enhancement

[Sergei Organov]

Henrique Gobbi <henrique2.gobbi@cyclades.com> writes:
> Dear all !!!
> 

Disclaimer: I'm not an expert in Linux kernel internals. Everything I'll say
below could well be plain wrong as my opinion is based only on superficial
investigation of tty source code and 3-months-long monitoring of this mailing
list.

> I was having data loss problems using my serial ports at 115200 with software
> flow control (I can't use hw flow control) and I ended up figuring out that
> the problem was happening because of the small value of the tty buffer high
> water mark (TTY_THRESHOLD_THROTTLE). Changing that define value and
> recompiling the kernel was the only solution i found to my problem.

I've faced with a similar problem and my attempt to get any help from any guru
here failed (you can try to find my post called "Q: problems interfacing with
tty ldisc using flipbufs" posted 02 Dec 2002 that describes the problem). It
seems that your post won't have any response either :-(

> 
> The way this code is implemented today is bad. The water marks are hard coded
> and the only way to change them is recompiling the kernel again, and this is
> not a good solution for that. I want to change that.

Not only hard-coded, but also are private for n_tty.c, so a tty driver has no
way to find out what are the values :-( It would be fine if there were a way
to send data to the n_tty line discipline without knowledge of the values, but
unfortunately it seems that it's impossible using current interface to line
disciplines.

> My idea is:
> -------------------------------------------------------------------------
> 1 - Create two new variables in the tty struct: high_watermark and
>     low_watermark;
> 2 - Initialize this variables with the values they have today: 128 and 128;
> 3 - Create 4 ioctl's to set and get the values of this 2 variables;
> 4 - Change the file n_tty.c. The line that has
> 	if (n_tty_receive_room(tty) < TTY_THRESHOLD_THROTTLE) {
>      will have:
> 	if (n_tty_receive_room(tty) < tty->high_watermark) {
>      and the same thing will be done for the low watermark
> -------------------------------------------------------------------------

1. I don't think that adding n_tty--specific field(s) to the tty structure is
   a good idea.

2. I think that the interface between tty drivers and line disciplines is
   broken in the sense that it fails to provide reliable method of data
   transfer between tty driver and line discipline. I believe that either the
   interface should be re-designed (that may involve quite large amount of
   work as it will affect line disciplines other than n_tty), or a work-around
   local to n_tty.c should be implemented. As what you suggest is neither of
   the above two solutions (as adding the fields to the tty structure won't
   fix the interface), I don't think it's a correct way to fix the problem.

My own solution to this problem is to make TTY_THRESHOLD_THROTTLE to be at
least as large as TTY_FLIPBUF_SIZE. It will guarantee that driver's throttle
routine will be called without data loss. I have no idea though which
unfortunate side effects this change may have.

-- 
Sergei.