Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
Hello, There is a typo in the PCA9555 driver at line 817: CONFIG_TCA64XX_INT_NCALLBACKS is a bad copy paste, should be CONFIG_PCA9555_INT_NCALLBACKS. After this we managed to recompile our project using the latest NuttX sources, but it fails when trying to init the PHY irq on our STM32F427 board: We get "unexpected IRQ". Yes I know that's pretty vague :-) Is there anything obvious I should have been careful with in this domain, before I dig the jtag probe to fix it (tomorrow) ? Sebastien
Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
https://github.com/apache/incubator-nuttx/issues/3769 Le 24/05/2021 à 17:36, Sebastien Lorquet a écrit : Hello, There is a typo in the PCA9555 driver at line 817: CONFIG_TCA64XX_INT_NCALLBACKS is a bad copy paste, should be CONFIG_PCA9555_INT_NCALLBACKS. After this we managed to recompile our project using the latest NuttX sources, but it fails when trying to init the PHY irq on our STM32F427 board: We get "unexpected IRQ". Yes I know that's pretty vague :-) Is there anything obvious I should have been careful with in this domain, before I dig the jtag probe to fix it (tomorrow) ? Sebastien
Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
On Mon, May 24, 2021 at 11:36 AM Sebastien Lorquet wrote: > > Hello, > > There is a typo in the PCA9555 driver at line 817: > CONFIG_TCA64XX_INT_NCALLBACKS is a bad copy paste, should be > CONFIG_PCA9555_INT_NCALLBACKS. Good catch! Please feel free to open a PR. > After this we managed to recompile our project using the latest NuttX > sources, but it fails when trying to init the PHY irq on our STM32F427 > board: We get "unexpected IRQ". > > Yes I know that's pretty vague :-) > > Is there anything obvious I should have been careful with in this > domain, before I dig the jtag probe to fix it (tomorrow) ? I would first start by looking through the Release Notes between v7.30 and v10.1. Many big improvements and bug fixes happened and some of them are mentioned in Compatibility Concerns along with some changes you might need to make to configuration etc. Also another thing you can try: Has this board and PHY worked correctly with v7.30? If so, you can bisect and with very few tests (I'm guessing fewer than 20) find the exact commit that broke it. Nathan
Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
done, what a process for a 7-character change... The PHY and cable detection worked perfectly fine in our project. Sebastien Le 24/05/2021 à 23:04, Nathan Hartman a écrit : On Mon, May 24, 2021 at 11:36 AM Sebastien Lorquet wrote: Hello, There is a typo in the PCA9555 driver at line 817: CONFIG_TCA64XX_INT_NCALLBACKS is a bad copy paste, should be CONFIG_PCA9555_INT_NCALLBACKS. Good catch! Please feel free to open a PR. After this we managed to recompile our project using the latest NuttX sources, but it fails when trying to init the PHY irq on our STM32F427 board: We get "unexpected IRQ". Yes I know that's pretty vague :-) Is there anything obvious I should have been careful with in this domain, before I dig the jtag probe to fix it (tomorrow) ? I would first start by looking through the Release Notes between v7.30 and v10.1. Many big improvements and bug fixes happened and some of them are mentioned in Compatibility Concerns along with some changes you might need to make to configuration etc. Also another thing you can try: Has this board and PHY worked correctly with v7.30? If so, you can bisect and with very few tests (I'm guessing fewer than 20) find the exact commit that broke it. Nathan
Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
On Tue, May 25, 2021 at 10:05 AM Sebastien Lorquet wrote: > > done, what a process for a 7-character change... > > The PHY and cable detection worked perfectly fine in our project. > > Sebastien Thanks so much for doing that! Regarding the process, did you have any difficulty, i.e., anything that should be improved in our docs explaining the workflow? Cheers, Nathan
Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
No, the workflow is very clear, the pull request model is a defacto standard that works everywhere. But it is heavy for trivial changes. fork, mess with remotes, make a branch, forget to change the git config --local user.name, push, deal with github and my ssh agent messing with multiple ssh keys for different github users, etc etc and then wait for the CI to build megabytes of useless tests just for an obvious typo. It was just easier to send a patch inline and have Greg merge that immediately. I was never happy with this change and there is no reason to feel better now. But there is no way back now.Just less contributions from me. Sebastien Le 25/05/2021 à 16:11, Nathan Hartman a écrit : On Tue, May 25, 2021 at 10:05 AM Sebastien Lorquet wrote: done, what a process for a 7-character change... The PHY and cable detection worked perfectly fine in our project. Sebastien Thanks so much for doing that! Regarding the process, did you have any difficulty, i.e., anything that should be improved in our docs explaining the workflow? Cheers, Nathan
Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
it will be easier next time. Does any of the 21 queued test that I see waiting in github enable this driver? Because if they dont (which I suspect, hence this typo) these tests are useless. Sebastien Le 25/05/2021 à 16:17, Sebastien Lorquet a écrit : No, the workflow is very clear, the pull request model is a defacto standard that works everywhere. But it is heavy for trivial changes. fork, mess with remotes, make a branch, forget to change the git config --local user.name, push, deal with github and my ssh agent messing with multiple ssh keys for different github users, etc etc and then wait for the CI to build megabytes of useless tests just for an obvious typo. It was just easier to send a patch inline and have Greg merge that immediately. I was never happy with this change and there is no reason to feel better now. But there is no way back now.Just less contributions from me. Sebastien Le 25/05/2021 à 16:11, Nathan Hartman a écrit : On Tue, May 25, 2021 at 10:05 AM Sebastien Lorquet wrote: done, what a process for a 7-character change... The PHY and cable detection worked perfectly fine in our project. Sebastien Thanks so much for doing that! Regarding the process, did you have any difficulty, i.e., anything that should be improved in our docs explaining the workflow? Cheers, Nathan
Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
On Tue, May 25, 2021 at 10:22 AM Sebastien Lorquet wrote: > > it will be easier next time. Yes the workflow of git in general is a lot of steps to do a simple thing. If you'd like to, you can still send patches to the mailing list. Just please remember to name the file with ".txt" extension or the mailing list will drop it. If you send a patch rather than a PR, someone will convert it into a PR on GitHub, because we don't commit directly to the repository anymore. It's part of taking the burden off of Greg and allowing the community to split the work. You can keep a fork of NuttX in your GitHub; then you won't need to fork it again. You just need to remember to create a branch each time you want to make a PR, because if you create the changes on master then you'll end up having to delete your fork and then make a new fork. Also it's not possible to have multiple forks of the same repo in one GitHub account. Note that if you want to keep your fork in GitHub, it will get out-of-date with NuttX's repo, but you can bring it up-to-date with something like: Add the official repo as a remote called "upstream": $ git remote add upstream https://github.com/apache/incubator-nuttx.git Fetch new commits from there: $ git fetch upstream Make sure you're on your master branch: $ git checkout master Rebase your master branch to upstream/master. Assuming you haven't made any commits on your master branch, this shouldn't have to do anything: $ git rebase upstream/master Then push it back to GitHub: $ git push origin A lot of steps. :-) (But much faster than deleting the fork and forking again.) This won't sync your fork with things like new tags that are created upstream. There are other git incantations for that, which I can't remember right now. > Does any of the 21 queued test that I see waiting in github enable this > driver? I don't know the answer to that, but... > Because if they dont (which I suspect, hence this typo) these tests are > useless. ...we have had discussions about trying to make the pre-checks smarter about what they check in the future. Thanks again, Nathan
Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
Back to the business After this we managed to recompile our project using the latest NuttX sources, but it fails when trying to init the PHY irq on our STM32F427 board: We get "unexpected IRQ". Yes I know that's pretty vague :-) Is there anything obvious I should have been careful with in this domain, before I dig the jtag probe to fix it (tomorrow) ? I would first start by looking through the Release Notes between v7.30 and v10.1. Many big improvements and bug fixes happened and some of them are mentioned in Compatibility Concerns along with some changes you might need to make to configuration etc. Also another thing you can try: Has this board and PHY worked correctly with v7.30? If so, you can bisect and with very few tests (I'm guessing fewer than 20) find the exact commit that broke it. Release notes are hard to read but I did not find anything special about phy interrupts. Note that it may not be the phy interrupt. Here is my log: stm32_netinitialize: Enabling PHY power stm32_netinitialize: PHY reset... stm32_netinitialize: PHY reset done. stm32_netinitialize: Configuring PHY int F irq_unexpected_isr: ERROR irq: 3 up_assert: Assertion failed at file:irq/irq_unexpectedisr.c line: 50 up_registerdump: R0: 0001 2000737c c0f2 08000101 200073c8 up_registerdump: R8: 200073c8 080126ad 080126f8 up_registerdump: xPSR: 2100 PRIMASK: CONTROL: up_registerdump: EXC_RETURN: fff9 A lot of OS initialization things happen at the point, marked by the letter F. It seems that an unexpected IRQ happens in this interval, around the time the filesystem is initialized. The backtrace goes down to memory allocation routines through the initialization of the root inode. My guess is that AN external IRQ is triggered (possibly not the PHY IRQ) but the ISR handler for that one is not ready yet. I will add debug messages. I would expect that situation to be a simple NOP, but it seems that undefined handlers are set to this function "irq_unexpected_isr" Is that a new behaviour? a default config that I did not set properly when porting our old defconfig? Sebastien Nathan
Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
irq_unexpected_isr: ERROR irq: 3 ... My guess is that AN external IRQ is triggered (possibly not the PHY IRQ) but the ISR handler for that one is not ready yet. I will add debug messages. IRQ 3 is a Hardfault, not an external IRQ or peripheral interrupt. I would expect that situation to be a simple NOP, but it seems that undefined handlers are set to this function "irq_unexpected_isr" Initially all interrupts vector to irq_unexpected_isr() but that is fixed early in irq_initialize() when the hard fault handler is attached to IRQ 2. Prior to that, the hard fault would be given to irq_unexpected_isr(), although I don't think the serial driver has been initialized at that point either.
Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
On Tue, May 25, 2021 at 12:02 PM Sebastien Lorquet wrote: > Back to the business > >> After this we managed to recompile our project using the latest NuttX > >> sources, but it fails when trying to init the PHY irq on our STM32F427 > >> board: We get "unexpected IRQ". > >> > >> Yes I know that's pretty vague :-) > >> > >> Is there anything obvious I should have been careful with in this > >> domain, before I dig the jtag probe to fix it (tomorrow) ? > > I would first start by looking through the Release Notes between v7.30 > > and v10.1. Many big improvements and bug fixes happened and some of > > them are mentioned in Compatibility Concerns along with some changes > > you might need to make to configuration etc. > > > > Also another thing you can try: Has this board and PHY worked > > correctly with v7.30? If so, you can bisect and with very few tests > > (I'm guessing fewer than 20) find the exact commit that broke it. > > Release notes are hard to read but I did not find anything special about > phy interrupts. > > Note that it may not be the phy interrupt. Here is my log: > > stm32_netinitialize: Enabling PHY power > stm32_netinitialize: PHY reset... > stm32_netinitialize: PHY reset done. > stm32_netinitialize: Configuring PHY int > F > irq_unexpected_isr: ERROR irq: 3 > up_assert: Assertion failed at file:irq/irq_unexpectedisr.c line: 50 > up_registerdump: R0: 0001 2000737c c0f2 08000101 > 200073c8 > up_registerdump: R8: > 200073c8 080126ad 080126f8 > up_registerdump: xPSR: 2100 PRIMASK: CONTROL: > up_registerdump: EXC_RETURN: fff9 > > A lot of OS initialization things happen at the point, marked by the > letter F. > > It seems that an unexpected IRQ happens in this interval, around the > time the filesystem is initialized. The backtrace goes down to memory > allocation routines through the initialization of the root inode. > > My guess is that AN external IRQ is triggered (possibly not the PHY IRQ) > but the ISR handler for that one is not ready yet. I will add debug > messages. > > > I would expect that situation to be a simple NOP, but it seems that > undefined handlers are set to this function "irq_unexpected_isr" > > Is that a new behaviour? a default config that I did not set properly > when porting our old defconfig? > > Sebastien > > > > > Nathan > Did you try disabling the PHY (or networking) in Kconfig to see if removing it from the build will eliminate the hardfault? Have you seen this about hardfault debugging: https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=139629445#content/view/139629445 Nathan
Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
Update: stack dump and register analysis are in fact pointing to a crash
in mm_alloc
I have enabled memory management debug:
mm_initialize: Heap: start=0x1000 size=65536
mm_addregion: Region 1: base=0x1154 size=65184
stm32_netinitialize: Enabling PHY power
stm32_netinitialize: PHY reset...
stm32_netinitialize: PHY reset done.
stm32_netinitialize: Configuring PHY int
F
mm_free: Freeing 0x70fb460b
irq_unexpected_isr: ERROR irq: 3
up_assert: Assertion failed at file:irq/irq_unexpectedisr.c line: 50
up_registerdump: R0: 0001 2000737c c0f2 08000101
200073c8
up_registerdump: R8:
200073c8 080126ad 080126f8
up_registerdump: xPSR: 2100 PRIMASK: CONTROL:
up_registerdump: EXC_RETURN: fff9
up_dumpstate: sp: 200072c8
up_dumpstate: stack base: 20007078
up_dumpstate: stack size: 0400
The fact that mm_initialize only shows one region is weird... where is
the heap for the main RAM at 0x2000?
the mm_free(0x70fb460b) is not what causes the hardfault (it comes
later), but what the hell is is this invalid address!
This is the first call to mm_free, here is the backtrace:
Breakpoint 1, mm_free (heap=0x200060b4 , mem=0x70fb460b) at
mm_heap/mm_free.c:85
85 if (!mem)
(gdb) bt
#0 mm_free (heap=0x200060b4 , mem=0x70fb460b) at
mm_heap/mm_free.c:85
#1 0x0801264a in mm_free_delaylist (heap=0x200060b4 ) at
mm_heap/mm_malloc.c:82
#2 0x08012672 in mm_malloc (heap=0x200060b4 , size=24) at
mm_heap/mm_malloc.c:115
#3 0x08012a32 in mm_zalloc (heap=0x200060b4 , size=24) at
mm_heap/mm_zalloc.c:45
#4 0x080123ac in zalloc (size=24) at umm_heap/umm_zalloc.c:68
#5 0x080399fa in inode_alloc (name=0x8059a78 "") at
inode/fs_inodereserve.c:78
#6 0x08039a5c in inode_root_reserve () at inode/fs_inodereserve.c:129
#7 0x080398cc in inode_initialize () at inode/fs_inode.c:92
#8 0x08039284 in fs_initialize () at fs_initialize.c:47
#9 0x08007eb4 in nx_start () at init/nx_start.c:600
#10 0x0800421e in __start () at chip/stm32_start.c:338
As previously analyzed, this happens in fs_initialize through
inode_root_reserve, so I was on the right track.
Caller shows mm_free called with that weird address:
(gdb) f 1
#1 0x0801264a in mm_free_delaylist (heap=0x200060b4 ) at
mm_heap/mm_malloc.c:82
82 mm_free(heap, address);
(gdb) list
77
78 /* The address should always be non-NULL since that was
checked in the
79 * 'while' condition above.
80 */
81
82 mm_free(heap, address); <-- address == 0x70fb460b
83 }
84 #endif
85 }
86
(gdb) print &g_mmheap
$3 = (struct mm_heap_s *) 0x200060b4
(gdb) print g_mmheap
$4 = {mm_impl = 0x0}
this is not good!
This is not a timing or IRQ related issue but a heap issue.
R15 = 080126f8 translates to here:
https://github.com/apache/incubator-nuttx/blob/master/mm/mm_heap/mm_malloc.c#L199
=> this free() has corrupted a badly initialized heap, and the next
malloc fails, giving a hardfault because that address is invalid.
Horrific mess!
==>
I think that my old board code does not initialize the board properly, I
probably have to check for differences between my code and the
stm32f429i-disco built-in board (on which I based my board).
Sebastien
Le 25/05/2021 à 21:26, Nathan Hartman a écrit :
On Tue, May 25, 2021 at 12:02 PM Sebastien Lorquet
wrote:
Back to the business
After this we managed to recompile our project using the latest NuttX
sources, but it fails when trying to init the PHY irq on our STM32F427
board: We get "unexpected IRQ".
Yes I know that's pretty vague :-)
Is there anything obvious I should have been careful with in this
domain, before I dig the jtag probe to fix it (tomorrow) ?
I would first start by looking through the Release Notes between v7.30
and v10.1. Many big improvements and bug fixes happened and some of
them are mentioned in Compatibility Concerns along with some changes
you might need to make to configuration etc.
Also another thing you can try: Has this board and PHY worked
correctly with v7.30? If so, you can bisect and with very few tests
(I'm guessing fewer than 20) find the exact commit that broke it.
Release notes are hard to read but I did not find anything special about
phy interrupts.
Note that it may not be the phy interrupt. Here is my log:
stm32_netinitialize: Enabling PHY power
stm32_netinitialize: PHY reset...
stm32_netinitialize: PHY reset done.
stm32_netinitialize: Configuring PHY int
F
irq_unexpected_isr: ERROR irq: 3
up_assert: Assertion failed at file:irq/irq_unexpectedisr.c line: 50
up_registerdump: R0: 0001 2000737c c0f2 08000101
200073c8
up_registerdump: R8:
200073c8 080126ad 080126f8
up_registerdump: xPSR: 2100 PRIMASK: CONTROL:
up_registerdump: EXC_RETURN: fff9
A lot of OS initialization things happen at the po
Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
If you use CONFIG_BUILD_FLAT=y, make sure that __KERNEL__ flag is set here:
https://github.com/apache/incubator-nuttx/blob/master/include/nuttx/mm/mm.h#L85
I remember that at some point I had a similar hardfault in mm which doesn't
make sense and it was due to outdated board Make.defs.
śr., 26 maj 2021 o 17:21 Sebastien Lorquet
napisał(a):
> Update: stack dump and register analysis are in fact pointing to a crash
> in mm_alloc
>
> I have enabled memory management debug:
>
> mm_initialize: Heap: start=0x1000 size=65536
> mm_addregion: Region 1: base=0x1154 size=65184
> stm32_netinitialize: Enabling PHY power
> stm32_netinitialize: PHY reset...
> stm32_netinitialize: PHY reset done.
> stm32_netinitialize: Configuring PHY int
> F
> mm_free: Freeing 0x70fb460b
> irq_unexpected_isr: ERROR irq: 3
> up_assert: Assertion failed at file:irq/irq_unexpectedisr.c line: 50
> up_registerdump: R0: 0001 2000737c c0f2 08000101
> 200073c8
> up_registerdump: R8:
> 200073c8 080126ad 080126f8
> up_registerdump: xPSR: 2100 PRIMASK: CONTROL:
> up_registerdump: EXC_RETURN: fff9
> up_dumpstate: sp: 200072c8
> up_dumpstate: stack base: 20007078
> up_dumpstate: stack size: 0400
>
> The fact that mm_initialize only shows one region is weird... where is
> the heap for the main RAM at 0x2000?
>
> the mm_free(0x70fb460b) is not what causes the hardfault (it comes
> later), but what the hell is is this invalid address!
>
> This is the first call to mm_free, here is the backtrace:
>
> Breakpoint 1, mm_free (heap=0x200060b4 , mem=0x70fb460b) at
> mm_heap/mm_free.c:85
> 85if (!mem)
> (gdb) bt
> #0 mm_free (heap=0x200060b4 , mem=0x70fb460b) at
> mm_heap/mm_free.c:85
> #1 0x0801264a in mm_free_delaylist (heap=0x200060b4 ) at
> mm_heap/mm_malloc.c:82
> #2 0x08012672 in mm_malloc (heap=0x200060b4 , size=24) at
> mm_heap/mm_malloc.c:115
> #3 0x08012a32 in mm_zalloc (heap=0x200060b4 , size=24) at
> mm_heap/mm_zalloc.c:45
> #4 0x080123ac in zalloc (size=24) at umm_heap/umm_zalloc.c:68
> #5 0x080399fa in inode_alloc (name=0x8059a78 "") at
> inode/fs_inodereserve.c:78
> #6 0x08039a5c in inode_root_reserve () at inode/fs_inodereserve.c:129
> #7 0x080398cc in inode_initialize () at inode/fs_inode.c:92
> #8 0x08039284 in fs_initialize () at fs_initialize.c:47
> #9 0x08007eb4 in nx_start () at init/nx_start.c:600
> #10 0x0800421e in __start () at chip/stm32_start.c:338
>
> As previously analyzed, this happens in fs_initialize through
> inode_root_reserve, so I was on the right track.
>
> Caller shows mm_free called with that weird address:
>
> (gdb) f 1
> #1 0x0801264a in mm_free_delaylist (heap=0x200060b4 ) at
> mm_heap/mm_malloc.c:82
> 82mm_free(heap, address);
> (gdb) list
> 77
> 78/* The address should always be non-NULL since that was
> checked in the
> 79 * 'while' condition above.
> 80 */
> 81
> 82mm_free(heap, address); <-- address == 0x70fb460b
> 83 }
> 84 #endif
> 85 }
> 86
>
> (gdb) print &g_mmheap
> $3 = (struct mm_heap_s *) 0x200060b4
> (gdb) print g_mmheap
> $4 = {mm_impl = 0x0}
>
> this is not good!
>
> This is not a timing or IRQ related issue but a heap issue.
>
> R15 = 080126f8 translates to here:
>
>
> https://github.com/apache/incubator-nuttx/blob/master/mm/mm_heap/mm_malloc.c#L199
>
> => this free() has corrupted a badly initialized heap, and the next
> malloc fails, giving a hardfault because that address is invalid.
>
> Horrific mess!
>
> ==>
>
> I think that my old board code does not initialize the board properly, I
> probably have to check for differences between my code and the
> stm32f429i-disco built-in board (on which I based my board).
>
> Sebastien
>
> Le 25/05/2021 à 21:26, Nathan Hartman a écrit :
> > On Tue, May 25, 2021 at 12:02 PM Sebastien Lorquet >
> > wrote:
> >
> >> Back to the business
> After this we managed to recompile our project using the latest NuttX
> sources, but it fails when trying to init the PHY irq on our STM32F427
> board: We get "unexpected IRQ".
>
> Yes I know that's pretty vague :-)
>
> Is there anything obvious I should have been careful with in this
> domain, before I dig the jtag probe to fix it (tomorrow) ?
> >>> I would first start by looking through the Release Notes between v7.30
> >>> and v10.1. Many big improvements and bug fixes happened and some of
> >>> them are mentioned in Compatibility Concerns along with some changes
> >>> you might need to make to configuration etc.
> >>>
> >>> Also another thing you can try: Has this board and PHY worked
> >>> correctly with v7.30? If so, you can bisect and with very few tests
> >>> (I'm guessing fewer than 20) find the exact commit that broke it.
> >> Release notes are hard to read but I did not find anything special about
> >> phy interrupts.
> >>
> >> Note that it may not b
Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
Hello,
Thanks for the remarks.
I am using the flat (monolithic build) and I see no place that define
this flag, at all.
I dont even see a place in the codebase that defines this flag.
I see nothing related to mm, nor anything outdated in my Make.defs,
which is from my old setup, yes, but still similar to a recent one.
Sebastien
Le 26/05/2021 à 18:08, raiden00pl a écrit :
If you use CONFIG_BUILD_FLAT=y, make sure that __KERNEL__ flag is set here:
https://github.com/apache/incubator-nuttx/blob/master/include/nuttx/mm/mm.h#L85
I remember that at some point I had a similar hardfault in mm which doesn't
make sense and it was due to outdated board Make.defs.
śr., 26 maj 2021 o 17:21 Sebastien Lorquet
napisał(a):
Update: stack dump and register analysis are in fact pointing to a crash
in mm_alloc
I have enabled memory management debug:
mm_initialize: Heap: start=0x1000 size=65536
mm_addregion: Region 1: base=0x1154 size=65184
stm32_netinitialize: Enabling PHY power
stm32_netinitialize: PHY reset...
stm32_netinitialize: PHY reset done.
stm32_netinitialize: Configuring PHY int
F
mm_free: Freeing 0x70fb460b
irq_unexpected_isr: ERROR irq: 3
up_assert: Assertion failed at file:irq/irq_unexpectedisr.c line: 50
up_registerdump: R0: 0001 2000737c c0f2 08000101
200073c8
up_registerdump: R8:
200073c8 080126ad 080126f8
up_registerdump: xPSR: 2100 PRIMASK: CONTROL:
up_registerdump: EXC_RETURN: fff9
up_dumpstate: sp: 200072c8
up_dumpstate: stack base: 20007078
up_dumpstate: stack size: 0400
The fact that mm_initialize only shows one region is weird... where is
the heap for the main RAM at 0x2000?
the mm_free(0x70fb460b) is not what causes the hardfault (it comes
later), but what the hell is is this invalid address!
This is the first call to mm_free, here is the backtrace:
Breakpoint 1, mm_free (heap=0x200060b4 , mem=0x70fb460b) at
mm_heap/mm_free.c:85
85if (!mem)
(gdb) bt
#0 mm_free (heap=0x200060b4 , mem=0x70fb460b) at
mm_heap/mm_free.c:85
#1 0x0801264a in mm_free_delaylist (heap=0x200060b4 ) at
mm_heap/mm_malloc.c:82
#2 0x08012672 in mm_malloc (heap=0x200060b4 , size=24) at
mm_heap/mm_malloc.c:115
#3 0x08012a32 in mm_zalloc (heap=0x200060b4 , size=24) at
mm_heap/mm_zalloc.c:45
#4 0x080123ac in zalloc (size=24) at umm_heap/umm_zalloc.c:68
#5 0x080399fa in inode_alloc (name=0x8059a78 "") at
inode/fs_inodereserve.c:78
#6 0x08039a5c in inode_root_reserve () at inode/fs_inodereserve.c:129
#7 0x080398cc in inode_initialize () at inode/fs_inode.c:92
#8 0x08039284 in fs_initialize () at fs_initialize.c:47
#9 0x08007eb4 in nx_start () at init/nx_start.c:600
#10 0x0800421e in __start () at chip/stm32_start.c:338
As previously analyzed, this happens in fs_initialize through
inode_root_reserve, so I was on the right track.
Caller shows mm_free called with that weird address:
(gdb) f 1
#1 0x0801264a in mm_free_delaylist (heap=0x200060b4 ) at
mm_heap/mm_malloc.c:82
82mm_free(heap, address);
(gdb) list
77
78/* The address should always be non-NULL since that was
checked in the
79 * 'while' condition above.
80 */
81
82mm_free(heap, address); <-- address == 0x70fb460b
83 }
84 #endif
85 }
86
(gdb) print &g_mmheap
$3 = (struct mm_heap_s *) 0x200060b4
(gdb) print g_mmheap
$4 = {mm_impl = 0x0}
this is not good!
This is not a timing or IRQ related issue but a heap issue.
R15 = 080126f8 translates to here:
https://github.com/apache/incubator-nuttx/blob/master/mm/mm_heap/mm_malloc.c#L199
=> this free() has corrupted a badly initialized heap, and the next
malloc fails, giving a hardfault because that address is invalid.
Horrific mess!
==>
I think that my old board code does not initialize the board properly, I
probably have to check for differences between my code and the
stm32f429i-disco built-in board (on which I based my board).
Sebastien
Le 25/05/2021 à 21:26, Nathan Hartman a écrit :
On Tue, May 25, 2021 at 12:02 PM Sebastien Lorquet
Back to the business
After this we managed to recompile our project using the latest NuttX
sources, but it fails when trying to init the PHY irq on our STM32F427
board: We get "unexpected IRQ".
Yes I know that's pretty vague :-)
Is there anything obvious I should have been careful with in this
domain, before I dig the jtag probe to fix it (tomorrow) ?
I would first start by looking through the Release Notes between v7.30
and v10.1. Many big improvements and bug fixes happened and some of
them are mentioned in Compatibility Concerns along with some changes
you might need to make to configuration etc.
Also another thing you can try: Has this board and PHY worked
correctly with v7.30? If so, you can bisect and with very few tests
(I'm guessing fewer than 20) find the exact commit that broke it.
Release notes are hard to read but I did not find anyt
Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
Maybe this one could help:
https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.1#NuttX9.1-CompatibilityConcerns
> I am using the flat (monolithic build) and I see no place that define
>this flag, at all.
>I dont even see a place in the codebase that defines this flag.
__KERNEL__ is defined in tools/Config.mk (line:100)
> The fact that mm_initialize only shows one region is weird... where is
the heap for the main RAM at 0x2000?
CONFIG_MM_REGIONS needs to be set up correctly if you have multiple
heap regions.
On Wed, May 26, 2021 at 5:22 PM Sebastien Lorquet wrote:
>
> Hello,
>
> Thanks for the remarks.
>
> I am using the flat (monolithic build) and I see no place that define
> this flag, at all.
>
> I dont even see a place in the codebase that defines this flag.
>
> I see nothing related to mm, nor anything outdated in my Make.defs,
> which is from my old setup, yes, but still similar to a recent one.
>
> Sebastien
>
> Le 26/05/2021 à 18:08, raiden00pl a écrit :
> > If you use CONFIG_BUILD_FLAT=y, make sure that __KERNEL__ flag is set here:
> > https://github.com/apache/incubator-nuttx/blob/master/include/nuttx/mm/mm.h#L85
> > I remember that at some point I had a similar hardfault in mm which doesn't
> > make sense and it was due to outdated board Make.defs.
> >
> > śr., 26 maj 2021 o 17:21 Sebastien Lorquet
> > napisał(a):
> >
> >> Update: stack dump and register analysis are in fact pointing to a crash
> >> in mm_alloc
> >>
> >> I have enabled memory management debug:
> >>
> >> mm_initialize: Heap: start=0x1000 size=65536
> >> mm_addregion: Region 1: base=0x1154 size=65184
> >> stm32_netinitialize: Enabling PHY power
> >> stm32_netinitialize: PHY reset...
> >> stm32_netinitialize: PHY reset done.
> >> stm32_netinitialize: Configuring PHY int
> >> F
> >> mm_free: Freeing 0x70fb460b
> >> irq_unexpected_isr: ERROR irq: 3
> >> up_assert: Assertion failed at file:irq/irq_unexpectedisr.c line: 50
> >> up_registerdump: R0: 0001 2000737c c0f2 08000101
> >> 200073c8
> >> up_registerdump: R8:
> >> 200073c8 080126ad 080126f8
> >> up_registerdump: xPSR: 2100 PRIMASK: CONTROL:
> >> up_registerdump: EXC_RETURN: fff9
> >> up_dumpstate: sp: 200072c8
> >> up_dumpstate: stack base: 20007078
> >> up_dumpstate: stack size: 0400
> >>
> >> The fact that mm_initialize only shows one region is weird... where is
> >> the heap for the main RAM at 0x2000?
> >>
> >> the mm_free(0x70fb460b) is not what causes the hardfault (it comes
> >> later), but what the hell is is this invalid address!
> >>
> >> This is the first call to mm_free, here is the backtrace:
> >>
> >> Breakpoint 1, mm_free (heap=0x200060b4 , mem=0x70fb460b) at
> >> mm_heap/mm_free.c:85
> >> 85if (!mem)
> >> (gdb) bt
> >> #0 mm_free (heap=0x200060b4 , mem=0x70fb460b) at
> >> mm_heap/mm_free.c:85
> >> #1 0x0801264a in mm_free_delaylist (heap=0x200060b4 ) at
> >> mm_heap/mm_malloc.c:82
> >> #2 0x08012672 in mm_malloc (heap=0x200060b4 , size=24) at
> >> mm_heap/mm_malloc.c:115
> >> #3 0x08012a32 in mm_zalloc (heap=0x200060b4 , size=24) at
> >> mm_heap/mm_zalloc.c:45
> >> #4 0x080123ac in zalloc (size=24) at umm_heap/umm_zalloc.c:68
> >> #5 0x080399fa in inode_alloc (name=0x8059a78 "") at
> >> inode/fs_inodereserve.c:78
> >> #6 0x08039a5c in inode_root_reserve () at inode/fs_inodereserve.c:129
> >> #7 0x080398cc in inode_initialize () at inode/fs_inode.c:92
> >> #8 0x08039284 in fs_initialize () at fs_initialize.c:47
> >> #9 0x08007eb4 in nx_start () at init/nx_start.c:600
> >> #10 0x0800421e in __start () at chip/stm32_start.c:338
> >>
> >> As previously analyzed, this happens in fs_initialize through
> >> inode_root_reserve, so I was on the right track.
> >>
> >> Caller shows mm_free called with that weird address:
> >>
> >> (gdb) f 1
> >> #1 0x0801264a in mm_free_delaylist (heap=0x200060b4 ) at
> >> mm_heap/mm_malloc.c:82
> >> 82mm_free(heap, address);
> >> (gdb) list
> >> 77
> >> 78/* The address should always be non-NULL since that was
> >> checked in the
> >> 79 * 'while' condition above.
> >> 80 */
> >> 81
> >> 82mm_free(heap, address); <-- address == 0x70fb460b
> >> 83 }
> >> 84 #endif
> >> 85 }
> >> 86
> >>
> >> (gdb) print &g_mmheap
> >> $3 = (struct mm_heap_s *) 0x200060b4
> >> (gdb) print g_mmheap
> >> $4 = {mm_impl = 0x0}
> >>
> >> this is not good!
> >>
> >> This is not a timing or IRQ related issue but a heap issue.
> >>
> >> R15 = 080126f8 translates to here:
> >>
> >>
> >> https://github.com/apache/incubator-nuttx/blob/master/mm/mm_heap/mm_malloc.c#L199
> >>
> >> => this free() has corrupted a badly initialized heap, and the next
> >> malloc fails, giving a hardfault because that address is invalid.
> >>
> >> Horrific mess!
> >>
> >> ==>
> >>
> >> I think that my old board code does not initialize the board proper
RE: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
Hi Sebastien,
Stack crashing into heap?
Have you upped the stack sizes across the board?
David
-Original Message-
From: Sebastien Lorquet [mailto:sebast...@lorquet.fr]
Sent: Wednesday, May 26, 2021 9:22 AM
To: dev@nuttx.apache.org
Subject: Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
Hello,
Thanks for the remarks.
I am using the flat (monolithic build) and I see no place that define
this flag, at all.
I dont even see a place in the codebase that defines this flag.
I see nothing related to mm, nor anything outdated in my Make.defs,
which is from my old setup, yes, but still similar to a recent one.
Sebastien
Le 26/05/2021 à 18:08, raiden00pl a écrit :
> If you use CONFIG_BUILD_FLAT=y, make sure that __KERNEL__ flag is set
> here:
> https://github.com/apache/incubator-nuttx/blob/master/include/nuttx/mm/mm.h#L85
> I remember that at some point I had a similar hardfault in mm which
> doesn't
> make sense and it was due to outdated board Make.defs.
>
> śr., 26 maj 2021 o 17:21 Sebastien Lorquet
> napisał(a):
>
>> Update: stack dump and register analysis are in fact pointing to a crash
>> in mm_alloc
>>
>> I have enabled memory management debug:
>>
>> mm_initialize: Heap: start=0x1000 size=65536
>> mm_addregion: Region 1: base=0x1154 size=65184
>> stm32_netinitialize: Enabling PHY power
>> stm32_netinitialize: PHY reset...
>> stm32_netinitialize: PHY reset done.
>> stm32_netinitialize: Configuring PHY int
>> F
>> mm_free: Freeing 0x70fb460b
>> irq_unexpected_isr: ERROR irq: 3
>> up_assert: Assertion failed at file:irq/irq_unexpectedisr.c line: 50
>> up_registerdump: R0: 0001 2000737c c0f2 08000101
>> 200073c8
>> up_registerdump: R8:
>> 200073c8 080126ad 080126f8
>> up_registerdump: xPSR: 2100 PRIMASK: CONTROL:
>> up_registerdump: EXC_RETURN: fff9
>> up_dumpstate: sp: 200072c8
>> up_dumpstate: stack base: 20007078
>> up_dumpstate: stack size: 0400
>>
>> The fact that mm_initialize only shows one region is weird... where is
>> the heap for the main RAM at 0x2000?
>>
>> the mm_free(0x70fb460b) is not what causes the hardfault (it comes
>> later), but what the hell is is this invalid address!
>>
>> This is the first call to mm_free, here is the backtrace:
>>
>> Breakpoint 1, mm_free (heap=0x200060b4 , mem=0x70fb460b) at
>> mm_heap/mm_free.c:85
>> 85if (!mem)
>> (gdb) bt
>> #0 mm_free (heap=0x200060b4 , mem=0x70fb460b) at
>> mm_heap/mm_free.c:85
>> #1 0x0801264a in mm_free_delaylist (heap=0x200060b4 ) at
>> mm_heap/mm_malloc.c:82
>> #2 0x08012672 in mm_malloc (heap=0x200060b4 , size=24) at
>> mm_heap/mm_malloc.c:115
>> #3 0x08012a32 in mm_zalloc (heap=0x200060b4 , size=24) at
>> mm_heap/mm_zalloc.c:45
>> #4 0x080123ac in zalloc (size=24) at umm_heap/umm_zalloc.c:68
>> #5 0x080399fa in inode_alloc (name=0x8059a78 "") at
>> inode/fs_inodereserve.c:78
>> #6 0x08039a5c in inode_root_reserve () at inode/fs_inodereserve.c:129
>> #7 0x080398cc in inode_initialize () at inode/fs_inode.c:92
>> #8 0x08039284 in fs_initialize () at fs_initialize.c:47
>> #9 0x08007eb4 in nx_start () at init/nx_start.c:600
>> #10 0x0800421e in __start () at chip/stm32_start.c:338
>>
>> As previously analyzed, this happens in fs_initialize through
>> inode_root_reserve, so I was on the right track.
>>
>> Caller shows mm_free called with that weird address:
>>
>> (gdb) f 1
>> #1 0x0801264a in mm_free_delaylist (heap=0x200060b4 ) at
>> mm_heap/mm_malloc.c:82
>> 82mm_free(heap, address);
>> (gdb) list
>> 77
>> 78/* The address should always be non-NULL since that was
>> checked in the
>> 79 * 'while' condition above.
>> 80 */
>> 81
>> 82mm_free(heap, address); <-- address == 0x70fb460b
>> 83 }
>> 84 #endif
>> 85 }
>> 86
>>
>> (gdb) print &g_mmheap
>> $3 = (struct mm_heap_s *) 0x200060b4
>> (gdb) print g_mmheap
>> $4 = {mm_impl = 0x0}
>>
>> this is not good!
>>
>> This is not a timing or IRQ related issue but a heap issue.
>>
>> R15 = 080126f8 translates to here:
>>
>>
>> https://github.com/apache/incubator-nuttx/blob/master/mm/mm_heap/mm_malloc.c#L199
>>
>> => this free() has corrupted a badly initialized heap, and the next
>> malloc fails, giving a hardfault because that addres
Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
Code was working perfectly before the nuttx upgrade so I tend to think
that stack is sufficient.
Sebastien
Le 26/05/2021 à 21:49, David Sidrane a écrit :
Hi Sebastien,
Stack crashing into heap?
Have you upped the stack sizes across the board?
David
-Original Message-
From: Sebastien Lorquet [mailto:sebast...@lorquet.fr]
Sent: Wednesday, May 26, 2021 9:22 AM
To: dev@nuttx.apache.org
Subject: Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
Hello,
Thanks for the remarks.
I am using the flat (monolithic build) and I see no place that define
this flag, at all.
I dont even see a place in the codebase that defines this flag.
I see nothing related to mm, nor anything outdated in my Make.defs,
which is from my old setup, yes, but still similar to a recent one.
Sebastien
Le 26/05/2021 à 18:08, raiden00pl a écrit :
If you use CONFIG_BUILD_FLAT=y, make sure that __KERNEL__ flag is set
here:
https://github.com/apache/incubator-nuttx/blob/master/include/nuttx/mm/mm.h#L85
I remember that at some point I had a similar hardfault in mm which
doesn't
make sense and it was due to outdated board Make.defs.
śr., 26 maj 2021 o 17:21 Sebastien Lorquet
napisał(a):
Update: stack dump and register analysis are in fact pointing to a crash
in mm_alloc
I have enabled memory management debug:
mm_initialize: Heap: start=0x1000 size=65536
mm_addregion: Region 1: base=0x1154 size=65184
stm32_netinitialize: Enabling PHY power
stm32_netinitialize: PHY reset...
stm32_netinitialize: PHY reset done.
stm32_netinitialize: Configuring PHY int
F
mm_free: Freeing 0x70fb460b
irq_unexpected_isr: ERROR irq: 3
up_assert: Assertion failed at file:irq/irq_unexpectedisr.c line: 50
up_registerdump: R0: 0001 2000737c c0f2 08000101
200073c8
up_registerdump: R8:
200073c8 080126ad 080126f8
up_registerdump: xPSR: 2100 PRIMASK: CONTROL:
up_registerdump: EXC_RETURN: fff9
up_dumpstate: sp: 200072c8
up_dumpstate: stack base: 20007078
up_dumpstate: stack size: 0400
The fact that mm_initialize only shows one region is weird... where is
the heap for the main RAM at 0x2000?
the mm_free(0x70fb460b) is not what causes the hardfault (it comes
later), but what the hell is is this invalid address!
This is the first call to mm_free, here is the backtrace:
Breakpoint 1, mm_free (heap=0x200060b4 , mem=0x70fb460b) at
mm_heap/mm_free.c:85
85if (!mem)
(gdb) bt
#0 mm_free (heap=0x200060b4 , mem=0x70fb460b) at
mm_heap/mm_free.c:85
#1 0x0801264a in mm_free_delaylist (heap=0x200060b4 ) at
mm_heap/mm_malloc.c:82
#2 0x08012672 in mm_malloc (heap=0x200060b4 , size=24) at
mm_heap/mm_malloc.c:115
#3 0x08012a32 in mm_zalloc (heap=0x200060b4 , size=24) at
mm_heap/mm_zalloc.c:45
#4 0x080123ac in zalloc (size=24) at umm_heap/umm_zalloc.c:68
#5 0x080399fa in inode_alloc (name=0x8059a78 "") at
inode/fs_inodereserve.c:78
#6 0x08039a5c in inode_root_reserve () at inode/fs_inodereserve.c:129
#7 0x080398cc in inode_initialize () at inode/fs_inode.c:92
#8 0x08039284 in fs_initialize () at fs_initialize.c:47
#9 0x08007eb4 in nx_start () at init/nx_start.c:600
#10 0x0800421e in __start () at chip/stm32_start.c:338
As previously analyzed, this happens in fs_initialize through
inode_root_reserve, so I was on the right track.
Caller shows mm_free called with that weird address:
(gdb) f 1
#1 0x0801264a in mm_free_delaylist (heap=0x200060b4 ) at
mm_heap/mm_malloc.c:82
82mm_free(heap, address);
(gdb) list
77
78/* The address should always be non-NULL since that was
checked in the
79 * 'while' condition above.
80 */
81
82mm_free(heap, address); <-- address == 0x70fb460b
83 }
84 #endif
85 }
86
(gdb) print &g_mmheap
$3 = (struct mm_heap_s *) 0x200060b4
(gdb) print g_mmheap
$4 = {mm_impl = 0x0}
this is not good!
This is not a timing or IRQ related issue but a heap issue.
R15 = 080126f8 translates to here:
https://github.com/apache/incubator-nuttx/blob/master/mm/mm_heap/mm_malloc.c#L199
=> this free() has corrupted a badly initialized heap, and the next
malloc fails, giving a hardfault because that address is invalid.
Horrific mess!
==>
I think that my old board code does not initialize the board properly, I
probably have to check for differences between my code and the
stm32f429i-disco built-in board (on which I based my board).
Sebastien
Le 25/05/2021 à 21:26, Nathan Hartman a écrit :
On Tue, May 25, 2021 at 12:02 PM Sebastien Lorquet
Back to the business
After this we managed to recompile our project using the latest NuttX
sources, but it fails when trying to init the PHY irq on our
STM32F427
board: We get "unexpected IRQ".
Yes I know that's pretty vague :-)
Is there anything obvious I should have been careful with in this
domain, before I dig the jtag probe t
Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
Boom, that was the extrastuff. The board now boots. We're going to run a
lot of functional tests to make sure everything is okay, but I dont have
this strange hardfault at boot.
Thank you.
I did not find this page despite searching through a lot of
documentation, mainly the "official" ReadTheDocs-like documentation.
I suggest you link to this doc in the getting started manuals.
Sebastien
Le 26/05/2021 à 18:42, Abdelatif Guettouche a écrit :
Maybe this one could help:
https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.1#NuttX9.1-CompatibilityConcerns
I am using the flat (monolithic build) and I see no place that define
this flag, at all.
I dont even see a place in the codebase that defines this flag.
__KERNEL__ is defined in tools/Config.mk (line:100)
The fact that mm_initialize only shows one region is weird... where is
the heap for the main RAM at 0x2000?
CONFIG_MM_REGIONS needs to be set up correctly if you have multiple
heap regions.
On Wed, May 26, 2021 at 5:22 PM Sebastien Lorquet wrote:
Hello,
Thanks for the remarks.
I am using the flat (monolithic build) and I see no place that define
this flag, at all.
I dont even see a place in the codebase that defines this flag.
I see nothing related to mm, nor anything outdated in my Make.defs,
which is from my old setup, yes, but still similar to a recent one.
Sebastien
Le 26/05/2021 à 18:08, raiden00pl a écrit :
If you use CONFIG_BUILD_FLAT=y, make sure that __KERNEL__ flag is set here:
https://github.com/apache/incubator-nuttx/blob/master/include/nuttx/mm/mm.h#L85
I remember that at some point I had a similar hardfault in mm which doesn't
make sense and it was due to outdated board Make.defs.
śr., 26 maj 2021 o 17:21 Sebastien Lorquet
napisał(a):
Update: stack dump and register analysis are in fact pointing to a crash
in mm_alloc
I have enabled memory management debug:
mm_initialize: Heap: start=0x1000 size=65536
mm_addregion: Region 1: base=0x1154 size=65184
stm32_netinitialize: Enabling PHY power
stm32_netinitialize: PHY reset...
stm32_netinitialize: PHY reset done.
stm32_netinitialize: Configuring PHY int
F
mm_free: Freeing 0x70fb460b
irq_unexpected_isr: ERROR irq: 3
up_assert: Assertion failed at file:irq/irq_unexpectedisr.c line: 50
up_registerdump: R0: 0001 2000737c c0f2 08000101
200073c8
up_registerdump: R8:
200073c8 080126ad 080126f8
up_registerdump: xPSR: 2100 PRIMASK: CONTROL:
up_registerdump: EXC_RETURN: fff9
up_dumpstate: sp: 200072c8
up_dumpstate: stack base: 20007078
up_dumpstate: stack size: 0400
The fact that mm_initialize only shows one region is weird... where is
the heap for the main RAM at 0x2000?
the mm_free(0x70fb460b) is not what causes the hardfault (it comes
later), but what the hell is is this invalid address!
This is the first call to mm_free, here is the backtrace:
Breakpoint 1, mm_free (heap=0x200060b4 , mem=0x70fb460b) at
mm_heap/mm_free.c:85
85if (!mem)
(gdb) bt
#0 mm_free (heap=0x200060b4 , mem=0x70fb460b) at
mm_heap/mm_free.c:85
#1 0x0801264a in mm_free_delaylist (heap=0x200060b4 ) at
mm_heap/mm_malloc.c:82
#2 0x08012672 in mm_malloc (heap=0x200060b4 , size=24) at
mm_heap/mm_malloc.c:115
#3 0x08012a32 in mm_zalloc (heap=0x200060b4 , size=24) at
mm_heap/mm_zalloc.c:45
#4 0x080123ac in zalloc (size=24) at umm_heap/umm_zalloc.c:68
#5 0x080399fa in inode_alloc (name=0x8059a78 "") at
inode/fs_inodereserve.c:78
#6 0x08039a5c in inode_root_reserve () at inode/fs_inodereserve.c:129
#7 0x080398cc in inode_initialize () at inode/fs_inode.c:92
#8 0x08039284 in fs_initialize () at fs_initialize.c:47
#9 0x08007eb4 in nx_start () at init/nx_start.c:600
#10 0x0800421e in __start () at chip/stm32_start.c:338
As previously analyzed, this happens in fs_initialize through
inode_root_reserve, so I was on the right track.
Caller shows mm_free called with that weird address:
(gdb) f 1
#1 0x0801264a in mm_free_delaylist (heap=0x200060b4 ) at
mm_heap/mm_malloc.c:82
82mm_free(heap, address);
(gdb) list
77
78/* The address should always be non-NULL since that was
checked in the
79 * 'while' condition above.
80 */
81
82mm_free(heap, address); <-- address == 0x70fb460b
83 }
84 #endif
85 }
86
(gdb) print &g_mmheap
$3 = (struct mm_heap_s *) 0x200060b4
(gdb) print g_mmheap
$4 = {mm_impl = 0x0}
this is not good!
This is not a timing or IRQ related issue but a heap issue.
R15 = 080126f8 translates to here:
https://github.com/apache/incubator-nuttx/blob/master/mm/mm_heap/mm_malloc.c#L199
=> this free() has corrupted a badly initialized heap, and the next
malloc fails, giving a hardfault because that address is invalid.
Horrific mess!
==>
I think that my old board code does not initialize the board properly, I
probably have to check for differences between my code and the
s
Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
I sill wonder what is the purpose of this variable rename. Sorry to say, but it just looks cosmetic while critically breaking everything that was made before, and this kind of thing is a nightmare for migration when you cant follow the project day to day. Boards can be external to the project, and are a supported feature, so they should continue to work reliably even if you change the internal sauce! At one point there was too many trafic on the mailing list and I just stopped reading it, I marked several hundreds of messages as read without having the time to go through then. It seems that this change was made during this time. Sebastien Le 27/05/2021 à 09:38, Sebastien Lorquet a écrit : Boom, that was the extrastuff. The board now boots. We're going to run a lot of functional tests to make sure everything is okay, but I dont have this strange hardfault at boot. Thank you. I did not find this page despite searching through a lot of documentation, mainly the "official" ReadTheDocs-like documentation. I suggest you link to this doc in the getting started manuals. Sebastien Le 26/05/2021 à 18:42, Abdelatif Guettouche a écrit : Maybe this one could help: https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.1#NuttX9.1-CompatibilityConcerns I am using the flat (monolithic build) and I see no place that define this flag, at all. I dont even see a place in the codebase that defines this flag. __KERNEL__ is defined in tools/Config.mk (line:100) The fact that mm_initialize only shows one region is weird... where is the heap for the main RAM at 0x2000? CONFIG_MM_REGIONS needs to be set up correctly if you have multiple heap regions. On Wed, May 26, 2021 at 5:22 PM Sebastien Lorquet wrote: Hello, Thanks for the remarks. I am using the flat (monolithic build) and I see no place that define this flag, at all. I dont even see a place in the codebase that defines this flag. I see nothing related to mm, nor anything outdated in my Make.defs, which is from my old setup, yes, but still similar to a recent one. Sebastien Le 26/05/2021 à 18:08, raiden00pl a écrit : If you use CONFIG_BUILD_FLAT=y, make sure that __KERNEL__ flag is set here: https://github.com/apache/incubator-nuttx/blob/master/include/nuttx/mm/mm.h#L85 I remember that at some point I had a similar hardfault in mm which doesn't make sense and it was due to outdated board Make.defs. śr., 26 maj 2021 o 17:21 Sebastien Lorquet napisał(a): Update: stack dump and register analysis are in fact pointing to a crash in mm_alloc I have enabled memory management debug: mm_initialize: Heap: start=0x1000 size=65536 mm_addregion: Region 1: base=0x1154 size=65184 stm32_netinitialize: Enabling PHY power stm32_netinitialize: PHY reset... stm32_netinitialize: PHY reset done. stm32_netinitialize: Configuring PHY int F mm_free: Freeing 0x70fb460b irq_unexpected_isr: ERROR irq: 3 up_assert: Assertion failed at file:irq/irq_unexpectedisr.c line: 50 up_registerdump: R0: 0001 2000737c c0f2 08000101 200073c8 up_registerdump: R8: 200073c8 080126ad 080126f8 up_registerdump: xPSR: 2100 PRIMASK: CONTROL: up_registerdump: EXC_RETURN: fff9 up_dumpstate: sp: 200072c8 up_dumpstate: stack base: 20007078 up_dumpstate: stack size: 0400 The fact that mm_initialize only shows one region is weird... where is the heap for the main RAM at 0x2000? the mm_free(0x70fb460b) is not what causes the hardfault (it comes later), but what the hell is is this invalid address! This is the first call to mm_free, here is the backtrace: Breakpoint 1, mm_free (heap=0x200060b4 , mem=0x70fb460b) at mm_heap/mm_free.c:85 85 if (!mem) (gdb) bt #0 mm_free (heap=0x200060b4 , mem=0x70fb460b) at mm_heap/mm_free.c:85 #1 0x0801264a in mm_free_delaylist (heap=0x200060b4 ) at mm_heap/mm_malloc.c:82 #2 0x08012672 in mm_malloc (heap=0x200060b4 , size=24) at mm_heap/mm_malloc.c:115 #3 0x08012a32 in mm_zalloc (heap=0x200060b4 , size=24) at mm_heap/mm_zalloc.c:45 #4 0x080123ac in zalloc (size=24) at umm_heap/umm_zalloc.c:68 #5 0x080399fa in inode_alloc (name=0x8059a78 "") at inode/fs_inodereserve.c:78 #6 0x08039a5c in inode_root_reserve () at inode/fs_inodereserve.c:129 #7 0x080398cc in inode_initialize () at inode/fs_inode.c:92 #8 0x08039284 in fs_initialize () at fs_initialize.c:47 #9 0x08007eb4 in nx_start () at init/nx_start.c:600 #10 0x0800421e in __start () at chip/stm32_start.c:338 As previously analyzed, this happens in fs_initialize through inode_root_reserve, so I was on the right track. Caller shows mm_free called with that weird address: (gdb) f 1 #1 0x0801264a in mm_free_delaylist (heap=0x200060b4 ) at mm_heap/mm_malloc.c:82 82 mm_free(heap, address); (gdb) list 77 78 /* The address should always be non-NULL since that was checked in the 79 * 'while' condition above.
Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
I think a benefit from renaming many of those "up_something" to "stm32_something", "esp32_something", etc is now it is easy for software find the right function. I think many IDEs cannot handle functions search correctly for NuttX because they don't have heuristics to know that IF I'm searching a function inside a board or inside an arch, it shouldn't return a function with same name from other board or from other arch. So, at end-of-day, these modifications you are complain about, will make the life of all users better. BR, Alan On 5/27/21, Sebastien Lorquet wrote: > I sill wonder what is the purpose of this variable rename. Sorry to say, > but it just looks cosmetic while critically breaking everything that was > made before, and this kind of thing is a nightmare for migration when > you cant follow the project day to day. Boards can be external to the > project, and are a supported feature, so they should continue to work > reliably even if you change the internal sauce! > > At one point there was too many trafic on the mailing list and I just > stopped reading it, I marked several hundreds of messages as read > without having the time to go through then. It seems that this change > was made during this time. > > Sebastien > > Le 27/05/2021 à 09:38, Sebastien Lorquet a écrit : >> Boom, that was the extrastuff. The board now boots. We're going to run >> a lot of functional tests to make sure everything is okay, but I dont >> have this strange hardfault at boot. >> >> Thank you. >> >> I did not find this page despite searching through a lot of >> documentation, mainly the "official" ReadTheDocs-like documentation. >> >> I suggest you link to this doc in the getting started manuals. >> >> Sebastien >> >> >> Le 26/05/2021 à 18:42, Abdelatif Guettouche a écrit : >>> Maybe this one could help: >>> https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.1#NuttX9.1-CompatibilityConcerns >>> >>> >>> I am using the flat (monolithic build) and I see no place that define this flag, at all. I dont even see a place in the codebase that defines this flag. >>> __KERNEL__ is defined in tools/Config.mk (line:100) >>> The fact that mm_initialize only shows one region is weird... where is >>> the heap for the main RAM at 0x2000? >>> >>> CONFIG_MM_REGIONS needs to be set up correctly if you have multiple >>> heap regions. >>> >>> On Wed, May 26, 2021 at 5:22 PM Sebastien Lorquet >>> wrote: Hello, Thanks for the remarks. I am using the flat (monolithic build) and I see no place that define this flag, at all. I dont even see a place in the codebase that defines this flag. I see nothing related to mm, nor anything outdated in my Make.defs, which is from my old setup, yes, but still similar to a recent one. Sebastien Le 26/05/2021 à 18:08, raiden00pl a écrit : > If you use CONFIG_BUILD_FLAT=y, make sure that __KERNEL__ flag is > set here: > https://github.com/apache/incubator-nuttx/blob/master/include/nuttx/mm/mm.h#L85 > > > I remember that at some point I had a similar hardfault in mm which > doesn't > make sense and it was due to outdated board Make.defs. > > śr., 26 maj 2021 o 17:21 Sebastien Lorquet > napisał(a): > >> Update: stack dump and register analysis are in fact pointing to a >> crash >> in mm_alloc >> >> I have enabled memory management debug: >> >> mm_initialize: Heap: start=0x1000 size=65536 >> mm_addregion: Region 1: base=0x1154 size=65184 >> stm32_netinitialize: Enabling PHY power >> stm32_netinitialize: PHY reset... >> stm32_netinitialize: PHY reset done. >> stm32_netinitialize: Configuring PHY int >> F >> mm_free: Freeing 0x70fb460b >> irq_unexpected_isr: ERROR irq: 3 >> up_assert: Assertion failed at file:irq/irq_unexpectedisr.c line: 50 >> up_registerdump: R0: 0001 2000737c c0f2 08000101 >> 200073c8 >> up_registerdump: R8: >> 200073c8 080126ad 080126f8 >> up_registerdump: xPSR: 2100 PRIMASK: CONTROL: >> up_registerdump: EXC_RETURN: fff9 >> up_dumpstate: sp: 200072c8 >> up_dumpstate: stack base: 20007078 >> up_dumpstate: stack size: 0400 >> >> The fact that mm_initialize only shows one region is weird... >> where is >> the heap for the main RAM at 0x2000? >> >> the mm_free(0x70fb460b) is not what causes the hardfault (it comes >> later), but what the hell is is this invalid address! >> >> This is the first call to mm_free, here is the backtrace: >> >> Breakpoint 1, mm_free (heap=0x200060b4 , mem=0x70fb460b) at >> mm_heap/mm_free.c:85 >> 85if (!mem) >> (gdb) bt >> #0 mm_free (heap=0x200060b4 , mem=0x70fb460b) at >> mm_heap/mm_free.c:85 >> #1 0x0801264a
Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
I'm not talking of renaming code symbols like up_anything to arm_anything, which makes sense and can be noticed quite easily at link stage. I'm talking about renaming a shell/make variable from EXTRADEFINES to EXTRAFLAGS. This is hidden, and the build system has no way to complain about anything missing. Of course, this has no impact on any built-in board, because the change was made locally. so CI cannot detect this. But this breaks ALL the custom boards people actually use for real projects. And the relevant documentation is hidden at the bottom of some obsolete (nuttx 9) release notes, in a "concerns" section. This doc is critical from anyone porting a custom board from pre-9 nuttx to current one. I cant believe I'm the only one in this case... Sebastien Le 27/05/2021 à 16:51, Alan Carvalho de Assis a écrit : I think a benefit from renaming many of those "up_something" to "stm32_something", "esp32_something", etc is now it is easy for software find the right function. I think many IDEs cannot handle functions search correctly for NuttX because they don't have heuristics to know that IF I'm searching a function inside a board or inside an arch, it shouldn't return a function with same name from other board or from other arch. So, at end-of-day, these modifications you are complain about, will make the life of all users better. BR, Alan On 5/27/21, Sebastien Lorquet wrote: I sill wonder what is the purpose of this variable rename. Sorry to say, but it just looks cosmetic while critically breaking everything that was made before, and this kind of thing is a nightmare for migration when you cant follow the project day to day. Boards can be external to the project, and are a supported feature, so they should continue to work reliably even if you change the internal sauce! At one point there was too many trafic on the mailing list and I just stopped reading it, I marked several hundreds of messages as read without having the time to go through then. It seems that this change was made during this time. Sebastien Le 27/05/2021 à 09:38, Sebastien Lorquet a écrit : Boom, that was the extrastuff. The board now boots. We're going to run a lot of functional tests to make sure everything is okay, but I dont have this strange hardfault at boot. Thank you. I did not find this page despite searching through a lot of documentation, mainly the "official" ReadTheDocs-like documentation. I suggest you link to this doc in the getting started manuals. Sebastien Le 26/05/2021 à 18:42, Abdelatif Guettouche a écrit : Maybe this one could help: https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.1#NuttX9.1-CompatibilityConcerns I am using the flat (monolithic build) and I see no place that define this flag, at all. I dont even see a place in the codebase that defines this flag. __KERNEL__ is defined in tools/Config.mk (line:100) The fact that mm_initialize only shows one region is weird... where is the heap for the main RAM at 0x2000? CONFIG_MM_REGIONS needs to be set up correctly if you have multiple heap regions. On Wed, May 26, 2021 at 5:22 PM Sebastien Lorquet wrote: Hello, Thanks for the remarks. I am using the flat (monolithic build) and I see no place that define this flag, at all. I dont even see a place in the codebase that defines this flag. I see nothing related to mm, nor anything outdated in my Make.defs, which is from my old setup, yes, but still similar to a recent one. Sebastien Le 26/05/2021 à 18:08, raiden00pl a écrit : If you use CONFIG_BUILD_FLAT=y, make sure that __KERNEL__ flag is set here: https://github.com/apache/incubator-nuttx/blob/master/include/nuttx/mm/mm.h#L85 I remember that at some point I had a similar hardfault in mm which doesn't make sense and it was due to outdated board Make.defs. śr., 26 maj 2021 o 17:21 Sebastien Lorquet napisał(a): Update: stack dump and register analysis are in fact pointing to a crash in mm_alloc I have enabled memory management debug: mm_initialize: Heap: start=0x1000 size=65536 mm_addregion: Region 1: base=0x1154 size=65184 stm32_netinitialize: Enabling PHY power stm32_netinitialize: PHY reset... stm32_netinitialize: PHY reset done. stm32_netinitialize: Configuring PHY int F mm_free: Freeing 0x70fb460b irq_unexpected_isr: ERROR irq: 3 up_assert: Assertion failed at file:irq/irq_unexpectedisr.c line: 50 up_registerdump: R0: 0001 2000737c c0f2 08000101 200073c8 up_registerdump: R8: 200073c8 080126ad 080126f8 up_registerdump: xPSR: 2100 PRIMASK: CONTROL: up_registerdump: EXC_RETURN: fff9 up_dumpstate: sp: 200072c8 up_dumpstate: stack base: 20007078 up_dumpstate: stack size: 0400 The fact that mm_initialize only shows one region is weird... where is the heap for the main RAM at 0x2000? the mm_free(0x70fb460b) is not what causes the hardfault (it comes later), but what
Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
On Fri, May 28, 2021 at 9:12 AM Sebastien Lorquet wrote: > I'm not talking of renaming code symbols like up_anything to > arm_anything, which makes sense and can be noticed quite easily at link > stage. > > I'm talking about renaming a shell/make variable from EXTRADEFINES to > EXTRAFLAGS. This is hidden, and the build system has no way to complain > about anything missing. > > Of course, this has no impact on any built-in board, because the change > was made locally. so CI cannot detect this. > > But this breaks ALL the custom boards people actually use for real > projects. > > And the relevant documentation is hidden at the bottom of some obsolete > (nuttx 9) release notes, in a "concerns" section. > > This doc is critical from anyone porting a custom board from pre-9 nuttx > to current one. > > I cant believe I'm the only one in this case... > > Sebastien Yes, it's documented way near the bottom of the very long ReleaseNotes file and is hard to find. Several things we could do to improve: 1. When we make a change like this, detect the obsolete define in the build system and give some kind of warning? 2. Split up the ReleaseNotes file? As it is now, it reads a bit more like a ChangeLog rather than ReleaseNotes. In the past we talked about a Documentation/ReleaseNotes directory that could hold a separate ReleaseNotes for each major version? 3. Make a ReleaseNotes section of the website that will render those ReleaseNotes files and offer an easy to use index, so it's easier to find this information. The newer ones are Markdown but not rendered as such when opened in any text editor or browser because of all the preexisting non-markdown content. 4. Add a troubleshooting (or FAQ) section to the website and add this EXTRAFLAGS case to it, i.e., list the symptom and give this as a potential cause to check for. 5. We use semantic versioning, but it would be worthwhile to check if the major version number was bumped in the first release that contained this change. If not, that might have been a mistake. Any other thoughts? Nathan
Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
On Fri, May 28, 2021, 7:54 AM Nathan Hartman wrote: > On Fri, May 28, 2021 at 9:12 AM Sebastien Lorquet > wrote: > > > I'm not talking of renaming code symbols like up_anything to > > arm_anything, which makes sense and can be noticed quite easily at link > > stage. > > > > I'm talking about renaming a shell/make variable from EXTRADEFINES to > > EXTRAFLAGS. This is hidden, and the build system has no way to complain > > about anything missing. > > > > Of course, this has no impact on any built-in board, because the change > > was made locally. so CI cannot detect this. > > > > But this breaks ALL the custom boards people actually use for real > > projects. > > > > And the relevant documentation is hidden at the bottom of some obsolete > > (nuttx 9) release notes, in a "concerns" section. > > > > This doc is critical from anyone porting a custom board from pre-9 nuttx > > to current one. > > > > I cant believe I'm the only one in this case... > > > > Sebastien > > > > Yes, it's documented way near the bottom of the very long ReleaseNotes file > and is hard to find. > > Several things we could do to improve: > > 1. When we make a change like this, detect the obsolete define in the build > system and give some kind of warning? > 2. Split up the ReleaseNotes file? As it is now, it reads a bit more like a > ChangeLog rather than ReleaseNotes. In the past we talked about a > Documentation/ReleaseNotes directory that could hold a separate > ReleaseNotes for each major version? > They are broken out per release and linked on the download page. > 3. Make a ReleaseNotes section of the website that will render those > ReleaseNotes files and offer an easy to use index, so it's easier to find > this information. The newer ones are Markdown but not rendered as such when > opened in any text editor or browser because of all the preexisting > non-markdown content. > Already done http://nuttx.apache.org/releases/10.0.0/#compatibility-concerns > 4. Add a troubleshooting (or FAQ) section to the website and add this > EXTRAFLAGS case to it, i.e., list the symptom and give this as a potential > cause to check for. > > 5. We use semantic versioning, but it would be worthwhile to check if the > major version number was bumped in the first release that contained this > change. If not, that might have been a mistake. > This was part of the reason for making the major version number jump for this release. We already do so much to try and not break things. If you are going to jump 3 major release versions that span __6 years__ you have to expect to run into something and should read at least the compatibility comments for the major releases. I'm all for changing the release notes to be easier to use and they take a huge amount of time to compile. But it is disingenuous to say that nothing was done. --Brennan
Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
> > We already do so much to try and not break things. If you are going to > jump 3 major release versions that span __6 years__ you have to expect to > run into something and should read at least the compatibility comments for > the major releases. > Should have said 2 years not 6 (7.3 was 6). But I stand by what I said. These were not blind changes and they were discussed, documented and done as major breaking release numbers. >
Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
On Fri, May 28, 2021 at 11:43 AM Brennan Ashton wrote: > > On Fri, May 28, 2021, 7:54 AM Nathan Hartman > > 3. Make a ReleaseNotes section of the website that will render those > > ReleaseNotes files and offer an easy to use index, so it's easier to find > > this information. The newer ones are Markdown but not rendered as such when > > opened in any text editor or browser because of all the preexisting > > non-markdown content. > > > > Already done > http://nuttx.apache.org/releases/10.0.0/#compatibility-concerns I completely missed that! Thanks! Nathan
Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
On Fri, May 28, 2021 at 11:49 AM Nathan Hartman wrote: > > On Fri, May 28, 2021 at 11:43 AM Brennan Ashton > wrote: > > > > On Fri, May 28, 2021, 7:54 AM Nathan Hartman > > > 3. Make a ReleaseNotes section of the website that will render those > > > ReleaseNotes files and offer an easy to use index, so it's easier to find > > > this information. The newer ones are Markdown but not rendered as such > > > when > > > opened in any text editor or browser because of all the preexisting > > > non-markdown content. > > > > > > > Already done > > http://nuttx.apache.org/releases/10.0.0/#compatibility-concerns > > I completely missed that! Thanks! I see why I missed it. It wasn't obvious (to me, anyway) that the version numbers in the left column were links to the release notes for that version. Perhaps there should be a column called Release Notes with the links. I'll try to experiment with it later and if I can come up with something more clear, I'll send a PR for review. Thanks, Nathan
Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
> > 2. Split up the ReleaseNotes file? As it is now, it reads a bit more like a > > ChangeLog rather than ReleaseNotes. In the past we talked about a > > Documentation/ReleaseNotes directory that could hold a separate > > ReleaseNotes for each major version? > > > They are broken out per release and linked on the download page. It would still be a good idea if we can do this to the main ReleaseNote file as well. It's 29344 lines long (and counting). We talked before about keeping the latest notes in the top level ReleaseNote and kind of archive the rest somewhere else. On Fri, May 28, 2021 at 4:56 PM Nathan Hartman wrote: > > On Fri, May 28, 2021 at 11:49 AM Nathan Hartman > wrote: > > > > On Fri, May 28, 2021 at 11:43 AM Brennan Ashton > > wrote: > > > > > > On Fri, May 28, 2021, 7:54 AM Nathan Hartman > > > > 3. Make a ReleaseNotes section of the website that will render those > > > > ReleaseNotes files and offer an easy to use index, so it's easier to > > > > find > > > > this information. The newer ones are Markdown but not rendered as such > > > > when > > > > opened in any text editor or browser because of all the preexisting > > > > non-markdown content. > > > > > > > > > > Already done > > > http://nuttx.apache.org/releases/10.0.0/#compatibility-concerns > > > > I completely missed that! Thanks! > > I see why I missed it. It wasn't obvious (to me, anyway) that the > version numbers in the left column were links to the release notes for > that version. > > Perhaps there should be a column called Release Notes with the links. > I'll try to experiment with it later and if I can come up with > something more clear, I'll send a PR for review. > > Thanks, > Nathan
Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
I will try to continue testing my custom board with upcoming releases to detect such breaks. Even if I dont get to vote in your committees I will tell you if I find some problem. Yes I skipped two years of nuttx development, starting christmas holiday 2019, followed by covid lockdowns and a busy 2020 year. Honestly this was discussed maybe, but at some point during that timeframe there was so many nuttx messages coming in the list (more than 100 per day) that it was not possible to follow everything. it was overwhelming. I stopped reading. A porting guide or troubleshooting page would be helpful. These breaking changes are durable, they are not "release" events. They are permanent, so it makes change to maintain an history of these. I still have doubts about *why* EXTRADEFINES *had to* become EXTRAFLAGS :) but whatever. Abdelatif replied something while I was writing: Yes, the only place I had the idea to read release notes was the ReleaseNote files in the repository. I had no idea there was specific release notes on your new wiki. Same reasons as before. The documentation about NuttX is exploded all around. This is an issue that is often noticed by all of my colleagues that attempted to have a look at this project. Sebastien Le 28/05/2021 à 17:56, Nathan Hartman a écrit : On Fri, May 28, 2021 at 11:49 AM Nathan Hartman wrote: On Fri, May 28, 2021 at 11:43 AM Brennan Ashton wrote: On Fri, May 28, 2021, 7:54 AM Nathan Hartman 3. Make a ReleaseNotes section of the website that will render those ReleaseNotes files and offer an easy to use index, so it's easier to find this information. The newer ones are Markdown but not rendered as such when opened in any text editor or browser because of all the preexisting non-markdown content. Already done http://nuttx.apache.org/releases/10.0.0/#compatibility-concerns I completely missed that! Thanks! I see why I missed it. It wasn't obvious (to me, anyway) that the version numbers in the left column were links to the release notes for that version. Perhaps there should be a column called Release Notes with the links. I'll try to experiment with it later and if I can come up with something more clear, I'll send a PR for review. Thanks, Nathan
Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
> Even if I dont get to vote in your committees I will tell you if I find some problem. You do get to vote, everyone can vote. It's actually helpful to have more people voting and participating in the whole release process. Voting for releases is done in the public dev list. PPMC members have binding votes but any issue raised by any member of the community needs to be addressed before we can move forward with a release. > I still have doubts about *why* EXTRADEFINES *had to* become EXTRAFLAGS :) but whatever. Because at that point we started using that variable to pass flags in general and not only defines. EXTRADEFINES was not a valid name anymore. (it's used in the testing script to pass -Wno-cpp -Werror for example) On Fri, May 28, 2021 at 5:16 PM Sebastien Lorquet wrote: > > I will try to continue testing my custom board with upcoming releases to > detect such breaks. Even if I dont get to vote in your committees I will > tell you if I find some problem. > > Yes I skipped two years of nuttx development, starting christmas holiday > 2019, followed by covid lockdowns and a busy 2020 year. > > Honestly this was discussed maybe, but at some point during that > timeframe there was so many nuttx messages coming in the list (more than > 100 per day) that it was not possible to follow everything. it was > overwhelming. I stopped reading. > > A porting guide or troubleshooting page would be helpful. These breaking > changes are durable, they are not "release" events. They are permanent, > so it makes change to maintain an history of these. > > I still have doubts about *why* EXTRADEFINES *had to* become EXTRAFLAGS > :) but whatever. > > > Abdelatif replied something while I was writing: > > Yes, the only place I had the idea to read release notes was the > ReleaseNote files in the repository. > > I had no idea there was specific release notes on your new wiki. Same > reasons as before. > > > The documentation about NuttX is exploded all around. This is an issue > that is often noticed by all of my colleagues that attempted to have a > look at this project. > > > Sebastien > > Le 28/05/2021 à 17:56, Nathan Hartman a écrit : > > On Fri, May 28, 2021 at 11:49 AM Nathan Hartman > > wrote: > >> On Fri, May 28, 2021 at 11:43 AM Brennan Ashton > >> wrote: > >>> On Fri, May 28, 2021, 7:54 AM Nathan Hartman > 3. Make a ReleaseNotes section of the website that will render those > ReleaseNotes files and offer an easy to use index, so it's easier to find > this information. The newer ones are Markdown but not rendered as such > when > opened in any text editor or browser because of all the preexisting > non-markdown content. > > >>> Already done > >>> http://nuttx.apache.org/releases/10.0.0/#compatibility-concerns > >> I completely missed that! Thanks! > > I see why I missed it. It wasn't obvious (to me, anyway) that the > > version numbers in the left column were links to the release notes for > > that version. > > > > Perhaps there should be a column called Release Notes with the links. > > I'll try to experiment with it later and if I can come up with > > something more clear, I'll send a PR for review. > > > > Thanks, > > Nathan
Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ
On Fri, May 28, 2021 at 12:16 PM Sebastien Lorquet wrote: > The documentation about NuttX is exploded all around. This is an issue > that is often noticed by all of my colleagues that attempted to have a > look at this project. Documentation has moved from place to place over the years, but we are gradually consolidating it in the Documentation directory, which is included in release artifacts and also appears on the website. AFAIK the CWIKI is basically deprecated since having docs in the git repo make it easier for anyone to contribute PRs, as opposed to needing an account for the CWIKI. Also, that keeps the docs together with the code so we don't have to worry about things like a future migration to a different wiki or something like that. (Not saying that's gonna happen; just saying we don't have to worry about the possibility of it.) But there might still be things on the CWIKI or other older locations that aren't in Documentation yet. If you find something like that, please do let us know, or just send a PR. I will say that much documentation exists in the form of people's personal blogs, which are not part of this project. That is a testament to this project's success. Compare Linux, which has documentation on millions of websites. I do think it would be helpful for ReleaseNotes (in the form of separate files per releases) to be in Documentation/ReleaseNotes and be made accessible from the Documentation page of the website (http://nuttx.apache.org/docs/latest/) in case someone is looking for them there; the same files should be accessible from the Releases page where they are now, as Brennan enlightened me earlier. Nathan
