Messages in this thread | | | Date | Mon, 19 May 2003 17:13:12 +0200 | From | Alex Riesen <> | Subject | Re: 2.5.69+bk: oops in apmd after waking up from suspend mode |
| |
Alex Riesen, Mon, May 19, 2003 16:41:30 +0200: > Alex Riesen, Mon, May 19, 2003 14:31:19 +0200: > > > >EIP is at fix_processor_context+0x5f/0x100 > > > >Process kapmd (pid: 4, threadinfo=c5f0e000 task=c5fbc640) > > > > > > After receiving Alex' .config and gcc version (3.2.3), I've been > > > able to decipher this. current->mm is NULL in the kapmd task. The call > > > > > > load_LDT(¤t->mm->context); /* This does lldt */ > > > > > > in fix_processor_context() computes the address of context as > > > (current->mm)+0x7c, which is 0x7c. load_LDT_nolock() dereferences > > > 0x7c+0x14 (void *segments = pc->ldt) and the oops follows. > > > > > > As to _why_ kapmd's current->mm is NULL, I don't know. It isn't > > > when I test APM suspend in 2.5.69-bk. A lot of code dereferences > > > current->mm without checking, so I guess current->mm==NULL is a bug. > > > > > > > i just go and try it with the latest -bk. > > > > no change. Still oopses. > > Is it safe to trace this path with printks? I'm about to put them in, > but a good advice could probably come before the compilation finishes. >
current->mm is NULL even before save_processor_state.
The unlucky wakeup afterwards made the system unstable:
Unable to handle kernel NULL pointer dereference at virtual address 000003ff printing eip: c0180015 *pde = 00000000 Oops: 0002 [#2] CPU: 0 EIP: 0060:[<c0180015>] Not tainted EFLAGS: 00010297 EIP is at ext3_get_inode_loc+0xf5/0x180 eax: 000003ff ebx: 00000300 ecx: c5ae8604 edx: c12ee9a0 esi: c5ebb200 edi: 00000260 ebp: c5af1c90 esp: c5af1c78 ds: 007b es: 007b ss: 0068 Process syslogd (pid: 171, threadinfo=c5af0000 task=c5bf38c0) Stack: 00000016 00000013 00026007 00000000 c58cc3c4 c5af1cc4 c5af1cb0 c0180b1d c5ae8604 c5af1cc3 c5af1cc4 c5af1cc4 c5ae8604 c58cc3c4 c5af1ce0 c0180bba c58cc3c4 c5ae8604 c5af1cc4 c5af1ce0 c018ab09 c5ee1a80 c58cc3c4 c58cc3c4 Call Trace: [<c0180b1d>] ext3_reserve_inode_write+0x1d/0xa0 [<c0180bba>] ext3_mark_inode_dirty+0x1a/0x40 [<c018ab09>] journal_start+0x89/0xb0 [<c0180c97>] ext3_dirty_inode+0xb7/0xc0 [<c01688a7>] __mark_inode_dirty+0xf7/0x100 [<c0162e78>] inode_update_time+0x68/0xa0 [<c0132567>] generic_file_aio_write_nolock+0x207/0xac0 [<c020573b>] __kfree_skb+0x7b/0xf0 [<c0252841>] unix_dgram_recvmsg+0x141/0x1f0 [<c0132e8d>] generic_file_write_nolock+0x6d/0x90 [<c0203333>] sys_recvfrom+0x83/0xe0 [<c0130b4d>] unlock_page+0xd/0x50 [<c013d023>] do_wp_page+0x3c3/0x420 [<c015bc2a>] poll_freewait+0x3a/0x50 [<c013307d>] generic_file_writev+0x3d/0x60 [<c014aeb3>] do_readv_writev+0x143/0x270 [<c014aa10>] do_sync_write+0x0/0xb0 [<c014b07b>] vfs_writev+0x4b/0x50 [<c014b0fe>] sys_writev+0x2e/0x50 [<c0109187>] syscall_call+0x7/0xb
Code: 89 10 8b 4a 18 01 cb 89 58 04 8b 55 ec 89 50 08 31 c0 e9 58
and some more, more or less like that. This was the first.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |