fixes for ipc4 fuzzer build

[cujomalainey]

No description provided.

[cujomalainey]

Realizing now that I am going to need some fancy tricks to deal with the fact that the IPC depends directly on the manifest baked into the FW. Anyone got any ideas how to map this into the x86 linux build?

[marc-hb]

I'm confused: why did the ipc-fuzzer-build PASSED in #4777 and all PRs before and after it? Asking because https://github.com/thesofproject/sof/pull/4786/checks?check_run_id=3657884209 (which disappeared on force push?!?) failed with "rimage not found"

[cujomalainey]

removing dependency on rimage for now, oss-fuzz CI isn't ready for submodules yet, see google/oss-fuzz#5908

[marc-hb]

https://github.com/thesofproject/sof/pull/4786/checks?check_run_id=3657976348 built without any issue now (and without rimage)

On the other hand this CML crash does not ring any bell:
https://sof-ci.01.org/sofpr/PR4786/build10398/devicetest/?model=CML_HEL_RT5682&testcase=check-kmod-load-unload

[ 1342.049627] kernel: rt5682 i2c-10EC5682:00: sysclk/dai not set correctly
[ 1342.050165] kernel: general protection fault, probably for non-canonical address 0x70614320324649f1: 0000 [#1] SMP NOPTI
[ 1342.050202] kernel: CPU: 2 PID: 17764 Comm: systemd-udevd Not tainted 5.15.0-rc1-daily-default-20210920 #73e5ae02
[ 1342.050233] kernel: Hardware name: Google Helios/Helios, BIOS  01/21/2020
[ 1342.050247] kernel: RIP: 0010:__clk_register+0x47c/0x7e0
[ 1342.050287] kernel: Code: 63 e8 45 85 ed 0f 85 66 02 00 00 4c 89 ff e8 8b c5 ff ff 49 89 c4 49 89 47 30 49 8d 87 b8 00 00 00 4d 85 e4 0f 84 7a 02 00 00 <49> 8b 94 24 b0 00 00 00 49 89 97 b8 00 00 00 48 85 d2 74 04 48 89
[ 1342.050311] kernel: RSP: 0018:ffffbad1813df950 EFLAGS: 00010206
[ 1342.050338] kernel: RAX: ffffa3c77d5fdcb8 RBX: ffffa3c7463edbc8 RCX: 00000000895c2d7f
[ 1342.050358] kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffa3c77d5fdc00
[ 1342.050376] kernel: RBP: 0000000000000001 R08: 00000000ffffffff R09: 0000000000000000
[ 1342.050393] kernel: R10: 0000000000000000 R11: 0000000000000000 R12: 7061432032464941
[ 1342.050408] kernel: R13: ffffa3c7531d0ba0 R14: ffffa3c76c9914a8 R15: ffffa3c77d5fdc00
[ 1342.050427] kernel: FS:  00007f351a81e880(0000) GS:ffffa3c896200000(0000) knlGS:0000000000000000
[ 1342.050449] kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1342.050466] kernel: CR2: 00005604c8060fe4 CR3: 0000000105a20002 CR4: 00000000003706e0
[ 1342.050486] kernel: Call Trace:
[ 1342.050507] kernel:  ? clk_hw_unregister+0x10/0x10
[ 1342.050544] kernel:  clk_hw_register+0x19/0x40
[ 1342.050573] kernel:  devm_clk_hw_register+0x41/0x80
[ 1342.050608] kernel:  rt5682_probe+0x148/0x1f0 [snd_soc_rt5682]
[ 1342.050661] kernel:  ? set_filter_clk+0x100/0x100 [snd_soc_rt5682]
[ 1342.050725] kernel:  snd_soc_component_probe+0x19/0x40 [snd_soc_core]
[ 1342.050919] kernel:  soc_probe_component+0x1cb/0x300 [snd_soc_core]
[ 1342.051089] kernel:  snd_soc_bind_card+0x506/0xcf0 [snd_soc_core]
[ 1342.051254] kernel:  ? is_module_address+0xc/0x20
[ 1342.051286] kernel:  ? lockdep_init_map_type+0x51/0x210
[ 1342.051323] kernel:  ? __raw_spin_lock_init+0x36/0x60

[lgirdwood]

SOFCI TEST

[lgirdwood]

Realizing now that I am going to need some fancy tricks to deal with the fact that the IPC depends directly on the manifest baked into the FW. Anyone got any ideas how to map this into the x86 linux build?

Short term we are just going to have to fuzz the whole IPC4 message set (with some hard coded defaults) and ignore manifest.

[cujomalainey]

@marc-hb I am not sure how this would cause that, given this should only be fixing uninitialized data or build time bugs

[lgirdwood]

CML fail on PM streams known about and unrelated.

[marc-hb]

CML fail on PM streams known about and unrelated.

@lgirdwood I couldn't find any related issue. I think @ranj063 mentioned thesofproject/linux#3120, is that what you had in mind too?

[lgirdwood]

CML fail on PM streams known about and unrelated.

@lgirdwood I couldn't find any related issue. I think @ranj063 mentioned thesofproject/linux#3120, is that what you had in mind too?

No, it's the trace DMA.

[marc-hb]

You mean HD DMA / brand new #4793?