Related to Bug 1554 http://bugzilla.kernel.org/show_bug.cgi?id=1554 Since upgrading to Mandriva 9.1 (currently at 2.6.29.3-desktop-1mnb), I have experienced system lockups that had been a thing of the distant past. Some searching led me to bug report 1554. I fixed the DSDT for my Tyan Tiger 2466 and have had no more problems, so I assume it is a regression? That report showed the bug as originally fixed in 20031029.
Could you please explain more what problem you have seen? And what have you fixed for the DSDT? Also, please attach your acpidump output.
Created attachment 21916 [details] acpidupm.out
Intel ACPI Component Architecture ASL Optimizing Compiler version 20090521 [Jun 13 2009] Copyright (C) 2000 - 2009 Intel Corporation Supports ACPI Specification Revision 3.0a DSDT.dsl 235: Store (Local0, Local0) Error 4050 - ^ Method local variable is not initializ DSDT.dsl 240: Store (Local0, Local0) Error 4050 - ^ Method local variable is not initializ DSDT.dsl 245: Store (Local0, Local0) Error 4050 - ^ Method local variable is not initializ DSDT.dsl 296: Method (\_WAK, 1, NotSerialized) Warning 1080 - ^ Reserved method must return a value (_WAK) DSDT.dsl 310: Store (Local0, Local0) Error 4050 - ^ Method local variable is not initializ 1Help 2Save 3Mark 4Replac 5Copy 6Move 7Search 8Delete 9PullDn 10Quit I commented out the Store ( errors and added Return(Package(0x02){0x00, 0x00}) to the end of \_WAK to get it to compile cleanly. I have experienced system freezes so sever that I could only power off the computer. I didn't write it down, but the stack trace I saw once led me to consider the BIOS, but it also could be IRQ re-lated. There are numerous Internet posts about the AMD-768 chipset and Tyan 2466 mobo. I had not experienced problems in years until I upgraded to Mandriva 2009.1 and their current kernel. Thanks for looking at this.
Hi, Hoyt Do you mean that the system will freeze? Will you please try the following boot options and see whether it still freezes? a. nolapic_timer b. idle=poll c. processor.max_cstate=1 It will be great if you can confirm whether it freezes on the latest kernel after using the custom DSDT as in comment #0. Thanks.
All at one time? Or each one in turn? And I'll try to get a good photo of the stack trace if that would be helpful.
please send the diff between the original DSDT that fails, and the "fixed" DSDT that works. does the hang ALWAYS go away with the modified DSDT? it is sort of surprising that this could be related to the system hang, but who knows... it sounds like you got a stack trace upon the freeze? that is the 1st thing to look at.
I see one if I'm not using X. I'll go back to the original BIOS and wait for a crash. I''ll take a picture of the screen if I get a stack trace. But I'll be out of the office for a few days and in the field, so look for something by the end of the week. On 6/15/09, bugzilla-daemon@bugzilla.kernel.org <bugzilla-daemon@bugzilla.kernel.org> wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=13532 > > > Len Brown <len.brown@intel.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEW |NEEDINFO > CC| |len.brown@intel.com > > > > > --- Comment #6 from Len Brown <len.brown@intel.com> 2009-06-16 01:34:01 --- > please send the diff between the original DSDT that fails, > and the "fixed" DSDT that works. does the hang ALWAYS > go away with the modified DSDT? > > it is sort of surprising that this could be related to > the system hang, but who knows... > > it sounds like you got a stack trace upon the freeze? > that is the 1st thing to look at. > > -- > Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You reported the bug. >
I see one if I'm not using X. I'll go back to the original BIOS and wait for a crash. I''ll take a picture of the screen if I get a stack trace. But I'll be out of the office for a few days and in the field, so look for something by the end of the week.
As far as the ACPI Error message, it looks as though this message was added sometime after code was added to allow a Store(LocalX,LocalX) when LocalX is not initialized. It looks to me like an extraneous message in this case, as the control method is not actually aborted, and the Store in question is in fact treated as a NOOP. We will look at either removing the message or moving it to a point in the execution where we know that it is an unrecoverable error.
I copied this by hand: [<c022583b>] native_smp_send_stop+0x1b/0x50 [<c0399673>] panic+0x52/0xfc [<c039d009>] oops_end+0xc9/0xd0 [<c03ac691>] do_trap+0x91/0xd0 [<c0106300>] ? do_invalid_op+0x0/0xa0 [<c0106386>] do_invalid_op+0x86/0xa0 [<c014a6c7>] ? run_posix_cpu_timers+0x997/0x9f0 [<c018b691>] ? lru_cache_add_anon_rmap+0x74/0x80 [<c0198c48>] ? page_add_lru+0x21/0x40 [<c0198c48>] ? handle_mm_fault+0x3a8/0x780 [<c039c45a>] error_code+0x72/0x78 [<c014a6c7>] ? run_posix_cpu_timers+0x997/0x9f0 [<c0126d4b>] ? task_tick_+0xb6/0x1f0 [<c012e186>] ? scheduler_tick+0xb6/0x1f0 [<c013dd84>] update_process_times+0x54/0x70 [<c0155d2d>] tick_sched_timer+0x5d/0xc0 [<c014bc81>] __run_hrtimer+0x71/0xe0 [<c0155cd0>] ? tick_sched_timer+0x0/0xc0 [<c014c4ed>] hrtimer_interrupt+0x17d/0x220 [<c0116d19>] smp_apic_timer_interrupt+0x59/0x90 [<c0105bc0>] apic_timer_interrupt+0x28/0x30 I'm now trying the bot options mentioned above.
There are two problems in this bug report. 1. acpi error message they appear to be totally unrelated. The ACPI error message is cosmetic only, since we have not changed that behaviour of store(local0, local0) in years. But apparently its appearance is a regression. So we'll keep this bug report open until that error message is gone. (Note that it is being tracked in the upstream ACPICA tree here: http://acpica.org/bugzilla/show_bug.cgi?id=785 2. system crash/hang I don't see this one at kerneloops.org, which suggests that others are not seeing it -- or that it is so severe that it isn't getting saved. do_invalid_op sounds like perhaps the kernel build is for the wrong version of the processor or some sort of memory corruption? I recommend that you send the stack trace above to LKML and see what the folks there think. There is no indication that the crash/hang is related to ACPI, so this bug report shall be relegated to the (trivial) issue of the ACPI error message.
iASL sightings are filed in the ACPICA database, per comment #11. (and it is likely a FEATURE rather than a BUG that it complains to the programmer about what appears to be a programming typo that serves no logical purpose) The crash mentioned in this bug report doesn't appear related to ACPI. Please report it on LKML. closed as invalid.