Hi
I am testing a PCI network device driver on linux-2.4.19.
I have observed a peculiar problem during testing.
I have a functionality which works well if the code whcih performs this
function is embedded in the required function. If this functionality is
implemented as a separate function, and this function is called at the
required place, the system crashes. I have used KDB for debugging. But,
KDB also fails when this system crash occurs.
Could this be because of any function stack overflow? I am new to this
field. Could someone through some light on this.
Thanks in advacne.
regards
Madhavi.
>
>
>I have a functionality which works well if the code whcih performs this
>function is embedded in the required function. If this functionality is
>implemented as a separate function, and this function is called at the
>required place, the system crashes. I have used KDB for debugging. But,
>
>
I'd suggest check the args passed to the function and the sizes they
would consume when they are passed as 'call by value'.
Try to pass them as pointers maybe.
Yes, i think there is a limit on kernel stack but not i'm not too sure
about the number.
On Fri, 2003-01-24 at 01:53, Linux Geek wrote:
> >
> >
> >I have a functionality which works well if the code whcih performs this
> >function is embedded in the required function. If this functionality is
> >implemented as a separate function, and this function is called at the
> >required place, the system crashes. I have used KDB for debugging. But,
> >
> >
> I'd suggest check the args passed to the function and the sizes they
> would consume when they are passed as 'call by value'.
> Try to pass them as pointers maybe.
>
> Yes, i think there is a limit on kernel stack but not i'm not too sure
> about the number.
The kernel has an 8K stack max. That said, it *could* be your stack. Do
you get any panics or oops? If so, you *could* write them down :-D And
debug them later. If it appears corrupted, then it's probably stack.
On 24 Jan 2003, GrandMasterLee wrote:
> On Fri, 2003-01-24 at 01:53, Linux Geek wrote:
> > >
> > >
> > >I have a functionality which works well if the code whcih performs this
> > >function is embedded in the required function. If this functionality is
> > >implemented as a separate function, and this function is called at the
> > >required place, the system crashes. I have used KDB for debugging. But,
> > >
> > >
> > I'd suggest check the args passed to the function and the sizes they
> > would consume when they are passed as 'call by value'.
> > Try to pass them as pointers maybe.
> >
> > Yes, i think there is a limit on kernel stack but not i'm not too sure
> > about the number.
>
> The kernel has an 8K stack max. That said, it *could* be your stack. Do
> you get any panics or oops? If so, you *could* write them down :-D And
> debug them later. If it appears corrupted, then it's probably stack.
>
I am getting a panic saying "attempted to kill idle task". The call trace
scrolls through for 4-5 pages. I have also observed complete system hang a
few times.
How can I solve this problem, supposing I can't avoid that function call?
Any pointers regarding this would be of great help for me.
thanks & regards
Madhavi.
On Fri, 24 Jan 2003, Madhavi wrote:
>
> On 24 Jan 2003, GrandMasterLee wrote:
>
> > On Fri, 2003-01-24 at 01:53, Linux Geek wrote:
> > > >
> > > >
> > > >I have a functionality which works well if the code whcih performs this
> > > >function is embedded in the required function. If this functionality is
> > > >implemented as a separate function, and this function is called at the
> > > >required place, the system crashes. I have used KDB for debugging. But,
> > > >
> > > >
> > > I'd suggest check the args passed to the function and the sizes they
> > > would consume when they are passed as 'call by value'.
> > > Try to pass them as pointers maybe.
> > >
> > > Yes, i think there is a limit on kernel stack but not i'm not too sure
> > > about the number.
> >
> > The kernel has an 8K stack max. That said, it *could* be your stack. Do
> > you get any panics or oops? If so, you *could* write them down :-D And
> > debug them later. If it appears corrupted, then it's probably stack.
> >
>
> I am getting a panic saying "attempted to kill idle task". The call trace
> scrolls through for 4-5 pages. I have also observed complete system hang a
> few times.
>
> How can I solve this problem, supposing I can't avoid that function call?
> Any pointers regarding this would be of great help for me.
>
> thanks & regards
> Madhavi.
>
Make a user-mode 'main()' test program that calls your function with
the required parameters. Link it with your function and run it either
with gdb or with lots of ordinary printf statements.
You can resolve all missing globals, including functions, with
simple 'ints' as long as they are not accessed in your code. This
lets you test practically anything in user-mode when, if you
screw up, you just have a core file and don't have to re-boot.
Most all of the modules that I write for embedded systems are
initially tested this way. That lets me get linked-lists and
other easy-to-muck-up things working correctly before I throw
it off the cliff, hoping it will fly. My user-mode code calls
ISRs, actually accessing hardware in most cases (iopl(3) allows
this).
Also, PCI interrupts are level interrupts. Do not enable interrupts
in your ISR until you have serviced the reason why you got the
interrupt in the first place, otherwise the ISR will be interrupted
by the same interrupt...,
by the same interrupt...,
by the same interrupt...,
until you crash.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
On Fri, 2003-01-24 at 15:41, Madhavi wrote:
> How can I solve this problem, supposing I can't avoid that function call?
> Any pointers regarding this would be of great help for me.
post source code.
--
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source http://www.scaramanga.co.uk/gianni-at-ecsc.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D