Your referenced commit is only relevant for validation logic if your hardware supports QAT or not. We now run Kernel 4.19.155 - please retry with the latest rolling release.

A few updates... the failure still occurs on latest rolling. Similar outcome—the kernel panics and dumps a stacktrace during the initial boot-up configure process. However, this issue goes back further than I expected (and initially expressed in the ticket). I goofed up in my testing of 1.3-rolling-202010260327 by booting with a default config file without the QAT option.

At this point 1.3-rolling-202010091522 is the most recent image I have verified to boot without issue when QAT is enabled.

Any chance https://github.com/vyos/vyos-build/commit/b234558db422390ed4d995e9134fe91c37d6cc8f could be related? My CPU is Intel(R) Atom(TM) CPU C3558 @ 2.20GHz, so seems unlikely since it seems like that file is for a different platform.

I will perform a few additional tests tomorrow with the oldest available rolling releases (looks like October 13th as of writing). Will see if I can binary search my way to when things broke.

@lucasec of course this commit could be related and we can try revert back to the old version. Would you be willing in testing a binary for us?

Sure—if you want to drop me an image I can try it out. I do have a working vyos-build as well, I can also try and produce my own with that change backed out when I get some time towards the end of the week.

I have reverted the commit of QAT driver update. can you please try out this image:

https://helix.mybll.net/vyos-1.3-qat-test-202011131253-amd64.iso

Your revert appears to do the trick. Image booted fine with QAT enabled, and "show system acceleration qat status" shows the QAT device came up fine and is running happily.

Thank you for the feedback! Will incorporate this into the rolling releases. Looks like once again Intel did us a favor.

Next rolling release will carry the revert