Bill.Holler wrote:

> Hi Ashok,
> 
> There is no workaround for this issue.

kmdb

[0]> cpupm_vendors/Z 0

[0]> :c

Thanks,
-Aubrey


> 
> snv_112 is the first bi-weekly build with the fix.
> 
> Regards,
> Bill Holler
> 
> 
> On 04/03/09 11:52, Raj, Ashok wrote:
>> Hi Bill
>> 
>> Do we have this fixed in 111? I tried 111 on Toshiba M10,
> and run into same issue. But the following workaround also
> didn't seem to help
>> 
>> [araj-...@~]tip keyspan
>> connected
>> 
>> [0]> idle_cpu_no_deep_c/W1
>> idle_cpu_no_deep_c:             0               =       0x1 [0]> :c
>> SunOS Release 5.11 Version snv_111 64-bit
>> Copyright 1983-2009 Sun Microsystems, Inc.  All rights reserved.
>> Use is subject to license terms.
>> features:
> 675f7fff<sse4_1,ssse3,cpuid,mwait,cmp,cx16,sse3,nx,asysc,sse2,s
se,sep,pat,cx8,pae,mca,mmx,cmov,de,pge,mtrr,msr,tsc,lgpg>
>> mem = 4123884K (0xfbb3b000)
>> Using default device instance data
>> initialized model-specific module 'cpu_ms.GenuineIntel' on chip 0
>> core 0 strand 0 root nexus = i86pc pseudo0 at root
>> pseudo0 is /pseudo
>> scsi_vhci0 at root
>> scsi_vhci0 is /scsi_vhci
>> isa0 at root
>> pseudo-device: acpippm0
>> acpippm0 is /pseudo/acpippm at 0
>> pseudo-device: ppm0
>> ppm0 is /pseudo/ppm at 0
>> ramdisk0 at root
>> ramdisk0 is /ramdisk
>> root on /ramdisk:a fstype ufs
>> SMBIOS v2.5 loaded (1708 bytes)
>> panic[cpu0]/thread=fffffffffbc2cca0: BAD TRAP: type=d (#gp
> General protection) rp=fffffffffbc4d780 addr=0
>> 
>> #gp General protection
>> pid=0, pc=0xfffffffffb80fd9e, sp=0xfffffffffbc4d870, eflags=0x10212
>> cr0: 8005003b<pg,wp,ne,et,ts,mp,pe> cr4:
> 6f8<xmme,fxsr,pge,mce,pae,pse,de>
>> cr2: 0cr3: 11c00000cr8: c
>> 
>>         rdi:           200000 rsi:              1ca rdx:
>>         fffffffff78980e9 rcx:            40000  r8:    4000000080473
>>         r9: fffffffff78a0ea0 rax:                0 rbx:             
>>         4 rbp: fffffffffbc4d8c0 r10: ffffff01c9804f40 r11:
>>         fffffffff7896e78 r12: ffffff01c6875548 r13:                0
>> r14: ffffff01c6882080 r15: 
>           0
>>         fsb:        200000000 gsb: fffffffffbc2e070  ds:
>           0
>>          es:                0  fs:                0  gs:
>           0
>>         trp:                d err:                0 rip:
>>          fffffffffb80fd9e cs:               30 rfl:            10212
>> rsp: fffffffffbc4d870          ss:               38 
>> 
>> fffffffffbc4d660 unix:die+10f ()
>> fffffffffbc4d770 unix:trap+43e ()
>> fffffffffbc4d780 unix:cmntrap+e9 ()
>> fffffffffbc4d8c0 unix:cpu_acpi_cache_cst+66 ()
>> fffffffffbc4d8e0 unix:cpu_acpi_cache_cstate_data+16 ()
>> fffffffffbc4d950 unix:cpu_idle_init+2f ()
>> fffffffffbc4da20 unix:cpupm_init+174 ()
>> fffffffffbc4da40 unix:post_startup+88 ()
>> fffffffffbc4da70 genunix:main+122 ()
>> fffffffffbc4da80 unix:_locore_start+92 ()
>> 
>> panic: entering debugger (no dump device, continue to reboot)
>> Loaded modules: [ scsi_vhci mac uppc ufs specfs pcplusmp cpu.generic
>> ] kmdb: target stopped at: kmdb_enter+0xb: movq   %rax,%rdi
>> [0]>
>> 
>> 
>> 
>>> -----Original Message-----
>>> From: tesla-dev-bounces at opensolaris.org
> [mailto:tesla-dev-bounces at opensolaris.org] On Behalf Of Bill
>>> Holler
>>> Sent: Tuesday, March 17, 2009 11:13 AM
>>> To: Mike.Ramchand at Sun.COM; nv-users at Sun.COM; Kuriakose
> Kuruvilla; tesla-dev at opensolaris.org
>>> Subject: Re: [tesla-dev] [Fwd: Lu from b105 - b110, panic on reboot]
>>> 
>>> Hi,
>>> 
>>> Your kernel is panicking on this line:
>>> 
>>> /*
>>>         * Does the package look coherent?
>>>         */
>>>        cnt = obj->Package.Elements[0].Integer.Value;
>>> 
>>> 
>>> The system's ACPI _CST object claimed to have more than 2 elements.
>>> However dereferencing Elements[0] traps.
>>> 
>>> In short: your BIOS has a buggy _CST table.  Please try upgrading
>>> your BIOS.  A possible workaround is to disable C-state in BIOS.
>>> If that does not avoid this issue, then set idle_cpu_no_deep_c
>>> with kmdb at boot:
>>>    1. Add these flag to the end of the grub $kernel line:       -k
>>> -d 
>>>    2. boot will stop in kmdb
>>>    3. [0] > idle_cpu_no_deep_c/w1
>>>    4. [0] > :c
>>> 
>>> 
>>> 
>>> On the other hand Solaris can use ontrap protection to guard
>>> against traps due to bad ACPI tables.  Please file a bug to
>>> add ontrap protection for ACPI table access.
>>> 
>>> Best regards,
>>> Bill Holler
>>> 
>>> 
>>> 
>>> On 03/17/09 09:48, Kuriakose Kuruvilla wrote:
>>> 
>>>> Panic during
>>>> 
>>>> cmntrap
>>>> cpu_acpi_cache_cst
>>>> cpu_acpi_cache_cstate_data
>>>> cpu_idle_init
>>>> post_startup
>>>> genunix:main
>>>> 
>>>> -------- Original Message --------
>>>> Subject: Lu from b105 - b110, panic on reboot
>>>> Date: Tue, 17 Mar 2009 11:27:27 +0000
>>>> From: Mike Ramchand <Mike.Ramchand at Sun.COM>
>>>> To: nv-users at sun.com
>>>> 
>>>> Hi All,
>>>> 
>>>> I've just LUed from 105 to 110 on my Tosh M9.
>>>> 
>>>> I get a panic (every time) on reboot.
>>>> 
>>>> The only packages which failed on the LU were SUNWxwfnt (which I
>>>> manually installed, and SUNWdcopy (which I've tried unchanged,
>>>> removed, and re-installed.) 
>>>> 
>>>> I enabled kmdb, and attached is the pretty picture I get. Any
>>>> clues? 
>>>> 
>>>> (I've also searched bugtraq, and sunsolve for references to
>>>> cpu_acpi_cache and 6612299, 6756843 and 6781321 are all that I
>>>> found, but they don't seem related) 
>>>> 
>>>> Mike
>>>> 
>>>> 
> ---------------------------------------------------------------
> ---------
>>>> 
>>>> 
>>> _______________________________________________
>>> tesla-dev mailing list
>>> tesla-dev at opensolaris.org
>>> http://mail.opensolaris.org/mailman/listinfo/tesla-dev
>>> 
> 
> _______________________________________________
> tesla-dev mailing list
> tesla-dev at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/tesla-dev


Reply via email to