On Mon, 11 August 2008 Suresh Siddha <suresh.b.siddha@intel.com> wrote:
quoted text
> On Sun, Aug 10, 2008 at 04:39:23PM -0700, H. Peter Anvin wrote:
> > Bruno Pr=C3=A9mont 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...
> > >
> >=20
> > Out of those, viafb by far seems most likely.  Could you try
> > compiling with only one or the other?
>=20
> [    5.010629] general protection fault: 0000 [#1]=20
> [    5.021782] Modules linked in:
> [    5.030227]=20
> [    5.030227] Pid: 3, comm: ksoftirqd/0 Not tainted (2.6.27-rc2-git4_noc=
rypto #1)
quoted text
> [    5.030227] EIP: 0060:[<c01042f5>] 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=3Df781d000 task=3Df782c6a0=
 task.ti=3Df782a000)
quoted text
> [    5.030227] Stack: f782c000 f782c6a0 f781d890 c01038dd f782c000 000000=
00 f782c000 f782c6a0
quoted text
> [    5.030227]        f782c20c f781d890 f7807e00 0000007b 0000007b 000000=
00 ffffffff c0101e8f
quoted text
> [    5.030227]        00000060 00010002 f782c8ac f782c000 c04d8180 c011fa=
50 f782afc0 c03cfa61
quoted text
> [    5.030227] Call Trace:
> [    5.030227]  [<c01038dd>] ? device_not_available+0x2d/0x32
> [    5.030227]  [<c0101e8f>] ? __switch_to+0x2f/0x130
>=20
> 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.
>=20
> 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? --
That's pretty possible...

I just recompiled (enabling some more stack debugging - which didn't help),
then I disabled 4k-stack and now system boots up...

Anything I forgot the enable to get stacktrace when stack is overflowing
instead of at a random time later on?
Also wondering that maximum stack usage is only printed for userspace apps
or kernel threads once init is running... is the stack usage not checked
earlier during boot process?

Changes to posted config:
 CONFIG_X86_VERBOSE_BOOTUP=3Dy
 CONFIG_EARLY_PRINTK=3Dy
 CONFIG_DEBUG_STACKOVERFLOW=3Dy
-# CONFIG_DEBUG_STACK_USAGE is not set
+CONFIG_DEBUG_STACK_USAGE=3Dy
 # CONFIG_DEBUG_PAGEALLOC is not set
 # CONFIG_X86_PTDUMP is not set
 CONFIG_DEBUG_RODATA=3Dy
 # CONFIG_DEBUG_RODATA_TEST is not set
 # CONFIG_DEBUG_NX_TEST is not set
-CONFIG_4KSTACKS=3Dy
+# CONFIG_4KSTACKS is not set
 CONFIG_DOUBLEFAULT=3Dy
 # CONFIG_MMIOTRACE is not set
 CONFIG_IO_DELAY_TYPE_0X80=3D0

Attached are bootlog with 4k stack and 8k stacks using above config diff
(with appropriate CONFIG_4KSTACKS)

Bruno