Re: Device Driver Etiquette

Hi Matthew,

On 6/1/07, Matthew Fredrickson <creslin@xxxxxxxxxx> wrote:
Greetings,

I maintain a device driver that has been bitten by the transition to 4K
stacks. It is a T1/E1 line interface PCI card driver that is
maintained outside of the kernel, although is used by a significant
number of people. The card has a part for doing echo cancellation, but
it is accessed through a vendor API which (when we received it) was
quite stack heavy. It used the stack for a number of large data
structures, although I have moved a great deal of them (particularly
the larger ones) onto the heap instead of the stack. Although this has
reduced stack usage to the point where it is usable within 4K stacks,
on some code paths, it can still use quite a bit of stack space (though
under 4K) for local variables and a handful of small data structures.
The problem is that in order to initialize and use the echo canceler,
there is a firmware load portion which takes a noticeable period of
time (~5-10 seconds). That is done through this stack heavy portion of
the code.

As Peter suggested earlier, the best strategy would be to
cleanup the code and make it stack-light in the first place ...

My question is this: is there a way to either work around the problem I
am seeing with the stack without recompiling the kernel with 8K stack
size or without disabling irqs for such a long period of time (which I
think is not a nice thing to do either)

There are standard mechanisms to push off long duration or
sleep-capable work from interrupts-disabled contexts to user
contexts. But those contexts can also, obviously, be interrupted,
so if you're stack-heavy and suffer a concurrent interrupt (which
you most definitely will in any codepath this long), there's always
the possibility of stack overflowing. I don't really see a better
solution to this than using bigger stacks or reducing your usage
of the same, but of course, better suggestions would be difficult
to give without looking at the code in question.

OR is it acceptable (although
not nice) to simply fix it this way, by disabling irqs while it loads
the firmware?

IMHO, *not*. You could try this, in any case, and learn it the
hard way :-)

Satyam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Interrupt context...
    ... > gone through most of the posts on interrupt in usenet. ... > kernel stack and ISR is executed. ... More may be saved depending on the architecture. ... Here the kernel have assembler code to save all general ...
    (comp.os.linux.development.system)
  • Re: BTX on USB pen drive
    ... my pc but doesn't boot on my supermicro server. ... * Emulate MOV reg,CRx. ... * Protected Mode Hardware interrupt jump table. ... * We place a trampoline on the user stack that will return to rret_tramp ...
    (freebsd-stable)
  • Re: interrupt routine and application pages
    ... application stack in the interrupt context. ... are still in the context of interrupted thread. ... your code runs at raised IRQL, Memory Manager just had no chance to ...
    (microsoft.public.development.device.drivers)
  • [PATCH 4/6] UML - IRQ stacks
    ... Add a separate IRQ stack. ... interrupt run on a separate stack rather than starting on the normal ... The IRQ stack for CPU 0 is declared in the same way as the initial ... handler can't run because it has no idea what shape the stack is in. ...
    (Linux-Kernel)
  • Re: Question about interrupt in MINIX3
    ... a new stack for use during the interrupt service. ... stack is determined by an entry in the Task State Segment. ... does interrupt service just use five last entries in stackframe as its stack? ...
    (comp.os.minix)
Loading