From: Andrew Morton <akpm@osdl.org>
To: Pavel Machek <pavel@suse.cz>
Cc: linux-kernel@vger.kernel.org, acpi-support@lists.sourceforge.net,
pavel@suse.cz
Subject: Re: [2.5.75] S3 and S4
Date: Fri, 11 Jul 2003 13:48:33 -0700 [thread overview]
Message-ID: <20030711134833.1adeceb1.akpm@osdl.org> (raw)
In-Reply-To: <20030711200053.GA402@elf.ucw.cz>
Pavel Machek <pavel@suse.cz> wrote:
>
> > Suspending devices
> > Badness in local_bh_enable at kernel/softirq.c:113
> > Call Trace:
> > [<c0130078>] local_bh_enable+0x88/0x90
> > [<f0a44fa4>] e100_do_wol+0x14/0x60 [e100]
> > [<f0a461ee>] e100_suspend+0x3e/0xa0 [e100]
> > [<f0a461b0>] e100_suspend+0x0/0xa0 [e100]
> > [<c0212577>] pci_device_suspend+0x47/0x70
> > [<c029bc99>] device_suspend+0xd9/0x100
> > [<c023e047>] acpi_system_save_state+0x42/0x8c
> > [<c023e153>] acpi_suspend+0x5e/0xb3
> > [<c023e394>] acpi_system_write_sleep+0xe3/0x132
> > [<c0177de0>] filp_open+0x60/0x70
> > [<c017952d>] vfs_write+0xad/0x120
> > [<c017963f>] sys_write+0x3f/0x60
> > [<c010b10f>] syscall_call+0x7/0xb
> >
>
> If e100. You have the hardware...
No, it's acpi_system_save_state() illegally calling device_suspend() under
local_irq_disable().
> > S4 suspends fine, but it seems that it doesn't like preemption on
> > resume:
> >
> > ......[lots of dots]......[nosave c041c000]Enabling SEP on CPU 0
> > Freeing prev allocated pagedir
> > bad: scheduling while atomic!
> > Call Trace:
> > [<c012419e>] schedule+0x6ce/0x6e0
> > [<c02ded7b>] pci_read+0x3b/0x40
> > [<c01358e8>] schedule_timeout+0x88/0xe0
> > [<c02dedbc>] pci_write+0x3c/0x40
> > [<c0135850>] process_timeout+0x0/0x10
> > [<c020f9e4>] pci_set_power_state+0xe4/0x190
> > [<f0a46278>] e100_resume+0x28/0x70 [e100]
> > [<c02125cd>] pci_device_resume+0x2d/0x30
> > [<c029bd76>] device_resume+0xb6/0xd0
> > [<c014e60c>] drivers_resume+0x8c/0xa0
> > [<c014ea15>] do_magic_resume_2+0xc5/0x170
> > [<c011d410>] restore_processor_state+0x70/0x90
> > [<c011ff5f>] do_magic+0x11f/0x140
> > [<c014ef1d>] do_software_suspend+0x6d/0xa0
> > [<c023e3cc>] acpi_system_write_sleep+0x11b/0x132
> > [<c0177de0>] filp_open+0x60/0x70
> > [<c017952d>] vfs_write+0xad/0x120
> > [<c017963f>] sys_write+0x3f/0x60
> > [<c010b10f>] syscall_call+0x7/0xb
>
> That's e100 driver, again. Fix it.
No, e100_resume() looks OK to me. Something seems to have corrupted
preempt_count().
> > Fixing swap signatures... <3>bad: scheduling while atomic!
> > Call Trace:
> > [<c012419e>] schedule+0x6ce/0x6e0
> > [<c02a219d>] generic_make_request+0x17d/0x210
> > [<c01272d0>] autoremove_wake_function+0x0/0x50
> > [<c012641e>] io_schedule+0xe/0x20
> > [<c0150522>] wait_on_page_bit+0xa2/0xd0
> > [<c01272d0>] autoremove_wake_function+0x0/0x50
> > [<c01272d0>] autoremove_wake_function+0x0/0x50
> > [<c017194b>] swap_readpage+0x5b/0x80
> > [<c0171a2a>] rw_swap_page_sync+0xba/0x110
> > [<c014d8be>] mark_swapfiles+0x7e/0x1b0
> > [<c014ea35>] do_magic_resume_2+0xe5/0x170
> > [<c011d410>] restore_processor_state+0x70/0x90
> > [<c011ff5f>] do_magic+0x11f/0x140
> > [<c014ef1d>] do_software_suspend+0x6d/0xa0
> > [<c023e3cc>] acpi_system_write_sleep+0x11b/0x132
> > [<c0177de0>] filp_open+0x60/0x70
> > [<c017952d>] vfs_write+0xad/0x120
> > [<c017963f>] sys_write+0x3f/0x60
> > [<c010b10f>] syscall_call+0x7/0xb
>
> Ahha, this looks like generic problem. I'll probably take a look...
This will have the same cause as the earlier "scheduling while atomic"
problem.
next prev parent reply other threads:[~2003-07-11 20:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-11 19:36 [2.5.75] S3 and S4 Kronos
2003-07-11 20:00 ` Pavel Machek
2003-07-11 20:45 ` Pavel Machek
2003-07-11 20:48 ` Andrew Morton [this message]
2003-07-11 21:52 ` Pavel Machek
2003-07-11 21:53 ` Andrew Morton
2003-07-12 13:54 ` Pavel Machek
2003-07-12 16:45 ` [ACPI-sppt] " Kronos
2003-07-12 20:12 ` Pavel Machek
2003-07-17 19:09 ` Kronos
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030711134833.1adeceb1.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=acpi-support@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.