kernel errors to ignore are much too specific

[lyakh]

Some strings that the kernel log parser is configured to ignore are much too specific, they contain details of the local set up, which change when using a different hardware or network configuration. Examples:

usb 2-3: Enable of device-initiated U1 failed.
usb 2-3: Enable of device-initiated U2 failed.

The USB path can change, "U1," "U2" might also vary

iwlwifi 0000:00:14.3: Direct firmware load for iwlwifi-QuZ-a0-hr-b0-56.ucode failed with error -2
iwlwifi 0000:00:14.3: Direct firmware load for iwlwifi-QuZ-a0-hr-b0-54.ucode failed with error -2
iwlwifi 0000:00:14.3: Direct firmware load for iwlwifi-QuZ-a0-hr-b0-53.ucode failed with error -2
iwlwifi 0000:00:14.3: Direct firmware load for iwlwifi-QuZ-a0-hr-b0-52.ucode failed with error -2
iwlwifi 0000:00:14.3: Direct firmware load for iwlwifi-QuZ-a0-hr-b0-51.ucode failed with error -2
iwlwifi 0000:00:14.3: Direct firmware load for iwlwifi-QuZ-a0-hr-b0-50.ucode failed with error -2
iwlwifi 0000:00:14.3: Direct firmware load for iwlwifi-QuZ-a0-hr-b0-49.ucode failed with error -2
iwlwifi 0000:00:14.3: Direct firmware load for iwl-debug-yoyo.bin failed with error -2

Device path and name can change

iwlwifi 0000:00:14.3: Microcode SW error detected. Restarting 0x0.

Device path can change

acpi device:00: Failed to change power state to D3hot

Device number and state can be different

i915 0000:00:02.0: [drm] *ERROR* TC cold unblock failed
i915 0000:00:02.0: [drm] *ERROR* TC cold block failed

Device path can change

usb 3-.: device descriptor read/64, error .
usb 3-.: device not accepting address ., error .

Can happen on any USB adapter

hub 2-.: .
usb 2-.: .

On the one hand this can happen on any USB bus, on the other hand these errors might actually be too generic, but probably they all can be ignored. And BTW they also seem to cover above USB errors, as long as matching isn't performed on complete lines.

[aiChaoSONG]

@marc-hb What‘s your opinion?

[marc-hb]

My opinion is that this bug is... not specific enough :-)

More seriously: please "send patches"! Or discuss in the corresponding bug when there is one. Or discuss in the PR that last modified that filter, tig blame is your friend.

A number of filters were recently added in #529 which was not reviewed. I'm sure other, older filters are far from perfect either.

But please discuss or change only one filter at a time because each filter deals with a different message and a different problem unrelated to other error messages.

[marc-hb]

Ignoring all USB errors seems a bit risky to me. Is USB as a whole really such a total piece of crap? On ALL platforms?? How about ignoring all USB errors only on prototype hardware? See also #514 and probably others.

If you really must test with some crappy USB device then how about adding a one line filter only in your local workspace without affecting everyone else who doesn't use this crappy device? Once #502 is addressed then such a local change would not even affect git diff/status

[plbossart]

The USB errors I reported are all on production hardware - not Intel prototypes. It's annoying to have to add local magic, once you start in this direction you opened the doors to 'works for me' issues.

[marc-hb]

It's annoying to have to add local magic, once you start in this direction you opened the doors to 'works for me' issues.

USB errors that affect more than one person should absolutely be shared (the devil is still in the regex details). I'm only objecting to polluting this file and making it harder to maintain with "doesn't work for me ONLY" filters.

[kv2019i]

This really comes down to CI operational aspects. On one side, if you have relaxed filter rules, you will have less work to maintain the filter rules, but you take a higher risk of missing a real regression. Latter means we leak buggy code to upstream, so I would always err on the side of caution here.

My 2 cents:

• I agree with @lyakh that USB topology information should not be hardcoded in filter rules as these are very volatile (depends on how you plug the device to the system -- risk of slipping real regressions this way seems very low)
• the PCH PCI device topology data is very stable, so I think this is ok to hardcode in filter rules

I do think we should close this bug and instead discuss around specific pull-reqs to sof-test. This is inherently a case-by-case judgement call.

[marc-hb]

This is inherently a case-by-case judgement call.

+1

so I would always err on the side of caution here.

A reminder that I added some "policies" at the top of the source file where the filters are. These policies can be patched too and could/should include advice like the USB or PCI ones above.

[marc-hb]

This is a generic discussion, not a specific bug, closing. We can keep discussing even after it's closed!

PS: everyone agrees to ignore wifi EVERYTHING, please send a patch.