No need to answer that anymore, I have aligned the stacks inside the structure and that still fixed the issue. Can you now review it? (as soon as I fix the PR title, that is)
-----Original Message----- From: Paul Olaru Sent: Wednesday, November 20, 2019 5:54 PM To: Paul Olaru paul.olaru@nxp.com; Liam Girdwood liam.r.girdwood@linux.intel.com; sound-open-firmware@alsa-project.org Subject: RE: [Sound-open-firmware] [EXT] Re: Stack alignment issues with XCC?
Coming back on that, I have stopped trying to add prints and instead did as Tomasz suggested, namely manually aligning master_core_data (where all interrupt stacks live) to a multiple of 16 and that also stops all crashing. So it is an alignment issue after all, probably happening inside stuff like the volume component and which is fixed by doing said alignment.
Since I don't have a SMP architecture I don't know how the core data (and interrupt stacks) is allocated for slave cores. Can you provide me some input on that situation?
-----Original Message----- From: Sound-open-firmware sound-open-firmware-bounces@alsa-project.org On Behalf Of Paul Olaru Sent: Wednesday, November 20, 2019 5:09 PM To: Liam Girdwood liam.r.girdwood@linux.intel.com; sound-open-firmware@alsa-project.org Subject: Re: [Sound-open-firmware] [EXT] Re: Stack alignment issues with XCC?
Caution: EXT Email
No, the exception cause is accessing an unaligned memory region, and shifting the stack pointer like that fixes it. For some reason epc1 points after an "enter" instruction as well.
On GCC the stack is still unaligned but since GCC doesn't vectorize anything (XCC has vector operations for the Volume component in my case, although epc1 doesn't point there) everything else is fine.
Without alignment I see the stack still being misaligned when entering the IRQ handler for DMA multi channel domain; fixing the alignment as early as in my PR still preserves it at that point.
Also I read that Xtensa ABI requires stacks to be aligned to 16 bytes and compilers can just assume it's already aligned. Can't confirm the source for that claim yet but given my observations it seems likely to be in fact true. As such the compiler assumes the stack pointer is aligned and when allocating on-stack structures which require an alignment of 16 or less it doesn't insert any further alignment code.
I will test again on master, trying to add more and more prints in the code to see exactly where it crashes the DSP and report back. But this is my current observation, aligning the stack there keeps the stack aligned throughout and fixes my issue.
-----Original Message----- From: Liam Girdwood liam.r.girdwood@linux.intel.com Sent: Wednesday, November 20, 2019 5:02 PM To: Paul Olaru paul.olaru@nxp.com; sound-open-firmware@alsa-project.org Subject: Re: [Sound-open-firmware] [EXT] Re: Stack alignment issues with XCC?
Caution: EXT Email
On Wed, 2019-11-20 at 14:10 +0000, Paul Olaru wrote:
Didn't test the emulator (I still have trouble with that).
If other interrupts caused problems wouldn't I be able to see more logs than the one related to registering the DMA interrupt?
If IRQ handling was broken in general then I'd expect you would see similar errors for SW or Timer IRQs.
Also (see my draft/hack PR, #2111) if I force-align the stack within the irq_steer handler I don't get any panics further on. Although it may very well be possible that the compiler doesn't vectorize any instruction in any of the functions directly or indirectly called from such an interrupt (there is nothing to vectorize?) and thus the stack may still be misaligned but in those cases it doesn't matter.
I dont think there is anything to vectorize in the handlers, it's mostly HAL assembler before it jumps into C code.
My general suspicion is that something is corrupting stack or a ptr in your DMA code somewhere that's killing FW when the DMA IRQs. The alignment is probably moving any corruption to an unrelated data section not used in the IRQ handler ?
Liam
-----Original Message----- From: Liam Girdwood liam.r.girdwood@linux.intel.com Sent: Wednesday, November 20, 2019 1:09 PM To: Paul Olaru paul.olaru@nxp.com; sound-open-firmware@alsa-project.org Subject: [EXT] Re: [Sound-open-firmware] Stack alignment issues with XCC?
Caution: EXT Email
On Tue, 2019-11-19 at 15:33 +0000, Paul Olaru wrote:
Hello, I'm trying to begin doing all my builds with XCC for testing and, besides one issue where I need to manually insert stack alignment code in the IRQ handling function for the DMA domain it seems to work. Also, if I align the stack within my IRQ_STEER handler it remains aligned for the domain handler just fine.
My question is, why within irq_handler (see src/drivers/imx/interrupt.c, function begins around line 275) the stack is not aligned? Did you also encounter this issue on other platforms? And is there any good solution other than that bit of inline assembly that just force- aligns the stack pointer when entering the cascaded IRQ handler?
Never encountered this on Intel platforms. It could be another issue that shows up when handling an IRQ ?
Does the emulator shed any light on this ?
Without this code I seem to get panics with an alignment exception, the address pointing within an Interrupt stack and epc0 not being correct (I think I need to investigate that as well but that's a low-priority issue).
Could be corruption somewhere else ? I guess the timer IRQs and SW IRQs work fine without the alignment ?
Liam
Compiler version for reference (in case there is a known issue I'm not aware of):
xt-xcc -v xt-xcc version 11.0.4 Thread model: single _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.al...
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.al...
_______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.al...