Repository navigation
kernel errors to ignore are much too specific #536
Description
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.
Activity
aiChaoSONG commentedon Dec 7, 2020
@marc-hb What‘s your opinion?
marc-hb commentedon Dec 7, 2020
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 blameis 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 commentedon Dec 7, 2020
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/statusplbossart commentedon Dec 7, 2020
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 commentedon Dec 7, 2020
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 commentedon Dec 16, 2020
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 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 commentedon Dec 16, 2020
+1
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 commentedon Jan 27, 2021
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.