Description Federico Chiacchiaretta 2009-11-22 20:42:13 UTC
Hi I'm experiencing this problem on my dell laptop: on first boot temperatures are correctly detected, fan starts correctly when temperature goes up. If I suspend (to ram) the laptop and then resume, I get zero values by all three thermal zones (0 °C), and fan never starts, I have to reboot to fix this. I'm using kernel 2.6.32-rc8 from http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32-rc8/ , which AFAIK is kernel vanilla compiled for ubuntu. I also tried to build kernel with zen patchset (version 2.6.32-rc7) and the issue is present as well. Best Regards Federico Chiacchiaretta
Comment 1 Zhang Rui 2009-11-24 01:51:39 UTC
please attach the dmesg output after resume. please attach the acpidump output of this laptop.
Comment 2 Federico Chiacchiaretta 2009-11-24 08:00:09 UTC
Created attachment 23918 [details] acpidump
Comment 3 Federico Chiacchiaretta 2009-11-24 08:01:00 UTC
Created attachment 23919 [details] dmesg before suspending
Comment 4 Federico Chiacchiaretta 2009-11-24 08:01:35 UTC
Created attachment 23920 [details] dmesg after suspend and resume
Comment 5 Rafael J. Wysocki 2009-11-24 22:23:17 UTC
What was the last working kernel?
Comment 6 Federico Chiacchiaretta 2009-11-24 23:47:33 UTC
Kernel 2.6.31 (default in kubuntu) works perfectly, then I tried 2.6.32-rc7 (with zen patchset) and 2.6.32-rc8 (vanilla compiled for ubuntu) and they're both non working. Further info: 1 - Since fglrx module still does not support kernel 2.6.32 I managed to build it with this fix from debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554401 2 - When attaching dmesg-after-suspending I saw that during suspending procedure fglrx prints out an error; I tried to blacklist it and rebooted using radeon instead, but when resuming screen doesn't turn on anymore, it keeps black like it's powered off, so I can't see if fglrx is actually the problem.
Comment 7 Alexandre Peixoto Ferreira 2009-11-25 00:33:23 UTC
I have the same problem. I am using Gentoo with radeon X driver and I am not using fglrx. It works with 2.6.31 but does not work with 2.6.32-rc7 and 8.
Comment 8 Alexandre Peixoto Ferreira 2009-11-25 00:54:05 UTC
Kernel 2.6.32-rc2 is the first one that the problem appears.
Comment 9 Zhang Rui 2009-12-04 05:50:29 UTC
so you mean 2.6.32-rc1 is working well? could you please run git-bisect to find out which commit introduces this bug?
Comment 10 Alexandre Peixoto Ferreira 2009-12-06 18:10:35 UTC
I tested with 2.6.32-rc1 (but it seems that it was tagged 2.6.32-rc2). It seems that all 2.6.32 have the same problem. I will try to find which commit from 2.6.32-rc1 (compared to 2.6.31).
Comment 11 Alexandre Peixoto Ferreira 2009-12-08 03:02:43 UTC
The result of using git bisect from 2.6.31 and 2.6.32-rc1 is: commit 6a63b06f3c494cc87eade97f081300bda60acec7 Author: Alexey Starikovskiy <email@example.com> Date: Fri Aug 28 23:29:44 2009 +0400 ACPI: EC: use BURST mode only for MSI notebooks Signed-off-by: Alexey Starikovskiy <firstname.lastname@example.org> Signed-off-by: Len Brown <email@example.com>
Comment 12 Zhang Rui 2009-12-08 03:06:57 UTC
alexey, can you look at this issue please?
Comment 13 Alexandre Peixoto Ferreira 2009-12-08 03:13:28 UTC
I confirmed that removing this commit, suspend works again for my Dell laptop (Studio XPS 16).
Comment 14 Zhang Rui 2009-12-08 03:21:15 UTC
please attach the dmidecode output of your laptop
Comment 15 Alexandre Peixoto Ferreira 2009-12-08 03:44:28 UTC
Created attachment 24087 [details] Dmidecode from a Dell Studio XPS 16 laptop
Comment 16 Zhang Rui 2009-12-22 02:20:49 UTC
*** Bug 14735 has been marked as a duplicate of this bug. ***
Comment 17 Alexey Starikovskiy 2009-12-24 11:56:56 UTC
Could you please uncomment "#define DEBUG" in drivers/acpi/ec.c and attach dmesg here?
Comment 18 Alexandre Peixoto Ferreira 2009-12-24 15:59:10 UTC
Created attachment 24293 [details] dmesg with ec.c (with DEBUG)
Comment 19 Alexandre Peixoto Ferreira 2009-12-24 16:01:16 UTC
Created attachment 24294 [details] dmesg with ec.c (with DEBUG) after resume (Suspend)
Comment 20 Alexandre Peixoto Ferreira 2009-12-24 16:01:58 UTC
Created attachment 24295 [details] dmesg with modified ec.c (with DEBUG)
Comment 21 Alexandre Peixoto Ferreira 2009-12-24 16:02:46 UTC
Created attachment 24296 [details] dmesg with modified ec.c (with DEBUG) after resume (Suspend)
Comment 22 shinydoofy 2009-12-27 02:43:56 UTC
I had the very issue updating from 2.6.31 to 2.6.32-rc1. Commenting out those two if lines in ec.c fixed it on my Dell Studio 1537. If you guys need another pair of debug log dumps like Alexandre's, just ping.
Comment 23 James Ettle 2010-01-20 00:15:28 UTC
Created attachment 24645 [details] dmesg output with #define DEBUG uncommented for Clevo M720R (In reply to comment #17) > Could you please uncomment "#define DEBUG" in drivers/acpi/ec.c and attach > dmesg here? I'll add one here as well, since I'm reporter of bug 14735 (which is a duplicate of this one). Apologies for the length. See bug 14735 for the notebook's acpidump.
Comment 24 Michał Witkowski 2010-01-28 19:24:54 UTC
I've got a Lenovo U330 here. After upgrading from kernel 2.6.31 to kernel 2.6.32 (and even 2.6.33-rc5) both my sleep and power-off buttons stopped working. :( Unfortunately I don't have the time to recompile a kernel with the ifs commented out in ec.c, so I must assume this is a similar bug. I'll attach a dmidecode for the laptop below.
Comment 25 Michał Witkowski 2010-01-28 19:25:44 UTC
Created attachment 24765 [details] dmidecode of Lenovo Ideapad U330
Comment 26 Rafael J. Wysocki 2010-01-28 20:04:35 UTC
What makes you think this issue is related to the $subject bug?
Comment 27 Michał Witkowski 2010-01-28 20:48:40 UTC
(In reply to comment #26) > What makes you think this issue is related to the $subject bug? I have really similar symptoms to the ones specified in bug 14735, which was closed as a duplicate of this bug. Thus I reported it here, because I didn't want to open a new bug. How can I verify it without the need to rebuild the kernel?
Comment 28 Rafael J. Wysocki 2010-01-28 21:00:27 UTC
I guess the only real test would be to revert commit 6a63b06f3c494cc87eade97f081300bda60acec7 and see if the problem goes away, but this cannot be done without rebuilding the kernel.
Comment 29 Rafael J. Wysocki 2010-01-28 21:00:48 UTC
First-Bad-Commit : 6a63b06f3c494cc87eade97f081300bda60acec7
Comment 30 Tournier Mathieu 2010-02-06 11:00:12 UTC
(In reply to comment #0) > Hi > I'm experiencing this problem on my dell laptop: on first boot temperatures > are > correctly detected, fan starts correctly when temperature goes up. If I > suspend > (to ram) the laptop and then resume, I get zero values by all three thermal > zones (0 °C), and fan never starts, I have to reboot to fix this. > I'm using kernel 2.6.32-rc8 from > http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32-rc8/ , which AFAIK is > kernel vanilla compiled for ubuntu. > I also tried to build kernel with zen patchset (version 2.6.32-rc7) and the > issue is present as well. > > Best Regards > Federico Chiacchiaretta This bug is still present in the trunk (5/02/2010) on a dell xps 1640 It is dangerous because the laptop overheat (the fan never starts after the resume)
Comment 31 Rafael J. Wysocki 2010-02-06 19:30:02 UTC
Can anyone able to reproduce this problem retest with the patch from http://bugzilla.kernel.org/attachment.cgi?id=24904 applied, please?
Comment 32 shinydoofy 2010-02-06 20:20:13 UTC
The patch applied fine with 2.6.32 after changing acpi_ec_query_unlocked to acpi_ec_query in it. Sadly, though, it does not solve the problem for me on a Dell Studio 1537. The fan stays off after resuming although it was running at top speed prior to suspending due to a stress test. Maybe it needs a kernel >.32 to work? Commenting out those two if lines as suggested before, however, does fix it for me.
Comment 33 Rafael J. Wysocki 2010-02-06 20:32:58 UTC
OK, lets try one more thing.
Comment 34 Rafael J. Wysocki 2010-02-06 20:43:14 UTC
Created attachment 24928 [details] Execute _WAK after enabling interrupts during resume Please retest with this patch applied and report back.
Comment 35 shinydoofy 2010-02-06 21:49:51 UTC
Sorry to say so, but having your patches from comments #31 and #34 in either by themselves or both together does not fix it on .32. I can't work with the very latest git tree for now as it's got some firmware issue with my Radeon R600 graphics chip, but that's another issue. However, I came up with a rather hacky "solution", if you will: Change ec_dmi_table in ec.c to check for the BIOS vendor "Dell Inc." instead of "Micro-Star" and drop checking for the chassis vendor and there it goes, the fan starts again after resuming from S3. So maybe adding another butchy hardware vendor to the list isn't the best solution for now, but it "works for me"...
Comment 36 Rafael J. Wysocki 2010-02-06 22:26:23 UTC
If the patches above don't help, I think for now the only thing we can do is to use the DMI information for identifying systems that need the burst mode.
Comment 37 shinydoofy 2010-02-06 22:30:58 UTC
Well then, will you need another set of dmidecode or acidump to distinguish the systems that need burst mode? For now it seems like it's limited to Dell laptops that aren't checked for yet.
Comment 38 Rafael J. Wysocki 2010-02-06 22:34:27 UTC
I'm still not sure about the Lenovo box reported in comment #25. Michał, have you tried to revert commit 6a63b06f3c494cc87eade97f081300bda60acec7 and see if the problem goes away?
Comment 39 Nathaniel Nelson 2010-02-07 03:03:46 UTC
I would also like to report that this exact behavior happens on my Toshiba A505. I will try the patches tonight hopefully and post my findings.
Comment 40 Nathaniel Nelson 2010-02-07 05:42:07 UTC
The patches in comments #31 and #34 do not work for me. I also tried the hack in comment #35 and used "INSYDE" instead of "Dell, Inc" as the vendor and that did not work for me either. A couple of side notes: In addition to the fan, I also lose events for the laptop lid and my touchpad enable/disable button when returning from S3. Oddly enough, if I add 'acpi_osi="Linux"' to my boot line, it will return from S3 ONCE correctly...the fan fires up as normal and all the bells and whistles come back to life. But the fan is dead after resuming from S3 a second time or any time after that. I'll attach my dmidecode.
Comment 41 Nathaniel Nelson 2010-02-07 05:46:44 UTC
Created attachment 24935 [details] Toshiba Satellite A505 dmidecode output Toshiba Satellite A505 dmidecode output
Comment 42 Rafael J. Wysocki 2010-02-07 10:56:05 UTC
Does reverting commit 6a63b06f3c494cc87eade97f081300bda60acec7 help?
Comment 43 Rafael J. Wysocki 2010-02-07 11:01:09 UTC
(In reply to comment #37) > Well then, will you need another set of dmidecode or acidump to distinguish > the > systems that need burst mode? For now it seems like it's limited to Dell > laptops that aren't checked for yet. In bug 14735 there is a Clevo box affectes, so evidently the problem is not limited to MSI and Dell really.
Comment 44 Rafael J. Wysocki 2010-02-07 13:41:53 UTC
However, I'd like to understand why the burst mode actually helps. firstname.lastname@example.org, can you please attach dmesg log generated after suspend/resume with the patch from comment #31, please?
Comment 45 Nathaniel Nelson 2010-02-07 20:49:53 UTC
@Rafael: Unfortunately, reverting the commit 6a63b06f3c494cc87eade97f081300bda60acec7 does not help. I even went back to the 2.6.30 kernel and the problem still exists for me. I can attach dmesg debug stuff if needed.
Comment 46 Rafael J. Wysocki 2010-02-07 21:35:23 UTC
This means the problem is different in your case. Please file a separate bug report and add my address to its CC list. Thanks!
Comment 47 Alessandro Zigliani 2010-02-14 15:12:36 UTC
I have the same problem starting, apparently, from any 2.6.32 versions on gentoo (vanilla, gentoo, tuxonice). I've tried the unmodified kernel version 220.127.116.11. I'm currently using version 2.6.31 that works correctly with suspend and resume, but I need to patch it as described here: http://en.gentoo-wiki.com/wiki/Dell_Studio_1555#ACPI Sorry I'm no kernel developer but if you need something just ask. Regards.
Comment 48 shinydoofy 2010-02-18 17:52:52 UTC
Created attachment 25105 [details] dmesg for suspending on a Dell Studio 1537 Sorry it took so long, but here goes...
Comment 49 Rafael J. Wysocki 2010-02-18 19:51:33 UTC
Thanks! Unfortunately it doesn't give us any new information.
Comment 50 James Ettle 2010-03-01 09:59:00 UTC
I still need comment out the if()s to enable EC burst mode on my Clevo notebook in 2.6.33, is there anything I can test to help?
Comment 51 Alexey Starikovskiy 2010-03-01 10:05:29 UTC
James, Could you please uncomment "#define DEBUG" in drivers/acpi/ec.c, kernel timestamps, and attach dmesg here (or kernel log, if dmesg appears too short)?
Comment 52 Federico Chiacchiaretta 2010-03-01 19:55:02 UTC
Created attachment 25294 [details] dmesg dell 1555 with debug ec.c and timestamps Hi, I'm attaching dmesg with debug for ec.c as requested. This one is for dell studio 1555.
Comment 53 Alexey Starikovskiy 2010-03-01 20:32:28 UTC
Federico, debug output looks quite sane... EC seems to be working... Could you please show the output of "grep . /proc/acpi/battery/*/*'?
Comment 54 Federico Chiacchiaretta 2010-03-01 20:37:39 UTC
Created attachment 25297 [details] output of "grep . /proc/acpi/battery/*/*" Here it is, output of "grep . /proc/acpi/battery/*/*".
Comment 55 Alexey Starikovskiy 2010-03-01 20:44:00 UTC
Output from battery looks fine as well... Could you please show the output of "grep . /proc/acpi/thermal_zone/*/*' too?
Comment 56 Federico Chiacchiaretta 2010-03-01 20:47:33 UTC
Created attachment 25298 [details] output of "grep . /proc/acpi/thermal_zone/*/*" Of course, here it is.
Comment 57 Alexey Starikovskiy 2010-03-01 21:01:36 UTC
Temperatures are not zero. What is the bug again?
Comment 58 Federico Chiacchiaretta 2010-03-01 21:04:32 UTC
Created attachment 25299 [details] output of "grep . /proc/acpi/thermal_zone/*/*" Ops, I'm sorry, I picked up the wrong file. Here the correct one, after suspend and resume.
Comment 59 James Ettle 2010-03-01 22:57:10 UTC
Created attachment 25301 [details] dmesg from 2.6.33 with DEBUG enabled in ec.c (Clevo M720R) (In reply to comment #51) > James, > Could you please uncomment "#define DEBUG" in drivers/acpi/ec.c, kernel > timestamps, and attach dmesg here (or kernel log, if dmesg appears too > short)? Done. [Just as a reminder: mine's the Clevo notebook, of bug 14735. It's trouble is no sleep/lid events unless ec.c is tweaked to enable burst mode. I also see other "anomalies", e.g. broken AC status after suspend/resume, once saw cpufreq stuck in lowest state, screwed up interrupts that caused choppy audio.]
Comment 60 Alexey Starikovskiy 2010-03-01 23:36:53 UTC
Could you please check if last patch in bug #14733 changes anything?
Comment 61 James Ettle 2010-03-02 20:28:08 UTC
(In reply to comment #60) > Could you please check if last patch in bug #14733 changes anything? No, it didn't (applied to clean 2.6.33). Additional observation: something seems to persist across reboots. If I run a working kernel, and then reboot into either an unmodified one or one with the last patch in bug #14733, it works OK, but if I boot it from cold (including having removed the battery), it doesn't work.
Comment 62 Alexey Starikovskiy 2010-03-02 20:37:55 UTC
James, Could you please enable "#define DEBUG" in drivers/acpi/ec.c and timestamps in printk and produce kernel logs for broken and working cases?
Comment 63 James Ettle 2010-03-02 20:50:42 UTC
(In reply to comment #62) > James, > Could you please enable "#define DEBUG" in drivers/acpi/ec.c and timestamps > in > printk and produce kernel logs for broken and working cases? I'm now building a "working" kernel, and will attach output shortly. Attachment 25301 [details] above (comment #59) is a dmesg taken from a broken case without the bug 14733 patch, however there's so much stuff that the bit at the beginning is chopped off --- is that what you need? I'll see if I can get an earlier copy...
Comment 64 James Ettle 2010-03-04 21:04:30 UTC
Created attachment 25359 [details] Full dmesg from unmodified 2.6.33 with DEBUG and timestamps
Comment 65 James Ettle 2010-03-04 21:06:23 UTC
Created attachment 25360 [details] Full dmesg from working 2.6.33 ("if (EC_FLAGS_MSI)" commented out) with DEBUG and timestamps
Comment 66 James Ettle 2010-03-04 21:07:48 UTC
OK, requested logs attached (one enlarged message buffer later ;) ) --- hope these are what you need. Machine was powered down and battery temporarily disconnected between each test.
Comment 67 Islam Motab 2010-03-09 16:09:51 UTC
I am seeing the same problem on a Dell Studio 1555 on debian unstable with 2.6.33-0.slh.9-sidux-amd64 I will try the proposed fix and report back. I think #15425 and #12231 could be possible dupes.
Comment 68 Islam Motab 2010-03-09 18:45:37 UTC
I can confirm that reversing the commit mentioned in #11 allows me to suspend and resume without the laptop overheating.
Comment 69 Maximilian Mehnert 2010-03-10 12:44:47 UTC
*** Bug 15425 has been marked as a duplicate of this bug. ***
Comment 70 Matías Javier Rossi 2010-03-10 20:43:28 UTC
Hi! I was looking around and found the other bug report. I have a Dell Studio 1555 running 2.6.34-rc1 (in Arch Linux) I experience the same issue. Do you need my acpidump, logs or anything? If there is something to test, please let my computer be your bunny!
Comment 71 Alexey Starikovskiy 2010-03-12 15:27:03 UTC
Created attachment 25485 [details] Allow multibyte access to EC please check if this patch makes any difference
Comment 72 Federico Chiacchiaretta 2010-03-12 16:17:24 UTC
It works perfectly here with kernel 2.6.33 + archlinux patchset + allow_multibyte_access_to_EC.patch on a dell studio 1555. Thanks very much Alexey!
Comment 73 shinydoofy 2010-03-12 20:14:40 UTC
It does indeed make a difference, the fan's working again after suspending to RAM. Thanks a bunch!
Comment 74 Rafael J. Wysocki 2010-03-12 21:03:49 UTC
(In reply to comment #71) > Created an attachment (id=25485) [details] > Allow multibyte access to EC Clever. :-) Hopefully it won't break things for anyone.
Comment 75 James Ettle 2010-03-12 22:10:53 UTC
That's a yes from me, too. Lid and sleep button now seem to work OK on the Clevo M720R with the multibyte access patch.
Comment 76 Islam Motab 2010-03-13 13:20:00 UTC
I confirm that the patch fixes this problem. The fan is on and temperature is under control after several suspend and resume cycles. Thank you very much :)
Comment 77 Matías Javier Rossi 2010-03-13 14:51:29 UTC
I tried patching yesterday's git tree and it works perfectly in my Studio 1555. Is this going to hit stable tree soon?
Comment 78 James Ettle 2010-03-14 09:53:28 UTC
Hmm... started to see a few ACPI: EC: GPE storm detected, transactions will use polling mode messages since applying the multibyte patch, didn't see these before with just the naive burst-mode-enable tweak.
Comment 79 Alexey Starikovskiy 2010-03-14 12:52:22 UTC
Could you catch a debug dmesg from around such a point?
Comment 80 Len Brown 2010-03-14 22:24:18 UTC
patch in comment #71 is in the acpi test tree, queued for 2.6.34 same patch will be needed for 2.6.32.stable and 2.6.33.stable
Comment 81 Len Brown 2010-03-15 00:07:03 UTC
patch in commment #71 dropped, pending refresh
Comment 82 Alexey Starikovskiy 2010-03-15 00:31:17 UTC
Created attachment 25517 [details] Allow multibyte access to EC, take #2 allow more than 64 bit access (could be up to 32 bytes or 256 bits).
Comment 83 Len Brown 2010-03-15 01:36:33 UTC
patch in comment #82 added to acpi test tree, pending test results
Comment 84 Alexandre Peixoto Ferreira 2010-03-15 17:14:51 UTC
I confirm that the latest patch (comment #82) solves the suspend/resume problem with my laptop, studio XPS 16. It also seems to solve a lot of other problems that apparently were related to ACPI, like brightness (backlight would turn red, blue, yellow) when powered by battery and brightness was changed and loss of touchpad (serio1 of 8042 was missing the input functions). Thanks for the patch
Comment 85 Islam Motab 2010-03-15 18:07:53 UTC
It seems this patch doesn't apply to latest stable 18.104.22.168 , do I have to apply some other patch from the acpi test tree ?
Comment 86 Rafael J. Wysocki 2010-03-15 19:17:32 UTC
It certainly is possible to rebase the patch on top of 22.214.171.124, but it would be very helpful to us if you tested it on top of 2.6.34-rc1 too.
Comment 87 Alexey Starikovskiy 2010-03-15 21:13:27 UTC
Created attachment 25531 [details] Reviewed patch This is a reviewed patch with Bob and Lin suggestions.
Comment 88 Rafael J. Wysocki 2010-03-15 22:26:42 UTC
That doesn't build on top of current -git. ACPI_ROUND_UP is the problem.
Comment 89 Alexey Starikovskiy 2010-03-15 22:58:36 UTC
Created attachment 25538 [details] Reviewed patch, fixed sorry for the typo...
Comment 90 Islam Motab 2010-03-15 23:30:01 UTC
I am trying to compile 2.6.34-rc1 but it is failing, in the meantime I noticed that the eject key does not work anymore and when I press it dmesg says : "dell-wmi: Unknown key 0 pressed" This might be unrelated, I'll try an older unpatched kernel and see if it is fixed.
Comment 91 Matías Javier Rossi 2010-03-15 23:37:02 UTC
I've tried the eject key and noticed the same issue that Islam. Using 2.6.34-rc1 with the first patch.
Comment 92 Rafael J. Wysocki 2010-03-16 00:17:51 UTC
This most likely is a separate issue, but it would be helpful to verify that. If it turns out to be unrelated, please file a separate bug report for it.
Comment 93 Islam Motab 2010-03-16 02:00:58 UTC
Finally got it to compile. Now running 2.6.34-rc1 with the latest patch in #89 and after several suspend and resume cycles the fan is working and temperature is under control. I tried several older kernels and in none of them the eject key works, so it is unrelated. I'll open a separate bug.
Comment 94 Len Brown 2010-03-17 17:15:49 UTC
patch in acpi tree is now refreshed with patch in comment #89
Comment 95 Federico Chiacchiaretta 2010-03-24 15:46:45 UTC
Would it be possible to rebase the patch on top of 2.6.33.x ? I'd like to file a bug on Archlinux bugtracker for inclusion in next 2.6.33.x release to arch repos. Thank you.
Comment 96 Alessandro Zigliani 2010-04-11 15:51:02 UTC
I've tried the patch at comment 89 on my dell studio 1555 and it doesn't work. I still get 0° thermal zones when resuming with version 2.6.34-rc3. I'm using the gentoo's vanilla-sources package. Since I'm going to do the same with packages directly from kernel.org (just to be sure), which version is this patch supposed to be applied to, exactly?
Comment 97 Len Brown 2010-04-16 19:47:07 UTC
Created attachment 26030 [details] bugzilla-14667-15749.patch The patch in comment #89 shipped in Linux-2.6.34-rc4. However, it caused the regression described bug 15749. So if you are running 2.6.34-rc4, you need the patch in bug 15749. If you are running something older, you need the patch here plus that one, which I've combined into a single patch here. this bug report is closed. bug 15749 will be closed when the 2nd patch goes upstream.
Comment 98 Simon Gebler 2011-03-23 18:54:58 UTC
Found this bug still appears on my Dell Studio 1555, when there's no battery inserted while suspending/resuming. Temeratures are all 0°C and the fan is not working. But everything is fine again, when I insert the battery again - after a few seconds the temperatures and the speed are working again. I'm running the latest Debian-unstable Kernel 2.6.38 - also happened on 2.6.37, found others reporting the same issue on Ubuntu: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/575030/comments/12
Comment 99 Alessandro Zigliani 2011-03-23 21:18:13 UTC
(In reply to comment #98) > Found this bug still appears on my Dell Studio 1555, when there's no battery > inserted while suspending/resuming. > Temeratures are all 0°C and the fan is not working. > But everything is fine again, when I insert the battery again - after a few > seconds the temperatures and the speed are working again. > > I'm running the latest Debian-unstable Kernel 2.6.38 - also happened on > 2.6.37, > found others reporting the same issue on Ubuntu: > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/575030/comments/12 I can confirm this with basically any kernel from 2.6.32 to 2.6.37, except maybe 2.6.33 (I've never deployed that one). I tried this on gentoo with many flavors (vanilla, gentoo, tuxonice) and even some ubuntu. I was waaay too busy to report. Besides, not so many people are worried about keeping batteries inside a notebook all the time, even if that shortens battery life considerably. It's weird because suspend-to-disk has been OK since 2.6.34, as far as I remember. It's "just" suspend-to-ram...
Comment 100 Rafael J. Wysocki 2011-03-23 22:19:29 UTC
Guys, could you not hijack existing bugs for reporting new issues? The "temperature readings are never correct after resume" problem is kind of different from the "temperature readings are not correct after resume if battery is not present while suspending/resuming" one. Please create a new entry for the new issue.