2.6.26-rc8-mm1 - Kernel

This is a discussion on 2.6.26-rc8-mm1 - Kernel ; On Thu, 2008-07-03 at 15:31 -0400, Valdis.Kletnieks@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 ...

+ Reply to Thread
Page 2 of 9 FirstFirst 1 2 3 4 ... LastLast
Results 21 to 40 of 171

Thread: 2.6.26-rc8-mm1

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

    On Thu, 2008-07-03 at 15:31 -0400, Valdis.Kletnieks@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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    From: Jeff Garzik
    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    On Thursday, 3 of July 2008, David Woodhouse wrote:
    > On Thu, 2008-07-03 at 15:31 -0400, Valdis.Kletnieks@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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    On Thu, 2008-07-03 at 13:34 -0700, David Miller wrote:
    > From: Jeff Garzik
    > 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
    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
    ---
    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    Alan Cox wrote:
    >> 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.


    Agreed.


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


    heh, *cough* yes


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


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

    Jeff



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

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

    > 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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    From: David Woodhouse
    Date: Thu, 03 Jul 2008 19:56:02 +0100

    > It's wrong to change the CONFIG_FIRMWARE_IN_KERNEL default to 'Y',
    > because the _normal_ setting for that option _really_ should be 'N'.


    On what basis? From a "obviously works" basis, the default should be
    'y'.

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


    You say "conform" I say "break".

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


    No!

    The 5701 A0 firmware is necessary to load in order to work around
    hardware and existing firmware bugs on those cards. It's an issue of
    basic functionality, not just optimizations.

    5701 A0 tg3 chips cannot operate at all without the firmware being
    present in the driver.

    Therefore, if you can't load the firmware, the card is not going to
    work.

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


    No, it is properly directed, you are breaking the tree for users.

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


    I disagree.

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


    So now the real truth is revealed. You have no technical basis for
    this stuff you are ramming down everyone's throats.

    You want to choose a default based upon your legal agenda.

    That explains all of the bull**** that is attached to your work, and
    all of the bull**** arguments you make wrt. choosing defaults that
    break things for users.

    It's all about agendas rather than any real technical objectives.

    If it was purely technical, you wouldn't be choosing defaults that
    break things for users by default. Jeff and I warned you about this
    from day one, you did not listen, and now we have at least 10 reports
    just today of people with broken networking.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  17. Re: 2.6.26-rc8-mm1--No e100 :( logs say missing formware

    On Thu, 3 Jul 2008 02:02:36 -0700, Andrew Morton wrote:

    >ftp://ftp.kernel.org/pub/linux/kerne....6.26-rc8-mm1/


    Hi, it booted up on a Core2Duo box but failed to connect via e100 NIC
    to localnet.

    /var/log/messages:

    Jul 4 09:14:13 pooh kernel: firmware: requesting e100/d102e_ucode.bin
    Jul 4 09:14:13 pooh firmware.sh[1666]: Cannot find firmware file 'e100/d102e_ucode.bin'

    /var/log/syslog:

    Jul 4 09:14:13 pooh kernel: e100: eth0: e100_request_firmware: Failed to load firmware "e100/d1
    02e_ucode.bin": -2
    Jul 4 09:14:13 pooh kernel: e100: eth0: e100_request_firmware: Failed to load firmware "e100/d1
    02e_ucode.bin": -2
    Jul 4 09:17:17 pooh kernel: e100: eth0: e100_request_firmware: Failed to load firmware "e100/d1
    02e_ucode.bin": -2
    Jul 4 09:17:30 pooh last message repeated 3 times

    So where did the firmware go? -- I been using these e100 NICs for years,
    2.4 & 2.6 kernels, never seen this kind of failure...

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

  18. Re: 2.6.26-rc8-mm1--No e100 :( logs say missing firmware

    On Thu, 3 Jul 2008 02:02:36 -0700, Andrew Morton wrote:

    >ftp://ftp.kernel.org/pub/linux/kerne....6.26-rc8-mm1/


    Hi, it booted up on a Core2Duo box but failed to connect via e100 NIC
    to localnet.

    /var/log/messages:

    Jul 4 09:14:13 pooh kernel: firmware: requesting e100/d102e_ucode.bin
    Jul 4 09:14:13 pooh firmware.sh[1666]: Cannot find firmware file 'e100/d102e_ucode.bin'

    /var/log/syslog:

    Jul 4 09:14:13 pooh kernel: e100: eth0: e100_request_firmware: Failed to load firmware "e100/d1
    02e_ucode.bin": -2
    Jul 4 09:14:13 pooh kernel: e100: eth0: e100_request_firmware: Failed to load firmware "e100/d1
    02e_ucode.bin": -2
    Jul 4 09:17:17 pooh kernel: e100: eth0: e100_request_firmware: Failed to load firmware "e100/d1
    02e_ucode.bin": -2
    Jul 4 09:17:30 pooh last message repeated 3 times

    So where did the firmware go? -- I been using these e100 NICs for years,
    2.4 & 2.6 kernels, never seen this kind of failure...


    Duped mesg with typo corrected so searching Subject line works.

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

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

    David Miller wrote:
    > From: David Woodhouse
    > Date: Thu, 03 Jul 2008 19:56:02 +0100
    >
    >> It's wrong to change the CONFIG_FIRMWARE_IN_KERNEL default to 'Y',
    >> because the _normal_ setting for that option _really_ should be 'N'.

    >
    > On what basis? From a "obviously works" basis, the default should be
    > 'y'.


    I already changed it to 'y'.

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

    >
    > You say "conform" I say "break".


    You mean...
    "What we're doing now is just cleaning up the older drivers
    which don't use request_firmware(), to break to what is now
    common practice."
    ?

    Doesn't really scan, does it?

    Common practice in modern Linux drivers is to use request_firmware().
    I'm just going through and fixing up the older ones to do that too.

    (After making it possible to build that firmware _into_ the kernel so
    that we aren't forcing people to use an initrd where they didn't before,
    of course.)

    The word for that is definitely 'conform'. I know you don't _like_ the
    modern accepted practice, but that's _your_ windmill to tilt at. I have
    my own

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

    >
    > No!
    >
    > The 5701 A0 firmware is necessary to load in order to work around
    > hardware and existing firmware bugs on those cards. It's an issue of
    > basic functionality, not just optimizations.
    >
    > 5701 A0 tg3 chips cannot operate at all without the firmware being
    > present in the driver.
    >
    > Therefore, if you can't load the firmware, the card is not going to
    > work.


    Neat avoidance of question there... it was fairly clear that the 5701_A0
    firmware was going to be mandatory; I was asking about the TSO firmware.

    Does anyone _else_ actually want to give a straight answer to a simple
    question? Someone who wouldn't have to follow it with an apology because
    of all their shouting about 'breakage' when the firmware in question is
    actually optional anyway, perhaps?


    > If it was purely technical, you wouldn't be choosing defaults that
    > break things for users by default.


    Actually, the beauty of Linux is that we _can_ change things where a
    minor short-term inconvenience leads to a better situation in the long term.

    > Jeff and I warned you about this from day one, you did not listen, and
    > now we have at least 10 reports just today of people with broken
    > networking.


    Out of interest... of those, what proportion would be 'fixed' if they'd
    just paid attention when running 'make oldconfig', which is now
    addressed because I've changed the FIRMWARE_IN_KERNEL default to 'y'?

    And how many would be 'fixed' if someone had given me a straight answer
    when I asked about the TSO firmware, and that failure path no longer
    aborted the driver initialisation but instead just fell back to non-TSO?

    I'll look at making the requirement for 'make firmware_install' more
    obvious, or even making it happen automatically as part of
    'modules_install'.

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

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

    On Thu, Jul 03, 2008 at 04:21:20PM -0700, David Miller wrote:
    > > 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.

    >
    > So now the real truth is revealed. You have no technical basis for
    > this stuff you are ramming down everyone's throats.
    >
    > You want to choose a default based upon your legal agenda.


    Yep, legal agenda. As I suspected, licensing religious fundamentalism. :-)

    People who care can change the defaults. People who are real
    religious nuts won't even let the firmware live in the same source
    tarball. But I hope you agree we clearly don't have consensus to take
    *that* step (rip out all firmware and make a whole bunch of drivers
    non-functional and forcing users to go on a treasure-hunt to find some
    new tarball they have to install on their existing system). So given
    that we're not ready to take that step, why not just leave the default
    as "yes" for now?

    The staged approach means that if you really want to do this ASAP,
    then start assembling the firmware tarball *now*, and for a while
    (read: at least 9-18 months) we can distribute firmware both in the
    kernel source tarball as well as separately in the
    licensing-religion-firmware tarball. See if you can get distros
    willing to ship it by default in most user's systems, and give people
    plenty of time to understand that we are trying to decouple firmware
    from the kernel sources. If we need to institute better versioning
    regimes between the drivers and firmware release levels, that will
    also give people a chance to get that all right. Then 6-9 months
    later, we can turn the default to 'no', and then maybe another 6-9
    months after that, we can talk about removing the firmware modules.
    But it seems to me that you are skipping a few steps by arguing that
    the default should be changed here-and-now.

    We've been shipping firmware in the kernel for over a ***decade***; in
    fact, probably over 15 years. For people who are legal freaks/geeks,
    look up the legal terms "Estoppel" and "Laches". That provides a
    fairly large amount of protection right there. For people who aren't
    legal geeks, we've been doing this for well over a decade; another
    year or two really isn't a big deal. It certainly doesn't justify
    breaking users by default just to try to hurry up this process.

    > If it was purely technical, you wouldn't be choosing defaults that
    > break things for users by default. Jeff and I warned you about this
    > from day one, you did not listen, and now we have at least 10 reports
    > just today of people with broken networking.


    Not 15 minutes after David posted his note, we're now up to 11
    reports; and this is only from an -mm patch series. Can you imagine
    the number of bug reports if this were allowed to ship in a mainline
    kernel.org release? One good thing is that we can definitely show
    that there people that are downloading, compiling and trying to build
    the -mm kernel. :-)

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

+ Reply to Thread
Page 2 of 9 FirstFirst 1 2 3 4 ... LastLast