gmane.linux.power-management.general

Re: 2.6.28-rc7-git2: Reported regressions from 2.6.27

James Bottomley — 2008-12-04T00:17:21

Fixed by this patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9728c0814ecb505546696a659858fdb761375544 James

2.6.28-rc7-git2: Reported regressions from 2.6.27

Rafael J. Wysocki — 2008-12-03T21:49:35

[NOTES: * Sorry for the delayed report. Recently, I've been distracted by a number of regressions on one of my test boxes. * I haven't managed to follow all of the linked threads this time in search for fixes, so if you know of any patches fixing the listed bugs, please let me know.] This message contains a list of some regressions from 2.6.27, for which there are no fixes in the mainline I know of. If any of them have been fixed already, please let me know. If you know of any other unresolved regressions from 2.6.27, please let me know either and I'll add them to the list. Also, please let me know if any of the entries below are invalid. Each entry from the list will be sent additionally in an automatic reply to this message with CCs to the people involved in reporting and handling the issue. Listed regressions statistics: Date Total Pending Unresolved ---------------------------------------- 2008-12-04 106 29 21 2008-11-22 93 25

Re: Oops during hibernation under 2.6.28-rc6

Rafael J. Wysocki — 2008-12-03T22:05:25

Hi, Does it happen with 2.6.26(.y)? Rafael

Oops during hibernation under 2.6.28-rc6

Ferenc Wagner — 2008-12-02T17:21:23

Hi, swsusp usually works on my ThinkPad R50e. However sometimes it oopses instead of hibernating the machine. I can't provide real statistics as I haven't been using it for long (just about a month), but it also happened under 2.6.27. Last time in happened under 2.6.28-rc6. After two unsuccessful attempts (not enough free swap), I closed Emacs and Firefox, retried, and got the oops. I could scroll the console back, and did two screenshots, find them under http://apt.niif.hu/susp/. I'm not sure what other data may be useful for debugging, please ask.

Re: [Suspend-devel] TAP (and TUN?) devices not workingafter resume

James Le Cuirot — 2008-11-29T10:18:49

On Thu, 24 Jul 2008 20:50:32 -0700 Max Krasnyansky qualcomm.com> wrote: Sorry about the crazy delay here, I didn't need to use QEMU for ages and I don't like firing up Windows unless I have too. :D I'm not sure about 2.6.26 but this appears to be fixed in 2.6.27. Thanks, James

Re: [ath5k-devel] Bugs on aspire one A150

Maxim Levitsky — 2008-12-01T15:33:15

Hi, Any update on that? Best regards, Maxim Levitsky

Re: [PATCH 1/1] Hibernate: Take overlapping zones intoaccount (rev. 2)

Rafael J. Wysocki — 2008-11-26T23:11:47

Thanks a lot Len! Rafael

Re: [PATCH 1/1] Hibernate: Take overlapping zones intoaccount (rev. 2)

Len Brown — 2008-11-26T23:04:26

done. previous version has been replaced with this version. also, suspend branch is now rebased to latest linus top of tree. thanks, -Len

Re: [RFC] Tying sysfs "wakeup" file toplatform-level?handler

Alan Stern — 2008-11-25T21:07:47

On a standard laptop the WLAN interface would be a PCI device, so it could use the standard PCI wakeup method (PME#). Or the motherboard manufacturer could use vendor-specific signalling. But you're not likely to find an onboard WLAN interface communicating with the CPU via USB. In this particular case, can't you set it up so that the EC always pays attention to the WLAN's GPIO line, but the WLAN interface enables the GPIO for wakeup signalling only if power/wakeup is set? It sounds like the same sort of problem: a device on a different bus that has to talk to the platform's EC. Alan Stern

Re: [RFC] Tying sysfs "wakeup" filetoplatform-level?handler

Deepak Saxena — 2008-11-25T20:38:37

On Nov 25 2008, at 15:18, Alan Stern was caught saying: I'm going to throw a patch togethre and post it here and on lkml for vetting and we can go from there. I think in that case we couldn't really do WOL. I imagine this is the case on a standard laptop too. On future XO versions, we may move to an SDIO based card and we will have to deal with the same situation where the SDIO stack has a concept of wake up on card insert/remove but we will need to route the WOL signal from the card to the EC. ~Deepak

Re: [RFC] Tying sysfs "wakeup" file toplatform-level?handler

Alan Stern — 2008-11-25T20:18:29

It's a difficult problem. You've essentially got a platform device on the USB bus. I'm not sure... This sort of thing isn't something I've had to deal with before. Suppose the same sort of WLAN interface was packaged as an independent, external USB device and one of them was plugged into an OLPC. Then how would you know which device was the one attached to the embedded controller and which was external? That's understandable. Alan Stern

Re: [RFC] Tying sysfs "wakeup" filetoplatform-level?handler

Deepak Saxena — 2008-11-25T19:19:29

On Nov 25 2008, at 13:57, Alan Stern was caught saying: The sideband signal is a gpio. The driver knows that the GPIO exists, but it does not know that it anything about it is routed on the board IMHO it should not. Agreed, and there are several ways to do this: One is to do wrap code around #ifdef and if(machine_is_olpc()) to make a call to an OLPC-specific call. The other is to add a generic platform wakeup hook mechanism such as either my original proposal or adding a set_wakeup() to struct device itself. Another option is to have a single platform_set_wakeup() pointer similar to the platform_notify() and platform_notify_remove(). Note that in the OLPC tree we have some #ifdef OLPC in the wifi driver but those are not upstream and I'm going to work on removing them. I would prefer not to add anymore. ~Deepak

Re: [RFC] Tying sysfs "wakeup" file toplatform-level?handler

Alan Stern — 2008-11-25T18:57:17

It depends on the hardware and the driver. Is this a specialized sort of USB WLAN device with features specific to the XO? How is the sideband wakeup signal implemented? Does the driver know that it is running on an XO? Does the driver know that this sideband signal exists? The easiest answer is for the driver to call directly into the platform code. Alan Stern

Re: [RFC] Tying sysfs "wakeup" filetoplatform-level?handler

Deepak Saxena — 2008-11-25T18:07:44

On Nov 25 2008, at 10:09, Alan Stern was caught saying: What is the method to connect between the driver's WOL code and the platform code in this situation? tnx, ~Deepak

Re: [RFC] Tying sysfs "wakeup" file toplatform-level?handler

Alan Stern — 2008-11-25T15:09:14

No, don't do that. If the device has a sideband wakeup signal then the device's driver should be aware of that signal. So the driver should be modified, not the device core. The driver can ask the platform code to do whatever is necessary. Alan Stern

Re: [RFC] Tying sysfs "wakeup" filetoplatform-level?handler

Deepak Saxena — 2008-11-25T04:23:11

On Nov 24 2008, at 18:08, Alan Stern was caught saying: Just thought of something. Not all the devices we can wakeup on are platform devices. The WLAN specifically is an on-board USB device with a sideband wakeup signal connected to the EC. So instead I'll make the set_wakeup() ptr a member of struct device and call it in device_suspend(). ~Deepak

Re: [RFC] Tying sysfs "wakeup" filetoplatform-level?handler

Deepak Saxena — 2008-11-25T03:26:06

On Nov 24 2008, at 18:08, Alan Stern was caught saying: Correct. Most embedded platforms are fairly static and don't need the complexity of ACPI. This sounds good. I think I can get away with doing this w/o having to touch shared drivers such as i8042. ~Deepak

Re: [RFC] Tying sysfs "wakeup" file toplatform-level?handler

Alan Stern — 2008-11-24T23:08:39

ACPI may not be such a good model after all. It's very table-driven, with its own little interpreter (or not so little!), whereas most platforms have a pretty good idea beforehand of what devices can exist, and they are described as static data. Right? So the platform code could initialize the "can_wakeup" setting when it first detects and registers the device. And you could add a "set_wakeup" function pointer to struct platform_device, which the bus-level suspend and resume routines would invoke to enable or disable remote wakeup, as appropriate. In the static structures these function pointers would point to routines that set or clear the appropriate bits in your Embedded Controller. I think this is the right way to go... Alan Stern

Re: [RFC] Tying sysfs "wakeup" filetoplatform-level?handler

Deepak Saxena — 2008-11-24T22:32:58

On Nov 24 2008, at 23:19, Rafael J. Wysocki was caught saying: Yep. i8042, lid, power button, battery state change, WOL. I think I can do something similar to what ACPI is doing by trapping the device registration. ~Deepak

Re: [RFC] Tying sysfs "wakeup" file toplatform-levelhandler

Deepak Saxena — 2008-11-24T22:29:00

On Nov 24 2008, at 17:14, Alan Stern was caught saying: ACPI hides a lot of the EC magic from us, but it looks like it uses the platform_notify() and platform_remove_notify() handlers to track what devices are added to the system. I think I can make use of the same to set dev->wakeup_capable for the devices I care about, store the pointers to those devices, and then configure the EC bits as needed when we suspend by looking at the result of device_may_wakeup(). I might not need a callback afterall. Thanks, ~Deepak

Re: [RFC] Tying sysfs "wakeup" file to platform-levelhandler

Rafael J. Wysocki — 2008-11-24T22:19:14

For PCI we set the can_wakeup flag during the initialization of devices. For some other devices, ACPI BIOS contains information telling us whether they are capable of waking the system up and the ACPI code sets that flag for them on this basis. Does your platform know which devices can wake up? Rafael