Mailing List Archive: Linux: Kernel

[bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin"

1 2 3 4 5 6

View All

Index | Next | Previous | View Threaded

kosaki.motohiro at jp

Jul 3, 2008, 4:59 AM

Post #1 of 144 (486 views)
Permalink

[bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin"

Hi Michael,

my server output following error message on 2.6.26-rc8-mm1.
Is this a bug?

------------------------------------------------------------------
tg3.c:v3.93 (May 22, 2008)
GSI 72 (level, low) -> CPU 0 (0x0001) vector 51
tg3 0000:06:01.0: PCI INT A -> GSI 72 (level, low) -> IRQ 51
firmware: requesting tigon/tg3_tso.bin
tg3: Failed to load firmware "tigon/tg3_tso.bin"
tg3 0000:06:01.0: PCI INT A disabled
GSI 72 (level, low) -> CPU 0 (0x0001) vector 51 unregistered
tg3: probe of 0000:06:01.0 failed with error -2
GSI 73 (level, low) -> CPU 0 (0x0001) vector 51
tg3 0000:06:01.1: PCI INT B -> GSI 73 (level, low) -> IRQ 52
firmware: requesting tigon/tg3_tso.bin

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

jeff at garzik

Jul 3, 2008, 5:21 AM

Post #2 of 144 (472 views)
Permalink

Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" [In reply to]

KOSAKI Motohiro wrote:
> Hi Michael,
>
> my server output following error message on 2.6.26-rc8-mm1.
> Is this a bug?
>
> ------------------------------------------------------------------
> tg3.c:v3.93 (May 22, 2008)
> GSI 72 (level, low) -> CPU 0 (0x0001) vector 51
> tg3 0000:06:01.0: PCI INT A -> GSI 72 (level, low) -> IRQ 51
> firmware: requesting tigon/tg3_tso.bin
> tg3: Failed to load firmware "tigon/tg3_tso.bin"
> tg3 0000:06:01.0: PCI INT A disabled
> GSI 72 (level, low) -> CPU 0 (0x0001) vector 51 unregistered
> tg3: probe of 0000:06:01.0 failed with error -2
> GSI 73 (level, low) -> CPU 0 (0x0001) vector 51
> tg3 0000:06:01.1: PCI INT B -> GSI 73 (level, low) -> IRQ 52
> firmware: requesting tigon/tg3_tso.bin

This change did not come from the network developers or Broadcom, so
someone else broke tg3 in -mm...

Jeff

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

hugh at veritas

Jul 3, 2008, 6:04 AM

Post #3 of 144 (462 views)
Permalink

Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" [In reply to]

On Thu, 3 Jul 2008, Jeff Garzik wrote:
> KOSAKI Motohiro wrote:
> > Hi Michael,
> >
> > my server output following error message on 2.6.26-rc8-mm1.
> > Is this a bug?
> >
> > ------------------------------------------------------------------
> > tg3.c:v3.93 (May 22, 2008)
> > GSI 72 (level, low) -> CPU 0 (0x0001) vector 51
> > tg3 0000:06:01.0: PCI INT A -> GSI 72 (level, low) -> IRQ 51
> > firmware: requesting tigon/tg3_tso.bin
> > tg3: Failed to load firmware "tigon/tg3_tso.bin"
> > tg3 0000:06:01.0: PCI INT A disabled
> > GSI 72 (level, low) -> CPU 0 (0x0001) vector 51 unregistered
> > tg3: probe of 0000:06:01.0 failed with error -2
> > GSI 73 (level, low) -> CPU 0 (0x0001) vector 51
> > tg3 0000:06:01.1: PCI INT B -> GSI 73 (level, low) -> IRQ 52
> > firmware: requesting tigon/tg3_tso.bin
>
> This change did not come from the network developers or Broadcom, so someone
> else broke tg3 in -mm...

I think it's a consequence of not choosing CONFIG_FIRMWARE_IN_KERNEL=y.

That caught me out on PowerMac G5 trying mmotm yesterday, it just hung
for a few minutes in earlyish boot with a message about tg3_tso.bin,
and then proceeded to boot up but without the network. I was unclear
whether I'd been stupid, or the FIRMWARE_IN_KERNEL Kconfigery was poor.

I avoid initrd, and have tigon3 built in, if that's of any relevance.

I wonder if that's Andrew's problem with 2.6.26-rc8-mm1 on his G5:
mine here boots up fine (now I know to CONFIG_FIRMWARE_IN_KERNEL=y).

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

jeff at garzik

Jul 3, 2008, 6:11 AM

Post #4 of 144 (461 views)
Permalink

Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" [In reply to]

Hugh Dickins wrote:
> On Thu, 3 Jul 2008, Jeff Garzik wrote:
>> KOSAKI Motohiro wrote:
>>> Hi Michael,
>>>
>>> my server output following error message on 2.6.26-rc8-mm1.
>>> Is this a bug?
>>>
>>> ------------------------------------------------------------------
>>> tg3.c:v3.93 (May 22, 2008)
>>> GSI 72 (level, low) -> CPU 0 (0x0001) vector 51
>>> tg3 0000:06:01.0: PCI INT A -> GSI 72 (level, low) -> IRQ 51
>>> firmware: requesting tigon/tg3_tso.bin
>>> tg3: Failed to load firmware "tigon/tg3_tso.bin"
>>> tg3 0000:06:01.0: PCI INT A disabled
>>> GSI 72 (level, low) -> CPU 0 (0x0001) vector 51 unregistered
>>> tg3: probe of 0000:06:01.0 failed with error -2
>>> GSI 73 (level, low) -> CPU 0 (0x0001) vector 51
>>> tg3 0000:06:01.1: PCI INT B -> GSI 73 (level, low) -> IRQ 52
>>> firmware: requesting tigon/tg3_tso.bin
>> This change did not come from the network developers or Broadcom, so someone
>> else broke tg3 in -mm...
>
> I think it's a consequence of not choosing CONFIG_FIRMWARE_IN_KERNEL=y.
>
> That caught me out on PowerMac G5 trying mmotm yesterday, it just hung
> for a few minutes in earlyish boot with a message about tg3_tso.bin,
> and then proceeded to boot up but without the network. I was unclear
> whether I'd been stupid, or the FIRMWARE_IN_KERNEL Kconfigery was poor.
>
> I avoid initrd, and have tigon3 built in, if that's of any relevance.
>
> I wonder if that's Andrew's problem with 2.6.26-rc8-mm1 on his G5:
> mine here boots up fine (now I know to CONFIG_FIRMWARE_IN_KERNEL=y).

dwmw2 has been told repeatedly that his changes will cause PRECISELY
these problems, but he refuses to take the simple steps necessary to
ensure people can continue to boot their kernels after his changes go in.

Presently his tg3 changes have been nak'd, in part, because of this
obviously, forseeable, work-around-able breakage.

Jeff

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

dwmw2 at infradead

Jul 3, 2008, 6:33 AM

Post #5 of 144 (461 views)
Permalink

Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" [In reply to]

On Thu, 2008-07-03 at 09:11 -0400, Jeff Garzik wrote:
> Hugh Dickins wrote:
> > On Thu, 3 Jul 2008, Jeff Garzik wrote:
> >> KOSAKI Motohiro wrote:
> >>> Hi Michael,
> >>>
> >>> my server output following error message on 2.6.26-rc8-mm1.
> >>> Is this a bug?
> >>>
> >>> ------------------------------------------------------------------
> >>> tg3.c:v3.93 (May 22, 2008)
> >>> GSI 72 (level, low) -> CPU 0 (0x0001) vector 51
> >>> tg3 0000:06:01.0: PCI INT A -> GSI 72 (level, low) -> IRQ 51
> >>> firmware: requesting tigon/tg3_tso.bin
> >>> tg3: Failed to load firmware "tigon/tg3_tso.bin"
> >>> tg3 0000:06:01.0: PCI INT A disabled
> >>> GSI 72 (level, low) -> CPU 0 (0x0001) vector 51 unregistered
> >>> tg3: probe of 0000:06:01.0 failed with error -2
> >>> GSI 73 (level, low) -> CPU 0 (0x0001) vector 51
> >>> tg3 0000:06:01.1: PCI INT B -> GSI 73 (level, low) -> IRQ 52
> >>> firmware: requesting tigon/tg3_tso.bin
> >> This change did not come from the network developers or Broadcom, so someone
> >> else broke tg3 in -mm...
> >
> > I think it's a consequence of not choosing CONFIG_FIRMWARE_IN_KERNEL=y.
> >
> > That caught me out on PowerMac G5 trying mmotm yesterday, it just hung
> > for a few minutes in earlyish boot with a message about tg3_tso.bin,
> > and then proceeded to boot up but without the network. I was unclear
> > whether I'd been stupid, or the FIRMWARE_IN_KERNEL Kconfigery was poor.

I shall respectfully refrain from commenting on the likelihood of the
former. With regard to the latter, here is the help text for the
FIRMWARE_IN_KERNEL option:

help
The kernel source tree includes a number of firmware 'blobs'
which are used by various drivers. The recommended way to
use these is to run "make firmware_install" and to copy the
resulting binary files created in usr/lib/firmware directory
of the kernel tree to the /lib/firmware on your system so
that they can be loaded by userspace helpers on request.

Enabling this option will build each required firmware blob
into the kernel directly, where request_firmware() will find
them without having to call out to userspace. This may be
useful if your root file system requires a device which uses
such firmware, and do not wish to use an initrd.

This single option controls the inclusion of firmware for
every driver which usees request_firmare() and ships its
firmware in the kernel source tree, to avoid a proliferation
of 'Include firmware for xxx device' options.

Say 'N' and let firmware be loaded from userspace.

If you think you can improve it, please let me have a revised attempt.

> > I avoid initrd, and have tigon3 built in, if that's of any relevance.
> >
> > I wonder if that's Andrew's problem with 2.6.26-rc8-mm1 on his G5:
> > mine here boots up fine (now I know to CONFIG_FIRMWARE_IN_KERNEL=y).
>
>
> dwmw2 has been told repeatedly that his changes will cause PRECISELY
> these problems, but he refuses to take the simple steps necessary to
> ensure people can continue to boot their kernels after his changes go in.

Complete nonsense. Setting CONFIG_FIRMWARE_IN_KERNEL isn't hard. But
shouldn't be the _default_, either.

> Presently his tg3 changes have been nak'd, in part, because of this
> obviously, forseeable, work-around-able breakage.

They haven't even been reviewed. Nobody seems to have actually looked at
the real changes (in particular, and commented on whether the device can
run anyway without the TSO firmware being loaded, as some people seem to
report). You're just throwing your toys out of the pram because of the
'default n' on a patch about 30 commits earlier in my tree.

--
dwmw2

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

jeff at garzik

Jul 3, 2008, 6:38 AM

Post #6 of 144 (459 views)
Permalink

Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" [In reply to]

David Woodhouse wrote:
>> dwmw2 has been told repeatedly that his changes will cause PRECISELY
>> these problems, but he refuses to take the simple steps necessary to
>> ensure people can continue to boot their kernels after his changes go in.
>
> Complete nonsense. Setting CONFIG_FIRMWARE_IN_KERNEL isn't hard. But
> shouldn't be the _default_, either.
>
>> Presently his tg3 changes have been nak'd, in part, because of this
>> obviously, forseeable, work-around-able breakage.
>
> They haven't even been reviewed. Nobody seems to have actually looked at

Yes, they have. You just didn't like the answers you received.

In particular, the Kconfig default for built-in tg3 firmware should
result in the current behavior, without the user having to take extra steps.

Because of your stubborn refusal on this Kconfig defaults issue, WE
ALREADY HAVE DRIVER-DOES-NOT-WORK BREAKAGE, JUST AS PREDICTED.

Wake up and smell reality. Please.

Jeff

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

dwmw2 at infradead

Jul 3, 2008, 6:52 AM

Post #7 of 144 (459 views)
Permalink

Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" [In reply to]

On Thu, 2008-07-03 at 09:38 -0400, Jeff Garzik wrote:
> David Woodhouse wrote:
> >> dwmw2 has been told repeatedly that his changes will cause PRECISELY
> >> these problems, but he refuses to take the simple steps necessary to
> >> ensure people can continue to boot their kernels after his changes go in.
> >
> > Complete nonsense. Setting CONFIG_FIRMWARE_IN_KERNEL isn't hard. But
> > shouldn't be the _default_, either.
> >
> >> Presently his tg3 changes have been nak'd, in part, because of this
> >> obviously, forseeable, work-around-able breakage.
> >
> > They haven't even been reviewed. Nobody seems to have actually looked at
>
>
> Yes, they have. You just didn't like the answers you received.

I received no comment on any part of the changes within tg3.c; only
whining about the default behaviour -- which isn't even _set_ as part of
the patch in question, any more.

> In particular, the Kconfig default for built-in tg3 firmware should
> result in the current behavior, without the user having to take extra steps.

After feedback from a number of people, there is no individual Kconfig
option for the various firmwares; there is only one which controls them
all -- CONFIG_FIRMWARE_IN_KERNEL. The thing you're whining about isn't
even part of the patch which needs review.

> Because of your stubborn refusal on this Kconfig defaults issue, WE
> ALREADY HAVE DRIVER-DOES-NOT-WORK BREAKAGE, JUST AS PREDICTED.

I strongly disagree that CONFIG_FIRMWARE_IN_KERNEL=y should be the
default. But if I add this patch elsewhere in the kernel, will you quit
your whining and actually review the patch you were asked to review? ...

diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 339c148..d47482f 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -37,6 +37,7 @@ config FW_LOADER
config FIRMWARE_IN_KERNEL
bool "Include in-kernel firmware blobs in kernel binary"
depends on FW_LOADER
+ default y
help
The kernel source tree includes a number of firmware 'blobs'
which are used by various drivers. The recommended way to

--
dwmw2

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

chuck.lever at oracle

Jul 3, 2008, 9:10 AM

Post #8 of 144 (460 views)
Permalink

Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" [In reply to]

On Jul 3, 2008, at 7:59 AM, KOSAKI Motohiro wrote:
> Hi Michael,
>
> my server output following error message on 2.6.26-rc8-mm1.
> Is this a bug?
>
> ------------------------------------------------------------------
> tg3.c:v3.93 (May 22, 2008)
> GSI 72 (level, low) -> CPU 0 (0x0001) vector 51
> tg3 0000:06:01.0: PCI INT A -> GSI 72 (level, low) -> IRQ 51
> firmware: requesting tigon/tg3_tso.bin
> tg3: Failed to load firmware "tigon/tg3_tso.bin"
> tg3 0000:06:01.0: PCI INT A disabled
> GSI 72 (level, low) -> CPU 0 (0x0001) vector 51 unregistered
> tg3: probe of 0000:06:01.0 failed with error -2
> GSI 73 (level, low) -> CPU 0 (0x0001) vector 51
> tg3 0000:06:01.1: PCI INT B -> GSI 73 (level, low) -> IRQ 52
> firmware: requesting tigon/tg3_tso.bin

Same problem here with linux-next on a Dell Latitude D620.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

tytso at mit

Jul 3, 2008, 10:30 AM

Post #9 of 144 (451 views)
Permalink

Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" [In reply to]

On Thu, Jul 03, 2008 at 02:52:55PM +0100, David Woodhouse wrote:
>
> After feedback from a number of people, there is no individual Kconfig
> option for the various firmwares; there is only one which controls them
> all -- CONFIG_FIRMWARE_IN_KERNEL. The thing you're whining about isn't
> even part of the patch which needs review.
>
> > Because of your stubborn refusal on this Kconfig defaults issue, WE
> > ALREADY HAVE DRIVER-DOES-NOT-WORK BREAKAGE, JUST AS PREDICTED.
>
> I strongly disagree that CONFIG_FIRMWARE_IN_KERNEL=y should be the
> default. But if I add this patch elsewhere in the kernel, will you quit
> your whining and actually review the patch you were asked to review? ...

I don't think it's whining. If your patch introduces changes which
cause people .config to break by default after upgrading to a newer
kernel and doing "make oldconfig" --- then that's a problem with your
patch, and the missing hunk to enable CONFIG_FIRMWARE_IN_KERNEL=y is
critically important.

Linus has ruled this way in the past, when he's gotten screwed by this
sort of issue in the past, and he was justifiably annoyed. We should
treat the users who are willing to test and provide feedback on the
latest kernel.org kernels with the same amount of regard. And if
there are licensing religious fundamentalists who feel strongly about
the firmware issue, then fine, they can change the .config. But the
default should be to avoid users from having broken kernels, and a
number of (quite clueful) users have already demonstrated that without
setting CONFIG_FIRMWARE_IN_KERNEL=y as the default, your patches cause
breakage.

Regards,

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

dwmw2 at infradead

Jul 3, 2008, 11:56 AM

Post #10 of 144 (451 views)
Permalink

Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" [In reply to]

On Thu, 2008-07-03 at 13:30 -0400, Theodore Tso wrote:
> I don't think it's whining.

Neither is it an adequate review of the actual patch which was
submitted.

> If your patch introduces changes which
> cause people .config to break by default after upgrading to a newer
> kernel and doing "make oldconfig"

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.

Although it does make me wonder if it was better the way I had it
originally, with individual options like TIGON3_FIRMWARE_IN_KERNEL
attached to each driver, rather than a single FIRMWARE_IN_KERNEL option
which controls them all.

Perhaps one way to help Aunt Tillie would be to tweak Kbuild to look at
the MODULE_FIRMWARE() statements for in-kernel drivers, and to print a
warning when the build finishes: "Your static kernel image may require
the following firmware files, which are not included: ..."

It's wrong to change the CONFIG_FIRMWARE_IN_KERNEL default to 'Y',
because the _normal_ setting for that option _really_ should be 'N'.
Using request_firmware() satisfied from userspace is best practice these
days, and almost all recent drivers do it that way _unconditionally_
anyway.

What we're doing now is just cleaning up the older drivers which don't
use request_firmware(), to conform to what is now common practice. And
while we're retaining the _option_ to continue to build their firmware
into the static kernel image, it isn't recommended and really shouldn't
be the default configuration.

> Linus has ruled this way in the past, when he's gotten screwed by this
> sort of issue in the past, and he was justifiably annoyed.

I am content to let Linus decide on what the default for the
FIRMWARE_IN_KERNEL option will be. I am adamant that it _should_ be 'N',
but it's easy enough for Linus to overrule me with a one-line change.

In the meantime, it would be useful if Jeff would quit throwing his toys
out of the pram on that issue and actually review the _code_ changes. In
particular, are the reports correct that the device operates just fine
without the TSO firmware loaded? Should we change the request_firmware()
error path to just disable TSO and continue with the initialisation?

I can understand why he might not want to answer that if the answer is
affirmative, I suppose -- it detracts even _further_ from his already
rather dubious argument about 'breaking' the driver, if it'll actually
continue to work even when the firmware is completely absent. But it
would be nice to get an honest and straightforward review of the code
from _someone_ who actually knows the hardware.

> And if there are licensing religious fundamentalists who feel
> strongly about the firmware issue, then fine, they can change
> the .config.

Less of the ad hominem, please. Especially when it's so misdirected.

Updating these drivers to remove large blobs of static unswappable data
from the kernel, and having it provided from userspace on demand as
modern Linux drivers do, is a perfectly sensible technical goal all on
its own.

And given the GPL's explicit provisions with regard to collective works
there are also entirely reasonable, non-"fundamentalist" grounds for
believing that it _may_ pose a licensing problem, and for wanting to err
on the side of caution in that respect too.

Fedora is almost certain to ship with CONFIG_FIRMWARE_IN_KERNEL=n, and
I'd be very surprised if Debian and other major distributions don't
follow suit. It is the sensible, pragmatic, technically sound choice.

> But the default should be to avoid users from having broken kernels,
> and a number of (quite clueful) users have already demonstrated that
> without setting CONFIG_FIRMWARE_IN_KERNEL=y as the default, your
> patches cause breakage.

By this argument, shouldn't we include images in the static kernel for
_all_ drivers which currently use request_firmware()? Otherwise, it's
possible for the user to 'break' them, right?

--
dwmw2

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

Valdis.Kletnieks at vt

Jul 3, 2008, 12:31 PM

Post #11 of 144 (451 views)
Permalink

Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" [In reply to]

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.

dwmw2 at infradead

Jul 3, 2008, 12:49 PM

Post #12 of 144 (449 views)
Permalink

Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" [In reply to]

On Thu, 2008-07-03 at 15:31 -0400, Valdis.Kletnieks[at]vt.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 linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

davem at davemloft

Jul 3, 2008, 1:34 PM

Post #13 of 144 (451 views)
Permalink

Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" [In reply to]

From: Jeff Garzik <jeff[at]garzik.org>
Date: Thu, 03 Jul 2008 09:11:09 -0400

> dwmw2 has been told repeatedly that his changes will cause PRECISELY
> these problems, but he refuses to take the simple steps necessary to
> ensure people can continue to boot their kernels after his changes go in.
>
> Presently his tg3 changes have been nak'd, in part, because of this
> obviously, forseeable, work-around-able breakage.

I agree with Jeff, obviously.

We both saw this song and dance coming. Now the reports are coming in
from confused people who are losing their network. It is no surprise.

And the person who introduced this swath of regressions acts like it's
some kind of chore to enforce the obviously correct default behavior.

Why is it such a big deal to make "obviously working" the default?

In effect, you lied to us, in that you said that by default users
wouldn't have to do anything to keep getting a working setup. But
that is provably not true, look at all of these reports. Are you
saying these people are idiots and don't know how to configure their
kernel? Every single one of them?

So don't be surprised how pissed off some of us are about these
changes. You are inflicting pain on driver maintainers because now
they have to sift through these "firmware not found" reports in
addition to their normal workload.

And David make it seem like it's inconvenient for him to implement the
correct default, which in particular pisses me personally off the
most. It's totally irresponsible, and I don't care what the legal or
ideological motivation is.

Given that, how in the world can you be surprised that the effected
driver maintainers have no interest in reviewing the substance of
these patches? You don't piss people off, then say "help me review
this stuff." It doesn't work like that.

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

rjw at sisk

Jul 3, 2008, 1:52 PM

Post #14 of 144 (452 views)
Permalink

Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" [In reply to]

On Thursday, 3 of July 2008, David Woodhouse wrote:
> On Thu, 2008-07-03 at 15:31 -0400, Valdis.Kletnieks[at]vt.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.

Hm, well, but if the driver in question is in a module, then whether or not
this option is set really doesn't matter, does it?

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

dwmw2 at infradead

Jul 3, 2008, 1:54 PM

Post #15 of 144 (451 views)
Permalink

Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" [In reply to]

On Thu, 2008-07-03 at 13:34 -0700, David Miller wrote:
> From: Jeff Garzik <jeff[at]garzik.org>
> Date: Thu, 03 Jul 2008 09:11:09 -0400
>
> > dwmw2 has been told repeatedly that his changes will cause PRECISELY
> > these problems, but he refuses to take the simple steps necessary to
> > ensure people can continue to boot their kernels after his changes go in.
> >
> > Presently his tg3 changes have been nak'd, in part, because of this
> > obviously, forseeable, work-around-able breakage.
>
> I agree with Jeff, obviously.
>
> We both saw this song and dance coming. Now the reports are coming in
> from confused people who are losing their network. It is no surprise.
>
> And the person who introduced this swath of regressions acts like it's
> some kind of chore to enforce the obviously correct default behavior.
>
> Why is it such a big deal to make "obviously working" the default?

> In effect, you lied to us, in that you said that by default users
> wouldn't have to do anything to keep getting a working setup.

No, I didn't lie to you. The conversation, in case you forgot, went like
this...

On Wed, 2008-06-18 at 16:23 -0700, David Miller wrote:
> On Thu, 2008-06-19 at 00:16 +0100, David Woodhouse wrote:
> > On Wed, 2008-06-18 at 16:05 -0700, David Miller wrote:
> > > Tell me this, how can I (with the default config option settings)
> > > netboot properly without an initial ramdisk after these tg3 patches
> > > and still get the proper firmware?
> >
> > I suppose the facetious answer is that you can't, just as you can't do
> > it with a default config _before_ these patches -- because neither
> > CONFIG_TIGON3 nor the various options you need for nfsroot are enabled
> > by default.
> >
> > But if you _have_ a working nfsroot+tg3 config and you apply these
> > patches, then all you need to do is say 'y' when you're asked if you
> > want to include the firmware for it:
> > CONFIG_TIGON3_FIRMWARE=y
> >
> > If you are competent enough to get nfsroot working, it isn't really very
> > credible to claim you lack the wit to say 'y' when asked that question,
> > surely?
> >
> > Solving that problem was step #1 in the process of converting drivers to
> > use request_firmware(). You _have_ to be able to build the firmware into
> > the kernel image, and you _can_.
>
> Fair enough.
>
> I'll step back and let you work out the objections Jeff raised.

Since then, I responded to feedback and changed the individual
CONFIG_XXX_FIRMWARE options to a single CONFIG_FIRMWARE_IN_KERNEL which
controls them all, but basically nothing has changed. What you accepted
then is still true.

On Thu, 2008-07-03 at 13:34 -0700, David Miller wrote:
So don't be surprised how pissed off some of us are about these
> changes. You are inflicting pain on driver maintainers because now
> they have to sift through these "firmware not found" reports in
> addition to their normal workload.

It also improves coverage testing, and found a real bug in the failure
path...

> And David make it seem like it's inconvenient for him to implement the
> correct default, which in particular pisses me personally off the
> most. It's totally irresponsible, and I don't care what the legal or
> ideological motivation is.

It's not inconvenient at all. It's just the _wrong_ default. But if we
really can't get past it otherwise, then let's just set it to 'y' for
now. I've committed the following, which will appear in linux-next
tomorrow.

Now, can someone _please_ give me a straight response to the allegation
that the TSO firmware on the tg3 is _optional_ anyway, and that it can
work without it? If that's true, we should fix the code path where
request_firmware() fails, so it doesn't abort the initialisation. (And
most of the whining about the driver being 'broken' is nonsense too.)

----
>From 400f1b05a9707bd181a044877ca590e87c400749 Mon Sep 17 00:00:00 2001
From: David Woodhouse <dwmw2[at]infradead.org>
Date: Thu, 3 Jul 2008 21:36:11 +0100
Subject: [PATCH] firmware: default CONFIG_FIRMWARE_IN_KERNEL=y

This is obviously the wrong thing to do in the long (or even medium)
term -- since the recommended way of handling firmware, as used
_unconditionally_ by modern drivers, is to rely on request_firmware()
being satisfied from userspace rather than keeping the firmware in
unswappable static kernel memory.

But this change preserves the property, for now, that the fixes to make
older drivers use request_firmware() introduce _no_ "regressions" when
Aunt Tillie runs 'make oldconfig' and accepts the defaults without
looking at what she's doing.

Signed-off-by: David Woodhouse <dwmw2[at]infradead.org>
---
drivers/base/Kconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 339c148..d47482f 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -37,6 +37,7 @@ config FW_LOADER
config FIRMWARE_IN_KERNEL
bool "Include in-kernel firmware blobs in kernel binary"
depends on FW_LOADER
+ default y
help
The kernel source tree includes a number of firmware 'blobs'
which are used by various drivers. The recommended way to
--
1.5.5.1

--
dwmw2

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

jeff at garzik

Jul 3, 2008, 2:03 PM

Post #16 of 144 (450 views)
Permalink

Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" [In reply to]

David Woodhouse wrote:
> Although it does make me wonder if it was better the way I had it
> originally, with individual options like TIGON3_FIRMWARE_IN_KERNEL
> attached to each driver, rather than a single FIRMWARE_IN_KERNEL option
> which controls them all.

IMO, individual options would be better.

Plus, unless I am misunderstanding, the firmware is getting built into
the kernel image not the tg3 module?

If that is the case, then that creates problems by not moving with the
driver.

If that is not the case, all good.

Jeff

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

dwmw2 at infradead

Jul 3, 2008, 2:33 PM

Post #17 of 144 (448 views)
Permalink

Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" [In reply to]

Jeff Garzik wrote:
> David Woodhouse wrote:
>> Although it does make me wonder if it was better the way I had it
>> originally, with individual options like TIGON3_FIRMWARE_IN_KERNEL
>> attached to each driver, rather than a single FIRMWARE_IN_KERNEL option
>> which controls them all.
>
> IMO, individual options would be better.

They had individual options for a long time, but the consensus was that
I should remove them -- a consensus which was probably right. It was
moderately inconvenient going back through it all and recommitting it
without that, but it was worth it to get it right...

> Plus, unless I am misunderstanding, the firmware is getting built into
> the kernel image not the tg3 module?

That's right, although it doesn't really matter when they're both in the
vmlinux.

When it's actually a module, there really is no good reason not to let
request_firmware() get satisfied from userspace. If you can load
modules, then you can load firmware too -- the required udev stuff has
been there as standard for a _long_ time, as most modern drivers
_require_ it without even giving you the built-in-firmware option at all.

It makes no more sense to object to that than it does to object to the
module depending on _other_ modules. Both those other modules, and the
required firmware, are _installed_ by the kernel Makefiles, after all.

It wouldn't be _impossible_ to put firmware blobs into the foo.ko files
themselves and find them there. The firmware blobs in the kernel are
done in a separate section (like initcalls, exceptions tables, pci
fixups, and a bunch of other stuff). It'd just take some work in
module.c to link them into a global list, and some locking shenanigans
in the lookups (and lifetime issues to think about). But it just isn't
worth the added complexity, given that userspace is known to be alive
and working. It's pointless not to just use request_firmware() normally,
from a module.

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

rjw at sisk

Jul 3, 2008, 2:42 PM

Post #18 of 144 (448 views)
Permalink

Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" [In reply to]

On Thursday, 3 of July 2008, David Woodhouse wrote:
> Jeff Garzik wrote:
> > David Woodhouse wrote:
> >> Although it does make me wonder if it was better the way I had it
> >> originally, with individual options like TIGON3_FIRMWARE_IN_KERNEL
> >> attached to each driver, rather than a single FIRMWARE_IN_KERNEL option
> >> which controls them all.
> >
> > IMO, individual options would be better.
>
> They had individual options for a long time, but the consensus was that
> I should remove them -- a consensus which was probably right. It was
> moderately inconvenient going back through it all and recommitting it
> without that, but it was worth it to get it right...
>
> > Plus, unless I am misunderstanding, the firmware is getting built into
> > the kernel image not the tg3 module?
>
> That's right, although it doesn't really matter when they're both in the
> vmlinux.
>
> When it's actually a module, there really is no good reason not to let
> request_firmware() get satisfied from userspace. If you can load
> modules, then you can load firmware too -- the required udev stuff has
> been there as standard for a _long_ time, as most modern drivers
> _require_ it without even giving you the built-in-firmware option at all.
>
> It makes no more sense to object to that than it does to object to the
> module depending on _other_ modules. Both those other modules, and the
> required firmware, are _installed_ by the kernel Makefiles, after all.
>
> It wouldn't be _impossible_ to put firmware blobs into the foo.ko files
> themselves and find them there. The firmware blobs in the kernel are
> done in a separate section (like initcalls, exceptions tables, pci
> fixups, and a bunch of other stuff). It'd just take some work in
> module.c to link them into a global list, and some locking shenanigans
> in the lookups (and lifetime issues to think about). But it just isn't
> worth the added complexity, given that userspace is known to be alive
> and working. It's pointless not to just use request_firmware() normally,
> from a module.

Still, maybe we can add some kbuild magic to build the blobs along with
their modules and to install them under /lib/firmware (by default) when the
modules are installed in /lib/modules/... ?

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

dwmw2 at infradead

Jul 3, 2008, 2:43 PM

Post #19 of 144 (448 views)
Permalink

Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" [In reply to]

Rafael J. Wysocki wrote:
> Still, maybe we can add some kbuild magic to build the blobs along with
> their modules and to install them under /lib/firmware (by default) when the
> modules are installed in /lib/modules/... ?

Something like appending this to Makefile?

firmware_and_modules_install: firmware_install modules_install

(I'm still wondering if we should make 'firmware_install' install to
/lib/firmware by default, instead of into the build tree as
'headers_install' does. The Aunt Tillie answer would definitely be
'yes', although that means it requires root privs; like modules_install
does.)

--
dwmw2

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

rjw at sisk

Jul 3, 2008, 2:52 PM

Post #20 of 144 (448 views)
Permalink

Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" [In reply to]

On Thursday, 3 of July 2008, David Woodhouse wrote:
> Rafael J. Wysocki wrote:
> > Still, maybe we can add some kbuild magic to build the blobs along with
> > their modules and to install them under /lib/firmware (by default) when the
> > modules are installed in /lib/modules/... ?
>
> Something like appending this to Makefile?
>
> firmware_and_modules_install: firmware_install modules_install
>
> (I'm still wondering if we should make 'firmware_install' install to
> /lib/firmware by default, instead of into the build tree as
> 'headers_install' does. The Aunt Tillie answer would definitely be
> 'yes', although that means it requires root privs; like modules_install
> does.)

I would prefer 'make firmware_install' to just copy the blobs into specific
location in analogy with 'make modules_install', so that you can build the
blobs as a normal user (for example, on an NFS server) and then put them
into the right place as root (for example, on an NFS client that has no write
privilege on the server).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

dwmw2 at infradead

Jul 3, 2008, 2:54 PM

Post #21 of 144 (449 views)
Permalink

Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" [In reply to]

Rafael J. Wysocki wrote:
> On Thursday, 3 of July 2008, David Woodhouse wrote:
>> Rafael J. Wysocki wrote:
>>> Still, maybe we can add some kbuild magic to build the blobs along with
>>> their modules and to install them under /lib/firmware (by default) when the
>>> modules are installed in /lib/modules/... ?
>> Something like appending this to Makefile?
>>
>> firmware_and_modules_install: firmware_install modules_install
>>
>> (I'm still wondering if we should make 'firmware_install' install to
>> /lib/firmware by default, instead of into the build tree as
>> 'headers_install' does. The Aunt Tillie answer would definitely be
>> 'yes', although that means it requires root privs; like modules_install
>> does.)
>
> I would prefer 'make firmware_install' to just copy the blobs into specific
> location in analogy with 'make modules_install', so that you can build the
> blobs as a normal user (for example, on an NFS server) and then put them
> into the right place as root (for example, on an NFS client that has no write
> privilege on the server).

Not entirely sure which you mean. You _can't_ run 'make modules_install'
as a normal user, unless you override $(INSTALL_MOD_PATH) on the command
line.

Do you want 'make firmware_install' to be the same? It isn't at the
moment -- it installs to a subdirectory of the kernel build tree, like
'make headers_install' does. But I'm not sure which is better.

--
dwmw2

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

jeff at garzik

Jul 3, 2008, 3:22 PM

Post #22 of 144 (449 views)
Permalink

Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" [In reply to]

David Woodhouse wrote:
> Jeff Garzik wrote:
>> David Woodhouse wrote:
>>> Although it does make me wonder if it was better the way I had it
>>> originally, with individual options like TIGON3_FIRMWARE_IN_KERNEL
>>> attached to each driver, rather than a single FIRMWARE_IN_KERNEL option
>>> which controls them all.
>>
>> IMO, individual options would be better.
>
> They had individual options for a long time, but the consensus was that
> I should remove them -- a consensus which was probably right. It was
> moderately inconvenient going back through it all and recommitting it
> without that, but it was worth it to get it right...
>
>> Plus, unless I am misunderstanding, the firmware is getting built into
>> the kernel image not the tg3 module?
>
> That's right, although it doesn't really matter when they're both in the
> vmlinux.
>
> When it's actually a module, there really is no good reason not to let
> request_firmware() get satisfied from userspace. If you can load
> modules, then you can load firmware too -- the required udev stuff has
> been there as standard for a _long_ time, as most modern drivers
> _require_ it without even giving you the built-in-firmware option at all.
>
> It makes no more sense to object to that than it does to object to the
> module depending on _other_ modules. Both those other modules, and the
> required firmware, are _installed_ by the kernel Makefiles, after all.
>
> It wouldn't be _impossible_ to put firmware blobs into the foo.ko files
> themselves and find them there. The firmware blobs in the kernel are
> done in a separate section (like initcalls, exceptions tables, pci
> fixups, and a bunch of other stuff). It'd just take some work in
> module.c to link them into a global list, and some locking shenanigans
> in the lookups (and lifetime issues to think about). But it just isn't
> worth the added complexity, given that userspace is known to be alive
> and working. It's pointless not to just use request_firmware() normally,
> from a module.

It is pointless -- if you assume everybody wants to run their distro and
universe your way.

If a firmware is built-in, then 'make firmware_install' is clearly
optional and may be omitted. That invalidates several of your
assumptions above.

Further, all current kernel build and test etc. scripts are unaware of
'make firmware_install', and it is unfair to everybody to force a
flag-day build process change on people, just to keep their drivers in
the same working state today as it was yesterday.

Conclusion - kernel build process must produce a working driver after
your changes are applied, even in absence of 'make firmware_install'.

That does not, repeat /not/ exclude the desired end goal of course --
separating the firmware from the driver, installing in /lib/firmware via
'make firmware_install', etc.

I support your end goal, I really do. But I continue to feel there is a
lack of regard for breakage and regressions. You are either ignoring or
apparently just not seeing
* how many new ways this can produce a non-working driver
* how important it is in this specific case to fail-safe,
and avoid a broken driver at all costs.

As a concrete example, in the above quoted text you assume that a user
will never copy kernel modules around. I can tell you that, with tg3.ko
being nice and self-contained, yes it does get copied around (to
multiple machines, etc.). With the firmware newly separated from
tg3.ko, you have introduced breakage for any user that is unaware of
this new requirement (kernel module == requires additional file now).

Scripts that build install disks must be updated, otherwise a script
that builds a boot image will include the drivers it knows about, but
/not/ include the crucial firmware.

None of this stuff is "pointless", none of this stuff may be dismissed
as "making no sense". All these are real world examples where users
FOLLOWING THEIR NORMAL, PROSCRIBED KERNEL PROCESSES will produce
non-working drivers.

The only valid assumption here is to assume that the user is /unaware/
of these new steps they must take in order to continue to have a working
system.

Regards,

Jeff

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

alan at lxorguk

Jul 3, 2008, 3:25 PM

Post #23 of 144 (450 views)
Permalink

Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" [In reply to]

O
> Further, all current kernel build and test etc. scripts are unaware of
> 'make firmware_install', and it is unfair to everybody to force a
> flag-day build process change on people, just to keep their drivers in
> the same working state today as it was yesterday.

IMHO we want firmware built in as the default for the moment. If the
firmware model makes sense (as I think it does) then the distributions
will catch up, turn it on and sort out the default behaviour - exactly as
they did all those years ago with modules, more recently with "use an
initrd" and so on.

> as "making no sense". All these are real world examples where users
> FOLLOWING THEIR NORMAL, PROSCRIBED KERNEL PROCESSES will produce

I hope you mean "prescribed" ;)

> The only valid assumption here is to assume that the user is /unaware/
> of these new steps they must take in order to continue to have a working
> system.

To a large extent not the user but their distro - consider "make install"
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

rjw at sisk

Jul 3, 2008, 3:27 PM

Post #24 of 144 (449 views)
Permalink

Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" [In reply to]

On Thursday, 3 of July 2008, David Woodhouse wrote:
> Rafael J. Wysocki wrote:
> > On Thursday, 3 of July 2008, David Woodhouse wrote:
> >> Rafael J. Wysocki wrote:
> >>> Still, maybe we can add some kbuild magic to build the blobs along with
> >>> their modules and to install them under /lib/firmware (by default) when the
> >>> modules are installed in /lib/modules/... ?
> >> Something like appending this to Makefile?
> >>
> >> firmware_and_modules_install: firmware_install modules_install
> >>
> >> (I'm still wondering if we should make 'firmware_install' install to
> >> /lib/firmware by default, instead of into the build tree as
> >> 'headers_install' does. The Aunt Tillie answer would definitely be
> >> 'yes', although that means it requires root privs; like modules_install
> >> does.)
> >
> > I would prefer 'make firmware_install' to just copy the blobs into specific
> > location in analogy with 'make modules_install', so that you can build the
> > blobs as a normal user (for example, on an NFS server) and then put them
> > into the right place as root (for example, on an NFS client that has no write
> > privilege on the server).
>
> Not entirely sure which you mean. You _can't_ run 'make modules_install'
> as a normal user, unless you override $(INSTALL_MOD_PATH) on the command
> line.

Yes, I know that.

> Do you want 'make firmware_install' to be the same?

Yes, I'd prefer it to behave in the same way as 'make modules_install'.

I'd use a config option like BUILD_FIRMWARE_BLOBS that, if set, would make
the build system create firmware bin files in the same directories where the
driver's .o files are located. Then, 'make firmware_install' would only copy
those bin files to wherever was appropriate (eg. /lib/firmware/).

Of course, there still would be a problem if there already were such firmware
files at the destination, but that would have to be resolved anyway by the user
wanting to install the new kernel along with the new firmware blobs.

> It isn't at the moment -- it installs to a subdirectory of the kernel build tree, like
> 'make headers_install' does. But I'm not sure which is better.

IMO 'make headers_install' is used for a different purpose. You don't have to
run it to be able to use the kernel in a usual way.

OTOH, everyone is familiar with the 'make modules_install' mechanics and it
seems natural to use analogous mechanics for firmware blobs.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

alan at lxorguk

Jul 3, 2008, 4:02 PM

Post #25 of 144 (434 views)
Permalink

Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" [In reply to]

> Actually, I was tossing that about in my head:
>
> Is it a better idea to eliminate 'make firmware_install' completely, and
> instead implement it silently via 'make install'?
>
> 'make install' is already a big fat distro hook...

make firmware_install can encapsulate a lot of kernel specific knowledge
so I think it belongs in the kernel tree to avoid problems in future. The
use of make firmware_install belongs in the distro make install hooks.

Otherwise we will mess up the distro stuff if we have to change the
innards of make firmware_install in future, as may well occur.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo[at]vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

1 2 3 4 5 6

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com