netdev - Re: [bug?] tg3: Failed to load firmware "tigon/tg3

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]

Message-Id: <1215114540.10393.659.camel@pmac.infradead.org>
Date:	Thu, 03 Jul 2008 20:49:00 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Valdis.Kletnieks@...edu
Cc:	Theodore Tso <tytso@....edu>, Jeff Garzik <jeff@...zik.org>,
	Hugh Dickins <hugh@...itas.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	mchan@...adcom.com, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, netdev@...r.kernel.org
Subject: Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin"

On Thu, 2008-07-03 at 15:31 -0400, Valdis.Kletnieks@...edu wrote:
> On Thu, 03 Jul 2008 19:56:02 BST, David Woodhouse said:
> 
> > They had to 'make oldconfig' and then actually _choose_ to say 'no' to
> > an option which is fairly clearly documented, that they are the
> > relatively unusual position of wanting to have said 'yes' to. You're
> > getting into Aunt Tillie territory, when you complain about that.
> 
> Note that some of us chose 'no' because we *thought* that we already *had*
> everything in /lib/firmware that we needed (in my case, the iwl3945 wireless
> firmware and the Intel cpu microcode).  The first that I realized that
> the tg3 *had* firmware was when I saw the failure message, because before
> that, the binary blob was inside the kernel.  And then, it wasn't trivially
> obvious how to get firmware loaded if the tg3 driver was builtin rather
> than a module.
> 
> And based on some of the other people who apparently got bit by this same
> exact behavior change on this same exact "builtin but no firmware in kernel"
> config with this same exact driver, it's obvious that one of two things is true:
> 
> 1) Several of the highest-up maintainers are Aunt Tillies.
> or
> 2) This is sufficiently subtle and complicated that far more experienced
> people than Aunt Tillie will Get It Very Wrong.

Not really. It's just a transitional thing. As you said, you know
perfectly well that modern Linux drivers like iwl3945 handle their
firmware separately through request_firmware() rather than including it
in unswappable memory in the static kernel. We're just updating some of
the older drivers to match.

I've often managed to configure a kernel which doesn't boot, when I've
updated and not paid attention to the questions which 'oldconfig' asks
me. It's fairly easy to do. But I don't advocate that 'allyesconfig'
should be the default, just in case someone needs one of the options...

But as I said, I'm content to let Linus make that decision. In the
meantime, I'd prefer to get back to the simple business of updating
drivers to use request_firmware() as they should, and have maintainers
actually respond to the _patches_ rather than refusing to even look at
the code changes because they disagree with the default setting for the
CONFIG_FIRMWARE_IN_KERNEL option.

-- 
dwmw2

--
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