Skip to content

Conversation

@ranj063
Copy link
Collaborator

@ranj063 ranj063 commented Jul 29, 2021

Passing va_list seems to result in issues with stopping
the DMA. Call log_func() and mtrace_dict_entry() in the
_log_message() macro instead to prevent this.

This is an alternative for #4573 but needs to be tested with zephyr. Fixes the suspend/resume with capture issue on helios in my tests

Passing va_list seems to result in issues with stopping
the DMA. Call log_func() and mtrace_dict_entry() in the
_log_message() macro instead to prevent this.

Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
@ranj063
Copy link
Collaborator Author

ranj063 commented Jul 29, 2021

SOFCI TEST

to allow the build to succeed.

Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Copy link
Collaborator

@lyakh lyakh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll test this with Zephyr a bit later

(lvl <= MTRACE_DUPLICATION_LEVEL ? \
mtrace_dict_entry(true, (uint32_t)&log_entry, \
META_COUNT_VARAGS_BEFORE_COMPILE(__VA_ARGS__), \
##__VA_ARGS__) : 0); \
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ?: operator is (usually) used for returning a value. Do I understand it correctly that you just meant an if here? Also it would be nice to keep indentation for end-of-line backslashes

@lgirdwood
Copy link
Member

Lets try for this alternative before the revert as this still keeps the Zephyr trace working. @lyakh please report any Zephyr issues.
Also looks like the UTs are failing to build

cd /quickbuild/workspace1/24733/SOF_FW/build_ut/test/cmocka/src/audio/mixer && /usr/local/bin/cmake -E cmake_link_script CMakeFiles/mixer.dir/link.txt --verbose=1
/localdisk/tools/xtensa/RG-2017.8-linux/XtensaTools/bin/xt-xcc    CMakeFiles/mixer.dir/mixer_test.c.o CMakeFiles/mixer.dir/comp_mock.c.o CMakeFiles/mixer.dir/__/__/notifier_mocks.c.o CMakeFiles/mixer.dir/__/__/__/__/__/src/audio/buffer.c.o CMakeFiles/mixer.dir/__/__/__/__/__/src/audio/mixer.c.o CMakeFiles/mixer.dir/__/__/__/__/__/src/ipc/ipc3/helper.c.o CMakeFiles/mixer.dir/__/__/__/__/__/src/ipc/ipc-common.c.o CMakeFiles/mixer.dir/__/__/__/__/__/src/audio/pipeline/pipeline-graph.c.o CMakeFiles/mixer.dir/__/__/__/__/__/src/audio/pipeline/pipeline-params.c.o CMakeFiles/mixer.dir/__/__/__/__/__/src/audio/pipeline/pipeline-schedule.c.o CMakeFiles/mixer.dir/__/__/__/__/__/src/audio/pipeline/pipeline-stream.c.o CMakeFiles/mixer.dir/__/__/__/__/__/src/audio/pipeline/pipeline-xrun.c.o  -o mixer ../../../libcommon_mock.a -T/quickbuild/workspace1/24733/SOF_FW/build_ut/test/cmocka/memory_mock.x /localdisk/tools/cmocka/build_cavs2x_LX6HiFi3_2017_8/install/lib/libcmocka-static.a ../../../libcommon_mock.a -lm -lgcc -Wl,--no-check-sections -ucall_user_start -Wl,-static -lm 
CMakeFiles/mixer.dir/__/__/__/__/__/src/audio/buffer.c.o: In function `buffer_unlock':
/quickbuild/workspace1/24733/SOF_FW/src/arch/xtensa/include/arch/lib/cache.h:123: undefined reference to `mtrace_dict_entry'
/quickbuild/workspace1/24733/SOF_FW/src/arch/xtensa/include/arch/lib/cache.h:123: undefined reference to `mtrace_dict_entry'
CMakeFiles/mixer.dir/__/__/__/__/__/src/audio/buffer.c.o: In function `buffer_alloc':
/quickbuild/workspace1/24733/SOF_FW/src/audio/buffer.c:44: undefined reference to `mtrace_dict_entry'
/quickbuild/workspace1/24733/SOF_FW/src/audio/buffer.c:48: undefined reference to `mtrace_dict_entry'
/quickbuild/workspace1/24733/SOF_FW/src/audio/buffer.c:35: undefined reference to `mtrace_dict_entry'
CMakeFiles/mixer.dir/__/__/__/__/__/src/audio/buffer.c.o:/quickbuild/workspace1/24733/SOF_FW/src/audio/buffer.c:81: more undefined references to `mtrace_dict_entry' follow
test/cmocka/src/audio/mixer/CMakeFiles/mixer.dir/build.make:263: recipe for target 'test/cmocka/src/audio/mixer/mixer' failed
make[2]: *** [test/cmocka/src/audio/mixer/mixer] Error 2
make[2]: Leaving directory '/quickbuild/workspace1/24733/SOF_FW/build_ut'
CMakeFiles/Makefile2:1645: recipe for target 'test/cmocka/src/audio/mixer/CMakeFiles/mixer.dir/all' failed

Copy link
Member

@plbossart plbossart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have zero understanding of the relationships between the valist and APL build issues, and likewise why the use of the valist results in a DMA fail on CML only.
I would prefer a clean revert to this experiment-based approach where we really have no idea what we are doing. Nothing personal, I just feel like there is a different problem we haven't even root-cause behind all this.

CONFIG_COMP_KPB=n
CONFIG_COMP_SEL=n
CONFIG_COMP_CROSSOVER=n
CONFIG_COMP_DRC=n
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A change to be va_list leads to a build failure?
Something's not right here...

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@plbossart i've made the _log_message() macro heavier with this change and so it breaks the bss section for APL

CONFIG_COMP_SRC_SMALL=y
CONFIG_COMP_TDFB=n
CONFIG_COMP_TONE=n
CONFIG_COMP_KPB=n
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

btw, we have a weird sof-apl-keyword-detect.m4 which presumably uses KPB on APL, although FWIW my brief test of that topology on UP2 wasn't very successful, so maybe it's broken anyway

@lyakh
Copy link
Collaborator

lyakh commented Jul 30, 2021

I'll test this with Zephyr a bit later

@ranj063 Tested-by: @lyakh

@ranj063
Copy link
Collaborator Author

ranj063 commented Jul 30, 2021

I would prefer a clean revert to this experiment-based approach where we really have no idea what we are doing. Nothing personal, I just feel like there is a different problem we haven't even root-cause behind all this.

I dont mind this @plbossart but your PR seems to show failures on 2 other devices that I dont see with mine. Can you please look into it?

@ranj063
Copy link
Collaborator Author

ranj063 commented Jul 30, 2021

Lets try for this alternative before the revert as this still keeps the Zephyr trace working. @lyakh please report any Zephyr issues.

@lgirdwood I'm not able to decipher this failure. the function is defined in trace.c just as before except the signature is changed. I'm not sure why we're seeing this failure. Do you have any hints for me?

@plbossart
Copy link
Member

I would prefer a clean revert to this experiment-based approach where we really have no idea what we are doing. Nothing personal, I just feel like there is a different problem we haven't even root-cause behind all this.

I dont mind this @plbossart but your PR seems to show failures on 2 other devices that I dont see with mine. Can you please look into it?

The errors you are referring to are a completely unrelated failure on CML_SDW on trig-start. ADL has a similar issue.

I've spent enough time on these firmware issues, my position is that we have to revert all of the CML issues.

@lgirdwood
Copy link
Member

This actually looks like the correct fix (and aligns with Zephyr variadic tracing APIs) as I'm 99% sure now this is a compiler bug in the libgcc handling of the xtensa calling convention wrt to register and stack window spilling/shifting. e.g. the GCC va_list is

typedef struct {
   unsigned int gp_offset;
   unsigned int fp_offset;
   void *overflow_arg_area;
   void *reg_save_area;  <<< this will probably break as the registers may be shifted by 4, 8 or 12 in HW and the mapping could lose alignment
} va_list[1];

XCC handles this as it has a better understanding of the window shifting/spilling and a different calling conventions ABI compared to GCC. The va_list definition in XCC may also have extra members to deal with windows spill/shift.

@lgirdwood
Copy link
Member

@ranj063 are you able to rework this next week ?

@ranj063
Copy link
Collaborator Author

ranj063 commented Jul 30, 2021

@ranj063 are you able to rework this next week ?

@lgirdwood yes, I can squash this with Marc's original commits and resubmit next week.

@ranj063
Copy link
Collaborator Author

ranj063 commented Jul 30, 2021

closing for now. will resubmit next week

@ranj063 ranj063 closed this Jul 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants