On Friday 29 May 2009, Jan Scholz wrote: > Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> writes: > > >> We are too late in the cycle to revert this commit and it really is needed to > >> fix a more serious issue. Nevertheless knowing that it caused the problem to > >> appear on your system is also important. > >> > >> Ben, do you have an idea what may be going on here? Does __disable_irq() mask > >> the interrupt on this platform? > > > > I suppose so :-) I'll have to check what's going on, it's not > > immediately clear to me. > > > > Cheers, > > Ben. > > > >> > >> I'd like to see a boot log, preferably containing a suspend-resume in which > >> the problem was reproduced. > > Here is a log from booting, through several suspend cycles, until the > trackpad disappeared. The first few suspends were done while X was > running but from the console. As you can tell from lines like > May 28 23:51:26 [kernel] adb devices: [2]: 2 c4 [3]: 3 1 [7]: 7 1f > the trackpad was still present. The last suspend was done from within X, > here the trackpad did not make it. > May 28 23:58:09 [kernel] adb devices: [2]: 2 c4 [7]: 7 1f > However, there have been cases, although not in this log, were the > trackpad has been alive even when suspending from within X. This means the problem is probably timing-related. Can you please try to comment out suspend_device_irqs() and resume_device_irqs() in drivers/base/power/main.c and see if that changes anything? It's not entirely safe (well, that's why the calls are there after all), but hopefully the box won't hang during this test. Best, Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
