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,sse,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
