linux-kernel - 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: <1215181913.10393.799.camel@pmac.infradead.org>
Date:	Fri, 04 Jul 2008 15:31:52 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Theodore Tso <tytso@....edu>
Cc:	Jeff Garzik <jeff@...zik.org>, Andi Kleen <andi@...stfloor.org>,
	David Miller <davem@...emloft.net>, hugh@...itas.com,
	akpm@...ux-foundation.org, 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 Fri, 2008-07-04 at 10:10 -0400, Theodore Tso wrote:
> 
> FYI, at least Ubuntu Hardy's initramfs does not seem to deal with
> firmware for modules correctly.  
> 
> https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/180544
> 
> And remember, kernel/userspace interfaces are things which are far
> more careful about than kernel ABI interfaces....
> 
> You can flame about Ubuntu being broken (and I predict you will :-),

Flaming about it being broken wouldn't help; we _have_ to cope with it. 
Thanks for the reference; I'll keep an eye on it. 

Again, though, this just makes it clear that it's a _already_ a problem
which affects _every_ modern driver that uses request_firmware() -- so
one might reasonably assume it's already quite a high priority for them
to fix. Remember, I'm not doing anything _new_ when I update drivers to
use request_firmware(). That's actually been the norm for new drivers,
like ipw2200, for a _long_ time now.

So I'd kind of expect that by the time Ubuntu gets round to shipping a
2.6.27 kernel, they'd have long since fixed the bug in their scripts.
The few extra drivers which we've updated to conform to best current
practice, in the few cases where people actually need them in the
initrd, should be fairly much in the noise.

But as I said before, maybe there is some sense in leaving the network
drivers for now, and getting on with all the _other_ drivers which need
updating to use request_firmware() first.

> And so adding more breakages when it is *known* the distro's aren't
> moving as quickly as you think is reasonable for quote, modern,
> unquote, drivers is something you can flame about, but at the end of
> the day, *you* are the one introducing changes that is causing more#
> breakages.  

I don't think the Ubuntu bug you reference is because they aren't
"keeping up". AFAICT their tool _does_ look at MODULE_FIRMWARE() and
include the required firmware in the initramfs. But they have decided to
keep firmware in /lib/firmware/`uname -r`/ instead of /lib/firmware/,
and when making that policy change it looks like they forgot to update
that tool to cope. So it's being stored in the wrong place in the
initramfs.

It's purely a local screwup; just a bug. Not because they're being
'slow'. But it's certainly something we should bear in mind. Thanks for
pointing it out.

-- 
dwmw2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/