Re: Strange interrupt behaviour

Andrea Arcangeli (arcangeli@mbox.queen.it)
Mon, 13 Jul 1998 21:49:50 +0200 (CEST)


On Sat, 11 Jul 1998, Linus Torvalds wrote:

>No, the interrupt stack issue must be a red herring. We must _never_ get
>nested interrupts, no matter what. Using a separate stack is never an
>acceptable solution, it just means we have other problems.

Hmm I can' t see any other problem. Can anybody show me which other
problems are?

One month ago I developed a didactical kernel for mips for Univ. and since
I didn' t want to have to deal with mm at all I taken the most
strightforward way to allocate a static stack pool per interrupt. It
worked fine and it seems to me very more simple.

Since the _same_ interrupt can' t be nested why not to allocate a 4kbyte
of static stack per interrupt? On x86 with 16 interrupts we will allocate
64kbyte of contiguous space _only_ for irq stack. This way sound me more
robust and simple. Probably I am thinking this since I don' t know
implementation details though ;-). This has nothing to do with resizing
the stack to 4k (even if I would like to use all my """little""" 32Mbyte
memory ;-).

BTW, some time ago I got stack overflows with 2.1.5x too trying to use the
->command callback instead of the queuecommand one in ppa (ZIP parallel
drive). In read only the ppa ->command driven was very lighter and worked
fine. Writing to it instead the kernel crashed. Then I understood why
Grant was forced to use the ->queuecommand scsi callback even if ppa is
polled and not interrupt driven... The scsi code recurse_d_ without limits
during the write. When I asked to scsi guys they said me that ->command
callback was going to be removed (they was right ;-).

Andrea[s] Arcangeli

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html