Linux v2.6.27-rc1 - Kernel

This is a discussion on Linux v2.6.27-rc1 - Kernel ; On Tuesday, 29 of July 2008, Rafael J. Wysocki wrote: > On Tuesday, 29 of July 2008, Linus Torvalds wrote: > > > > It's two weeks (and one day), and the merge window is over. > > > > ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 42

Thread: Linux v2.6.27-rc1

  1. Re: Linux v2.6.27-rc1: problem with firmware stuff

    On Tuesday, 29 of July 2008, Rafael J. Wysocki wrote:
    > On Tuesday, 29 of July 2008, Linus Torvalds wrote:
    > >
    > > It's two weeks (and one day), and the merge window is over.
    > >
    > > Finally. I don't know why, but this one really did feel pretty dang busy.
    > > And the size of the -rc1 patch bears that out - at 12MB, it's about 50%
    > > bigger than 26-rc1 (but not that much bigger than 24/25-rc1, so it's not
    > > like it's anything unheard of).
    > >
    > > The pure size of the -rc's _is_ making me a bit nervous, though. Sure, it
    > > means that we are good at merging it all, but I have to say that I
    > > sometimes wonder if we don't merge too much in one go, and even our
    > > current (fairly short) release cycle is actually too big.
    > >
    > > Anyway, that's a discussion for some other event.
    > >
    > > Much of -rc1 was in linux-next, but certainly not everything. We'll see
    > > how that whole thing ends up evolving - it certainly didn't solve all
    > > problems, and there was some bickering about things that weren't there
    > > (and some things that mostly were , but maybe it helped.
    > >
    > > There's a ton of new stuff in there, but at least personally the
    > > interesting things are the BKL pushdown and perhaps the introduction of
    > > the lockless get_user_pages_fast(). The build system also got updated to
    > > allow moving the architecture include files ("include/asm-xyz") into the
    > > architecture subdirectories ("arch/xyz/include/asm"), and sparc seems to
    > > have taken advantage of that already.
    > >
    > > But those changes are just small details in the end. As usual, the bulk of
    > > changes are all to device drivers (roughly half, as usual), with the arch
    > > directory amounting to about half of the remainder. Dirstat:
    > >
    > > 3.2% arch/arm/
    > > 9.2% arch/ppc/
    > > 24.6% arch/
    > > 5.2% drivers/char/drm/
    > > 6.3% drivers/char/
    > > 4.5% drivers/gpu/drm/
    > > 4.5% drivers/gpu/
    > > 4.6% drivers/media/video/
    > > 5.5% drivers/media/
    > > 3.0% drivers/net/wireless/
    > > 10.7% drivers/net/
    > > 6.4% drivers/usb/misc/
    > > 4.7% drivers/usb/serial/
    > > 12.9% drivers/usb/
    > > 51.2% drivers/
    > > 4.4% firmware/
    > > 3.7% fs/
    > > 9.2% include/
    > >
    > > where the bulk of that fs/ update is the merge of the UBI filesystem, to
    > > pick one fairly sizeable chunk outside of arch or drivers (there's omfs
    > > too, but that's tiny in comparison).
    > >
    > > Other stuff? tracing. firmware loading.

    >
    > That one happens to break things for me badly:
    >
    > rafael@chimera:~/src/linux-2.6> make O=../build/mainline/chimera -j5
    > GEN /home/rafael/src/build/mainline/chimera/Makefile
    > CHK include/linux/version.h
    > CHK include/linux/utsrelease.h
    > Using /home/rafael/src/linux-2.6 as source for kernel
    > CALL /home/rafael/src/linux-2.6/scripts/checksyscalls.sh
    > CHK include/linux/compile.h
    > Building modules, stage 2.
    > Kernel: arch/x86/boot/bzImage is ready (#208)
    > MODPOST 564 modules
    > IHEX2FW firmware/emi26/loader.fw
    > Failed to open destination file: Permission deniedihex2fw: Convert ihex files into binary representation for use by Linux kernel
    > usage: ihex2fw []
    > -w: wide records (16-bit length)
    > -s: sort records by address
    > IHEX2FW firmware/emi26/bitstream.fw
    > IHEX2FW firmware/emi26/firmware.fw
    > Failed to open destination file: Permission deniedihex2fw: Convert ihex files into binary representation for use by Linux kernel
    > usage: ihex2fw []
    > -w: wide records (16-bit length)
    > -s: sort records by address
    > make[2]: *** [firmware/emi26/loader.fw] Error 1
    > make[2]: *** Waiting for unfinished jobs....
    > make[2]: *** [firmware/emi26/bitstream.fw] Error 1
    > Failed to open destination file: Permission deniedihex2fw: Convert ihex files into binary representation for use by Linux kernel
    > usage: ihex2fw []
    > -w: wide records (16-bit length)
    > -s: sort records by address
    > make[2]: *** [firmware/emi26/firmware.fw] Error 1
    > make[1]: *** [modules] Error 2
    > make: *** [sub-make] Error 2


    Actually, this happened due to some firmware files being created as root during
    installations of pre-rc -git kernels from the O= directory. So, not a real
    problem, but somewhat confusing.

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

  2. Re: Linux v2.6.27-rc1: problem with firmware stuff



    On Tue, 29 Jul 2008, Rafael J. Wysocki wrote:
    >
    > Actually, this happened due to some firmware files being created as root during
    > installations of pre-rc -git kernels from the O= directory. So, not a real
    > problem, but somewhat confusing.


    Yeah, I've had that happen myself. It used to be that "make
    modules_install" (as root, obviously) would try build a new version of the
    kernel, and as a result subsequent build attempts would fail horribly
    because of various random files being now owned-by-root.

    I don't know if there is a whole lot we can do about it in general..

    Linus
    --
    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: Linux v2.6.27-rc1

    On Mon, Jul 28, 2008 at 08:23:21PM -0700, Linus Torvalds wrote:

    > The build system also got updated to
    > allow moving the architecture include files ("include/asm-xyz") into the
    > architecture subdirectories ("arch/xyz/include/asm"), and sparc seems to
    > have taken advantage of that already.


    Most architectures are easy to convert. But those that uses
    symlinks to select between different platforms etc needs a bit more
    care if we shall get rid of all symlinks.

    Paul already fixed up sh and sent you a pull request.
    I have something ready for arm (not yet posted).
    And I sent Harvaard a small script that can fix avr32 when arm is done.
    cris looks similar and I can take care too.

    The rest that does not use additiona symlinks are in general much simpler.

    Kyle already fixed up parisc (simple).
    x86 is simple - only a small patch needed to arch/x86/Makefile.
    I have not dared looking at um.

    But will you accept this stuff now or will we have to wait until
    next merge window?
    Now is a good time as development just started for next kernel.
    And testing is simple - does it build?

    It will come in via arch maintainers but I will assist.

    Sam
    --
    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: Linux v2.6.27-rc1



    On Tue, 29 Jul 2008, Sam Ravnborg wrote:
    >
    > But will you accept this stuff now or will we have to wait until
    > next merge window?


    if the patches are really small adn the resulting build is well tested
    (ignoring the actual _move_ operation), I'm ok with taking them.

    In fact, in many ways I'd _prefer_ to do it now, rather than have it
    pending and then do it durign the next merge window when there are a lot
    of non-movement changes too.

    > Now is a good time as development just started for next kernel.
    > And testing is simple - does it build?


    Well, simple and simple. I'd love to see x86 done, but you yourself said
    you haven't even dared look at UM. Which is the thing that is most likely
    to have odd build things with direct symlinks etc.

    (But I haven't looked either. Maybe I'm wrong, and it's all trivial).

    Linus
    --
    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: Linux v2.6.27-rc1

    On Tue, Jul 29, 2008 at 02:42:00PM -0700, Linus Torvalds wrote:
    >
    >
    > On Tue, 29 Jul 2008, Sam Ravnborg wrote:
    > >
    > > But will you accept this stuff now or will we have to wait until
    > > next merge window?

    >
    > if the patches are really small adn the resulting build is well tested
    > (ignoring the actual _move_ operation), I'm ok with taking them.


    For arm the actual diff is:
    Makefile | 20 +++++++-------------
    boot/compressed/Makefile | 3 ---
    tools/Makefile | 1 +
    3 files changed, 8 insertions(+), 16 deletions(-)

    But on top of this there are ~600 files that needed a
    replacement of:
    #include
    to
    #include

    So maybe not such a minimal patch - because I wanted to drop all
    the symlink stuff.

    >
    > In fact, in many ways I'd _prefer_ to do it now, rather than have it
    > pending and then do it durign the next merge window when there are a lot
    > of non-movement changes too.
    >
    > > Now is a good time as development just started for next kernel.
    > > And testing is simple - does it build?

    >
    > Well, simple and simple. I'd love to see x86 done, but you yourself said
    > you haven't even dared look at UM. Which is the thing that is most likely
    > to have odd build things with direct symlinks etc.
    >
    > (But I haven't looked either. Maybe I'm wrong, and it's all trivial).

    um i never trivial :-(
    But I will give it a try - but I have to sleep first.

    Sam
    --
    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. Linux v2.6.27-rc1: fails to compile

    On Mon, 28 Jul 2008 20:23:21 -0700 (PDT), Linus Torvalds wrote:

    >
    >It's two weeks (and one day), and the merge window is over.
    >
    >Finally. I don't know why, but this one really did feel pretty dang busy.
    >And the size of the -rc1 patch bears that out - at 12MB, it's about 50%
    >bigger than 26-rc1 (but not that much bigger than 24/25-rc1, so it's not
    >like it's anything unheard of).


    Couple machines failed to compile with same error in different place:

    CC arch/x86/kernel/acpi/cstate.o
    arch/x86/kernel/acpi/cstate.c: In function `acpi_processor_ffh_cstate_probe':
    arch/x86/kernel/acpi/cstate.c:94: error: invalid lvalue in unary `&'
    make[2]: *** [arch/x86/kernel/acpi/cstate.o] Error 1
    make[1]: *** [arch/x86/kernel/acpi] Error 2
    make: *** [arch/x86/kernel] Error 2
    grant@peetoo:~/linux/linux-2.6.27-rc1a$

    Linux peetoo 2.6.25.13a #15 Tue Jul 29 07:41:48 EST 2008 i686 pentium3 i386 GNU/Linux

    Gnu C 3.4.6
    Gnu make 3.81
    binutils 2.15.92.0.2
    util-linux 2.12r
    mount 2.12r
    module-init-tools 3.2.2
    e2fsprogs 1.38
    reiserfsprogs 3.6.19
    quota-tools 3.13.
    PPP 2.4.4
    Linux C Library 2.3.6
    Dynamic linker (ldd) 2.3.6
    Linux C++ Library 6.0.3
    Procps 3.2.7
    Net-tools 1.60
    Kbd 1.12
    oprofile 0.9.1
    Sh-utils 5.97
    udev 097
    Modules Loaded adm9240 hwmon_vid nfsd exportfs tulip e100
    - - -

    CC arch/x86/kernel/ldt.o
    arch/x86/kernel/ldt.c: In function `alloc_ldt':
    arch/x86/kernel/ldt.c:67: error: invalid lvalue in unary `&'
    make[1]: *** [arch/x86/kernel/ldt.o] Error 1
    make: *** [arch/x86/kernel] Error 2
    grant@black:~/linux/linux-2.6.27-rc1a$

    Linux black 2.6.26a #1 SMP Fri Jul 25 08:49:49 EST 2008 i686 pentium4 i386 GNU/Linux

    Gnu C 3.4.6
    Gnu make 3.81
    binutils 2.15.92.0.2
    util-linux 2.12r
    mount 2.12r
    module-init-tools 3.2.2
    e2fsprogs 1.38
    jfsutils 1.1.11
    reiserfsprogs 3.6.19
    xfsprogs 2.8.10
    pcmciautils 014
    pcmcia-cs 3.2.8
    quota-tools 3.13.
    PPP 2.4.4
    Linux C Library 2.3.6
    Dynamic linker (ldd) 2.3.6
    Linux C++ Library 6.0.3
    Procps 3.2.7
    Net-tools 1.60
    Kbd 1.12
    oprofile 0.9.1
    Sh-utils 5.97
    udev 097
    Modules Loaded snd_pcm_oss snd_mixer_oss e100 ide_cd_mod snd_intel8x0 snd_ac97_codec cdrom ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc r8169

    Common factor is they're running slackware-11.0, but they both ran fairly
    recent -git11 or so.
    - - -

    Machine that compiled and booted 27-rc1 running slackware 12.1 with:
    Linux pooh 2.6.27-rc1a #1 SMP Wed Jul 30 17:37:16 EST 2008 i686 Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz GenuineIntel GNU/Linux

    Gnu C 4.2.3
    Gnu make 3.81
    binutils 2.17.50.0.17.20070615
    util-linux 2.13.1
    mount 2.13.1
    module-init-tools 3.4
    e2fsprogs 1.41.0
    reiserfsprogs 3.6.19
    Linux C Library 2.7
    Dynamic linker (ldd) 2.7
    Linux C++ Library 6.0.9
    Procps 3.2.7
    Net-tools 1.60
    Kbd 1.12
    oprofile 0.9.2
    Sh-utils 6.9
    udev 118
    Modules Loaded fuse sg

    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/

  7. Re: Linux v2.6.27-rc1



    On Tue, 29 Jul 2008, Sam Ravnborg wrote:
    >
    > For arm the actual diff is:
    > Makefile | 20 +++++++-------------
    > boot/compressed/Makefile | 3 ---
    > tools/Makefile | 1 +
    > 3 files changed, 8 insertions(+), 16 deletions(-)
    >
    > But on top of this there are ~600 files that needed a
    > replacement of:
    > #include
    > to
    > #include


    Yeah, that latter part doesn't strike me as wonderful.

    > So maybe not such a minimal patch - because I wanted to drop all
    > the symlink stuff.


    Why? There's nothing wrong with symlinks.

    The problem with 'include/asm' isn't the symlink per se, it's that it
    split up the architecture parts in two separate areas - arch and include.

    Linus
    --
    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: Linux v2.6.27-rc1: problem with firmware stuff

    On Tue, 2008-07-29 at 14:01 -0700, Linus Torvalds wrote:
    >
    > On Tue, 29 Jul 2008, Rafael J. Wysocki wrote:
    > >
    > > Actually, this happened due to some firmware files being created as root during
    > > installations of pre-rc -git kernels from the O= directory. So, not a real
    > > problem, but somewhat confusing.

    >
    > Yeah, I've had that happen myself. It used to be that "make
    > modules_install" (as root, obviously) would try build a new version of the
    > kernel, and as a result subsequent build attempts would fail horribly
    > because of various random files being now owned-by-root.
    >
    > I don't know if there is a whole lot we can do about it in general..


    Not in general. I _think_ I fixed the specific problem which led to
    Rafael's situation, but I'm still waiting for confirmation of that.

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

  9. Re: Linux v2.6.27-rc1

    On Tue, Jul 29, 2008 at 03:03:47PM -0700, Linus Torvalds wrote:
    >
    >
    > On Tue, 29 Jul 2008, Sam Ravnborg wrote:
    > >
    > > For arm the actual diff is:
    > > Makefile | 20 +++++++-------------
    > > boot/compressed/Makefile | 3 ---
    > > tools/Makefile | 1 +
    > > 3 files changed, 8 insertions(+), 16 deletions(-)
    > >
    > > But on top of this there are ~600 files that needed a
    > > replacement of:
    > > #include
    > > to
    > > #include

    >
    > Yeah, that latter part doesn't strike me as wonderful.
    >
    > > So maybe not such a minimal patch - because I wanted to drop all
    > > the symlink stuff.

    >
    > Why? There's nothing wrong with symlinks.
    >
    > The problem with 'include/asm' isn't the symlink per se, it's that it
    > split up the architecture parts in two separate areas - arch and include.


    I agree that we do this to combine all arch files. But we then have the
    possibility to get rid of some build stuff that is fragile and needs
    special care for O=.. builds etc.
    So when we anyway do the renames I saw the opportunity to go one step
    further.
    Lets see how the x86 + um stuff looks like.

    For x86 alone the patchs looks like this:

    diff --git a/arch/x86/Makefile b/arch/x86/Makefile
    index f5631da..c7493e7 100644
    --- a/arch/x86/Makefile
    +++ b/arch/x86/Makefile
    @@ -110,16 +110,16 @@ KBUILD_CFLAGS += $(call cc-option,-mno-sse -mno-mmx -mno-sse2 -mno-3dnow,)
    mcore-y := arch/x86/mach-default/

    # Voyager subarch support
    -mflags-$(CONFIG_X86_VOYAGER) := -Iinclude/asm-x86/mach-voyager
    +mflags-$(CONFIG_X86_VOYAGER) := -Iarch/x86/include/mach-voyager
    mcore-$(CONFIG_X86_VOYAGER) := arch/x86/mach-voyager/

    # generic subarchitecture
    -mflags-$(CONFIG_X86_GENERICARCH):= -Iinclude/asm-x86/mach-generic
    +mflags-$(CONFIG_X86_GENERICARCH):= -Iarch/x86/include/mach-generic
    fcore-$(CONFIG_X86_GENERICARCH) += arch/x86/mach-generic/
    mcore-$(CONFIG_X86_GENERICARCH) := arch/x86/mach-default/

    # default subarch .h files
    -mflags-y += -Iinclude/asm-x86/mach-default
    +mflags-y += -Iarch/x86/include/mach-default

    # 64 bit does not support subarch support - clear sub arch variables
    fcore-$(CONFIG_X86_64) :=

    And the script to move the files looks like this:
    set -e
    for D in include/asm-x86/mach-*; do
    echo $D
    DD=$(echo $D | cut -d '-' -f 3)
    mkdir -p arch/x86/include/mach-$DD/arch
    git mv include/asm-x86/mach-$DD/* arch/x86/include/mach-$DD
    rmdir include/asm-x86/mach-$DD
    done

    mkdir -p arch/x86/include/asm
    git mv include/asm-x86/* arch/x86/include/asm

    But I have not yet looked at um.

    Sam
    --
    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: Linux v2.6.27-rc1: fails to compile

    Hello Grant,
    On Wed, Jul 30, 2008 at 08:03:42AM +1000, Grant Coady wrote:
    > On Mon, 28 Jul 2008 20:23:21 -0700 (PDT), Linus Torvalds wrote:
    >
    > >
    > >It's two weeks (and one day), and the merge window is over.
    > >
    > >Finally. I don't know why, but this one really did feel pretty dang busy.
    > >And the size of the -rc1 patch bears that out - at 12MB, it's about 50%
    > >bigger than 26-rc1 (but not that much bigger than 24/25-rc1, so it's not
    > >like it's anything unheard of).

    >
    > Couple machines failed to compile with same error in different place:
    >
    > CC arch/x86/kernel/acpi/cstate.o
    > arch/x86/kernel/acpi/cstate.c: In function `acpi_processor_ffh_cstate_probe':
    > arch/x86/kernel/acpi/cstate.c:94: error: invalid lvalue in unary `&'
    > make[2]: *** [arch/x86/kernel/acpi/cstate.o] Error 1
    > make[1]: *** [arch/x86/kernel/acpi] Error 2
    > make: *** [arch/x86/kernel] Error 2
    > grant@peetoo:~/linux/linux-2.6.27-rc1a$
    >

    This issue has been reported, this is due to your old compiler.
    Fix here:
    http://lkml.org/lkml/2008/7/29/48

    Regards,
    Frederik
    --
    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: Linux v2.6.27-rc1: fails to compile

    On Wed, 30 Jul 2008 00:40:49 +0200, Frederik Deweerdt wrote:

    >Hello Grant,
    >On Wed, Jul 30, 2008 at 08:03:42AM +1000, Grant Coady wrote:
    >> On Mon, 28 Jul 2008 20:23:21 -0700 (PDT), Linus Torvalds wrote:
    >>
    >> >
    >> >It's two weeks (and one day), and the merge window is over.
    >> >
    >> >Finally. I don't know why, but this one really did feel pretty dang busy.
    >> >And the size of the -rc1 patch bears that out - at 12MB, it's about 50%
    >> >bigger than 26-rc1 (but not that much bigger than 24/25-rc1, so it's not
    >> >like it's anything unheard of).

    >>
    >> Couple machines failed to compile with same error in different place:
    >>
    >> CC arch/x86/kernel/acpi/cstate.o
    >> arch/x86/kernel/acpi/cstate.c: In function `acpi_processor_ffh_cstate_probe':
    >> arch/x86/kernel/acpi/cstate.c:94: error: invalid lvalue in unary `&'
    >> make[2]: *** [arch/x86/kernel/acpi/cstate.o] Error 1
    >> make[1]: *** [arch/x86/kernel/acpi] Error 2
    >> make: *** [arch/x86/kernel] Error 2
    >> grant@peetoo:~/linux/linux-2.6.27-rc1a$
    >>

    >This issue has been reported, this is due to your old compiler.
    >Fix here:
    >http://lkml.org/lkml/2008/7/29/48


    Thanks, that does the trick

    Grant.
    >
    >Regards,
    >Frederik


    --
    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: 2.6.27-rc1: zd1211rw association fails

    From: "John W. Linville"
    Date: Tue, 29 Jul 2008 13:52:06 -0400

    > On Tue, Jul 29, 2008 at 02:15:06PM +0200, Johannes Berg wrote:
    > >
    > > > > Yeah, it's really too bad -rc1 got released just before you were able
    > > > > to post the fix to this, since if there were 100 million people who
    > > > > were trying out kernels starting with -git7 that use wireless, there
    > > > > will probably be 200 million people trying out -rc1. :-)
    > > > >
    > > > > Thanks for finding and fixing it, though. I stopped trying out
    > > > > kernels after -git6 since I was travelling at OSCON, and not having
    > > > > wireless was a show-stopper for me....
    > > >
    > > > If everybody's going to decide now to hit on _me_, I'll point out that
    > > > davem's MQ TX changes broke it

    > >
    > > Of course that's not strictly true, it had been broken forever, it just
    > > happened to never show up before. And I mean forever, the original
    > > devicescape code that got in was already broken.

    >
    > FWIW, I think the MQ stuff didn't spend much (or any) time in -next...


    It did in a few formats, but then Patrick McHardy pointed out something
    that required my rewriting large swaths of it in the days leading up to
    the merge window.

    And the problem this showed up was a bug that existed in mac80211 long
    before I made any TX multiqueue changes :-)
    --
    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: 2.6.27-rc1: zd1211rw association fails

    On Tue, Jul 29, 2008 at 02:15:06PM +0200, Johannes Berg wrote:
    >
    > > > Yeah, it's really too bad -rc1 got released just before you were able
    > > > to post the fix to this, since if there were 100 million people who
    > > > were trying out kernels starting with -git7 that use wireless, there
    > > > will probably be 200 million people trying out -rc1. :-)
    > > >
    > > > Thanks for finding and fixing it, though. I stopped trying out
    > > > kernels after -git6 since I was travelling at OSCON, and not having
    > > > wireless was a show-stopper for me....

    > >
    > > If everybody's going to decide now to hit on _me_, I'll point out that
    > > davem's MQ TX changes broke it

    >
    > Of course that's not strictly true, it had been broken forever, it just
    > happened to never show up before. And I mean forever, the original
    > devicescape code that got in was already broken.


    FWIW, I think the MQ stuff didn't spend much (or any) time in -next...

    --
    John W. Linville
    linville@tuxdriver.com
    --
    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: Linux v2.6.27-rc1

    On Tue, 29 Jul 2008 09:59:18 -0700 (PDT) Linus Torvalds wrote:

    > - I don't think the 'next' thing works as well for the occasional
    > developer that just has a few patches pending as it works for subsystem
    > maintainers that are used to it.


    Those people's patches are in -mm, which now holds maybe 100 or more
    "trees", many of which are small or empty.

    My project within the next couple of weeks is to get most of that
    material into linux-next. Stephen will be involved

    > IOW, I think 'next' needs enough infrastructure setup from the
    > developer side that I don't think it's reasonable for _everything_ to
    > go through next.


    True. But

    a) some of the problematic changes which we've seen simply _should_
    have been in linux-next. Some of them were even coming from
    developers whose trees are already in linux-next.

    b) A lot of the bugs which hit your tree would have been quickly
    found in linux-next too.


    But it's all shuffling deckchairs, really. Are we actually merging
    better code as a reasult of all of this? Are we being more careful and
    reviewing better and testing better?

    Don't think so.

    > And that in turn means that I'm not entirely thrilled
    > when people then complain "that wasn't in next". I think people should
    > accept that not everything will be in next.


    Oh sure. But it depends on the _reason_ why it wasn't in linux-next.
    If the reason is a good one then fine. But if the reason is "I was too
    slack", or "I only wrote it five minutes ago" then the system is good,
    and the developer isn't.

    --
    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: Oops in microcode sysfs registration,

    2008/7/29 Alistair John Strachan :
    > On Tuesday 29 July 2008 17:22:14 Pekka Paalanen wrote:
    >> > Also, I'm sure this is reproducible without the NVIDIA garbage, but I was
    >> > too lazy to test it. If you want me to repeat the experiment without the
    >> > driver I would be more than happy to do so.

    >>
    >> I'm not sure people are willing to look into this without a clean report,
    >> so this would be cool. There's even a test module for mmiotrace in the
    >> kernel, but I doubt it would make difference to use it or not, when trying
    >> to reproduce the crash without the blob.

    >
    > Of course, and I should have attempted to reproduce without the driver.
    > Fortunately that was easy: it is not an NVIDIA driver bug.
    >
    > Steps to reproduce: have CONFIG_MICROCODE=y and a suitable Intel
    > processor, then do:
    >
    > echo mmiotrace >/debug/tracing/current_tracer
    > echo none >/debug/tracing/current_tracer
    >
    > And you get this (snipped) oops:
    >
    > in mmio_trace_init
    > mmiotrace: Disabling non-boot CPUs...
    > kvm: disabling virtualization on CPU1
    > CPU 1 is now offline
    > SMP alternatives: switching to UP code
    > CPU0 attaching NULL sched-domain.
    > CPU1 attaching NULL sched-domain.
    > CPU0 attaching NULL sched-domain.
    > mmiotrace: CPU1 is down.
    > mmiotrace: enabled.
    > in mmio_trace_reset
    > mmiotrace: Re-enabling CPUs...
    > SMP alternatives: switching to SMP code
    > Booting processor 1/1 ip 6000
    > Initializing CPU#1
    > Calibrating delay using timer specific routine.. <6>7204.76 BogoMIPS (lpj=3602381)
    > CPU: L1 I cache: 32K, L1 D cache: 32K
    > CPU: L2 cache: 4096K
    > CPU: Physical Processor ID: 0
    > CPU: Processor Core ID: 1
    > x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
    > CPU1: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz stepping 06
    > checking TSC synchronization [CPU#0 -> CPU#1]: passed.
    > kvm: enabling virtualization on CPU1
    > CPU0 attaching NULL sched-domain.
    > Switched to high resolution mode on CPU 1
    > CPU0 attaching sched-domain:
    > domain 0: span 0-1 level MC
    > groups: 0 1
    > CPU1 attaching sched-domain:
    > domain 0: span 0-1 level MC
    > groups: 1 0
    > ------------[ cut here ]------------
    > Kernel BUG at ffffffff8021a31d [verbose debug info unavailable]
    > invalid opcode: 0000 [1] PREEMPT SMP
    > CPU 0
    > Modules linked in: rfcomm l2cap kvm_intel kvm ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack ip_tables x_tables bridge stp llc acpi_cpufreq freq_table coretemp hwmon
    > snd_pcm_oss snd_mixer_oss firewire_sbp2 hci_usb bluetooth arc4 ecb crypto_blkcipher cryptomgr crypto_algapi usbhid zd1211rw mac80211 crypto cfg80211 snd_emu10k1 snd_rawmidi
    > snd_ac97_codec ac97_bus sg snd_seq_device snd_hda_intel snd_pcm snd_util_mem snd_timer sr_mod snd_hwdep i2c_i801 ehci_hcd firewire_ohci uhci_hcd snd snd_page_alloc firewire_core
    > soundcore r8169 cdrom usbcore i2c_core crc_itu_t
    > Pid: 2757, comm: bash Tainted: G A 2.6.27-rc1-damocles #3
    > RIP: 0010:[] [] __mc_sysdev_add+0xc3/0x1f1
    > RSP: 0018:ffff8800b8905ce8 EFLAGS: 00010297
    > RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff880080a04000
    > RDX: ffffffff8062c680 RSI: 0000000000000003 RDI: ffffffff8059e830
    > RBP: ffff8800b8905d48 R08: ffff8800b8904000 R09: ffffffff80229ca4
    > R10: ffff8800010247b0 R11: ffff8800bf879de0 R12: 0000000000000018
    > R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000
    > FS: 00007f8ddc78f6e0(0000) GS:ffffffff805da200(0000) knlGS:0000000000000000
    > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    > CR2: 00007f57cb9b2098 CR3: 00000000b8985000 CR4: 00000000000026e0
    > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    > Process bash (pid: 2757, threadinfo ffff8800b8904000, task ffff8800bd125640)
    > Stack: ffffffff80627040 0000000000000000 0000000000000008 ffffffff8048bb28
    > 0000000000000003 ffffffff802ce910 ffff8800b8905d28 0000000000000002
    > 00000000ffffffe8 0000000000000001 0000000000000001 ffff880001028418
    > Call Trace:
    > [] ? sysfs_add_file+0xc/0xe
    > [] mc_sysdev_add+0xb/0xd
    > [] mc_cpu_callback+0x4b/0x208
    > [] ? mce_cpu_callback+0x3e/0xbc
    > [] notifier_call_chain+0x33/0x5b
    > [] raw_notifier_call_chain+0xf/0x11
    > [] _cpu_up+0xce/0x119
    > [] cpu_up+0x5e/0x8a
    > [] disable_mmiotrace+0xfe/0x173
    > [] mmio_trace_reset+0x2d/0x44
    > [] tracing_set_trace_write+0xd3/0x10f
    > [] ? filp_close+0x67/0x72
    > [] vfs_write+0xa7/0xe1
    > [] sys_write+0x47/0x6f
    > [] system_call_fastpath+0x16/0x1b
    > [ 68.405002]
    > [ 68.405002]
    > Code: e8 59 80 e8 fd 69 26 00 48 c7 c2 80 c6 62 80 48 8b 05 c0 00 3c 00 48 8b 04 d8 48 8b 48 08 65 8b 04 25 24 00 00 00 44 39 e8 74 04 <0f> 0b eb fe 4c 8d 04 0a 41 c7 84 24 7c 36 64 80 00
    > 00 00 00 41
    > RIP [] __mc_sysdev_add+0xc3/0x1f1
    > RSP
    > ---[ end trace ee9c9240024cb48c ]---
    >
    > I've replaced the originally tainted dmesg with this new clean one, so
    > there's no proprietary smell about it :-)


    Yes, it's kind of a known issue. Take a look at this explanation:
    http://lkml.org/lkml/2008/7/24/260

    There were a few related discussions in other threads (mainly, Max
    Krasnyansky and I were asking for additional info on possible
    requirements from the 'microcode' driver...) heh, I think, we'd be
    better off just fixing it one way or another.



    --
    Best regards,
    Dmitry Adamushko
    --
    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: Oops in microcode sysfs registration,

    2008/7/30 Dmitry Adamushko :
    > 2008/7/29 Alistair John Strachan :
    >> On Tuesday 29 July 2008 17:22:14 Pekka Paalanen wrote:
    >>> > Also, I'm sure this is reproducible without the NVIDIA garbage, but I was
    >>> > too lazy to test it. If you want me to repeat the experiment without the
    >>> > driver I would be more than happy to do so.
    >>>
    >>> I'm not sure people are willing to look into this without a clean report,
    >>> so this would be cool. There's even a test module for mmiotrace in the
    >>> kernel, but I doubt it would make difference to use it or not, when trying
    >>> to reproduce the crash without the blob.

    >>
    >> Of course, and I should have attempted to reproduce without the driver.
    >> Fortunately that was easy: it is not an NVIDIA driver bug.
    >>
    >> Steps to reproduce: have CONFIG_MICROCODE=y and a suitable Intel
    >> processor, then do:
    >>
    >> echo mmiotrace >/debug/tracing/current_tracer
    >> echo none >/debug/tracing/current_tracer
    >>
    >> And you get this (snipped) oops:
    >>
    >> in mmio_trace_init
    >> mmiotrace: Disabling non-boot CPUs...
    >> kvm: disabling virtualization on CPU1
    >> CPU 1 is now offline
    >> SMP alternatives: switching to UP code
    >> CPU0 attaching NULL sched-domain.
    >> CPU1 attaching NULL sched-domain.
    >> CPU0 attaching NULL sched-domain.
    >> mmiotrace: CPU1 is down.
    >> mmiotrace: enabled.
    >> in mmio_trace_reset
    >> mmiotrace: Re-enabling CPUs...
    >> SMP alternatives: switching to SMP code
    >> Booting processor 1/1 ip 6000
    >> Initializing CPU#1
    >> Calibrating delay using timer specific routine.. <6>7204.76 BogoMIPS (lpj=3602381)
    >> CPU: L1 I cache: 32K, L1 D cache: 32K
    >> CPU: L2 cache: 4096K
    >> CPU: Physical Processor ID: 0
    >> CPU: Processor Core ID: 1
    >> x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
    >> CPU1: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz stepping 06
    >> checking TSC synchronization [CPU#0 -> CPU#1]: passed.
    >> kvm: enabling virtualization on CPU1
    >> CPU0 attaching NULL sched-domain.
    >> Switched to high resolution mode on CPU 1
    >> CPU0 attaching sched-domain:
    >> domain 0: span 0-1 level MC
    >> groups: 0 1
    >> CPU1 attaching sched-domain:
    >> domain 0: span 0-1 level MC
    >> groups: 1 0
    >> ------------[ cut here ]------------
    >> Kernel BUG at ffffffff8021a31d [verbose debug info unavailable]
    >> invalid opcode: 0000 [1] PREEMPT SMP
    >> CPU 0
    >> Modules linked in: rfcomm l2cap kvm_intel kvm ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack ip_tables x_tables bridge stp llc acpi_cpufreq freq_table coretemp hwmon
    >> snd_pcm_oss snd_mixer_oss firewire_sbp2 hci_usb bluetooth arc4 ecb crypto_blkcipher cryptomgr crypto_algapi usbhid zd1211rw mac80211 crypto cfg80211 snd_emu10k1 snd_rawmidi
    >> snd_ac97_codec ac97_bus sg snd_seq_device snd_hda_intel snd_pcm snd_util_mem snd_timer sr_mod snd_hwdep i2c_i801 ehci_hcd firewire_ohci uhci_hcd snd snd_page_alloc firewire_core
    >> soundcore r8169 cdrom usbcore i2c_core crc_itu_t
    >> Pid: 2757, comm: bash Tainted: G A 2.6.27-rc1-damocles #3
    >> RIP: 0010:[] [] __mc_sysdev_add+0xc3/0x1f1
    >> RSP: 0018:ffff8800b8905ce8 EFLAGS: 00010297
    >> RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff880080a04000
    >> RDX: ffffffff8062c680 RSI: 0000000000000003 RDI: ffffffff8059e830
    >> RBP: ffff8800b8905d48 R08: ffff8800b8904000 R09: ffffffff80229ca4
    >> R10: ffff8800010247b0 R11: ffff8800bf879de0 R12: 0000000000000018
    >> R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000
    >> FS: 00007f8ddc78f6e0(0000) GS:ffffffff805da200(0000) knlGS:0000000000000000
    >> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    >> CR2: 00007f57cb9b2098 CR3: 00000000b8985000 CR4: 00000000000026e0
    >> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    >> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    >> Process bash (pid: 2757, threadinfo ffff8800b8904000, task ffff8800bd125640)
    >> Stack: ffffffff80627040 0000000000000000 0000000000000008 ffffffff8048bb28
    >> 0000000000000003 ffffffff802ce910 ffff8800b8905d28 0000000000000002
    >> 00000000ffffffe8 0000000000000001 0000000000000001 ffff880001028418
    >> Call Trace:
    >> [] ? sysfs_add_file+0xc/0xe
    >> [] mc_sysdev_add+0xb/0xd
    >> [] mc_cpu_callback+0x4b/0x208
    >> [] ? mce_cpu_callback+0x3e/0xbc
    >> [] notifier_call_chain+0x33/0x5b
    >> [] raw_notifier_call_chain+0xf/0x11
    >> [] _cpu_up+0xce/0x119
    >> [] cpu_up+0x5e/0x8a
    >> [] disable_mmiotrace+0xfe/0x173
    >> [] mmio_trace_reset+0x2d/0x44
    >> [] tracing_set_trace_write+0xd3/0x10f
    >> [] ? filp_close+0x67/0x72
    >> [] vfs_write+0xa7/0xe1
    >> [] sys_write+0x47/0x6f
    >> [] system_call_fastpath+0x16/0x1b
    >> [ 68.405002]
    >> [ 68.405002]
    >> Code: e8 59 80 e8 fd 69 26 00 48 c7 c2 80 c6 62 80 48 8b 05 c0 00 3c 00 48 8b 04 d8 48 8b 48 08 65 8b 04 25 24 00 00 00 44 39 e8 74 04 <0f> 0b eb fe 4c 8d 04 0a 41 c7 84 24 7c 36 64 80 00
    >> 00 00 00 41
    >> RIP [] __mc_sysdev_add+0xc3/0x1f1
    >> RSP
    >> ---[ end trace ee9c9240024cb48c ]---
    >>
    >> I've replaced the originally tainted dmesg with this new clean one, so
    >> there's no proprietary smell about it :-)

    >
    > Yes, it's kind of a known issue. Take a look at this explanation:
    > http://lkml.org/lkml/2008/7/24/260
    >
    > There were a few related discussions in other threads (mainly, Max
    > Krasnyansky and I were asking for additional info on possible
    > requirements from the 'microcode' driver...) heh, I think, we'd be
    > better off just fixing it one way or another.


    does a patch below fix it for you?
    [ not really what we wanted ]

    (non-white-space-damaged version is enclosed)
    --- kernel/cpu.c-old 2008-07-30 12:31:15.000000000 +0200
    +++ kernel/cpu.c 2008-07-30 12:32:02.000000000 +0200
    @@ -349,6 +349,8 @@ static int __cpuinit _cpu_up(unsigned in
    goto out_notify;
    BUG_ON(!cpu_online(cpu));

    + cpu_set(cpu, cpu_active_map);
    +
    /* Now call notifier in preparation. */
    raw_notifier_call_chain(&cpu_chain, CPU_ONLINE | mod, hcpu);

    @@ -383,9 +385,6 @@ int __cpuinit cpu_up(unsigned int cpu)

    err = _cpu_up(cpu, 0);

    - if (cpu_online(cpu))
    - cpu_set(cpu, cpu_active_map);
    -
    out:
    cpu_maps_update_done();
    return err;


    --
    Best regards,
    Dmitry Adamushko


  17. Re: Oops in microcode sysfs registration,


    Dmitry Adamushko schrieb:
    > 2008/7/30 Dmitry Adamushko :
    >> 2008/7/29 Alistair John Strachan :
    >>> On Tuesday 29 July 2008 17:22:14 Pekka Paalanen wrote:
    >>>>> Also, I'm sure this is reproducible without the NVIDIA garbage, but I was
    >>>>> too lazy to test it. If you want me to repeat the experiment without the
    >>>>> driver I would be more than happy to do so.
    >>>> I'm not sure people are willing to look into this without a clean report,
    >>>> so this would be cool. There's even a test module for mmiotrace in the
    >>>> kernel, but I doubt it would make difference to use it or not, when trying
    >>>> to reproduce the crash without the blob.
    >>> Of course, and I should have attempted to reproduce without the driver.
    >>> Fortunately that was easy: it is not an NVIDIA driver bug.
    >>>
    >>> Steps to reproduce: have CONFIG_MICROCODE=y and a suitable Intel
    >>> processor, then do:
    >>>
    >>> echo mmiotrace >/debug/tracing/current_tracer
    >>> echo none >/debug/tracing/current_tracer
    >>>
    >>> And you get this (snipped) oops:
    >>>
    >>> in mmio_trace_init
    >>> mmiotrace: Disabling non-boot CPUs...
    >>> kvm: disabling virtualization on CPU1
    >>> CPU 1 is now offline
    >>> SMP alternatives: switching to UP code
    >>> CPU0 attaching NULL sched-domain.
    >>> CPU1 attaching NULL sched-domain.
    >>> CPU0 attaching NULL sched-domain.
    >>> mmiotrace: CPU1 is down.
    >>> mmiotrace: enabled.
    >>> in mmio_trace_reset
    >>> mmiotrace: Re-enabling CPUs...
    >>> SMP alternatives: switching to SMP code
    >>> Booting processor 1/1 ip 6000
    >>> Initializing CPU#1
    >>> Calibrating delay using timer specific routine.. <6>7204.76 BogoMIPS (lpj=3602381)
    >>> CPU: L1 I cache: 32K, L1 D cache: 32K
    >>> CPU: L2 cache: 4096K
    >>> CPU: Physical Processor ID: 0
    >>> CPU: Processor Core ID: 1
    >>> x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
    >>> CPU1: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz stepping 06
    >>> checking TSC synchronization [CPU#0 -> CPU#1]: passed.
    >>> kvm: enabling virtualization on CPU1
    >>> CPU0 attaching NULL sched-domain.
    >>> Switched to high resolution mode on CPU 1
    >>> CPU0 attaching sched-domain:
    >>> domain 0: span 0-1 level MC
    >>> groups: 0 1
    >>> CPU1 attaching sched-domain:
    >>> domain 0: span 0-1 level MC
    >>> groups: 1 0
    >>> ------------[ cut here ]------------
    >>> Kernel BUG at ffffffff8021a31d [verbose debug info unavailable]
    >>> invalid opcode: 0000 [1] PREEMPT SMP
    >>> CPU 0
    >>> Modules linked in: rfcomm l2cap kvm_intel kvm ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack ip_tables x_tables bridge stp llc acpi_cpufreq freq_table coretemp hwmon
    >>> snd_pcm_oss snd_mixer_oss firewire_sbp2 hci_usb bluetooth arc4 ecb crypto_blkcipher cryptomgr crypto_algapi usbhid zd1211rw mac80211 crypto cfg80211 snd_emu10k1 snd_rawmidi
    >>> snd_ac97_codec ac97_bus sg snd_seq_device snd_hda_intel snd_pcm snd_util_mem snd_timer sr_mod snd_hwdep i2c_i801 ehci_hcd firewire_ohci uhci_hcd snd snd_page_alloc firewire_core
    >>> soundcore r8169 cdrom usbcore i2c_core crc_itu_t
    >>> Pid: 2757, comm: bash Tainted: G A 2.6.27-rc1-damocles #3
    >>> RIP: 0010:[] [] __mc_sysdev_add+0xc3/0x1f1
    >>> RSP: 0018:ffff8800b8905ce8 EFLAGS: 00010297
    >>> RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff880080a04000
    >>> RDX: ffffffff8062c680 RSI: 0000000000000003 RDI: ffffffff8059e830
    >>> RBP: ffff8800b8905d48 R08: ffff8800b8904000 R09: ffffffff80229ca4
    >>> R10: ffff8800010247b0 R11: ffff8800bf879de0 R12: 0000000000000018
    >>> R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000
    >>> FS: 00007f8ddc78f6e0(0000) GS:ffffffff805da200(0000) knlGS:0000000000000000
    >>> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    >>> CR2: 00007f57cb9b2098 CR3: 00000000b8985000 CR4: 00000000000026e0
    >>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    >>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    >>> Process bash (pid: 2757, threadinfo ffff8800b8904000, task ffff8800bd125640)
    >>> Stack: ffffffff80627040 0000000000000000 0000000000000008 ffffffff8048bb28
    >>> 0000000000000003 ffffffff802ce910 ffff8800b8905d28 0000000000000002
    >>> 00000000ffffffe8 0000000000000001 0000000000000001 ffff880001028418
    >>> Call Trace:
    >>> [] ? sysfs_add_file+0xc/0xe
    >>> [] mc_sysdev_add+0xb/0xd
    >>> [] mc_cpu_callback+0x4b/0x208
    >>> [] ? mce_cpu_callback+0x3e/0xbc
    >>> [] notifier_call_chain+0x33/0x5b
    >>> [] raw_notifier_call_chain+0xf/0x11
    >>> [] _cpu_up+0xce/0x119
    >>> [] cpu_up+0x5e/0x8a
    >>> [] disable_mmiotrace+0xfe/0x173
    >>> [] mmio_trace_reset+0x2d/0x44
    >>> [] tracing_set_trace_write+0xd3/0x10f
    >>> [] ? filp_close+0x67/0x72
    >>> [] vfs_write+0xa7/0xe1
    >>> [] sys_write+0x47/0x6f
    >>> [] system_call_fastpath+0x16/0x1b
    >>> [ 68.405002]
    >>> [ 68.405002]
    >>> Code: e8 59 80 e8 fd 69 26 00 48 c7 c2 80 c6 62 80 48 8b 05 c0 00 3c 00 48 8b 04 d8 48 8b 48 08 65 8b 04 25 24 00 00 00 44 39 e8 74 04 <0f> 0b eb fe 4c 8d 04 0a 41 c7 84 24 7c 36 64 80 00
    >>> 00 00 00 41
    >>> RIP [] __mc_sysdev_add+0xc3/0x1f1
    >>> RSP
    >>> ---[ end trace ee9c9240024cb48c ]---
    >>>
    >>> I've replaced the originally tainted dmesg with this new clean one, so
    >>> there's no proprietary smell about it :-)

    >> Yes, it's kind of a known issue. Take a look at this explanation:
    >> http://lkml.org/lkml/2008/7/24/260
    >>
    >> There were a few related discussions in other threads (mainly, Max
    >> Krasnyansky and I were asking for additional info on possible
    >> requirements from the 'microcode' driver...) heh, I think, we'd be
    >> better off just fixing it one way or another.

    >
    > does a patch below fix it for you?
    > [ not really what we wanted ]
    >
    > (non-white-space-damaged version is enclosed)
    > --- kernel/cpu.c-old 2008-07-30 12:31:15.000000000 +0200
    > +++ kernel/cpu.c 2008-07-30 12:32:02.000000000 +0200
    > @@ -349,6 +349,8 @@ static int __cpuinit _cpu_up(unsigned in
    > goto out_notify;
    > BUG_ON(!cpu_online(cpu));
    >
    > + cpu_set(cpu, cpu_active_map);
    > +
    > /* Now call notifier in preparation. */
    > raw_notifier_call_chain(&cpu_chain, CPU_ONLINE | mod, hcpu);
    >
    > @@ -383,9 +385,6 @@ int __cpuinit cpu_up(unsigned int cpu)
    >
    > err = _cpu_up(cpu, 0);
    >
    > - if (cpu_online(cpu))
    > - cpu_set(cpu, cpu_active_map);
    > -
    > out:
    > cpu_maps_update_done();
    > return err;
    >
    >
    >


    Dmitry,

    works for me...

    Thanks,
    Peter

    --
    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: Oops in microcode sysfs registration,

    On Wednesday 30 July 2008 11:35:54 Dmitry Adamushko wrote:
    > 2008/7/30 Dmitry Adamushko :
    > > 2008/7/29 Alistair John Strachan :
    > >> On Tuesday 29 July 2008 17:22:14 Pekka Paalanen wrote:
    > >>> > Also, I'm sure this is reproducible without the NVIDIA garbage, but I
    > >>> > was too lazy to test it. If you want me to repeat the experiment
    > >>> > without the driver I would be more than happy to do so.
    > >>>
    > >>> I'm not sure people are willing to look into this without a clean
    > >>> report, so this would be cool. There's even a test module for mmiotrace
    > >>> in the kernel, but I doubt it would make difference to use it or not,
    > >>> when trying to reproduce the crash without the blob.
    > >>
    > >> Of course, and I should have attempted to reproduce without the driver.
    > >> Fortunately that was easy: it is not an NVIDIA driver bug.
    > >>
    > >> Steps to reproduce: have CONFIG_MICROCODE=y and a suitable Intel
    > >> processor, then do:
    > >>
    > >> echo mmiotrace >/debug/tracing/current_tracer
    > >> echo none >/debug/tracing/current_tracer
    > >>
    > >> And you get this (snipped) oops:
    > >>
    > >> in mmio_trace_init
    > >> mmiotrace: Disabling non-boot CPUs...
    > >> kvm: disabling virtualization on CPU1
    > >> CPU 1 is now offline
    > >> SMP alternatives: switching to UP code
    > >> CPU0 attaching NULL sched-domain.
    > >> CPU1 attaching NULL sched-domain.
    > >> CPU0 attaching NULL sched-domain.
    > >> mmiotrace: CPU1 is down.
    > >> mmiotrace: enabled.
    > >> in mmio_trace_reset
    > >> mmiotrace: Re-enabling CPUs...
    > >> SMP alternatives: switching to SMP code
    > >> Booting processor 1/1 ip 6000
    > >> Initializing CPU#1
    > >> Calibrating delay using timer specific routine.. <6>7204.76 BogoMIPS
    > >> (lpj=3602381) CPU: L1 I cache: 32K, L1 D cache: 32K
    > >> CPU: L2 cache: 4096K
    > >> CPU: Physical Processor ID: 0
    > >> CPU: Processor Core ID: 1
    > >> x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
    > >> CPU1: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz stepping 06
    > >> checking TSC synchronization [CPU#0 -> CPU#1]: passed.
    > >> kvm: enabling virtualization on CPU1
    > >> CPU0 attaching NULL sched-domain.
    > >> Switched to high resolution mode on CPU 1
    > >> CPU0 attaching sched-domain:
    > >> domain 0: span 0-1 level MC
    > >> groups: 0 1
    > >> CPU1 attaching sched-domain:
    > >> domain 0: span 0-1 level MC
    > >> groups: 1 0
    > >> ------------[ cut here ]------------
    > >> Kernel BUG at ffffffff8021a31d [verbose debug info unavailable]
    > >> invalid opcode: 0000 [1] PREEMPT SMP
    > >> CPU 0
    > >> Modules linked in: rfcomm l2cap kvm_intel kvm ipt_MASQUERADE iptable_nat
    > >> nf_nat nf_conntrack_ipv4 nf_conntrack ip_tables x_tables bridge stp llc
    > >> acpi_cpufreq freq_table coretemp hwmon snd_pcm_oss snd_mixer_oss
    > >> firewire_sbp2 hci_usb bluetooth arc4 ecb crypto_blkcipher cryptomgr
    > >> crypto_algapi usbhid zd1211rw mac80211 crypto cfg80211 snd_emu10k1
    > >> snd_rawmidi snd_ac97_codec ac97_bus sg snd_seq_device snd_hda_intel
    > >> snd_pcm snd_util_mem snd_timer sr_mod snd_hwdep i2c_i801 ehci_hcd
    > >> firewire_ohci uhci_hcd snd snd_page_alloc firewire_core soundcore r8169
    > >> cdrom usbcore i2c_core crc_itu_t
    > >> Pid: 2757, comm: bash Tainted: G A 2.6.27-rc1-damocles #3
    > >> RIP: 0010:[] []
    > >> __mc_sysdev_add+0xc3/0x1f1 RSP: 0018:ffff8800b8905ce8 EFLAGS: 00010297
    > >> RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff880080a04000
    > >> RDX: ffffffff8062c680 RSI: 0000000000000003 RDI: ffffffff8059e830
    > >> RBP: ffff8800b8905d48 R08: ffff8800b8904000 R09: ffffffff80229ca4
    > >> R10: ffff8800010247b0 R11: ffff8800bf879de0 R12: 0000000000000018
    > >> R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000
    > >> FS: 00007f8ddc78f6e0(0000) GS:ffffffff805da200(0000)
    > >> knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    > >> CR2: 00007f57cb9b2098 CR3: 00000000b8985000 CR4: 00000000000026e0
    > >> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    > >> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    > >> Process bash (pid: 2757, threadinfo ffff8800b8904000, task
    > >> ffff8800bd125640) Stack: ffffffff80627040 0000000000000000
    > >> 0000000000000008 ffffffff8048bb28 0000000000000003 ffffffff802ce910
    > >> ffff8800b8905d28 0000000000000002 00000000ffffffe8 0000000000000001
    > >> 0000000000000001 ffff880001028418 Call Trace:
    > >> [] ? sysfs_add_file+0xc/0xe
    > >> [] mc_sysdev_add+0xb/0xd
    > >> [] mc_cpu_callback+0x4b/0x208
    > >> [] ? mce_cpu_callback+0x3e/0xbc
    > >> [] notifier_call_chain+0x33/0x5b
    > >> [] raw_notifier_call_chain+0xf/0x11
    > >> [] _cpu_up+0xce/0x119
    > >> [] cpu_up+0x5e/0x8a
    > >> [] disable_mmiotrace+0xfe/0x173
    > >> [] mmio_trace_reset+0x2d/0x44
    > >> [] tracing_set_trace_write+0xd3/0x10f
    > >> [] ? filp_close+0x67/0x72
    > >> [] vfs_write+0xa7/0xe1
    > >> [] sys_write+0x47/0x6f
    > >> [] system_call_fastpath+0x16/0x1b
    > >> [ 68.405002]
    > >> [ 68.405002]
    > >> Code: e8 59 80 e8 fd 69 26 00 48 c7 c2 80 c6 62 80 48 8b 05 c0 00 3c 00
    > >> 48 8b 04 d8 48 8b 48 08 65 8b 04 25 24 00 00 00 44 39 e8 74 04 <0f> 0b
    > >> eb fe 4c 8d 04 0a 41 c7 84 24 7c 36 64 80 00 00 00 00 41
    > >> RIP [] __mc_sysdev_add+0xc3/0x1f1
    > >> RSP
    > >> ---[ end trace ee9c9240024cb48c ]---
    > >>
    > >> I've replaced the originally tainted dmesg with this new clean one, so
    > >> there's no proprietary smell about it :-)

    > >
    > > Yes, it's kind of a known issue. Take a look at this explanation:
    > > http://lkml.org/lkml/2008/7/24/260
    > >
    > > There were a few related discussions in other threads (mainly, Max
    > > Krasnyansky and I were asking for additional info on possible
    > > requirements from the 'microcode' driver...) heh, I think, we'd be
    > > better off just fixing it one way or another.

    >
    > does a patch below fix it for you?


    Well, if this patch is all that can be done about the issue, it gets my tested
    seal of approval. The CPUs online/offline properly without upsetting the mc
    driver. Thanks.

    --
    Cheers,
    Alistair.
    --
    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: Oops in microcode sysfs registration,


    * Dmitry Adamushko wrote:

    > 2008/7/30 Dmitry Adamushko :
    > > 2008/7/29 Alistair John Strachan :
    > >> On Tuesday 29 July 2008 17:22:14 Pekka Paalanen wrote:
    > >>> > Also, I'm sure this is reproducible without the NVIDIA garbage, but I was
    > >>> > too lazy to test it. If you want me to repeat the experiment without the
    > >>> > driver I would be more than happy to do so.
    > >>>
    > >>> I'm not sure people are willing to look into this without a clean report,
    > >>> so this would be cool. There's even a test module for mmiotrace in the
    > >>> kernel, but I doubt it would make difference to use it or not, when trying
    > >>> to reproduce the crash without the blob.
    > >>
    > >> Of course, and I should have attempted to reproduce without the driver.
    > >> Fortunately that was easy: it is not an NVIDIA driver bug.
    > >>
    > >> Steps to reproduce: have CONFIG_MICROCODE=y and a suitable Intel
    > >> processor, then do:
    > >>
    > >> echo mmiotrace >/debug/tracing/current_tracer
    > >> echo none >/debug/tracing/current_tracer
    > >>
    > >> And you get this (snipped) oops:
    > >>
    > >> in mmio_trace_init
    > >> mmiotrace: Disabling non-boot CPUs...
    > >> kvm: disabling virtualization on CPU1
    > >> CPU 1 is now offline
    > >> SMP alternatives: switching to UP code
    > >> CPU0 attaching NULL sched-domain.
    > >> CPU1 attaching NULL sched-domain.
    > >> CPU0 attaching NULL sched-domain.
    > >> mmiotrace: CPU1 is down.
    > >> mmiotrace: enabled.
    > >> in mmio_trace_reset
    > >> mmiotrace: Re-enabling CPUs...
    > >> SMP alternatives: switching to SMP code
    > >> Booting processor 1/1 ip 6000
    > >> Initializing CPU#1
    > >> Calibrating delay using timer specific routine.. <6>7204.76 BogoMIPS (lpj=3602381)
    > >> CPU: L1 I cache: 32K, L1 D cache: 32K
    > >> CPU: L2 cache: 4096K
    > >> CPU: Physical Processor ID: 0
    > >> CPU: Processor Core ID: 1
    > >> x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
    > >> CPU1: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz stepping 06
    > >> checking TSC synchronization [CPU#0 -> CPU#1]: passed.
    > >> kvm: enabling virtualization on CPU1
    > >> CPU0 attaching NULL sched-domain.
    > >> Switched to high resolution mode on CPU 1
    > >> CPU0 attaching sched-domain:
    > >> domain 0: span 0-1 level MC
    > >> groups: 0 1
    > >> CPU1 attaching sched-domain:
    > >> domain 0: span 0-1 level MC
    > >> groups: 1 0
    > >> ------------[ cut here ]------------
    > >> Kernel BUG at ffffffff8021a31d [verbose debug info unavailable]
    > >> invalid opcode: 0000 [1] PREEMPT SMP
    > >> CPU 0
    > >> Modules linked in: rfcomm l2cap kvm_intel kvm ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack ip_tables x_tables bridge stp llc acpi_cpufreq freq_table coretemp hwmon
    > >> snd_pcm_oss snd_mixer_oss firewire_sbp2 hci_usb bluetooth arc4 ecb crypto_blkcipher cryptomgr crypto_algapi usbhid zd1211rw mac80211 crypto cfg80211 snd_emu10k1 snd_rawmidi
    > >> snd_ac97_codec ac97_bus sg snd_seq_device snd_hda_intel snd_pcm snd_util_mem snd_timer sr_mod snd_hwdep i2c_i801 ehci_hcd firewire_ohci uhci_hcd snd snd_page_alloc firewire_core
    > >> soundcore r8169 cdrom usbcore i2c_core crc_itu_t
    > >> Pid: 2757, comm: bash Tainted: G A 2.6.27-rc1-damocles #3
    > >> RIP: 0010:[] [] __mc_sysdev_add+0xc3/0x1f1
    > >> RSP: 0018:ffff8800b8905ce8 EFLAGS: 00010297
    > >> RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff880080a04000
    > >> RDX: ffffffff8062c680 RSI: 0000000000000003 RDI: ffffffff8059e830
    > >> RBP: ffff8800b8905d48 R08: ffff8800b8904000 R09: ffffffff80229ca4
    > >> R10: ffff8800010247b0 R11: ffff8800bf879de0 R12: 0000000000000018
    > >> R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000
    > >> FS: 00007f8ddc78f6e0(0000) GS:ffffffff805da200(0000) knlGS:0000000000000000
    > >> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    > >> CR2: 00007f57cb9b2098 CR3: 00000000b8985000 CR4: 00000000000026e0
    > >> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    > >> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    > >> Process bash (pid: 2757, threadinfo ffff8800b8904000, task ffff8800bd125640)
    > >> Stack: ffffffff80627040 0000000000000000 0000000000000008 ffffffff8048bb28
    > >> 0000000000000003 ffffffff802ce910 ffff8800b8905d28 0000000000000002
    > >> 00000000ffffffe8 0000000000000001 0000000000000001 ffff880001028418
    > >> Call Trace:
    > >> [] ? sysfs_add_file+0xc/0xe
    > >> [] mc_sysdev_add+0xb/0xd
    > >> [] mc_cpu_callback+0x4b/0x208
    > >> [] ? mce_cpu_callback+0x3e/0xbc
    > >> [] notifier_call_chain+0x33/0x5b
    > >> [] raw_notifier_call_chain+0xf/0x11
    > >> [] _cpu_up+0xce/0x119
    > >> [] cpu_up+0x5e/0x8a
    > >> [] disable_mmiotrace+0xfe/0x173
    > >> [] mmio_trace_reset+0x2d/0x44
    > >> [] tracing_set_trace_write+0xd3/0x10f
    > >> [] ? filp_close+0x67/0x72
    > >> [] vfs_write+0xa7/0xe1
    > >> [] sys_write+0x47/0x6f
    > >> [] system_call_fastpath+0x16/0x1b
    > >> [ 68.405002]
    > >> [ 68.405002]
    > >> Code: e8 59 80 e8 fd 69 26 00 48 c7 c2 80 c6 62 80 48 8b 05 c0 00 3c 00 48 8b 04 d8 48 8b 48 08 65 8b 04 25 24 00 00 00 44 39 e8 74 04 <0f> 0b eb fe 4c 8d 04 0a 41 c7 84 24 7c 36 64 80 00
    > >> 00 00 00 41
    > >> RIP [] __mc_sysdev_add+0xc3/0x1f1
    > >> RSP
    > >> ---[ end trace ee9c9240024cb48c ]---
    > >>
    > >> I've replaced the originally tainted dmesg with this new clean one, so
    > >> there's no proprietary smell about it :-)

    > >
    > > Yes, it's kind of a known issue. Take a look at this explanation:
    > > http://lkml.org/lkml/2008/7/24/260
    > >
    > > There were a few related discussions in other threads (mainly, Max
    > > Krasnyansky and I were asking for additional info on possible
    > > requirements from the 'microcode' driver...) heh, I think, we'd be
    > > better off just fixing it one way or another.

    >
    > does a patch below fix it for you?
    > [ not really what we wanted ]
    >
    > (non-white-space-damaged version is enclosed)


    could you please send this patch with a changelog, explanation, etc.?

    Ingo
    --
    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: Oops in microcode sysfs registration,

    2008/7/31 Ingo Molnar :
    >
    > * Dmitry Adamushko wrote:
    >
    >> 2008/7/30 Dmitry Adamushko :
    >> > 2008/7/29 Alistair John Strachan :
    >> >> On Tuesday 29 July 2008 17:22:14 Pekka Paalanen wrote:
    >> >>> > Also, I'm sure this is reproducible without the NVIDIA garbage, but I was
    >> >>> > too lazy to test it. If you want me to repeat the experiment without the
    >> >>> > driver I would be more than happy to do so.
    >> >>>
    >> >>> I'm not sure people are willing to look into this without a clean report,
    >> >>> so this would be cool. There's even a test module for mmiotrace in the
    >> >>> kernel, but I doubt it would make difference to use it or not, when trying
    >> >>> to reproduce the crash without the blob.
    >> >>
    >> >> Of course, and I should have attempted to reproduce without the driver.
    >> >> Fortunately that was easy: it is not an NVIDIA driver bug.
    >> >>
    >> >> Steps to reproduce: have CONFIG_MICROCODE=y and a suitable Intel
    >> >> processor, then do:
    >> >>
    >> >> echo mmiotrace >/debug/tracing/current_tracer
    >> >> echo none >/debug/tracing/current_tracer
    >> >>
    >> >> And you get this (snipped) oops:
    >> >>
    >> >> in mmio_trace_init
    >> >> mmiotrace: Disabling non-boot CPUs...
    >> >> kvm: disabling virtualization on CPU1
    >> >> CPU 1 is now offline
    >> >> SMP alternatives: switching to UP code
    >> >> CPU0 attaching NULL sched-domain.
    >> >> CPU1 attaching NULL sched-domain.
    >> >> CPU0 attaching NULL sched-domain.
    >> >> mmiotrace: CPU1 is down.
    >> >> mmiotrace: enabled.
    >> >> in mmio_trace_reset
    >> >> mmiotrace: Re-enabling CPUs...
    >> >> SMP alternatives: switching to SMP code
    >> >> Booting processor 1/1 ip 6000
    >> >> Initializing CPU#1
    >> >> Calibrating delay using timer specific routine.. <6>7204.76 BogoMIPS (lpj=3602381)
    >> >> CPU: L1 I cache: 32K, L1 D cache: 32K
    >> >> CPU: L2 cache: 4096K
    >> >> CPU: Physical Processor ID: 0
    >> >> CPU: Processor Core ID: 1
    >> >> x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
    >> >> CPU1: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz stepping 06
    >> >> checking TSC synchronization [CPU#0 -> CPU#1]: passed.
    >> >> kvm: enabling virtualization on CPU1
    >> >> CPU0 attaching NULL sched-domain.
    >> >> Switched to high resolution mode on CPU 1
    >> >> CPU0 attaching sched-domain:
    >> >> domain 0: span 0-1 level MC
    >> >> groups: 0 1
    >> >> CPU1 attaching sched-domain:
    >> >> domain 0: span 0-1 level MC
    >> >> groups: 1 0
    >> >> ------------[ cut here ]------------
    >> >> Kernel BUG at ffffffff8021a31d [verbose debug info unavailable]
    >> >> invalid opcode: 0000 [1] PREEMPT SMP
    >> >> CPU 0
    >> >> Modules linked in: rfcomm l2cap kvm_intel kvm ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack ip_tables x_tables bridge stp llc acpi_cpufreq freq_table coretemp hwmon
    >> >> snd_pcm_oss snd_mixer_oss firewire_sbp2 hci_usb bluetooth arc4 ecb crypto_blkcipher cryptomgr crypto_algapi usbhid zd1211rw mac80211 crypto cfg80211 snd_emu10k1 snd_rawmidi
    >> >> snd_ac97_codec ac97_bus sg snd_seq_device snd_hda_intel snd_pcm snd_util_mem snd_timer sr_mod snd_hwdep i2c_i801 ehci_hcd firewire_ohci uhci_hcd snd snd_page_alloc firewire_core
    >> >> soundcore r8169 cdrom usbcore i2c_core crc_itu_t
    >> >> Pid: 2757, comm: bash Tainted: G A 2.6.27-rc1-damocles #3
    >> >> RIP: 0010:[] [] __mc_sysdev_add+0xc3/0x1f1
    >> >> RSP: 0018:ffff8800b8905ce8 EFLAGS: 00010297
    >> >> RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff880080a04000
    >> >> RDX: ffffffff8062c680 RSI: 0000000000000003 RDI: ffffffff8059e830
    >> >> RBP: ffff8800b8905d48 R08: ffff8800b8904000 R09: ffffffff80229ca4
    >> >> R10: ffff8800010247b0 R11: ffff8800bf879de0 R12: 0000000000000018
    >> >> R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000
    >> >> FS: 00007f8ddc78f6e0(0000) GS:ffffffff805da200(0000) knlGS:0000000000000000
    >> >> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    >> >> CR2: 00007f57cb9b2098 CR3: 00000000b8985000 CR4: 00000000000026e0
    >> >> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    >> >> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    >> >> Process bash (pid: 2757, threadinfo ffff8800b8904000, task ffff8800bd125640)
    >> >> Stack: ffffffff80627040 0000000000000000 0000000000000008 ffffffff8048bb28
    >> >> 0000000000000003 ffffffff802ce910 ffff8800b8905d28 0000000000000002
    >> >> 00000000ffffffe8 0000000000000001 0000000000000001 ffff880001028418
    >> >> Call Trace:
    >> >> [] ? sysfs_add_file+0xc/0xe
    >> >> [] mc_sysdev_add+0xb/0xd
    >> >> [] mc_cpu_callback+0x4b/0x208
    >> >> [] ? mce_cpu_callback+0x3e/0xbc
    >> >> [] notifier_call_chain+0x33/0x5b
    >> >> [] raw_notifier_call_chain+0xf/0x11
    >> >> [] _cpu_up+0xce/0x119
    >> >> [] cpu_up+0x5e/0x8a
    >> >> [] disable_mmiotrace+0xfe/0x173
    >> >> [] mmio_trace_reset+0x2d/0x44
    >> >> [] tracing_set_trace_write+0xd3/0x10f
    >> >> [] ? filp_close+0x67/0x72
    >> >> [] vfs_write+0xa7/0xe1
    >> >> [] sys_write+0x47/0x6f
    >> >> [] system_call_fastpath+0x16/0x1b
    >> >> [ 68.405002]
    >> >> [ 68.405002]
    >> >> Code: e8 59 80 e8 fd 69 26 00 48 c7 c2 80 c6 62 80 48 8b 05 c0 00 3c 00 48 8b 04 d8 48 8b 48 08 65 8b 04 25 24 00 00 00 44 39 e8 74 04 <0f> 0b eb fe 4c 8d 04 0a 41 c7 84 24 7c 36 64 80 00
    >> >> 00 00 00 41
    >> >> RIP [] __mc_sysdev_add+0xc3/0x1f1
    >> >> RSP
    >> >> ---[ end trace ee9c9240024cb48c ]---
    >> >>
    >> >> I've replaced the originally tainted dmesg with this new clean one, so
    >> >> there's no proprietary smell about it :-)
    >> >
    >> > Yes, it's kind of a known issue. Take a look at this explanation:
    >> > http://lkml.org/lkml/2008/7/24/260
    >> >
    >> > There were a few related discussions in other threads (mainly, Max
    >> > Krasnyansky and I were asking for additional info on possible
    >> > requirements from the 'microcode' driver...) heh, I think, we'd be
    >> > better off just fixing it one way or another.

    >>
    >> does a patch below fix it for you?
    >> [ not really what we wanted ]
    >>
    >> (non-white-space-damaged version is enclosed)

    >
    > could you please send this patch with a changelog, explanation, etc.?


    Now having thought a bit more on that issue, I tend to think that this
    patch is not all that nice (so I agree with Max here).

    The root problem is the way set_cpus_allowed_ptr() is used in
    microcode's cpu-hotplug handler. With cpu_active_map in place
    set_cpus_allowed_ptr() can't migrate a task on the soon-to-be-online
    cpu from withing a CPU_ONLINE handler (more in details here:
    http://lkml.org/lkml/2008/7/24/260)

    Basically, this patch marks a 'cpu' available for other tasks to be
    migrated to it before sending CPU_ONLINE notification to
    subscribers... [ now, there can be CPU_ONLINE
    http://lkml.org/lkml/2008/7/24/260handlers that has something to do
    with enabling migration/load-balancing. e.g. migration_call() ,
    although it has the highest prio and is supposed to run first in a
    chain ]

    In another thread, I've asked whether doing 'microcode update' in
    start_secondary() (or even at the beginning of idle_cpu() would be
    better):

    pros:
    - it's done as early as possible (no other tasks has started running
    on a cpu yet);
    - no actions in cpu-hotplug;

    cons:
    - microcode sub-systems becomes visible outside of microcode.c _but_
    it's arch-specific part anyway + with object-oriented re-work (which
    is in -tip), I think it'd be that bad.

    Alternatives:

    - delayed 'microcode' update -> scheduled to 'workqueue' (cons: it's
    not as early as possible);
    - Max suggested a combination of IPI + some wotk (request_firmware())
    from cpu-hotplug handler itself. But I think it's quite a complex
    scheme (and maybe prone to other problems).


    What do you think?


    >
    > Ingo
    >


    --
    Best regards,
    Dmitry Adamushko
    --
    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 3 FirstFirst 1 2 3 LastLast