Re: [REGRESSION] [BISECT] ACPI+Inspiron 1545 = crash at xrstor_state()

[Suresh Siddha <suresh.b.siddha@intel.com>]

On Tue, 2010-11-16 at 06:42 -0800, Borislav Petkov wrote:
> On Tue, Nov 16, 2010 at 04:56:06AM -0500, Jody Bruchon wrote:
> >  I previously reported an early boot crash on an Inspiron 1545 laptop;
> > see previous posts for more details.  I used the parameters "debug
> > vga=6 earlyprintk=vga" to catch these errors since they happen so
> > early in boot that the normal console has not yet initialized.
> > 
> > A picture of the crash dump from 2.6.37-rc2 is available here (2.6.36
> > crash is identical except for the reported kernel version):
> > http://c02ware.com/bugs/dump_c7ff0d9c92435e836e13aaa8d0e56d4000424bcc.jpg
> > 
> > I have experienced similar problems on a small number of other systems
> > also.  After confirming that the problem was introduced going from
> > 2.6.35 to 2.6.36, I have successfully bisected the kernel, and
> > narrowed down and tested to verify the commit which introduced the
> > problem.  Reverting this commit fixes 2.6.36 but 2.6.37-rc2 has the
> > exact same crash even if I revert it.  I don't know what to do from
> > here, but someone with more knowledge can surely guide me.  I will
> > only have the unit to test with for another day or two.  I have
> > attached a suitable .config for reference as well.  The commit info is
> > below.
> 
> I don't think this patch is at fault. Your oops photo above shows that
> the machine oopses at the first xrstor call in xstate_enable_boot_cpu():
> 
>  1c3:   0f 06                   clts
>  1c5:   83 c8 ff                or     $0xffffffff,%eax
>  1c8:   89 c2                   mov    %eax,%edx
>  1ca:   0f ae 2f                xrstor (%edi)			<---------
>  1cd:   8b 3d 54 00 00 00       mov    0x54,%edi
>  1d3:   0f ae 27                xsave  (%edi)
> 
> Adding more people to Cc.

hmm, that kernel .config has CONFIG_X86_L1_CACHE_SHIFT=5 and hence
xrstor faulted as it didn't find a 64byte aligned buffer.

Can you set the cpu type to GENERIC_CPU instead of MPENTIUMII? That
should avoid this issue.

I will see how can I fix this issue.

thanks,
suresh