Try disabling C-states (C2 and C3) in BIOS.
We still parse the _CST object when idle_cpu_no_deep_c is set
to be able to report what C-states are available.  :-(

I will have a fix you can try in under an hour.

Thank you,
Bill


On 03/17/09 15:29, Michael Ramchand wrote:
> Hi Bill,
>
> I just tried your suggestion, but I get the exact same panic.
>
> [0] > idle_cpu_no_deep_c/w1
> (which returns something like idle_cpu_no_deep_c :c = 0x1
> [0] > :c
>
> Then it panics in exactly the same way with the same stack lines.
>
> Any other suggestions? (or did I miss something)
>
> This is a Toshiba M9. I've downloaded and installed the latest BIOS. 
> John Martin reports the same with an Toshiba M10.
>
> Mike
>
>
> Bill Holler wrote:
>> On 03/17/09 11:13, Bill Holler wrote:
>>> 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
>>
>> If you need to disable C-states in kmdb (because they
>> could not be disabled in BIOS), then also add this line
>> to /etc/system to avoid having to apply the kmdb workaround
>> every boot:
>>
>> set  idle_cpu_no_deep_c=1
>>
>>>
>>>
>>>
>>> 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.
>>
>> Please assign the bug to me.
>>
>> Thank you,
>> Bill
>>
>>>
>>> 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
>>
>
>


Reply via email to