RE: Intel wireless microcode problem..

quoted

There is a new firmware that seems to help the problem. You can get it
from Emmanuel's git clone. As he wrote earlier

So quite frankly, this is *not* acceptable. We have regression policies for the
kernel, and this seems to be a kernel regression with the currently released
firmware. And I'm not downloading experimental firmware while traveling
with this laptop being my only way to work.

The warnings cause *so* much message log spam that the machine is
occasionally spending 5% of CPU time on systemd journaling, and
presumably filling up disk space too.

And the same way we don't tell people "update your buggy user space"
when we introduce kernel regressions, we don't tell people "try a new
firmware".

People who have old systems (old distributions, old firmware, old hardware,
old *anything*) that works with their previous kernel, are supposed to be
able to upgrade their kernel with no regressions.
That's the rules for the kernel, and that's what the rules have been for a long
time. Kernel developers - including wireless driver writers
- had better understand that rule. It's the absolute #1 rule when it comes to
kernel development. This is not something new and surprosing.

The insane amount of logging needs to be fixed. The wireless *works*, but
the logging is too verbose.

Now, maybe this isn't actually a kernel regression at all - maybe triggered by
the horrid internet I have while traveling - but I tried twice, and when I
booted into the regular Fedora kernel for testing (oh, just noticed that it's
3.15.8, not 3.16-based), I didn't see this kind of log spamming. So it looks like
a regression to me, and we have rules about regressions. And they are just
about the ONLY hard rules we have. But that regression rule really is very
very important indeed.

The wireless *works* with the current firmware, so all that is required is to
make sure that the kernel stops spamming the logs so heavily. It would
obviously be better to try to figure out *why* the microcode error happens,
and what changed in the kernel to trigger it, but the "don't make the
machine have trouble with the insane amount of logs" is at least an
acceptable workaround.

Ok?

As I said, I am tyring to repro right now - you are 100% right we are fully committed to make the current firmware work. The "experimental" firmware is just a firmware with a version problem - this is why I didn't release it formally. You can safely use it until we fix the problem.
And we will fix it.
And no - it is not related to the internet - this is surely a bug in our driver / firmware interface. I am currently trying to see how I can fix it - but I am also travelling...
N�����r��y���b�X��ǧv�^�)޺{.n�+����{��*ޕ�,�{ay�
ʇڙ�,j��f���h�����/oSc��ڳ9�u�����&jw��(�階�ݢj"���m�����z�ޖ���f���h���~�m�