From: Matthew Fredrickson <creslin@digium.com>
To: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Device Driver Etiquette
Date: Fri, 1 Jun 2007 12:47:07 -0500 [thread overview]
Message-ID: <a714c0e137cf5cf814e790e3fdef23c8@digium.com> (raw)
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.
The problem that I am seeing is that while this card is loading its
firmware, there are other device interrupts that occur, and if enough
levels of interrupt happen, it overflows the stack. Oh, the firmware
load occurs in the context of an ioctl, FWIW.
My solution was to disable interrupts while the firmware was being
loaded using local_irq_save/local_irq_restore, although that seems to
be a naughty thing to do, especially given the long period of time it
takes to load the firmware on the card.
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) OR is it acceptable (although
not nice) to simply fix it this way, by disabling irqs while it loads
the firmware?
Thanks,
Matthew Fredrickson
Kernel Developer
Digium, Inc.
next reply other threads:[~2007-06-01 18:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-01 17:47 Matthew Fredrickson [this message]
2007-06-01 18:38 ` Device Driver Etiquette Lee Revell
2007-06-01 22:28 ` H. Peter Anvin
2007-06-02 15:05 ` Satyam Sharma
2007-06-02 23:22 ` Arjan van de Ven
2007-06-03 1:45 ` Satyam Sharma
-- strict thread matches above, loose matches on Subject: below --
2007-06-01 23:16 Daniel J Blueman
[not found] <12467610.159201180797054019.JavaMail.root@jupiler.digium.com>
2007-06-02 15:12 ` Matt Fredrickson
2007-06-03 11:22 ` Daniel J Blueman
[not found] <17916027.160971180851607681.JavaMail.root@jupiler.digium.com>
2007-06-03 6:20 ` Matt Fredrickson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a714c0e137cf5cf814e790e3fdef23c8@digium.com \
--to=creslin@digium.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox