lkml.org 
[lkml]   [2003]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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(&current->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/

    \
     
     \ /
      Last update: 2005-03-22 13:35    [W:0.042 / U:182.096 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site