Re: [2.6.27-rc2-git4] Kernel panic on VIA Ester+VIA CX700 - Kernel

This is a discussion on Re: [2.6.27-rc2-git4] Kernel panic on VIA Ester+VIA CX700 - Kernel ; On Saturday, 9 of August 2008, Bruno Pr émont wrote: > Hi, Hi, > Trying out 2.6.27-rc2-git4 on a VIA Ester + CX700 based system I > experience the following panic using a config obtained with make > oldconfig from ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Re: [2.6.27-rc2-git4] Kernel panic on VIA Ester+VIA CX700

  1. Re: [2.6.27-rc2-git4] Kernel panic on VIA Ester+VIA CX700

    On Saturday, 9 of August 2008, Bruno Prémont wrote:
    > Hi,


    Hi,

    > Trying out 2.6.27-rc2-git4 on a VIA Ester + CX700 based system I
    > experience the following panic using a config obtained with make
    > oldconfig from working 2.6.26 config.
    >
    > Looking at the traces and when it happens it looks like it could be
    > libATA or SCSI related...
    >
    >
    > Note: the kernel is patched with viafb patches sent yesterday ([y]) and
    > squashfs ()


    Could you retest without these two, please?

    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: [2.6.27-rc2-git4] Kernel panic on VIA Ester+VIA CX700

    On Sun, Aug 10, 2008 at 12:00:24AM +0200, Rafael J. Wysocki wrote:
    > On Saturday, 9 of August 2008, Bruno Pr?mont wrote:
    > > Hi,

    >
    > Hi,
    >
    > > Trying out 2.6.27-rc2-git4 on a VIA Ester + CX700 based system I
    > > experience the following panic using a config obtained with make
    > > oldconfig from working 2.6.26 config.
    > >
    > > Looking at the traces and when it happens it looks like it could be
    > > libATA or SCSI related...
    > >
    > >
    > > Note: the kernel is patched with viafb patches sent yesterday ([y]) and
    > > squashfs ()

    >
    > Could you retest without these two, please?


    There'a another fun candidate: lazy allocation of fpu state. Do you have
    padlock-aes/padlock-sha/via-rng in use?
    --
    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: [2.6.27-rc2-git4] Kernel panic on VIA Ester+VIA CX700

    On Sat, 09 August 2008 Al Viro wrote:
    > On Sun, Aug 10, 2008 at 12:00:24AM +0200, Rafael J. Wysocki wrote:
    > > On Saturday, 9 of August 2008, Bruno Pr?mont wrote:
    > > > Hi,

    > >
    > > Hi,
    > >
    > > > Trying out 2.6.27-rc2-git4 on a VIA Ester + CX700 based system I
    > > > experience the following panic using a config obtained with make
    > > > oldconfig from working 2.6.26 config.
    > > >
    > > > Looking at the traces and when it happens it looks like it could
    > > > be libATA or SCSI related...
    > > >
    > > >
    > > > Note: the kernel is patched with viafb patches sent yesterday
    > > > ([y]) and squashfs ()

    > >
    > > Could you retest without these two, please?

    >
    > There'a another fun candidate: lazy allocation of fpu state. Do you
    > have padlock-aes/padlock-sha/via-rng in use?
    >

    They are compiled into the kernel and initialize with 2.6.26.2, though
    I have no idea if the kernel uses them more than that...

    The crash happens long enough before userspace gets started, as such
    except kernel-side users there should be no users of them.

    I will check tomorrow without these to determine which one might be the
    offending one:
    - no crypto,padlock/viarng
    - no viafb
    - no squashfs (though it should be pretty inoffensive)

    Bruno
    --
    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: [2.6.27-rc2-git4] Kernel panic on VIA Ester+VIA CX700

    Bruno Prémont wrote:
    >
    > Recompiling without viafb+squashfs patches makes the panic go away.
    >
    > So something from viafb or squashfs triggers the panic or prepare
    > for something else to trigger it...
    >


    Out of those, viafb by far seems most likely. Could you try compiling
    with only one or the other?

    -hpa
    --
    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: [2.6.27-rc2-git4] Kernel panic on VIA Ester+VIA CX700

    On Sun, Aug 10, 2008 at 04:39:23PM -0700, H. Peter Anvin wrote:
    > Bruno Prémont wrote:
    > >
    > > Recompiling without viafb+squashfs patches makes the panic go away.
    > >
    > > So something from viafb or squashfs triggers the panic or prepare
    > > for something else to trigger it...
    > >

    >
    > Out of those, viafb by far seems most likely. Could you try compiling
    > with only one or the other?


    [ 5.010629] general protection fault: 0000 [#1]
    [ 5.021782] Modules linked in:
    [ 5.030227]
    [ 5.030227] Pid: 3, comm: ksoftirqd/0 Not tainted (2.6.27-rc2-git4_nocrypto #1)
    [ 5.030227] EIP: 0060:[] EFLAGS: 00010046 CPU: 0
    [ 5.030227] EIP is at math_state_restore+0x25/0x60
    [ 5.030227] EAX: f781db3d EBX: f781d898 ECX: 00000000 EDX: 00000000
    [ 5.030227] ESI: f781d000 EDI: f782c20c EBP: f781d840 ESP: f781d838
    [ 5.030227] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
    [ 5.030227] Process ksoftirqd/0 (pid: 3, ti=f781d000 task=f782c6a0 task.ti=f782a000)
    [ 5.030227] Stack: f782c000 f782c6a0 f781d890 c01038dd f782c000 00000000 f782c000 f782c6a0
    [ 5.030227] f782c20c f781d890 f7807e00 0000007b 0000007b 00000000 ffffffff c0101e8f
    [ 5.030227] 00000060 00010002 f782c8ac f782c000 c04d8180 c011fa50 f782afc0 c03cfa61
    [ 5.030227] Call Trace:
    [ 5.030227] [] ? device_not_available+0x2d/0x32
    [ 5.030227] [] ? __switch_to+0x2f/0x130

    It got a GP fault, because in __switch_to() we were doing unlazy_fpu() and
    fxsave generated a DNA fault(which shouldn't happen unless we are hitting the
    via padlock instruction issue or something else) and the math_state_restore()
    found the task's math state pointer to be 0xf781db3d (EAX in the oops) and while
    doing fxrstor we got GP fault, as the fxrstor pointer(EAX) is not 16byte
    aligned.

    It is interesting to see the EAX value similar to stack pointer. Task's
    FP area gets dynamically allocated and as such EAX def looks wrong here.
    I also see the config is using 4K stacks. Some config(viafb/squashfs?) causing
    some thing wrong with the kernel stack?
    --
    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