Most recent kernel where this bug did not occur: ??? Distribution: Gentoo Linux with vanilla-sources-2.6.15.1 Hardware Environment: AMD Athlon 950MHz 512MB RAM, Logitech Optical PS2/USB Mouse on PS2 Problem Description: When I use swsusp for suspend to disk the system suspends normally, but upon resume I get warnings about "scheduling while atomic" (see attachments for details). After that, the mouse driver gets confused, i.e. the cursor jumps wildly on the screen and generates random mouse click events when I move the mouse. I think everything else works fine after resuming. Steps to reproduce: Use swsusp and then resume.
Created attachment 7104 [details] syslog log file of the session This is the /var/log/messages file created by syslog-ng.
Created attachment 7105 [details] lspci -vvv Output of lspci -vvv
Created attachment 7106 [details] hibernate.conf /etc/hibernate/hibernate.conf for hibernate-script-1.12
Created attachment 7107 [details] lsmod lsmod output
Created attachment 7108 [details] .config The config file of the kernel. If more information is needed, feel free to ask... ;-)
This is input subsystem in both cases, AFAICS. Scheduling in atomic happens on something called from PS/2 code.
Pavel, did you make device_resume atomic again?
Please note that it is not only input layer but also IDE... Generally speaking anything upder device_resume() should be allowed to sleep and schedule.
I think it has something to do with the mouse on PS/2. On my laptop the whole thing works fine, as I've just tested now. It has a synaptics touchpad and I've plugged in exactly the same mouse at USB, of course without the USB to PS/2 adapter.
Reply-To: pavel@ucw.cz Can you apply this and see if it triggers? diff --git a/drivers/base/power/resume.c b/drivers/base/power/resume.c index 0a7aa07..d9c9d78 100644 --- a/drivers/base/power/resume.c +++ b/drivers/base/power/resume.c @@ -72,6 +72,7 @@ void dpm_resume(void) void device_resume(void) { + might_sleep(); down(&dpm_sem); dpm_resume(); up(&dpm_sem); diff --git a/drivers/base/power/suspend.c b/drivers/base/power/suspend.c index 5050176..815e2f1 100644 --- a/drivers/base/power/suspend.c +++ b/drivers/base/power/suspend.c @@ -83,6 +83,7 @@ int device_suspend(pm_message_t state) { int error = 0; + might_sleep(); down(&dpm_sem); down(&dpm_list_sem); while (!list_empty(&dpm_active) && error == 0) {
Created attachment 7264 [details] syslog log file of the session with pavel's patch Suspending with pavel's patch.
The mouse kept in sync this time, but I didn't test very long. What I forgot to say (that might help): I tried swsusp with kernel 2.6.14 on the same machine some time ago and I also had the same problem.
Feb 7 11:51:11 athlon950 ACPI: PCI interrupt for device 0000:00:07.2 disabled Feb 7 11:52:11 athlon950 Stopping tasks: 75a>] ps2_sendbyte+0x12a/0x150 Feb 7 11:52:11 athlon950 [<c012e0e0>] autoremove_wake_function+0x0/0x60 Feb 7 11:52:11 athlon950 [<c024da2c>] ps2_command+0xdc/0x340 Feb 7 11:52:11 athlon950 [<c024da01>] ps2_command+0xb1/0x340 ..unfortunately log is truncated at the most interresting place :-(
That must be a problem with your browser (works fine with konqueror). The last line in the logfile is: "Feb 7 11:55:25 athlon950 syslog-ng[6108]: syslog-ng version 1.6.9 going down" But I could send you this log via e-mail if you want.
Reply-To: pavel@ucw.cz > ------- Additional Comments From mrsteven@gmx.de 2006-02-07 03:37 ------- > That must be a problem with your browser (works fine with konqueror). The last > line in the logfile is: > "Feb 7 11:55:25 athlon950 syslog-ng[6108]: syslog-ng version 1.6.9 going down" > > But I could send you this log via e-mail if you want. No, problem is in the middle. Part just after Freezing processes: is missing. Pavel
Created attachment 7265 [details] dmesg of another session with pavel's patch Here's a dmesg output of a session with pavel's patch. As you see, there's not enough space in the dmesg buffer to get all messages.
Does it still happen in 2.6.18-rc1? Dmitry, can you take a look what is going on?
If it still happens with 2.6.18, reopen.
Works perfectly here since months with newer kernels (2.6.18 and up), so I mark this as closed!
Thanks!