netdev - Re: Intel wireless microcode problem..

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 14 Aug 2014 09:51:14 -0600
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Larry Finger <Larry.Finger@...inger.net>
Cc:	Johannes Berg <johannes.berg@...el.com>,
	Emmanuel Grumbach <emmanuel.grumbach@...el.com>,
	Intel Linux Wireless <ilw@...ux.intel.com>,
	"John W. Linville" <linville@...driver.com>,
	Linux Wireless List <linux-wireless@...r.kernel.org>,
	Network Development <netdev@...r.kernel.org>
Subject: Re: Intel wireless microcode problem..

On Thu, Aug 14, 2014 at 9:42 AM, Larry Finger <Larry.Finger@...inger.net> wrote:
>
> 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?

               Linus
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html