From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760842AbYHUSHs (ORCPT ); Thu, 21 Aug 2008 14:07:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1760515AbYHUSGs (ORCPT ); Thu, 21 Aug 2008 14:06:48 -0400 Received: from ogre.sisk.pl ([217.79.144.158]:39118 "EHLO ogre.sisk.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760603AbYHUSGr (ORCPT ); Thu, 21 Aug 2008 14:06:47 -0400 From: "Rafael J. Wysocki" To: "Vegard Nossum" Subject: Re: latest -git: suspend: unable to handle kernel paging request (was Re: no_console_suspend doesn't work?) Date: Thu, 21 Aug 2008 20:10:05 +0200 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) Cc: "Linux Kernel Mailing List" References: <19f34abd0808211028w7889587fke523ff244339e7c5@mail.gmail.com> In-Reply-To: <19f34abd0808211028w7889587fke523ff244339e7c5@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808212010.06043.rjw@sisk.pl> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday, 21 of August 2008, Vegard Nossum wrote: > On Thu, Aug 21, 2008 at 6:49 PM, Vegard Nossum wrote: > > But I think it would be a lot more useful to see _everything_. Why > > doesn't output to ttyS0 work? It works with tty0... I have tried > > various combinations (leaving out console=tty0, leaving out > > earlyprintk, using netconsole, kexec crashdump), but nothing seems to > > be able to help. Do you have any suggestions? > > I did it! > > With a little debug patch, I got the oops to ttyS0, What exactly did you do to achieve that? > but with each printk() duplicated (I removed some of them). This is from resume: > > BUG: unable to handle kernel BUG: unable to handle kernel paging > requestpaging request at 00200200 > at 00200200 > IP:IP: [] list_del+0xc/0x90 > [] list_del+0xc/0x90 > *pdpt = 00000000331a0001 *pde = 0000000000000000 > Oops: 0000 [#1] Oops: 0000 [#1] PREEMPT PREEMPT SMP SMP > DEBUG_PAGEALLOCDEBUG_PAGEALLOC > Pid: 3473, comm: bash Not tainted (2.6.27-rc4-00003-ga798564-dirty #30) > EIP: 0060:[] EFLAGS: 00210082 CPU: 0 > EIP is at list_del+0xc/0x90 > EAX: 00200200 EBX: f77fcc00 ECX: 00000001 EDX: f31a6000 > ESI: c088e814 EDI: c088e83c EBP: f31a7be8 ESP: f31a7bd0 > DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 > Process bash (pid: 3473, ti=f31a6000 task=f30ea700 task.ti=f31a6000) > Stack: Stack: 00000000 00000000 00000002 00000002 00000000 00000000 > c01b39be c01b39be f77cefa0 f77cefa0 f77fcbd0 f77fcbd0 f31a7bfc > f31a7bfc c01b39ef c01b39ef > f77cefa0 f77cefa0 00000000 00000000 c1133598 c1133598 > f31a7c3c f31a7c3c c01b3ebc c01b3ebc c0b530c0 c0b530c0 f31a7c18 > f31a7c18 c015b60e c015b60e > f31a7c18 f31a7c18 ffffffff ffffffff 00000020 00000020 > c088e800 c088e800 00200046 00200046 00000000 00000000 00000000 > 00000000 00000000 00000000 > Call Trace: > [] [] ? ? get_partial_node+0x3e/0xc0 > [] [] ? ? get_partial_node+0x6f/0xc0 > [] [] ? ? __slab_alloc+0x11c/0x4e0 > [] [] ? ? get_lock_stats+0x1e/0x50 > [] [] ? ? __kmalloc+0x11c/0x130 > [] [] ? ? tty_buffer_request_room+0xe2/0x130 > [] [] ? ? tty_buffer_request_room+0xe2/0x130 > [] [] ? ? tty_buffer_request_room+0xe2/0x130 > [] [] ? ? tty_insert_flip_string_flags+0x2d/0xa0 > [] [] ? ? receive_chars+0x161/0x290 > [] [] ? ? serial8250_interrupt+0x134/0x150 > [] [] ? ? handle_IRQ_event+0x28/0x70 > [] [] ? ? handle_edge_irq+0xaf/0x140 > [] [] ? ? do_IRQ+0x48/0xa0 > [] [] ? ? trace_hardirqs_off_thunk+0xc/0x18 > [] [] ? ? common_interrupt+0x28/0x30 > [] [] ? ? vprintk+0x151/0x3c0 > [] [] ? ? trace_hardirqs_on_caller+0xd4/0x160 > [] [] ? ? trace_hardirqs_on+0xb/0x10 > [] [] ? ? _spin_unlock_irqrestore+0x43/0x70 > [] [] ? ? pci_bus_read_config_byte+0x5b/0x70 > [] [] ? ? printk+0x1b/0x20 > [] [] ? ? pcibios_set_master+0x68/0xa0 > [] [] ? ? pci_set_master+0x54/0x60 > [] [] ? ? usb_hcd_pci_resume+0x4c/0xf0 > [] [] ? ? trace_hardirqs_on+0xb/0x10 > [] [] ? ? pci_legacy_resume+0x16/0x30 > [] [] ? ? pci_pm_restore+0x4a/0x60 > [] [] ? ? pm_op+0x115/0x130 > [] [] ? ? device_resume+0xd6/0x380 > [] [] ? ? hibernation_snapshot+0xa1/0x220 > [] [] ? ? printk+0x1b/0x20 > [] [] ? ? hibernate+0xe0/0x180 > [] [] ? ? state_store+0x0/0xd0 > [] [] ? ? state_store+0xbf/0xd0 > [] [] ? ? state_store+0x0/0xd0 > [] [] ? ? kobj_attr_store+0x24/0x30 > [] [] ? ? sysfs_write_file+0xa2/0x100 > [] [] ? ? vfs_write+0x96/0x130 > [] [] ? ? sysfs_write_file+0x0/0x100 > [] [] ? ? sys_write+0x3d/0x70 > [] [] ? ? sysenter_do_call+0x12/0x3f > ======================= > Code: Code: e8 e8 01 01 89 89 44 44 24 24 04 04 e8 e8 94 94 08 08 db > db ff ff 8b 8b 55 55 04 04 b8 b8 80 80 45 45 7a 7a c0 c0 e8 e8 e7 e7 > c2 c2 dd dd ff ff e8 e8 > a2 a2 c7 c7 d7 d7 ff ff eb eb a9 a9 55 55 89 89 e5 e5 53 53 89 89 c3 > c3 83 83 ec ec 14 14 8b 8b 40 40 04 04 <8b> <8b> 00 00 39 39 d8 d8 75 > 75 24 24 8b 8b 13 13 > 8b 8b 42 42 04 04 39 39 d8 d8 75 75 41 41 8b 8b 43 43 04 04 89 89 42 42 04 04 > EIP: [] EIP: [] list_del+0xc/0x90list_del+0xc/0x90 > SS:ESP 0068:f31a7bd0 > Kernel panic - not syncing: Fatal exception in interrupt > > The EIP corresponds to the first line of list_del, lib/list_debug.c:46: > > void list_del(struct list_head *entry) > { > WARN(entry->prev->next != entry, > > I actually have one theory: Data arrives on the serial port at the > wrong moment, so interrupt happens before everything is > restored/resumed. You can see the interrupt in the stack trace. Does > this seem possible? To me, it does, but the question is if that's not caused by the serial console itself ... Thanks, Rafael