Bug 10734
| Summary: | CPU Frequency scaling gone on CPU1 after resume-from-sleep - Dell Latitude D630, XPS M1330 | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Dennis Noordsij (dennis.noordsij) |
| Component: | BIOS | Assignee: | Robert Moore (Robert.Moore) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | acpi-bugzilla, dariush, davej, khashayar.lists, Matt_Domsch, ming.m.lin, superm1 |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.26-rc2 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
| Attachments: |
dmesg of a fresh boot, suspend, then resume
acpidump output disassembled dsdt acpidump outputs as requested Merged CPU*ST and SSDT into the DSDT acpi dump Cpu*st tables before and after resume (*Ist become corrupted) acpidump, cpu*st, dmesg Copy external ACPI tables to our own buffer instead of mapping them Cleaned up patch ACPICA version of load table patch output of sudo lspci -v |
||
|
Description
Dennis Noordsij
2008-05-17 12:30:02 UTC
(btw, this is not a duplicate of either #9181 or #8581 afaict) Some output with cpufreq.debug=7 (2.6.26-rc2) Boot: [ 53.689628] acpi-cpufreq: acpi_cpufreq_init [ 53.689628] acpi-cpufreq: acpi_cpufreq_early_init [ 53.689628] cpufreq-core: trying to register driver acpi-cpufreq [ 53.689628] cpufreq-core: adding CPU 0 [ 53.689628] acpi-cpufreq: acpi_cpufreq_cpu_init [ 53.689628] acpi-cpufreq: HARDWARE addr space [ 53.689628] freq-table: table entry 0: 2201000 kHz, 0 index [ 53.689628] freq-table: table entry 1: 2200000 kHz, 1 index [ 53.689628] freq-table: table entry 2: 1600000 kHz, 2 index [ 53.689628] freq-table: table entry 3: 1200000 kHz, 3 index [ 53.689628] freq-table: table entry 4: 800000 kHz, 4 index [ 53.689628] acpi-cpufreq: get_cur_freq_on_cpu (0) [ 53.689628] acpi-cpufreq: get_cur_val = 100666153 [ 53.689628] acpi-cpufreq: cur freq = 2200000 [ 53.689628] acpi-cpufreq: CPU0 - ACPI performance management activated. [ 53.689628] acpi-cpufreq: *P0: 2201 MHz, 32000 mW, 10 uS [ 53.689628] acpi-cpufreq: P1: 2200 MHz, 31000 mW, 10 uS [ 53.689628] acpi-cpufreq: P2: 1600 MHz, 20000 mW, 10 uS [ 53.689628] acpi-cpufreq: P3: 1200 MHz, 13000 mW, 10 uS [ 53.689628] acpi-cpufreq: P4: 800 MHz, 10000 mW, 10 uS [ 53.689628] freq-table: setting show_table for cpu 0 to effb7dc0 [ 53.689628] cpufreq-core: CPU 1 already managed, adding link [ 53.689628] cpufreq-core: setting new policy for CPU 0: 800000 - 2201000 kHz [ 53.689628] acpi-cpufreq: acpi_cpufreq_verify [ 53.689628] freq-table: request for verification of policy (800000 - 2201000 kHz) for cpu 0 [ 53.689628] freq-table: verification lead to (800000 - 2201000 kHz) for cpu 0 [ 53.689628] acpi-cpufreq: acpi_cpufreq_verify [ 53.689628] freq-table: request for verification of policy (800000 - 2201000 kHz) for cpu 0 [ 53.689628] freq-table: verification lead to (800000 - 2201000 kHz) for cpu 0 [ 53.689628] cpufreq-core: new min and max freqs are 800000 - 2201000 kHz [ 53.689628] cpufreq-core: governor switch [ 53.689628] cpufreq-core: __cpufreq_governor for CPU 0, event 1 [ 53.689628] cpufreq-core: governor: change or update limits [ 53.689628] cpufreq-core: __cpufreq_governor for CPU 0, event 3 [ 53.689628] cpufreq-core: initialization complete [ 53.689628] cpufreq-core: adding CPU 1 [ 53.689628] cpufreq-core: driver acpi-cpufreq up and running [ 53.692801] acpi-cpufreq: cpu 0: performance percent 88 [ 53.692804] cpufreq-core: target for CPU 0: 0 kHz, relation 0 [ 53.692807] acpi-cpufreq: acpi_cpufreq_target 0 (0) [ 53.692809] freq-table: request for target 0 kHz (relation: 0) for cpu 0 [ 53.692811] freq-table: target is 4 (800000 kHz, 4) [ 53.692813] cpufreq-core: notification 0 of frequency transition to 800000 kHz [ 53.692816] cpufreq-core: notification 0 of frequency transition to 800000 kHz [ 53.695548] cpufreq-core: notification 1 of frequency transition to 800000 kHz [ 54.045419] toshiba_acpi: Unknown parameter `hotkeys_over_acpi' [ 58.814979] __ratelimit: 61 messages suppressed [ 58.814989] acpi-cpufreq: cpu 0: performance percent 58 [ 62.336641] apm: BIOS not found. [ 62.463239] cpufreq-core: setting new policy for CPU 0: 800000 - 2201000 kHz [ 62.463251] acpi-cpufreq: acpi_cpufreq_verify [ 62.463258] freq-table: request for verification of policy (800000 - 2201000 kHz) for cpu 0 [ 62.463265] freq-table: verification lead to (800000 - 2201000 kHz) for cpu 0 [ 62.463273] acpi-cpufreq: acpi_cpufreq_verify [ 62.463278] freq-table: request for verification of policy (800000 - 2201000 kHz) for cpu 0 [ 62.463286] freq-table: verification lead to (800000 - 2201000 kHz) for cpu 0 [ 62.463293] cpufreq-core: new min and max freqs are 800000 - 2201000 kHz [ 62.466433] cpufreq-core: governor: change or update limits etc .. then, after resuming: [ 165.391132] Back to C! [ 165.391423] Extended CMOS year: 2000 [ 165.391550] Enabling non-boot CPUs ... [ 165.391565] cpufreq-core: setting new policy for CPU 0: 800000 - 2201000 kHz [ 165.391566] acpi-cpufreq: acpi_cpufreq_verify [ 165.391568] freq-table: request for verification of policy (800000 - 2201000 kHz) for cpu 0 [ 165.391570] freq-table: verification lead to (800000 - 2201000 kHz) for cpu 0 [ 165.391573] acpi-cpufreq: acpi_cpufreq_verify [ 165.391575] freq-table: request for verification of policy (800000 - 2201000 kHz) for cpu 0 [ 165.391577] freq-table: verification lead to (800000 - 2201000 kHz) for cpu 0 [ 165.391579] cpufreq-core: new min and max freqs are 800000 - 2201000 kHz [ 165.391580] cpufreq-core: governor: change or update limits [ 165.391582] cpufreq-core: __cpufreq_governor for CPU 0, event 3 [ 165.391647] CPU0 attaching NULL sched-domain. [ 165.391762] SMP alternatives: switching to SMP code [ 165.399962] Booting processor 1/1 ip 6000 [ 165.408392] Initializing CPU#1 [ 165.408392] Calibrating delay using timer specific routine.. 4391.46 BogoMIPS (lpj=8782923) [ 165.408392] CPU: L1 I cache: 32K, L1 D cache: 32K [ 165.408392] CPU: L2 cache: 4096K [ 165.408392] CPU: Physical Processor ID: 0 [ 165.408392] CPU: Processor Core ID: 1 [ 165.489023] CPU1: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz stepping 0b [ 165.489056] CPU0 attaching sched-domain: [ 165.489059] domain 0: span 0-1 [ 165.489060] groups: 0 1 [ 165.489063] CPU1 attaching sched-domain: [ 165.489065] domain 0: span 0-1 [ 165.489066] groups: 1 0 [ 165.408392] cpufreq-core: adding CPU 1 [ 165.408392] acpi-cpufreq: acpi_cpufreq_cpu_init [ 165.408392] ACPI Error (psloop-0136): Found unknown opcode FE at AML address f883c7ca offset 3, ignoring [20080321] [ 165.408392] ACPI Error (psloop-0136): Found unknown opcode 1F at AML address f883c7cd offset 6, ignoring [20080321] [ 165.408392] ACPI Error (psloop-0136): Found unknown opcode 2 at AML address f883c7d4 offset D, ignoring [20080321] [ 165.408392] ACPI Error (psloop-0136): Found unknown opcode C2 at AML address f883c7d6 offset F, ignoring [20080321] [ 165.408392] ACPI Error (psargs-0358): [E] Namespace lookup failure, AE_NOT_FOUND [ 165.408392] ACPI Error (psparse-0530): Method parse/execution failed [\_PR_.CPU1._PCT] (Node f4c17930), AE_NOT_FOUND [ 165.408392] ACPI Exception (processor_perflib-0191): AE_NOT_FOUND, Evaluating _PCT [20080321] [ 165.408392] cpufreq-core: initialization failed [ 165.408392] CPU1 is up [ 165.512254] Switched to high resolution mode on CPU 1 Changed governor to performance: [ 247.730430] cpufreq-core: setting new policy for CPU 0: 800000 - 2201000 kHz [ 247.730430] acpi-cpufreq: acpi_cpufreq_verify [ 247.730430] freq-table: request for verification of policy (800000 - 2201000 kHz) for cpu 0 [ 247.730430] freq-table: verification lead to (800000 - 2201000 kHz) for cpu 0 [ 247.730430] acpi-cpufreq: acpi_cpufreq_verify [ 247.730430] freq-table: request for verification of policy (800000 - 2201000 kHz) for cpu 0 [ 247.730430] freq-table: verification lead to (800000 - 2201000 kHz) for cpu 0 [ 247.730430] cpufreq-core: new min and max freqs are 800000 - 2201000 kHz [ 247.730430] cpufreq-core: governor switch [ 247.730430] cpufreq-core: __cpufreq_governor for CPU 0, event 2 [ 247.730430] cpufreq-core: __cpufreq_governor for CPU 0, event 1 [ 247.730430] performance: setting to 2201000 kHz because of event 1 [ 247.730430] cpufreq-core: target for CPU 0: 2201000 kHz, relation 1 [ 247.730430] acpi-cpufreq: acpi_cpufreq_target 2201000 (0) [ 247.730430] freq-table: request for target 2201000 kHz (relation: 1) for cpu 0 [ 247.730430] freq-table: target is 0 (2201000 kHz, 0) [ 247.730430] cpufreq-core: notification 0 of frequency transition to 2201000 kHz [ 247.730430] cpufreq-core: notification 1 of frequency transition to 2201000 kHz [ 247.730430] cpufreq-core: governor: change or update limits [ 247.730430] cpufreq-core: __cpufreq_governor for CPU 0, event 3 [ 247.730430] performance: setting to 2201000 kHz because of event 3 [ 247.730430] cpufreq-core: target for CPU 0: 2201000 kHz, relation 1 [ 247.730430] acpi-cpufreq: acpi_cpufreq_target 2201000 (0) [ 247.730430] freq-table: request for target 2201000 kHz (relation: 1) for cpu 0 [ 247.730430] freq-table: target is 0 (2201000 kHz, 0) [ 247.730430] acpi-cpufreq: Called after resume, resetting to P0 [ 247.730430] cpufreq-core: notification 0 of frequency transition to 2201000 kHz [ 247.730430] cpufreq-core: notification 1 of frequency transition to 2201000 kHz Changing governor to ondemand: [ 264.608272] cpufreq-core: setting new policy for CPU 0: 800000 - 2201000 kHz [ 264.608272] acpi-cpufreq: acpi_cpufreq_verify [ 264.608272] freq-table: request for verification of policy (800000 - 2201000 kHz) for cpu 0 [ 264.608272] freq-table: verification lead to (800000 - 2201000 kHz) for cpu 0 [ 264.608272] acpi-cpufreq: acpi_cpufreq_verify [ 264.608272] freq-table: request for verification of policy (800000 - 2201000 kHz) for cpu 0 [ 264.608272] freq-table: verification lead to (800000 - 2201000 kHz) for cpu 0 [ 264.608272] cpufreq-core: new min and max freqs are 800000 - 2201000 kHz [ 264.608272] cpufreq-core: governor switch [ 264.608272] cpufreq-core: __cpufreq_governor for CPU 0, event 2 [ 264.608272] cpufreq-core: __cpufreq_governor for CPU 0, event 1 [ 264.608272] cpufreq-core: governor: change or update limits [ 264.608272] cpufreq-core: __cpufreq_governor for CPU 0, event 3 [ 264.630611] __ratelimit: 20 messages suppressed [ 264.630618] acpi-cpufreq: cpu 0: performance percent 77 Please attach the output of dmesg after boot and the acpidump here. Created attachment 16187 [details]
dmesg of a fresh boot, suspend, then resume
As requested: fresh boot dmesg. At 165.39 the system is suspended to RAM and woken up.
Created attachment 16188 [details]
acpidump output
As requested: acpidump output. Note that I have tried a "fixed" DSDT which fixes some of the errors/warnings, but this has no different effect.
Created attachment 16189 [details]
disassembled dsdt
Please run: acpidump --addr 0x7FE5C4F6 --length 0x286 > cpu0ist acpidump --addr 0x7FE5C77C --length 0xC4 > cpu1ist acpidump --addr 0x7FE5BE8C --length 0x5E5 > cpu0cst acpidump --addr 0x7FE5C471 --length 0x85 > cpu1cst The _PCT method should be in these dynamic tables. Created attachment 16190 [details]
acpidump outputs as requested
Hope it is OK I tar'd them (didn't want to spam)
Need to follow this bug. Created attachment 16244 [details]
Merged CPU*ST and SSDT into the DSDT
I have extracted the relevant parts of the SSDT, CPU0IST, CPU1IST, CPU0CST and CPU0IST tables and embedded them directly into the DSDT, and booted with that as well as the option "acpi_no_auto_ssdt".
(Had to also fix a few minor errors to compile it)
This gives me the following new acpi errors:
[ 15.569530] ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT, Index (000000001) is beyond end of object [20070126]
[ 15.569536] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU0._OSC] (Node f7c47d80), AE_AML_PACKAGE_LIMIT
[ 15.569572] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU0._PDC] (Node f7c47d68), AE_AML_PACKAGE_LIMIT
[ 15.570156] ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT, Index (000000004) is beyond end of object [20070126]
[ 15.570162] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU1._OSC] (Node f7c47e70), AE_AML_PACKAGE_LIMIT
[ 15.570193] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU1._PDC] (Node f7c47e58), AE_AML_PACKAGE_LIMIT
but frequency scaling (still) works, AND now also works when resuming from standby.
Since originally the search for \_CPU1._PCT runs into unknown opcodes, can there be some corruption going on ? _PCT seems to be there, and seems to generally work. The problem is in trying to locate it after resume ?
Please advise if you have any suggestions where I should continue to look for the cause.
Confirmed this bug. Hardware Environment: Dell Latitude D630 (BIOS rev. A10) Software Environment: Ubuntu Hardy Kernel: 2.6.25 (mainline) dmesg output after resume from S3: [ 3038.576849] Back to C! [ 3038.577288] Enabling non-boot CPUs ... [ 3038.577352] CPU0 attaching NULL sched-domain. [ 3038.577494] SMP alternatives: switching to SMP code [ 3038.578559] Booting processor 1/1 ip 4000 [ 3155.527155] Initializing CPU#1 [ 3155.527155] Calibrating delay using timer specific routine.. 4389.08 BogoMIPS (lpj=8778165) [ 3155.527155] CPU: L1 I cache: 32K, L1 D cache: 32K [ 3155.527155] CPU: L2 cache: 4096K [ 3155.527155] CPU: Physical Processor ID: 0 [ 3155.527155] CPU: Processor Core ID: 1 [ 3155.527155] Intel machine check architecture supported. [ 3155.527155] Intel machine check reporting enabled on CPU#1. [ 3038.667153] CPU1: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz stepping 0b [ 3038.667173] kvm: enabling virtualization on CPU1 [ 3038.667193] CPU0 attaching sched-domain: [ 3038.667195] domain 0: span 3 [ 3038.667196] groups: 1 2 [ 3038.667198] domain 1: span 3 [ 3038.667200] groups: 3 [ 3038.667202] CPU1 attaching sched-domain: [ 3038.667203] domain 0: span 3 [ 3038.667204] groups: 2 1 [ 3038.667206] domain 1: span 3 [ 3038.667207] groups: 3 [ 3155.527155] ACPI Error (psloop-0136): Found unknown opcode FE at AML address f8cf67ca offset 3, ignoring [20070126] [ 3155.527155] nssearch-0336 [00] ns_search_and_enter : Found bad character(s) in name, repaired: [C***] [ 3155.527155] ACPI Error (psargs-0355): [C���.D��] Namespace lookup failure, AE_NOT_FOUND [ 3155.527155] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU1._PCT] (Node f7818888), AE_NOT_FOUND [ 3155.527155] ACPI Exception (processor_perflib-0191): AE_NOT_FOUND, Evaluating _PCT [20070126] [ 3155.527155] CPU1 is up [ 3155.527170] Switched to high resolution mode on CPU 1 [ 3155.618445] PM: Writing back config space on device 0000:00:02.0 at offset f (was 100, writing 10b) [...] After that cpufreq doesn't recognise the 2nd CPU anymore (as Dennis described). I could also provide more information, if needed. Dariush Will you please attach the following outputs after the system is resumed from the suspend state? (Note: please do this after the system is resumed.) acpidump --addr 0x7FE5C4F6 --length 0x286 > cpu0ist acpidump --addr 0x7FE5C77C --length 0xC4 > cpu1ist acpidump --addr 0x7FE5BE8C --length 0x5E5 > cpu0cst acpidump --addr 0x7FE5C471 --length 0x85 > cpu1cst Thanks. > acpidump --addr 0x7FE5C4F6 --length 0x286 > cpu0ist
> acpidump --addr 0x7FE5C77C --length 0xC4 > cpu1ist
> acpidump --addr 0x7FE5BE8C --length 0x5E5 > cpu0cst
> acpidump --addr 0x7FE5C471 --length 0x85 > cpu1cst
Done that. They are all filled completely with 0xFF.
Dariush
Created attachment 16253 [details]
acpi dump
Note: The acpidump of the addresses you've given are 0xFF even before suspending.
Also attached the acpidump output (it differs slightly from Dennis' one).
Dariush
Dariush: note that those addresses were based on my system. What you are looking for is: dmesg | grep Cpu | grep st [ 14.437438] ACPI: SSDT 7FE5C4F6, 0286 (r1 PmRef Cpu0Ist 3000 INTL 20050624) [ 14.437597] ACPI: SSDT 7FE5BE8C, 05E5 (r1 PmRef Cpu0Cst 3001 INTL 20050624) [ 14.438352] ACPI: SSDT 7FE5C77C, 00C4 (r1 PmRef Cpu1Ist 3000 INTL 20050624) [ 14.438497] ACPI: SSDT 7FE5C471, 0085 (r1 PmRef Cpu1Cst 3000 INTL 20050624) The value after SSDT is the address, the next is the length, both in hex so prefix with 0x. Created attachment 16254 [details]
Cpu*st tables before and after resume (*Ist become corrupted)
Attached the CPU tables before and after resume.
The Cst tables remain the same, the Ist tables seem to have gotten corrupted (partially similar, partially garbage, can not be disassembled by iasl anymore). This seems to make sense with the observed bug.
Please advise on further testing or suggestions. Many thanks for the help so far!
Created attachment 16255 [details]
acpidump, cpu*st, dmesg
Ah yes, thanks Dennis.
Attached the cpu*st dumps before and after.
Dariush
FWIW, the same corruption happens when resuming under Windows XP, ruling out any Linux bug causing it. (confirmed using RW Read & Write utility http://jacky5488.myweb.hinet.net/index.htm) I don't know if and how this affects the CPU frequency scaling under Windows XP (note that the laptop was intended for Vista). <acpi_noob> Should the Linux ACPI stack make a private copy of the external tables ? </acpi_noob> Thanks for the info.
The ACPI tables(for example: CPU0IST, CPU1IST) reside in the following address range. After the system is resumed, the content can't be resumed correctly.
>BIOS-e820: 000000007fe5b800 - 0000000080000000 (reserved)
Because the ACPI tables become incorrect (For example: Cpu0IST, CPU1IST)and the objects in the ACPI tables are required, the ACPI cpufreq driver can't work well. Of course maybe there will be some potential issues.
IMO this is a bios bug and it had better be fixed by upgrading bios.
True, however the latest BIOS does not seem to fix this (Dariush: which version are you using? A10?), and working around broken BIOS's is part of the fun isn't it? :-) As an alternative solution, since apparantly other OS's manage to work around this, and there are many users with this problem, what needs to be done to make acpi_cpufreq unloadable ? Currently once it is loaded it is always "in use". This issue would be managable by blacklisting acpi_cpufreq on suspend, and loading it again on resume. The _PCT is never actually followed in the initialization, only when resuming. However the only way currently is to remove it by force, which is not good. Yes, I use BIOS rev. A10 (upgraded during testing this bug.). I suspect that we will have to make Dell aware of this Bug to actually get it fixed. BTW: Dennis, I tried your modified DSDT and it works fine! Up to now I didn't notice any regressions, so thank you very much! Have a nice sunday! Dariush Created attachment 16275 [details]
Copy external ACPI tables to our own buffer instead of mapping them
Copying the tables rather than mapping them (this only applies to the external tables, not the standard ones, so it is at most a few KB) works around the issue completely. After my first tests, this seems to resume correctly without any issue.
A solution which does not require explicit workarounds (blacklisting certain modules) but which just works is of course preferred.
Now, I don't know nearly enough to tell if this would break (other) things horribly, or if this goes against some policy, so please comment on wether something like this should or should not be done, as well as suggest on how this issue can be worked around permanently (such as a specific blacklist which enables this on known bad BIOS's? etc).
Patch is against latest ACPI tree git, should apply against both test and release branches.
Dariush: is it possible for you to test this ? It should apply against a vanilla kernel with at most small modifications.
Dennis: Yes, it works! I tried it against the current linux-2.6 git tree. With this patch the laptop behaves exactly like with your modified DSDT (no strange ACPI messages or similar). To me this also seems like a good workaround. But as I am an even bigger ACPI noob than you, I'll better leave this assessment to the experts. :-) Dariush Hi, Dennis
Thanks for your great work. What you have done is very terrific.
In current kernel when one ACPI table is loaded, thememory region is only mapped instead of copying them to the buffer. If the memory region is crashed in the course of suspend/resume, the objects can't be accessed. Maybe it will be better that OS copies the ACPI tables instead of mapping them.
Thanks for your great work again.
Did we confirm windows work in the system? Created attachment 16280 [details]
Cleaned up patch
- Added ACPI_FREE in the case acpi_os_map_memory fails.
- Made patch compliant with submission requirements.
What is now the next step ? Will it be considered for inclusion in the acpi test tree automatically or do I need to send it somewhere?
Hi Dennis: I verified that your patch worked correctly for me on my XPS M1330. Thanks! Does Unload() automatically work with this patch? Robert: Yes, it should, there should be no side-effects from changing the table type from mapped to allocated. If you have some specific test (to confirm) in mind I would be happy to try it. Do we have permission from the author to port this patch and include it into ACPICA? Robert: Yes, please feel free to do so. Created attachment 16460 [details]
ACPICA version of load table patch
Attached is the ported version of the code. A few changes, notably that we simply always use the table length, since it must be correct if the table is valid.
I doesn't look like the table checksum gets validated in the load from region case. Dennis, could you please attach the lspci output? Created attachment 16663 [details]
output of sudo lspci -v
Added on request
Change was integrated and released in ACPICA version 20080701 workaround patch is now in acpi test tree, thanks guys! specifically, the patch in the tree is this one: Author: Dennis Noordsij <dennis.noordsij@helsinki.fi> 2008-08-14 21:37:58 Committer: Len Brown <len.brown@intel.com> 2008-09-22 17:39:13 Parent: d3ff268a0149fce8835f6d48ab481d5e3321e0f7 (ACPICA: Fix possible memory leak in Unload() operator) Child: 76a509bb8fabcfe111be65b67cfdc03d4768b654 (ACPICA: Fix warning for 64-bit build) Branches: acpica, acpica-fixes, test Follows: v2.6.27-rc7 Precedes: ACPICA: Copy dynamically loaded tables to local buffer shipped in linux-2.6.28-rc1 closed commit f0e0da8a6cca44396c7a711e308d58084e881617 Author: Dennis Noordsij <dennis.noordsij@helsinki.fi> Date: Fri Aug 15 09:37:58 2008 +0800 ACPICA: Copy dynamically loaded tables to local buffer Previously, dynamically loaded tables were simply mapped, but on some machines this memory is corrupted after suspend. Now copy the table to a local buffer. For OpRegion case, added checksum verify. Use the table length from the table header, not the region length. For Buffer case, use the table length also. |