Bill Holler wrote: > 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. Whoa. Let's figure out why ACPI CA is returning an apparently invalid Package structure from AcpiEvaluateObject() first - it's likely not directly the result of a buggy _CST "table".
[_CST is an ACPI object encoded as AML, it's not simple table like the firmware tables are; ACPI CA parses it and constructs the returned object which is tripping over a panic] What I need to see is the entire output of '/home/sethg/iasl -g' for this machine. Dana > > 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 >>> >> >> > > _______________________________________________ > tesla-dev mailing list > tesla-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/tesla-dev >
