2.6.26-rc8-mm1 - Kernel

This is a discussion on 2.6.26-rc8-mm1 - Kernel ; On Fri, 04 Jul 2008 09:35:43 +1000 Grant Coady wrote: > So where did the firmware go? Dave ate it. Please see the thread "[bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin"" -- To unsubscribe from this list: send the line ...

+ Reply to Thread
Page 3 of 9 FirstFirst 1 2 3 4 5 ... LastLast
Results 41 to 60 of 171

Thread: 2.6.26-rc8-mm1

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

    On Fri, 04 Jul 2008 09:35:43 +1000 Grant Coady wrote:

    > So where did the firmware go?


    Dave ate it. Please see the thread "[bug?] tg3: Failed to load
    firmware "tigon/tg3_tso.bin""

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

    Theodore Tso wrote:
    > On Thu, Jul 03, 2008 at 04:21:20PM -0700, David Miller wrote:
    >> You want to choose a default based upon your legal agenda.

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


    You are mistaken, and you're responding some words that someone _else_
    put in my mouth.

    > The staged approach means that if you really want to do this ASAP,
    > then start assembling the firmware tarball *now*,


    That's easy enough. We can automatically generate a tree _from_ Linus'
    tree, with a scripted transform so that it includes only the firmware
    files (much like the kernel-headers tree automatically follows each
    commit in Linus' tree, but includes only the exported headers).

    And there are some hardware manufacturers who are willing to have their
    firmware included in such a firmware tarball, but who will _not_ give
    their permission to have it included in the Linux kernel because of the
    legal concerns you're so dismissive of. But that's OK -- we can pull
    from the automatically generated tree into a 'real' linux-firmware.git
    tree, which includes those extra firmware files.

    But there's no need to do it _now_. It can wait until the basic stuff is
    in Linus' tree and it can automatically derive from that. There's no
    particular rush, is there?

    > and for a while (read: at least 9-18 months) we can distribute firmware
    > both in the kernel source tarball as well as separately


    That makes a certain amount of sense.

    > in the licensing-religion-firmware tarball.


    Please don't be gratuitously offensive, Ted. It's not polite, and it's
    not a particularly good debating technique either. I expect better from you.

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


    The distros are certainly willing (and keen) to do it. The Fedora
    Engineering Steering Committee has already stated that it wants to do
    so, and the specfile changes to spit out a 'kernel-firmware' sub-package
    with the kernel build are ready to go right now.

    Fedora already modifies tarballs, for example 'openssh-5.0p1-noacss'. I
    think it's quite likely they'd end up using a 'linux-2.6.27-nofirmware'
    tarball too, and build the firmware package from the separate tree.

    Some other distributions have been doing that kind of thing _already_,
    even when it meant just ripping out certain drivers completely. That
    seems excessive to me; I prefer not to actually _break_ anything.

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


    I disagree that the _default_ is such an issue -- largely because the
    normal case for modern drivers is not to include the firmware _anyway_,
    and the tools like 'mkinitrd' already cope with it just fine.

    But I've changed the default to 'y' now, as I already said.

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

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

    On Fri, 04 Jul 2008 01:24:59 +0100, David Woodhouse wrote:
    ....
    >I'll look at making the requirement for 'make firmware_install' more
    >obvious, or even making it happen automatically as part of
    >'modules_install'.


    I like this one: Automagically part of modules_install. No break existing
    kernel build scripts for the expected-by-user build sequence?

    And please put 'make firmware_install' into 'make help' if that's the way
    you go.

    And another point, at the moment I seem to get all sorts of odd things
    built I didn't know were there?

    root@pooh:/home/grant/linux/linux-2.6.26-rc8-mm1a# make firmware_install
    HOSTCC firmware/ihex2fw
    IHEX2FW firmware/atmsar11.fw
    INSTALL usr/lib/firmware/atmsar11.fw
    IHEX2FW firmware/dabusb/firmware.fw
    INSTALL usr/lib/firmware/dabusb/firmware.fw
    IHEX2FW firmware/emi26/loader.fw
    INSTALL usr/lib/firmware/emi26/loader.fw
    IHEX2FW firmware/emi26/firmware.fw
    INSTALL usr/lib/firmware/emi26/firmware.fw
    IHEX2FW firmware/emi26/bitstream.fw
    INSTALL usr/lib/firmware/emi26/bitstream.fw
    IHEX2FW firmware/emi62/loader.fw
    INSTALL usr/lib/firmware/emi62/loader.fw
    IHEX2FW firmware/emi62/bitstream.fw
    INSTALL usr/lib/firmware/emi62/bitstream.fw
    IHEX2FW firmware/emi62/spdif.fw
    INSTALL usr/lib/firmware/emi62/spdif.fw
    IHEX2FW firmware/emi62/midi.fw
    INSTALL usr/lib/firmware/emi62/midi.fw
    IHEX2FW firmware/keyspan/mpr.fw
    INSTALL usr/lib/firmware/keyspan/mpr.fw
    IHEX2FW firmware/keyspan/usa18x.fw
    INSTALL usr/lib/firmware/keyspan/usa18x.fw
    IHEX2FW firmware/keyspan/usa19.fw
    INSTALL usr/lib/firmware/keyspan/usa19.fw
    IHEX2FW firmware/keyspan/usa19qi.fw
    INSTALL usr/lib/firmware/keyspan/usa19qi.fw
    IHEX2FW firmware/keyspan/usa19qw.fw
    INSTALL usr/lib/firmware/keyspan/usa19qw.fw
    IHEX2FW firmware/keyspan/usa19w.fw
    INSTALL usr/lib/firmware/keyspan/usa19w.fw
    IHEX2FW firmware/keyspan/usa28.fw
    INSTALL usr/lib/firmware/keyspan/usa28.fw
    IHEX2FW firmware/keyspan/usa28xa.fw
    INSTALL usr/lib/firmware/keyspan/usa28xa.fw
    IHEX2FW firmware/keyspan/usa28xb.fw
    INSTALL usr/lib/firmware/keyspan/usa28xb.fw
    IHEX2FW firmware/keyspan/usa28x.fw
    INSTALL usr/lib/firmware/keyspan/usa28x.fw
    IHEX2FW firmware/keyspan/usa49w.fw
    INSTALL usr/lib/firmware/keyspan/usa49w.fw
    IHEX2FW firmware/keyspan/usa49wlc.fw
    INSTALL usr/lib/firmware/keyspan/usa49wlc.fw
    IHEX2FW firmware/whiteheat_loader.fw
    INSTALL usr/lib/firmware/whiteheat_loader.fw
    IHEX2FW firmware/whiteheat.fw
    INSTALL usr/lib/firmware/whiteheat.fw
    IHEX2FW firmware/keyspan_pda/keyspan_pda.fw
    INSTALL usr/lib/firmware/keyspan_pda/keyspan_pda.fw
    IHEX2FW firmware/keyspan_pda/xircom_pgs.fw
    INSTALL usr/lib/firmware/keyspan_pda/xircom_pgs.fw
    H16TOFW firmware/vicam/firmware.fw
    INSTALL usr/lib/firmware/vicam/firmware.fw

    The .config and dmesg are at:
    http://bugsplatter.mine.nu/test/boxe...26-rc8-mm1a.gz
    http://bugsplatter.mine.nu/test/boxe...26-rc8-mm1a.gz

    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/

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

    On Fri, Jul 04, 2008 at 02:09:15AM +0100, David Woodhouse wrote:
    > But there's no need to do it _now_. It can wait until the basic stuff is
    > in Linus' tree and it can automatically derive from that. There's no
    > particular rush, is there?


    The only rush if the main agenda is to extirpate all firmware from the
    mainline kernel sources. I don't think we can start the timer for
    doing that until the firmware tarball is created and it starts being
    used as the default way of delivering firmware for what you call
    "legacy" drivers. If there's no particular rush to finally rm the
    firmware for trivers such as tg3 from the source tree (and I
    personally don't think there should be any rush), or any rush to
    change the default for CONFIG_FIRMWARE_IN_KERNEL to "no", then I don't
    see any rush in creating the firmware tarball.

    If *you* think there is a rush in making CONFIG_FIRMWARE_IN_KERNEL
    default to "no", then you might want to decide to create the firmware
    tarball sooner, and get distro's everywhere to start using it, and to
    get everyone to understand that they should start including it in
    their systems. (Remember, not everyone uses the popular distributions
    like Fedora, Debian, Ubuntu, Open SuSE, etc.)

    But heck, that's up to you. :-)

    >> and for a while (read: at least 9-18 months) we can distribute firmware
    > > both in the kernel source tarball as well as separately

    >
    > That makes a certain amount of sense.


    Glad we agree.

    >> in the licensing-religion-firmware tarball.

    >
    > Please don't be gratuitously offensive, Ted. It's not polite, and it's
    > not a particularly good debating technique either. I expect better from
    > you.


    Well, I think it's offensive to break users who have happily been
    using drivers that have been including firmware for a long, long, LONG
    time, and I expected better of you.

    So there. :-)

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

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

    Alan Cox writes:
    > > 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"
    > --


    Last time I checked only x86 had 'make install'. I regularly build
    natively on ppc(32|64) and sparc64, and none of them implement
    'make install' AFAIK. And on ARM I move the kernels over to a tftp
    server for network boots, again w/o 'make install'.

    Not that 'make install' is difficult. All it does it hand over to
    /sbin/installkernel or something like that.

    In the context of .config changes, 'make oldconfig' with 'select the
    default' must IMO result in a working kernel similar to the previous
    one. Anything else is madness or arrogance.
    --
    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. Question: split-lur // Re: 2.6.26-rc8-mm1


    In split-lru, zone->prev_priority seems not to be used.
    (just remembers....)
    Is this obsolete parameter ?

    I'm sorry if I miss something.

    Thanks,
    -Kame

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

    On Fri, 4 Jul 2008, David Woodhouse wrote:

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


    has this taken place yet? (and if so, what kernel version first included
    this fix)

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


    but doing so should not be a easy and quick decision, and it needs to be
    made very clear exactly what breakage is going to take place and why
    (along with the explination of why the breakage couldn't be avoided)

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


    I won't mind this as long as I can get a working kernel without doing make
    firmware_install or make modules_install (I almost never use modules, my
    laptop is one of the few exceptions, and even there it's mostly becouse of
    the intel wireless driver needing userspace for firmware)

    David Lang
    --
    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. memcg: lru scan fix (Was: 2.6.26-rc8-mm1

    Since rc5-mm3, memcg easily goes into OOM when limit was low.
    This is a fix to split-lru to fix OOM.

    ==
    Under memcg, active anon tend not to go to inactive anon.
    This will cause OOM in memcg easily when tons of anon was used at once.
    This check was lacked in split-lru.

    Signed-off-by:KAMEZAWA Hiroyuki

    Index: test-2.6.26-rc8-mm1/mm/vmscan.c
    ================================================== =================
    --- test-2.6.26-rc8-mm1.orig/mm/vmscan.c
    +++ test-2.6.26-rc8-mm1/mm/vmscan.c
    @@ -1501,6 +1501,8 @@ static unsigned long shrink_zone(int pri
    */
    if (scan_global_lru(sc) && inactive_anon_is_low(zone))
    shrink_active_list(SWAP_CLUSTER_MAX, zone, sc, priority, 0);
    + else if (!scan_global_lru(sc))
    + shrink_active_list(SWAP_CLUSTER_MAX, zone, sc, priority, 0);

    throttle_vm_writeout(sc->gfp_mask);
    return nr_reclaimed;

    --
    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. [PATCH] memcg: handle shmem's swap cache (Was 2.6.26-rc8-mm1

    My swapcache accounting under memcg patch failed to catch tmpfs(shmem)'s one.
    Can I test this under -mm tree ?
    (If -mm is busy, I'm not in hurry.)
    This patch works well in my box.
    =
    SwapCache handling fix.

    shmem's swapcache behavior is a little different from anonymous's one and
    memcg failed to handle it. This patch tries to fix it.

    After this:

    Any page marked as SwapCache is not uncharged. (delelte_from_swap_cache()
    delete the SwapCache flag.)

    To check a shmem-page-cache is alive or not we use
    page->mapping && !PageAnon(page) instead of
    pc->flags & PAGE_CGROUP_FLAG_CACHE.

    Signed-off-by: KAMEZAWA Hiroyuki

    Index: test-2.6.26-rc8-mm1/mm/memcontrol.c
    ================================================== =================
    --- test-2.6.26-rc8-mm1.orig/mm/memcontrol.c
    +++ test-2.6.26-rc8-mm1/mm/memcontrol.c
    @@ -687,11 +687,45 @@ __mem_cgroup_uncharge_common(struct page

    VM_BUG_ON(pc->page != page);

    - if ((ctype == MEM_CGROUP_CHARGE_TYPE_MAPPED)
    - && ((pc->flags & PAGE_CGROUP_FLAG_CACHE)
    - || page_mapped(page)
    - || PageSwapCache(page)))
    + /*
    + * File Cache
    + * If called with MEM_CGROUP_CHARGE_TYPE_MAPPED, check page->mapping.
    + * add_to_page_cache() .... charged before inserting radix-tree.
    + * remove_from_page_cache() .... uncharged at removing from radix-tree.
    + * page->mapping && !PageAnon(page) catches file cache.
    + *
    + * Anon/Shmem.....We check PageSwapCache(page).
    + * Anon .... charged before mapped.
    + * Shmem .... charged at add_to_page_cache() as usual File Cache.
    + *
    + * This page will be finally uncharged when removed from swap-cache
    + *
    + * we treat 2 cases here.
    + * A. anonymous page B. shmem.
    + * We never uncharge if page is marked as SwapCache.
    + * add_to_swap_cache() have nothing to do with charge/uncharge.
    + * SwapCache flag is deleted before delete_from_swap_cache() calls this
    + *
    + * shmem's behavior is following. (see shmem.c/swap_state.c also)
    + * at swap-out:
    + * 0. add_to_page_cache()//charged at page creation.
    + * 1. add_to_swap_cache() (marked as SwapCache)
    + * 2. remove_from_page_cache(). (calls this.)
    + * (finally) delete_from_swap_cache(). (calls this.)
    + * at swap-in:
    + * 3. add_to_swap_cache() (no charge here.)
    + * 4. add_to_page_cache() (charged here.)
    + * 5. delete_from_swap_cache() (calls this.)
    + * PageSwapCache(page) catches "2".
    + * page->mapping && !PageAnon() catches "5" and avoid uncharging.
    + */
    + if (PageSwapCache(page))
    goto unlock;
    + /* called from unmap or delete_from_swap_cache() */
    + if ((ctype == MEM_CGROUP_CHARGE_TYPE_MAPPED)
    + && (page_mapped(page)
    + || (page->mapping && !PageAnon(page))))/* alive cache ? */
    + goto unlock;

    mz = page_cgroup_zoneinfo(pc);
    spin_lock_irqsave(&mz->lru_lock, flags);

    --
    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 Thu, 2008-07-03 at 19:42 -0700, david@lang.hm wrote:
    > > (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.)

    >
    > has this taken place yet? (and if so, what kernel version first included
    > this fix)


    It's in linux-next now. See the CONFIG_EXTRA_FIRMWARE option.

    That's one of the reasons Ted's ranting about 'religious fundamentalism'
    is so funny -- I've actually made it _easier_ for you to combine
    arbitrary firmware files into your kernel.

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

    >
    > but doing so should not be a easy and quick decision, and it needs to be
    > made very clear exactly what breakage is going to take place and why
    > (along with the explination of why the breakage couldn't be avoided)


    All forms of change introduce _some_ risk of breakage, of course. In
    this case, as usual, I've tried to be careful to avoid regressions. The
    most important part, obviously, was having a way to build firmware into
    the static kernel.

    When it comes to _modules_, doing that would introduce a certain amount
    of complexity which just doesn't seem necessary -- if you can load
    modules, then you have userspace, and you can use hotplug for firmware
    too. Especially given that so many modern drivers already _require_ you
    to do that, so the users understand it, and the tools like mkinitrd
    already cope with it -- checking MODULE_FIRMWARE() for the modules they
    include and including the appropriate files automatically.

    The alleged problem with modules seems to be _just_ about the fact that
    people need to run 'make firmware_install', and need to have their
    firmware installed. Something which all modern drivers require _anyway_,
    and people are used to in the general case already. It's not exactly
    hard; there's just the initial step of realising that the driver _you_
    are using has now been updated to behave like all the others.

    That step is _minor_, and it doesn't actually get any easier _however_
    long you postpone it. Yes, you might get 10 people in the first day
    tripping over it, and I'll look to see if I can make it clearer. But
    it's still a very minor, short-term thing.

    I suspect that the best option is just to hold off on updating the net
    drivers until later, when people already _know_ that they need to run
    'make firmware_install', (or it happens automatically or something, if
    we go down that route). That way, Dave and Jeff shouldn't be affected by
    the initial transition period.

    There's plenty of other drivers which need updating, after all. And most
    maintainers are _happy_ to see the patches to bring their drivers in
    line with best current practice.

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

    >
    > I won't mind this as long as I can get a working kernel without doing make
    > firmware_install or make modules_install


    You can. You need to stay sober for long enough to say 'Y' when it asks
    you if you want to build the required firmware into the kernel. And we
    even made that the _default_ now, for the benefit of those who can't
    stay sober that long. (Perhaps we'll make 'allyesconfig' the default
    next?)

    > (I almost never use modules, my laptop is one of the few exceptions,
    > and even there it's mostly becouse of the intel wireless driver
    > needing userspace for firmware)


    You don't need to do that any more

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

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

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


    Perhaps I didn't pay enough attention, but how are "only
    boot bzImage without initrd or modules" setups supposed to work now
    for those drivers? My testing setup relies on that heavily.

    Will the firmware automatically end up in initramfs and be included
    in the bzImage and loaded at the right point?

    I hope we won't let lawyers decide technical topics here.

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

    At Thu, 3 Jul 2008 14:04:36 +0100 (BST),
    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).


    Hmm, I got this error even with CONFIG_FIRMWARE_IN_KERNEL=y.

    Through a quick look at the code, the firmwares are not built indeed.
    I guess the fix like the following needed for building firmwares for
    modules. Now trying to build the kernel again to check this...


    Takashi


    diff --git a/firmware/Makefile b/firmware/Makefile
    index f88d746..e11fc2a 100644
    --- a/firmware/Makefile
    +++ b/firmware/Makefile
    @@ -55,6 +55,8 @@ fw-shipped-$(CONFIG_USB_SERIAL_XIRCOM) += keyspan_pda/xircom_pgs.fw
    fw-shipped-$(CONFIG_USB_VICAM) += vicam/firmware.fw
    fw-shipped-$(CONFIG_VIDEO_CPIA2) += cpia2/stv0672_vp4.bin

    +fw-shipped-y := $(fw-shipped-y) $(fw-shipped-m)
    +
    # If CONFIG_FIRMWARE_IN_KERNEL is not set, then don't include any firmware
    ifneq ($(CONFIG_FIRMWARE_IN_KERNEL),y)
    fw-shipped-y :=
    --
    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"

    On Fri, 2008-07-04 at 13:06 +0200, Takashi Iwai wrote:
    > Hmm, I got this error even with CONFIG_FIRMWARE_IN_KERNEL=y.
    >
    > Through a quick look at the code, the firmwares are not built indeed.
    > I guess the fix like the following needed for building firmwares for
    > modules. Now trying to build the kernel again to check this...


    For modules, you just need run
    'make INSTALL_FW_PATH=/lib/firmare firmware_install'.

    I should...

    1. Change the default to /lib/firmware so that you don't have to set
    INSTALL_FW_PATH.
    2. Add that to the 'make help' text.
    3. Look at making 'make modules_install' installl the firmware required
    by the modules it's installing, so you don't even need to do
    _anything_ new.

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

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

    David Woodhouse wrote:
    > On Fri, 2008-07-04 at 12:09 +0200, Andi Kleen wrote:
    >> David Woodhouse writes:
    >>> I'll look at making the requirement for 'make firmware_install' more
    >>> obvious, or even making it happen automatically as part of
    >>> 'modules_install'.

    >> Perhaps I didn't pay enough attention, but how are "only
    >> boot bzImage without initrd or modules" setups supposed to work now
    >> for those drivers? My testing setup relies on that heavily.

    >
    > That will continue to work just fine.
    >
    >> Will the firmware automatically end up in initramfs and be included
    >> in the bzImage and loaded at the right point?

    >
    > No, not even in the initramfs. It's built _right_ into the static kernel
    > image, and request_firmware() finds it there without even having to call
    > out to userspace at all.
    > http://git.infradead.org/users/dwmw2...iff;h=81d4e79a


    However, there is still a broken element to the system: the firmware no
    longer rides along in the module's .ko file. That introduces new
    problems for any user and script that copies modules around.

    The compiled-in firmware should be in the same place where it was before
    your changes -- in the driver's kernel module.

    So, yes, there should not be regressions for non-module users. Let's
    now solve the regression problem for the other half of the world...

    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"

    On Fri, 2008-07-04 at 12:09 +0200, Andi Kleen wrote:
    > David Woodhouse writes:
    > >
    > > I'll look at making the requirement for 'make firmware_install' more
    > > obvious, or even making it happen automatically as part of
    > > 'modules_install'.

    >
    > Perhaps I didn't pay enough attention, but how are "only
    > boot bzImage without initrd or modules" setups supposed to work now
    > for those drivers? My testing setup relies on that heavily.


    That will continue to work just fine.

    > Will the firmware automatically end up in initramfs and be included
    > in the bzImage and loaded at the right point?


    No, not even in the initramfs. It's built _right_ into the static kernel
    image, and request_firmware() finds it there without even having to call
    out to userspace at all.
    http://git.infradead.org/users/dwmw2...iff;h=81d4e79a

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

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

    At Fri, 04 Jul 2008 14:17:51 +0100,
    David Woodhouse wrote:
    >
    > On Fri, 2008-07-04 at 13:06 +0200, Takashi Iwai wrote:
    > > Hmm, I got this error even with CONFIG_FIRMWARE_IN_KERNEL=y.
    > >
    > > Through a quick look at the code, the firmwares are not built indeed.
    > > I guess the fix like the following needed for building firmwares for
    > > modules. Now trying to build the kernel again to check this...

    >
    > For modules, you just need run
    > 'make INSTALL_FW_PATH=/lib/firmare firmware_install'.
    >
    > I should...
    >
    > 1. Change the default to /lib/firmware so that you don't have to set
    > INSTALL_FW_PATH.
    > 2. Add that to the 'make help' text.
    > 3. Look at making 'make modules_install' installl the firmware required
    > by the modules it's installing, so you don't even need to do
    > _anything_ new.


    Ah I see. I thought you implemented the built-in firmware even for
    modules, but apparently it's not.

    Is mkinitrd clever enough to put all needed firmware files to initrd
    automatically? Otherwise this can still break the existing setup...


    thanks,

    Takashi
    --
    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: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin"

    On Fri, 2008-07-04 at 15:26 +0200, Takashi Iwai wrote:
    > Ah I see. I thought you implemented the built-in firmware even for
    > modules, but apparently it's not.


    It isn't really necessary. If you can load modules, then you have
    userspace. And if you have userspace, you can load firmware too.

    > Is mkinitrd clever enough to put all needed firmware files to initrd
    > automatically? Otherwise this can still break the existing setup...


    Yes, it's had to be clever enough for that for a long time anyway --
    most modern drivers have _only_ the 'request_firmware()' option and
    never gave you the choice of building it in. I'm just updating some of
    the older drivers to catch up.

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

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

    On Fri, 2008-07-04 at 09:15 -0400, Jeff Garzik wrote:
    >
    > However, there is still a broken element to the system: the firmware no
    > longer rides along in the module's .ko file. That introduces new
    > problems for any user and script that copies modules around.
    >
    > The compiled-in firmware should be in the same place where it was before
    > your changes -- in the driver's kernel module.


    No, Jeff. That is neither new, nor a real problem. You're just
    posturing.

    That's the way it has been for a _long_ time anyway, for any modern
    driver which uses request_firmware(). The whole point about modules is
    _modularity_. Yes, that means that sometimes they depend on _other_
    modules, or on firmware.

    The scripts which handle that kind of thing have handled inter-module
    dependencies, and MODULE_FIRMWARE(), for a long time now.

    If I ask mkinitrd to include the b43 driver in my initrd, for example,
    it should quite happily include both mac80211.ko and the required
    firmware.

    All I'm doing is updating some of the older drivers which don't conform
    to current best practice, and which still keep large chunks of data in
    unswappable kernel memory instead of loading it on demand. And making
    that more workable in the general case, but giving the _option_ of
    building arbitrary firmware into the kernel, for _all_ modern drivers.

    Your argument makes about as much sense as an argument that we should
    link b43.ko with mac80211.ko so that the 802.11 core code "rides along
    in the module's .ko file". It's just silly.

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

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

    David Woodhouse wrote:
    > 3. Look at making 'make modules_install' installl the firmware required
    > by the modules it's installing, so you don't even need to do
    > _anything_ new.



    Anything that works with existing build processes would be a positive
    step, preventing loads of build&test regressions.

    This does not change the need, of course, to default this firmware
    install stuff to 'off', and allow distros to turn it on when they're
    ready (as Alan, Ted, and others have suggested in this thread).

    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/

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

    > Why is it so difficult to see the value of KEEPING STUFF WORKING AS IT
    > WORKS TODAY?


    Sure Jeff. Lets delete libata, that caused all sorts of problems when it
    was being added. We could freeze on linux 1.2.13-lmp, that was a good
    release - why break it ?

    There are good sound reasons for having a firmware tree, the fact tg3 is
    a bit of dinosaur in this area doesn't make it wrong.
    --
    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 3 of 9 FirstFirst 1 2 3 4 5 ... LastLast