Messages in this thread | | | Date | Mon, 13 Jul 1998 21:49:50 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: Strange interrupt behaviour |
| |
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
| |